Subject: RE: [tcpm] RFC2581bis

From: "Duke, Martin" <[email-masked]>
Date: Fri, 17 Feb 2006 08:08:58 -0800

I'm not sure I agree that this is outside the scope of the task at hand,
largely because I don't think that this is a change in what 2581
specifies. 

I believe that the current specification can be interpreted two ways,
and in fact, Linux and BSD interpret them differently.  If we're going
to clarify the intent, as the last draft of 2581bis seems to do, I think
we should clarify it in the way that best prepares TCP to function in
the future with minimum modification.

Excerpt from the text of both documents is below.

Martin

(1) Original 2581 text:
"When a TCP sender detects segment loss using the retransmission
   timer, the value of ssthresh MUST be set to no more than the value
   given in equation 3:

      ssthresh = max (FlightSize / 2, 2*SMSS)            (3)

   As discussed above, FlightSize is the amount of outstanding data in
   the network.

   Implementation Note: an easy mistake to make is to simply use cwnd,
   rather than FlightSize, which in some implementations may
   incidentally increase well beyond rwnd."

Flightsize is described as:
"FLIGHT SIZE:  The amount of data that has been sent but not yet
      acknowledged."
But does that include data that has timed out?

(2) 2581bis adds the following explanatory text:
"On the other hand, when a TCP sender detects segment loss using the
    retransmission timer and the given segment has already been
    retransmitted at least once, the value of ssthresh MUST be set to no
    more than the value given in equation 5:

        ssthresh = max (ssthresh / 2, 2*SMSS)              (5)

    In other words, upon the first retransmission of a segment the value
    of ssthresh should be set to half the amount of outstanding data in
    the network, whereas on subsequent retransmissions the value of
    ssthresh should simply be halved."

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, February 16, 2006 1:27 PM
To: David Borman
Cc: Ethan Blanton; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tcpm] RFC2581bis

David Borman wrote:
> How about adding it as an appendix or a discussion item?  That would 
> document the issue and the proposed solution, but defer making it  
> part of the standard.
> 
>             -David Borman

It could/should be listed as an open issue, under "pending mods that are
not covered by this document".

(I'd avoid an appendix devoted to this issue; IMO, the issue should be
covered elsewhere in detail, not in this doc).

Joe

> 
> On Feb 16, 2006, at 8:51 AM, Mark Allman wrote:
> 
>>
>> Folks-
>>
>>> I have concerns about setting ssthresh after multiple timeouts 
>>> (Equation 5).  My initial feeling is that cutting ssthresh in half 
>>> each time is too conservative.
>>>
>>> [...]
>>>
>>> So as an alternative, perhaps we should leave ssthresh unchanged  
>>> after the first retransmit.
>>
>>
>> Vern, Ethan and I have been chatting about this proposal.  We're a 
>> little bit torn here because:
>>
>>   * Our intent was to revise RFC 2581 for two reasons: (1) to roll in
>>     small changes to TCP that are already standards track (e.g.,
limited
>>     transmit and the larger initial window) and (2) to fix bugs
>>     identified in 2581.  It seems to us that the above is outside the
>>     scope of either of these tasks.
>>
>>   * It seems to the three of us that setting ssthresh on the first
RTO
>>     and then not adjusting it on subsequent RTOs for the same
sequence
>>     number is safe and may well be a reasonable path.
>>
>> So, how to reconcile these things?  Do we really want to require  
>> Martin (or someone) to write a standards track RFC for something so 
>> small  such that it can someday be rolled into the main spec?  That 
>> seems like a pretty high price.
>>
>> So, we're asking the WG whether (a) the change seems reasonable and  
>> (b) whether it is OK to include this small tweak into the current 
>> revision of RFC2581.
>>
>> (Note: (b) is being asked about this small change only.  We still  
>> think that (1) and (2) should be the guiding principles for the
revision.
>> Although, of course, the WG can decide otherwise, as well.)
>>
>> Thanks!
>>
>> allman
>>
>>
>>
>> --
>> Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/
>>
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/tcpm
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Feb 2006 08:37:29 -0800

> But does that include data that has timed out?

Send but timed out is still sent. You can't 'unsend' it. It can still
get there - and sometimes does.

Trying to reinterpret that recommendation to accommodate what *might*
happen in *some* contexts is speculation.

Joe