Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01

[Alexander Zimmermann <[e-mail]>]

Hi Joe, hi Mark,

may be we can reuse a paragraph from RFC 3517:

"We define a variable "DupThresh" that holds the number of duplicate  
acknowledgments required to trigger a retransmission. Per [RFC2581]  
this threshold is defined to be 3 duplicate acknowledgments. However,  
implementers should consult any updates to [RFC2581] to determine the  
current value for DupThresh (or method for determining its value)."

First, it's easier to see where the magic *4* comes from, second it's   
future-proof when "5681bis" alters the number of duplicate Acks  
required for fast retransmit. :-)

Alex

Am 23.09.2009 um 16:28 schrieb Joe Touch:

> ...
>>> In 2.1, do you want to define this in terms a fixed value of 4*SMSS,
>>> or define it as a pointer (i.e., to the initial CWND, so if init  
>>> CWND
>>> increases, so does this?) same for the part about packet-based  
>>> (again,
>>> would that be segment-based?) not referring to 4, but the number of
>>> segments in the initial CWND (e.g., as "currently 4" -- PS, should
>>> that be 4, or shouldn't it be "initial_CWND/SMSS", i.e., a max of 4,
>>> but in most current cases it seems like this would still be 3).
>>
>> No, I don't.  This doesn't have anything to do with the initial
>> congestion window size.  The "4"---which I thought was well  
>> motivated,
>> perhaps not---comes from fast retransmit's magic constant of "3".   
>> I.e.,
>> if there are at least 4 segments outstanding and we lose one then  
>> we'll
>> have a shot at getting 3 dupacks.  If there are fewer segments
>> outstanding then we will have no chance at getting 3 dupacks.  So,  
>> this
>> has nothing to do with the initial window.
>
> I didn't get that as clearly. It might be useful to reiterate it when
> the number is introduced (maybe a few times for people like me who  
> miss it).

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: [phone], fax: [phone]
// email: [e-mail]
// web: http://www.umic-mesh.net
//