[PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Gerrit Renker]

[DCCP]: Fix bug in calculation of first t_nom and first t_ipi

Problem:
--------
 Currently the inter-packet-interval for the first packet is set to 500msec instead
 of the 1 second specified in RFC 3448 (detailed derivation below).
 Furthermore, the code is complicated, since t_ipi is, in fact, added twice to t_0 = t_now.

Solution:
---------
 This patch
	* sets the initial value of t_ipi to 1 second, as per RFC 3448
	* simplifies the initial setting of t_ipi and t_delta through a case analysis


Detailed Derivation:
--------------------
 When the first CCID 3 packet is sent in ccid3_hc_tx_send_packet, t_ipi is set to 

		hctx->ccid3hctx_t_ipi = TFRC_INITIAL_IPI;

 which is USEC_PER_SEC / 4 = 250 msec. This is then added twice to t_0, due to:

	case TFRC_SSTATE_NO_SENT:
		// ...
		/* Set nominal send time for initial packet */
		hctx->ccid3hctx_t_nom = now;
		timeval_add_usecs(&hctx->ccid3hctx_t_nom, hctx->ccid3hctx_t_ipi);
		rc = 0;
		break;
	// ...		
	/* Can we send? if so add options and add to packet history */
	if (rc = 0) {
		// ...
		timeval_add_usecs(&hctx->ccid3hctx_t_nom, hctx->ccid3hctx_t_ipi);
	}

 As a result, t_1 = t_0 + t_ipi = t_now + t_ipi 
                  = t_0 + 500msec

 This contradicts RFC 3448, due to the following requirements:

  a) Section 4.2, "Sender Initialization"
     "the value of X[/s] is set to 1 packet/second [...] The
      initial values for R (RTT) and t_RTO are undefined"

  b) Section 4.5, "Preventing Oscillations
     R_sqmean is undefined since R is undefined
     Therefore, X_init = X

  c) Section 4.6, "Scheduling of Packet Transmissions"
     
     t_ipi = X_init / s = 1 second

 A further simplification is possible for the initial `delta' value, which is
 defined in [RFC 3448, section 4.6] as

 	t_delta = min(t_ipi/2, t_gran/2)

 t_gran/2 here is TFRC_OPSYS_HALF_TIME_GRAN = USEC_PER_SEC / (2 * HZ).
 Since Linux always schedules with a higher granularity than 1 second, 
 the initial value of t_delta is thus simply 
	
 	t_delta = min(USEC_PER_SEC / 2 , USEC_PER_SEC / (2 * HZ))
 	        =  USEC_PER_SEC / (2 * HZ)

 Lastly, TFRC_INITIAL_IPI is not referenced anywhere else and can thus be removed.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
 net/dccp/ccids/ccid3.c |   10 +++++-----
 net/dccp/ccids/ccid3.h |    2 --
 2 files changed, 5 insertions(+), 7 deletions(-)

--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -298,13 +298,13 @@ static int ccid3_hc_tx_send_packet(struc
 		hctx->ccid3hctx_last_win_count	 = 0;
 		hctx->ccid3hctx_t_last_win_count = now;
 		ccid3_hc_tx_set_state(sk, TFRC_SSTATE_NO_FBACK);
-		hctx->ccid3hctx_t_ipi = TFRC_INITIAL_IPI;
+		/* First timeout, according to [RFC 3448, 4.2], is 1 second */
+		hctx->ccid3hctx_t_ipi = USEC_PER_SEC;
+		/* Initial delta: minimum of 0.5 sec and t_gran/2 */
+		hctx->ccid3hctx_delta = TFRC_OPSYS_HALF_TIME_GRAN;
 
-		/* Set nominal send time for initial packet */
+		/* Set t_0 for initial packet */
 		hctx->ccid3hctx_t_nom = now;
-		timeval_add_usecs(&hctx->ccid3hctx_t_nom,
-				  hctx->ccid3hctx_t_ipi);
-		ccid3_calc_new_delta(hctx);
 		rc = 0;
 		break;
 	case TFRC_SSTATE_NO_FBACK:
--- a/net/dccp/ccids/ccid3.h
+++ b/net/dccp/ccids/ccid3.h
@@ -49,8 +49,6 @@
 /* Two seconds as per CCID3 spec */
 #define TFRC_INITIAL_TIMEOUT	   (2 * USEC_PER_SEC)
 
-#define TFRC_INITIAL_IPI	   (USEC_PER_SEC / 4)
-
 /* In usecs - half the scheduling granularity as per RFC3448 4.6 */
 #define TFRC_OPSYS_HALF_TIME_GRAN  (USEC_PER_SEC / (2 * HZ))
 

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Ian McDonald]

Looks good in theory. Will check some more. Have you double checked
against RFC4342 as that overrides parts of RFC 3448 (see section 5 in
particular)?

Ian

On 11/22/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> [DCCP]: Fix bug in calculation of first t_nom and first t_ipi
>
> Problem:
> --------
>  Currently the inter-packet-interval for the first packet is set to 500msec instead
>  of the 1 second specified in RFC 3448 (detailed derivation below).
>  Furthermore, the code is complicated, since t_ipi is, in fact, added twice to t_0 = t_now.
>
> Solution:
> ---------
>  This patch
>         * sets the initial value of t_ipi to 1 second, as per RFC 3448
>         * simplifies the initial setting of t_ipi and t_delta through a case analysis
>
>
> Detailed Derivation:
> --------------------
>  When the first CCID 3 packet is sent in ccid3_hc_tx_send_packet, t_ipi is set to
>
>                 hctx->ccid3hctx_t_ipi = TFRC_INITIAL_IPI;
>
>  which is USEC_PER_SEC / 4 = 250 msec. This is then added twice to t_0, due to:
>
>         case TFRC_SSTATE_NO_SENT:
>                 // ...
>                 /* Set nominal send time for initial packet */
>                 hctx->ccid3hctx_t_nom = now;
>                 timeval_add_usecs(&hctx->ccid3hctx_t_nom, hctx->ccid3hctx_t_ipi);
>                 rc = 0;
>                 break;
>         // ...
>         /* Can we send? if so add options and add to packet history */
>         if (rc = 0) {
>                 // ...
>                 timeval_add_usecs(&hctx->ccid3hctx_t_nom, hctx->ccid3hctx_t_ipi);
>         }
>
>  As a result, t_1 = t_0 + t_ipi = t_now + t_ipi
>                   = t_0 + 500msec
>
>  This contradicts RFC 3448, due to the following requirements:
>
>   a) Section 4.2, "Sender Initialization"
>      "the value of X[/s] is set to 1 packet/second [...] The
>       initial values for R (RTT) and t_RTO are undefined"
>
>   b) Section 4.5, "Preventing Oscillations
>      R_sqmean is undefined since R is undefined
>      Therefore, X_init = X
>
>   c) Section 4.6, "Scheduling of Packet Transmissions"
>
>      t_ipi = X_init / s = 1 second
>
>  A further simplification is possible for the initial `delta' value, which is
>  defined in [RFC 3448, section 4.6] as
>
>         t_delta = min(t_ipi/2, t_gran/2)
>
>  t_gran/2 here is TFRC_OPSYS_HALF_TIME_GRAN = USEC_PER_SEC / (2 * HZ).
>  Since Linux always schedules with a higher granularity than 1 second,
>  the initial value of t_delta is thus simply
>
>         t_delta = min(USEC_PER_SEC / 2 , USEC_PER_SEC / (2 * HZ))
>                 =  USEC_PER_SEC / (2 * HZ)
>
>  Lastly, TFRC_INITIAL_IPI is not referenced anywhere else and can thus be removed.
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>

-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Ian McDonald]

>   However, I think your point is valid and we should add a ToDo for that section
>   of code which re-adjusts the sending rate after the first feedback packet has arrived.
>
Thanks for checking this and I agree with your conclusions.

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Arnaldo Carvalho de Melo]

On 11/22/06, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> >   However, I think your point is valid and we should add a ToDo for that section
> >   of code which re-adjusts the sending rate after the first feedback packet has arrived.
> >
> Thanks for checking this and I agree with your conclusions.

Can you please provide a Signed-off-by for this one?

- Arnaldo

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Ian McDonald]

On 11/26/06, Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> On 11/22/06, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> > >   However, I think your point is valid and we should add a ToDo for that section
> > >   of code which re-adjusts the sending rate after the first feedback packet has arrived.
> > >
> > Thanks for checking this and I agree with your conclusions.
>
> Can you please provide a Signed-off-by for this one?
>
> - Arnaldo
>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>

-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Arnaldo Carvalho de Melo]

On 11/26/06, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> On 11/26/06, Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > On 11/22/06, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> > > >   However, I think your point is valid and we should add a ToDo for that section
> > > >   of code which re-adjusts the sending rate after the first feedback packet has arrived.
> > > >
> > > Thanks for checking this and I agree with your conclusions.
> >
> > Can you please provide a Signed-off-by for this one?
> >
> > - Arnaldo
> >
> Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>

Thanks, I'm now going over the latest the_whole_lot [1], looking for
patches were discussion already happened, harvesting Signed-off-by
lines in the lists.

Regards,

- Arnaldo

[1] http://www.erg.abdn.ac.uk/users/gerrit/dccp/patch-backlog/the_whole_lot.tar.gz

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first

[Eddie Kohler]

Hi Gerrit, Ian,

I am not sure I am completely following this discussion, but there is one 
point I wanted to bring up.  DCCP senders DO have an estimate of the 
round-trip time even BEFORE the first feedback packet, namely from the 
Request-Response exchange.  RFC 4342 senders and receivers can use the RTT 
measured by the core DCCP protocol.  Reading over RFC 4342, this is extremely 
not clear (sorry), but it was our intention.  (Sally, this is right, yes?)  We 
will put together an erratum for the RFC Editor.

Eddie


Gerrit Renker wrote:
> Quoting Ian McDonald:
> |  Looks good in theory. Will check some more. Have you double checked
> |  against RFC4342 as that overrides parts of RFC 3448 (see section 5 in
> |  particular)?
> You are right to raise this, thank you.
> 
> I have checked the patch against both RFC 3448 and 4342: what this patch does is fully
> standards-compliant; I copy the relevant references below.
> 
>   1) [RFC 3448, 4.2] emphasizes that the values of R (RTT) and t_RTO are undefined
>      until the first feedback packet arrives.
> 
>   2) The relevant section of RFC 4342 is on page 6:
> 
>      "[RFC3448], Section 4, specifies an initial sending rate of one packet
>       per round-trip time (RTT) as follows: The sender initializes the
>       allowed sending rate to one packet per second.As soon as a feedback
>       packet is received from the receiver, the sender has a measurement of
>       the round-trip time and then sets the initial allowed sending rate to
>       one packet per RTT."
> 
>      It then goes on and changes the RFC 3448 recommendation of an initial sending rate
>      of 1 packet per RTT to 2..4 packets per RTT depending on the packet size.
> 
>     => These are all issues which are not applicable until the first feedback has arrived.
> 
>   3) Further below, on [RFC 4342, page 7] we have the following clarification:
> 
>      "If the sender never receives a feedback packet from the receiver, and
>       as a consequence never gets to set the allowed sending rate to one
>       packet per RTT, then the sending rate is left at its initial rate of
>       one packet per second, [...]"
> 
> 
> Conclusion
> ----------
>   The relevant parts of RFC 4342 which override RFC 3448 are of no concern for this patch,
>   since these are not applicable until the first feedback packet has arrived. As a consequence,
>   this patch fully conforms to both RFC 3448 (as presented in detail below) and RFC 4342. 
>   The patch submission therefore stands as before.
> 
>   However, I think your point is valid and we should add a ToDo for that section
>   of code which re-adjusts the sending rate after the first feedback packet has arrived. 
>    
> Thank you
> Gerrit  
> 
> |  
> |  On 11/22/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> |  > [DCCP]: Fix bug in calculation of first t_nom and first t_ipi
> |  >
> |  > Problem:
> |  > --------
> |  >  Currently the inter-packet-interval for the first packet is set to 500msec instead
> |  >  of the 1 second specified in RFC 3448 (detailed derivation below).
> |  >  Furthermore t_ipi is added twice to t_now instead of just once.
> |  >
> |  > Solution:
> |  > ---------
> |  >  This patch
> |  >         * sets the initial value of t_ipi to 1 second, as per RFC 3448
> |  >         * simplifies the initial setting of t_ipi and t_delta through a case analysis
> |  >
> |  >
> |  > Detailed Derivation:
> |  > --------------------
> |  >  When the first CCID 3 packet is sent in ccid3_hc_tx_send_packet, t_ipi is set to
> |  >
> |  >                 hctx->ccid3hctx_t_ipi = TFRC_INITIAL_IPI;
> |  >
> |  >  which is USEC_PER_SEC / 4 = 250 msec. This is then added twice to t_0, due to:
> |  >
> |  >         case TFRC_SSTATE_NO_SENT:
> |  >                 // ...
> |  >                 /* Set nominal send time for initial packet */
> |  >                 hctx->ccid3hctx_t_nom = now;
> |  >                 timeval_add_usecs(&hctx->ccid3hctx_t_nom, hctx->ccid3hctx_t_ipi);
> |  >                 rc = 0;
> |  >                 break;
> |  >         // ...
> |  >         /* Can we send? if so add options and add to packet history */
> |  >         if (rc = 0) {
> |  >                 // ...
> |  >                 timeval_add_usecs(&hctx->ccid3hctx_t_nom, hctx->ccid3hctx_t_ipi);
> |  >         }
> |  >
> |  >  As a result, t_1 = t_0 + t_ipi = t_now + t_ipi
> |  >                   = t_0 + 500msec
> |  >
> |  >  This contradicts RFC 3448, due to the following requirements:
> |  >
> |  >   a) Section 4.2, "Sender Initialization"
> |  >      "the value of X[/s] is set to 1 packet/second [...] The
> |  >       initial values for R (RTT) and t_RTO are undefined"
> |  >
> |  >   b) Section 4.5, "Preventing Oscillations
> |  >      R_sqmean is undefined since R is undefined
> |  >      Therefore, X_init = X
> |  >
> |  >   c) Section 4.6, "Scheduling of Packet Transmissions"
> |  >
> |  >      t_ipi = X_init / s = 1 second
> |  >
> |  >  A further simplification is possible for the initial `delta' value, which is
> |  >  defined in [RFC 3448, section 4.6] as
> |  >
> |  >         t_delta = min(t_ipi/2, t_gran/2)
> |  >
> |  >  t_gran/2 here is TFRC_OPSYS_HALF_TIME_GRAN = USEC_PER_SEC / (2 * HZ).
> |  >  Since Linux always schedules with a higher granularity than 1 second,
> |  >  the initial value of t_delta is thus simply
> |  >
> |  >         t_delta = min(USEC_PER_SEC / 2 , USEC_PER_SEC / (2 * HZ))
> |  >                 =  USEC_PER_SEC / (2 * HZ)
> |  >
> |  >  Lastly, TFRC_INITIAL_IPI is not referenced anywhere else and can thus be removed.
> |  >
> |  > Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> |  
> -
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Gerrit Renker]

Quoting Eddie Kohler:
|  Hi Gerrit, Ian,
|  
|  I am not sure I am completely following this discussion, but there is one 
|  point I wanted to bring up.  DCCP senders DO have an estimate of the 
|  round-trip time even BEFORE the first feedback packet, namely from the 
|  Request-Response exchange.  RFC 4342 senders and receivers can use the RTT 
|  measured by the core DCCP protocol.  Reading over RFC 4342, this is extremely 
|  not clear (sorry), but it was our intention.  (Sally, this is right, yes?)  We 
|  will put together an erratum for the RFC Editor.
This is an experimental feature and also appears in draft-ietf-dccp-rfc3448bis-00.txt,
section 4.2:
    "If the sender does have a round trip sample when it is ready to
     first send data (e.g., from the SYN exchange or from a previous
     connection [RFC2140]), the initial transmit rate X is set to
     W_init/R, and tld is set to the current time."

However, this is a draft, still under revision and subject to further change. 

The Linux CCID 3 module is at present not even compliant with 3448 / 4342, and we are having
enough work getting that done. There is therefore at the moment little point in thinking
about what could be done and what should be done: what we are implementing is RFC 4342/3448, 
not more.

And if what is in the specification was not your intention, then this is certainly not our problem!

You are suggesting and requesting features for which there is no support currently in the RFCs
(see e.g. your earlier suggestion to re-introduce a socket option for packet sizes). 

What you are suggesting is helpful only for yourself as a writer of specifications, but it is not
helpful for those who have to implement these specifications. If we give in to suggestions which
are not documented by IETF-reviewed and IETF-approved standards documents, then we end up doing 
experimental work while the main target (a standards-compliant DCCP stack) is not even finished.

Therefore, let me put it very clearly: I am against implementing anything which is not stated in 
RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
matches these RFCs, but before we have accomplished that: please stop sending feature requests or
annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
use dccp@ietf instead. 

I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
not via the avenue of implementing feature requests which you state without contributing in work or in
funding.

Gerrit

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Arnaldo Carvalho de Melo]

On 11/27/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Quoting Eddie Kohler:
> |  Hi Gerrit, Ian,
> |
> |  I am not sure I am completely following this discussion, but there is one
> |  point I wanted to bring up. DCCP senders DO have an estimate of the
> |  round-trip time even BEFORE the first feedback packet, namely from the
> |  Request-Response exchange. RFC 4342 senders and receivers can use the RTT
> |  measured by the core DCCP protocol. Reading over RFC 4342, this is extremely
> |  not clear (sorry), but it was our intention. (Sally, this is right, yes?) We
> |  will put together an erratum for the RFC Editor.
> This is an experimental feature and also appears in draft-ietf-dccp-rfc3448bis-00.txt,
> section 4.2:
>     "If the sender does have a round trip sample when it is ready to
>      first send data (e.g., from the SYN exchange or from a previous
>      connection [RFC2140]), the initial transmit rate X is set to
>      W_init/R, and tld is set to the current time."
>
> However, this is a draft, still under revision and subject to further change.
>
> The Linux CCID 3 module is at present not even compliant with 3448 / 4342, and we are having
> enough work getting that done. There is therefore at the moment little point in thinking
> about what could be done and what should be done: what we are implementing is RFC 4342/3448,
> not more.
>
> And if what is in the specification was not your intention, then this is certainly not our problem!
>
> You are suggesting and requesting features for which there is no support currently in the RFCs
> (see e.g. your earlier suggestion to re-introduce a socket option for packet sizes).
>
> What you are suggesting is helpful only for yourself as a writer of specifications, but it is not
> helpful for those who have to implement these specifications. If we give in to suggestions which
> are not documented by IETF-reviewed and IETF-approved standards documents, then we end up doing
> experimental work while the main target (a standards-compliant DCCP stack) is not even finished.
>
> Therefore, let me put it very clearly: I am against implementing anything which is not stated in
> RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
> matches these RFCs, but before we have accomplished that: please stop sending feature requests or
> annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
> use dccp@ietf instead.
>
> I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
> not via the avenue of implementing feature requests which you state without contributing in work or in
> funding.

I violently agree with Gerrit on this one, no one is preventing anyone
from doing experimental work, the infrastructure is there and if
changes are required for supporting different ways of the DCCP core
interacting with any new CCID (experimental or a standard) we'd love
to hear so as to work on making the Linux DCCP infrastructure as
useful as possible for the community at large.

Regards,

- Arnaldo

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Gerrit Renker]

Quoting Arnaldo Carvalho de Melo:
|  On 11/27/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
|  > Quoting Eddie Kohler:
|  > |  Hi Gerrit, Ian,
|  > |
|  > |  I am not sure I am completely following this discussion, but there is one
|  > |  point I wanted to bring up. DCCP senders DO have an estimate of the
|  > |  round-trip time even BEFORE the first feedback packet, namely from the
|  > |  Request-Response exchange. RFC 4342 senders and receivers can use the RTT
|  > |  measured by the core DCCP protocol. Reading over RFC 4342, this is extremely
|  > |  not clear (sorry), but it was our intention. (Sally, this is right, yes?) We
|  > |  will put together an erratum for the RFC Editor.
|  > This is an experimental feature and also appears in draft-ietf-dccp-rfc3448bis-00.txt,
|  > section 4.2:
|  >     "If the sender does have a round trip sample when it is ready to
|  >      first send data (e.g., from the SYN exchange or from a previous
|  >      connection [RFC2140]), the initial transmit rate X is set to
|  >      W_init/R, and tld is set to the current time."
|  >
|  > However, this is a draft, still under revision and subject to further change.
|  >
|  > The Linux CCID 3 module is at present not even compliant with 3448 / 4342, and we are having
|  > enough work getting that done. There is therefore at the moment little point in thinking
|  > about what could be done and what should be done: what we are implementing is RFC 4342/3448,
|  > not more.
|  >
|  > And if what is in the specification was not your intention, then this is certainly not our problem!
|  >
|  > You are suggesting and requesting features for which there is no support currently in the RFCs
|  > (see e.g. your earlier suggestion to re-introduce a socket option for packet sizes).
|  >
|  > What you are suggesting is helpful only for yourself as a writer of specifications, but it is not
|  > helpful for those who have to implement these specifications. If we give in to suggestions which
|  > are not documented by IETF-reviewed and IETF-approved standards documents, then we end up doing
|  > experimental work while the main target (a standards-compliant DCCP stack) is not even finished.
|  >
|  > Therefore, let me put it very clearly: I am against implementing anything which is not stated in
|  > RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
|  > matches these RFCs, but before we have accomplished that: please stop sending feature requests or
|  > annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
|  > use dccp@ietf instead.
|  >
|  > I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
|  > not via the avenue of implementing feature requests which you state without contributing in work or in
|  > funding.
|  
|  I violently agree with Gerrit on this one, no one is preventing anyone
|  from doing experimental work, the infrastructure is there and if
|  changes are required for supporting different ways of the DCCP core
|  interacting with any new CCID (experimental or a standard) we'd love
|  to hear so as to work on making the Linux DCCP infrastructure as
|  useful as possible for the community at large.
|  
I can not see your disagreement in this. The fact is that the Linux DCCP implementation currently is
not compliant with the RFCs and an implementation which only partially implements a standard is of
not much service to the community. Features which have not met the approval of public bodies such as 
the IETF, on the other hand, serve the interest of only a few and not that of a larger community.

Therefore, Arnaldo, I fail to see the contradiction in what you are saying with regard to what I have
stated above. 

I also didn't say that doing experimental work is totally impossible - but I do consider getting the
basics right first.

And lastly: it is only thanks due to your ingenious efforts that the Linux DCCP implementation has made it
            this far, the number of other half-completed implementations attests to the fact that DCCP,
            even without additional feature requests, is hard to implement. Therefore I do think that 
            the above arguments are justified, and that experimental features - whose discussion and 
            implementation takes time away which could be more fruitfully spent on finishing the incomplete
            DCCP Linux implementation - should come last.


Please let me repeat - I have stated above that I can think of a constructive way of integrating
Eddies ideas as well, but clearly not in the way of integrating experimental and feature requests 
when the main work is not even finished. 


Gerrit

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Arnaldo Carvalho de Melo]

On 11/27/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Quoting Arnaldo Carvalho de Melo:
> |  On 11/27/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> |  > Quoting Eddie Kohler:
> |  > |  Hi Gerrit, Ian,
> |  > |
> |  > |  I am not sure I am completely following this discussion, but there is one
> |  > |  point I wanted to bring up. DCCP senders DO have an estimate of the
> |  > |  round-trip time even BEFORE the first feedback packet, namely from the
> |  > |  Request-Response exchange. RFC 4342 senders and receivers can use the RTT
> |  > |  measured by the core DCCP protocol. Reading over RFC 4342, this is extremely
> |  > |  not clear (sorry), but it was our intention. (Sally, this is right, yes?) We
> |  > |  will put together an erratum for the RFC Editor.
> |  > This is an experimental feature and also appears in draft-ietf-dccp-rfc3448bis-00.txt,
> |  > section 4.2:
> |  >     "If the sender does have a round trip sample when it is ready to
> |  >      first send data (e.g., from the SYN exchange or from a previous
> |  >      connection [RFC2140]), the initial transmit rate X is set to
> |  >      W_init/R, and tld is set to the current time."
> |  >
> |  > However, this is a draft, still under revision and subject to further change.
> |  >
> |  > The Linux CCID 3 module is at present not even compliant with 3448 / 4342, and we are having
> |  > enough work getting that done. There is therefore at the moment little point in thinking
> |  > about what could be done and what should be done: what we are implementing is RFC 4342/3448,
> |  > not more.
> |  >
> |  > And if what is in the specification was not your intention, then this is certainly not our problem!
> |  >
> |  > You are suggesting and requesting features for which there is no support currently in the RFCs
> |  > (see e.g. your earlier suggestion to re-introduce a socket option for packet sizes).
> |  >
> |  > What you are suggesting is helpful only for yourself as a writer of specifications, but it is not
> |  > helpful for those who have to implement these specifications. If we give in to suggestions which
> |  > are not documented by IETF-reviewed and IETF-approved standards documents, then we end up doing
> |  > experimental work while the main target (a standards-compliant DCCP stack) is not even finished.
> |  >
> |  > Therefore, let me put it very clearly: I am against implementing anything which is not stated in
> |  > RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
> |  > matches these RFCs, but before we have accomplished that: please stop sending feature requests or
> |  > annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
> |  > use dccp@ietf instead.
> |  >
> |  > I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
> |  > not via the avenue of implementing feature requests which you state without contributing in work or in
> |  > funding.
> |
> |  I violently agree with Gerrit on this one, no one is preventing anyone
                        ^^^^^^^^^^
                        ^^^^^^^^^^
> |  from doing experimental work, the infrastructure is there and if
> |  changes are required for supporting different ways of the DCCP core
> |  interacting with any new CCID (experimental or a standard) we'd love
> |  to hear so as to work on making the Linux DCCP infrastructure as
> |  useful as possible for the community at large.
> |
> I can not see your disagreement in this. The fact is that the Linux DCCP implementation currently is
> not compliant with the RFCs and an implementation which only partially implements a standard is of
> not much service to the community. Features which have not met the approval of public bodies such as
> the IETF, on the other hand, serve the interest of only a few and not that of a larger community.

Lemme reread what I've wrote... English is not my first language so I
may have commited some mistake, no, I guess you misunderstood me,
reread what I've written, I'm supporting what you've said, agreeing
with you, keep up the good work !

- Arnaldo

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Arnaldo Carvalho de Melo]

On 11/27/06, Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> On 11/27/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> > Quoting Arnaldo Carvalho de Melo:
> > |  On 11/27/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> > |  > Quoting Eddie Kohler:
> > |  > |  Hi Gerrit, Ian,
> > |  > |
> > |  > |  I am not sure I am completely following this discussion, but there is one
> > |  > |  point I wanted to bring up. DCCP senders DO have an estimate of the
> > |  > |  round-trip time even BEFORE the first feedback packet, namely from the
> > |  > |  Request-Response exchange. RFC 4342 senders and receivers can use the RTT
> > |  > |  measured by the core DCCP protocol. Reading over RFC 4342, this is extremely
> > |  > |  not clear (sorry), but it was our intention. (Sally, this is right, yes?) We
> > |  > |  will put together an erratum for the RFC Editor.
> > |  > This is an experimental feature and also appears in draft-ietf-dccp-rfc3448bis-00.txt,
> > |  > section 4.2:
> > |  >     "If the sender does have a round trip sample when it is ready to
> > |  >      first send data (e.g., from the SYN exchange or from a previous
> > |  >      connection [RFC2140]), the initial transmit rate X is set to
> > |  >      W_init/R, and tld is set to the current time."
> > |  >
> > |  > However, this is a draft, still under revision and subject to further change.
> > |  >
> > |  > The Linux CCID 3 module is at present not even compliant with 3448 / 4342, and we are having
> > |  > enough work getting that done. There is therefore at the moment little point in thinking
> > |  > about what could be done and what should be done: what we are implementing is RFC 4342/3448,
> > |  > not more.
> > |  >
> > |  > And if what is in the specification was not your intention, then this is certainly not our problem!
> > |  >
> > |  > You are suggesting and requesting features for which there is no support currently in the RFCs
> > |  > (see e.g. your earlier suggestion to re-introduce a socket option for packet sizes).
> > |  >
> > |  > What you are suggesting is helpful only for yourself as a writer of specifications, but it is not
> > |  > helpful for those who have to implement these specifications. If we give in to suggestions which
> > |  > are not documented by IETF-reviewed and IETF-approved standards documents, then we end up doing
> > |  > experimental work while the main target (a standards-compliant DCCP stack) is not even finished.
> > |  >
> > |  > Therefore, let me put it very clearly: I am against implementing anything which is not stated in
> > |  > RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
> > |  > matches these RFCs, but before we have accomplished that: please stop sending feature requests or
> > |  > annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
> > |  > use dccp@ietf instead.
> > |  >
> > |  > I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
> > |  > not via the avenue of implementing feature requests which you state without contributing in work or in
> > |  > funding.
> > |
> > |  I violently agree with Gerrit on this one, no one is preventing anyone
>                         ^^^^^^^^^^
>                         ^^^^^^^^^^
> > |  from doing experimental work, the infrastructure is there and if
> > |  changes are required for supporting different ways of the DCCP core
> > |  interacting with any new CCID (experimental or a standard) we'd love
> > |  to hear so as to work on making the Linux DCCP infrastructure as
> > |  useful as possible for the community at large.
> > |
> > I can not see your disagreement in this. The fact is that the Linux DCCP implementation currently is
> > not compliant with the RFCs and an implementation which only partially implements a standard is of
> > not much service to the community. Features which have not met the approval of public bodies such as
> > the IETF, on the other hand, serve the interest of only a few and not that of a larger community.
>
> Lemme reread what I've wrote... English is not my first language so I
> may have commited some mistake, no, I guess you misunderstood me,
> reread what I've written, I'm supporting what you've said, agreeing
> with you, keep up the good work !

Perhaps because of the second part, that is only for the interaction
of CCIDs and the core, i.e. I'm not in favour of being non standard
compliant in the CCID3 implementation nor the core, just that I, at
least, would love to hear from experimental CCID implementators
requirements for the interaction of the standards compliant DCCP core
with the experimental CCIDs, i.e. net/dccp/ccids.[ch] basically.

Hope to have clarified.

- Arnaldo

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Gerrit Renker]

|  > |  I violently agree with Gerrit on this one, no one is preventing anyone
|                          ^^^^^^^^^^
|                          ^^^^^^^^^^
Ouch - I was sure I had read `violently disagree'. Weierha ...
|  > |  from doing experimental work, the infrastructure is there and if
|  > |  changes are required for supporting different ways of the DCCP core
|  > |  interacting with any new CCID (experimental or a standard) we'd love
|  > |  to hear so as to work on making the Linux DCCP infrastructure as
|  > |  useful as possible for the community at large.
|  > |
|  > I can not see your disagreement in this. The fact is that the Linux DCCP implementation currently is
|  > not compliant with the RFCs and an implementation which only partially implements a standard is of
|  > not much service to the community. Features which have not met the approval of public bodies such as
|  > the IETF, on the other hand, serve the interest of only a few and not that of a larger community.
|  
|  Lemme reread what I've wrote... English is not my first language so I
.... and it is not my first language either. I misread your email.
     I had read it as `violently disagree'. Sorry for the mistake.

While at it, I think that the thanks and a big lot of kudos clearly goes to you - having provided basically
the entire infrastructure on which DCCP currently rests.

Gerrit

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Ian McDonald]

> Therefore, let me put it very clearly: I am against implementing anything which is not stated in
> RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
> matches these RFCs, but before we have accomplished that: please stop sending feature requests or
> annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
> use dccp@ietf instead.

I will throw in my opinion here. Linux is about experimenting with
ideas in many cases - that is the joy of it. People can and should
contribute whatever they want. They shouldn't be constrained by
anything.

Eddie can suggest whatever he likes and I welcome it. That doesn't
mean it will get included though as it depends on coders. You don't
like his approach which is fine - it means that you won't code it. I
like the sounds of it but very time constrained so probably won't
unless it helps me solve a problem in my PhD. But someone else who is
motivated might go and do it.

Linux isn't always RFC compliant either - ask Sally for example about
TCP.... (Although Linux is probably better than any other OS in RFC
compliance).
>
> I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
> not via the avenue of implementing feature requests which you state without contributing in work or in
> funding.
>
I agree that the main focus of Linux is "show me the code" and for
this to go in someone has to code. I also value Eddie making comments
and hope it continues.

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Gerrit Renker]

|  I'm not in favour of being non standard
|  compliant in the CCID3 implementation nor the core, just that I, at
|  least, would love to hear from experimental CCID implementators
|  requirements for the interaction of the standards compliant DCCP core
|  with the experimental CCIDs, i.e. net/dccp/ccids.[ch] basically.
I am also much in favour of this. It is however a different area. That is
why I said I can think of interacting constructively with Eddie's ideas.
This would be something which solves an existing issue, rather than adding
further issues to the existing list.

Gerrit

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Arnaldo Carvalho de Melo]

On 11/27/06, Ian McDonald <ian.mcdonald@jandi.co.nz> wrote:
> > Therefore, let me put it very clearly: I am against implementing anything which is not stated in
> > RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
> > matches these RFCs, but before we have accomplished that: please stop sending feature requests or
> > annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
> > use dccp@ietf instead.
>
> I will throw in my opinion here. Linux is about experimenting with
> ideas in many cases - that is the joy of it. People can and should
> contribute whatever they want. They shouldn't be constrained by
> anything.

Agreed, and we've worked really hard in the last years for Linux to be
a testbed for new ideas, look no further than the pluggable TCP
congestion control and the DCCP CCID pluggable infrastructures, that
we dream of unifying one day (look at
http://darkircop.org/dccp/tcp/ to see Andrea's experimentation making
DCCP use all the TCP congestion control algorithms).

> Eddie can suggest whatever he likes and I welcome it. That doesn't
> mean it will get included though as it depends on coders. You don't
> like his approach which is fine - it means that you won't code it. I
> like the sounds of it but very time constrained so probably won't
> unless it helps me solve a problem in my PhD. But someone else who is
> motivated might go and do it.

And as I said, go for it! If it needs changes on how the core
interacts with CCIDs, I'd love to hear, I just understand Gerrit's
worries as we all need a standards compliant DCCP implementation as a
much longed for milestone.

> Linux isn't always RFC compliant either - ask Sally for example about
> TCP.... (Although Linux is probably better than any other OS in RFC
> compliance).

Its just great that the RFC authors are taking part on the discussion,
that way things like this are noticed and provide clues for further
work on erratums and updates to the RFCs, we just don't want to trow
all the effort they have put in writing the RFCs by not following it
8-)

> > I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
> > not via the avenue of implementing feature requests which you state without contributing in work or in
> > funding.
> >
> I agree that the main focus of Linux is "show me the code" and for
> this to go in someone has to code. I also value Eddie making comments
> and hope it continues.

Heck, I was commenting with David Miller, Linux has come a long way,
now the RFC authors are reviewing Linux kernel code, that is
absolutely awesome and I sincerely _beg_ for this to continue :-)

- Arnaldo

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first

[Eddie Kohler]

Gerrit:

I am able to read code.  When I look at the existing Linux code and patches 
for CCID 3, I see a lot of corner cases designed to handle the 
TFRC_SSTATE_NO_FBACK state.

That state may not need to exist.  CCID 3 always has an RTT estimate, provided 
by the request/response exchange.  Removing this state would improve the code. 
  You think the state is required for standards compliance.  Well, the 
standard's author is trying to tell you differently.  This is not about 
"experimental" features, this is about interpretations of the core spec.  You 
seem to think that only you can interpret the core spec correctly; this is not 
so.  And if an erratum is published, following that erratum will be required 
for "standards compliance".

The "nominal packet size" is not "experimental" either, it is explicitly 
allowed by the spec.

Thanks for your work on DCCP, which I **really do appreciate**.  However, I 
really do NOT appreciate your tone.

Eddie


Gerrit Renker wrote:
> Quoting Eddie Kohler:
> |  Hi Gerrit, Ian,
> |  
> |  I am not sure I am completely following this discussion, but there is one 
> |  point I wanted to bring up.  DCCP senders DO have an estimate of the 
> |  round-trip time even BEFORE the first feedback packet, namely from the 
> |  Request-Response exchange.  RFC 4342 senders and receivers can use the RTT 
> |  measured by the core DCCP protocol.  Reading over RFC 4342, this is extremely 
> |  not clear (sorry), but it was our intention.  (Sally, this is right, yes?)  We 
> |  will put together an erratum for the RFC Editor.
> This is an experimental feature and also appears in draft-ietf-dccp-rfc3448bis-00.txt,
> section 4.2:
>     "If the sender does have a round trip sample when it is ready to
>      first send data (e.g., from the SYN exchange or from a previous
>      connection [RFC2140]), the initial transmit rate X is set to
>      W_init/R, and tld is set to the current time."
> 
> However, this is a draft, still under revision and subject to further change. 
> 
> The Linux CCID 3 module is at present not even compliant with 3448 / 4342, and we are having
> enough work getting that done. There is therefore at the moment little point in thinking
> about what could be done and what should be done: what we are implementing is RFC 4342/3448, 
> not more.
> 
> And if what is in the specification was not your intention, then this is certainly not our problem!
> 
> You are suggesting and requesting features for which there is no support currently in the RFCs
> (see e.g. your earlier suggestion to re-introduce a socket option for packet sizes). 
> 
> What you are suggesting is helpful only for yourself as a writer of specifications, but it is not
> helpful for those who have to implement these specifications. If we give in to suggestions which
> are not documented by IETF-reviewed and IETF-approved standards documents, then we end up doing 
> experimental work while the main target (a standards-compliant DCCP stack) is not even finished.
> 
> Therefore, let me put it very clearly: I am against implementing anything which is not stated in 
> RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
> matches these RFCs, but before we have accomplished that: please stop sending feature requests or
> annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
> use dccp@ietf instead. 
> 
> I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
> not via the avenue of implementing feature requests which you state without contributing in work or in
> funding.
> 
> Gerrit
> 

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Gerrit Renker]

Quoting Eddie Kohler:
|  Gerrit:
|  
|  I am able to read code.  When I look at the existing Linux code and patches 
|  for CCID 3, I see a lot of corner cases designed to handle the 
|  TFRC_SSTATE_NO_FBACK state.
|  
|  That state may not need to exist.  CCID 3 always has an RTT estimate, provided 
|  by the request/response exchange.  Removing this state would improve the code. 
|    You think the state is required for standards compliance.  Well, the 
|  standard's author is trying to tell you differently.  This is not about 
|  "experimental" features, this is about interpretations of the core spec.  You 
|  seem to think that only you can interpret the core spec correctly; this is not 
|  so.  And if an erratum is published, following that erratum will be required 
|  for "standards compliance".
|  
|  The "nominal packet size" is not "experimental" either, it is explicitly 
|  allowed by the spec.
|  
|  Thanks for your work on DCCP, which I **really do appreciate**.  However, I 
|  really do NOT appreciate your tone.
I am not going to argue, you are entitled to your own opinion and who am I to say whether
it is wrong or right? And if you can walk away from this discussion with material to provide
an erratum for future implementers and ideas for improving the specifications, then this
discussion has in fact been constructive. 

Good for you - but it does not solve the issues with the Linux implementation, which remains
as yet another half-completed attempt.

I think it would suit your and our purposes better if instead of debating the latest erratums 
and how X could also be implemented using method Z (while X is at least working without failure), 
there were some concerted effort to achieve at least _one_ completed implementation. Otherwise,
it takes only 3 more years and then there will be a sad anniversary of 10 years of TFRC/DCCP research
without even a single completed implementation.

This is was the email below says - sorry if you did not appreciate the tone of it.
  

|  Gerrit Renker wrote:
|  > Quoting Eddie Kohler:
|  > |  Hi Gerrit, Ian,
|  > |  
|  > |  I am not sure I am completely following this discussion, but there is one 
|  > |  point I wanted to bring up.  DCCP senders DO have an estimate of the 
|  > |  round-trip time even BEFORE the first feedback packet, namely from the 
|  > |  Request-Response exchange.  RFC 4342 senders and receivers can use the RTT 
|  > |  measured by the core DCCP protocol.  Reading over RFC 4342, this is extremely 
|  > |  not clear (sorry), but it was our intention.  (Sally, this is right, yes?)  We 
|  > |  will put together an erratum for the RFC Editor.
|  > This is an experimental feature and also appears in draft-ietf-dccp-rfc3448bis-00.txt,
|  > section 4.2:
|  >     "If the sender does have a round trip sample when it is ready to
|  >      first send data (e.g., from the SYN exchange or from a previous
|  >      connection [RFC2140]), the initial transmit rate X is set to
|  >      W_init/R, and tld is set to the current time."
|  > 
|  > However, this is a draft, still under revision and subject to further change. 
|  > 
|  > The Linux CCID 3 module is at present not even compliant with 3448 / 4342, and we are having
|  > enough work getting that done. There is therefore at the moment little point in thinking
|  > about what could be done and what should be done: what we are implementing is RFC 4342/3448, 
|  > not more.
|  > 
|  > And if what is in the specification was not your intention, then this is certainly not our problem!
|  > 
|  > You are suggesting and requesting features for which there is no support currently in the RFCs
|  > (see e.g. your earlier suggestion to re-introduce a socket option for packet sizes). 
|  > 
|  > What you are suggesting is helpful only for yourself as a writer of specifications, but it is not
|  > helpful for those who have to implement these specifications. If we give in to suggestions which
|  > are not documented by IETF-reviewed and IETF-approved standards documents, then we end up doing 
|  > experimental work while the main target (a standards-compliant DCCP stack) is not even finished.
|  > 
|  > Therefore, let me put it very clearly: I am against implementing anything which is not stated in 
|  > RFCs 3448, RFC 4340, RFC 4341, and RFC 4342. About the rest we might talk when the Linux implementation
|  > matches these RFCs, but before we have accomplished that: please stop sending feature requests or
|  > annotations which are not part of the publicly and IETF-approved RFCs. For these purposes, please
|  > use dccp@ietf instead. 
|  > 
|  > I am sure we can work out a constructive way of dealing with your interests as well, but it is certainly
|  > not via the avenue of implementing feature requests which you state without contributing in work or in
|  > funding.
|  > 
|  > Gerrit
|  > 
|  -
|  To unsubscribe from this list: send the line "unsubscribe dccp" in
|  the body of a message to majordomo@vger.kernel.org
|  More majordomo info at  http://vger.kernel.org/majordomo-info.html
|  
|  

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Gerrit Renker]

|  Eddie can suggest whatever he likes and I welcome it. That doesn't
|  mean it will get included though as it depends on coders. You don't
|  like his approach which is fine - it means that you won't code it. I
|  like the sounds of it but very time constrained so probably won't
|  unless it helps me solve a problem in my PhD. But someone else who is
|  motivated might go and do it.
I think this is a good way of summing this up. My time is also constrained,
if the remaining bits can be finished before Easter then it would be possible
to look at more recent addendums and newer drafts. Before that there is
little point.

Re: [PATCH 1/6]: Fix bug in calculation of first t_nom and first t_ipi

[Arnaldo Carvalho de Melo]

On 11/28/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Quoting Eddie Kohler:
> |  Gerrit:
> |
> |  I am able to read code.  When I look at the existing Linux code and patches
> |  for CCID 3, I see a lot of corner cases designed to handle the
> |  TFRC_SSTATE_NO_FBACK state.
> |
> |  That state may not need to exist.  CCID 3 always has an RTT estimate, provided
> |  by the request/response exchange.  Removing this state would improve the code.
> |    You think the state is required for standards compliance.  Well, the
> |  standard's author is trying to tell you differently.  This is not about
> |  "experimental" features, this is about interpretations of the core spec.  You
> |  seem to think that only you can interpret the core spec correctly; this is not
> |  so.  And if an erratum is published, following that erratum will be required
> |  for "standards compliance".
> |
> |  The "nominal packet size" is not "experimental" either, it is explicitly
> |  allowed by the spec.
> |
> |  Thanks for your work on DCCP, which I **really do appreciate**.  However, I
> |  really do NOT appreciate your tone.
> I am not going to argue, you are entitled to your own opinion and who am I to say whether
> it is wrong or right? And if you can walk away from this discussion with material to provide
> an erratum for future implementers and ideas for improving the specifications, then this
> discussion has in fact been constructive.

Indeed constructive, even if at times too, humm, "nervous" :)

> Good for you - but it does not solve the issues with the Linux implementation, which remains
> as yet another half-completed attempt.

I guess its more than 60% after last month 8-)

> I think it would suit your and our purposes better if instead of debating the latest erratums
> and how X could also be implemented using method Z (while X is at least working without failure),
> there were some concerted effort to achieve at least _one_ completed implementation. Otherwise,
> it takes only 3 more years and then there will be a sad anniversary of 10 years of TFRC/DCCP research
> without even a single completed implementation.

<bad joke>
The ultimate irony is a half completed DCCP implementation on top of IPv6 ;-)
</bad joke>

> This is was the email below says - sorry if you did not appreciate the tone of it.

Lets get over it :-)

Take a look at the state of DaveM's tree today, its completely in sync
with mine and has most things merged, except for the packet size and
TRFC equation patches, that I thought a day or two would be nice for
further discussion.

- Arnaldo