 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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 initialcongestion 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'llhave a shot at getting 3 dupacks. If there are fewer segmentsoutstanding then we will have no chance at getting 3 dupacks. So, thishas nothing to do with the initial window.I didn't get that as clearly. It might be useful to reiterate it whenthe 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: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann at cs.rwth-aachen.de // web: http://www.umic-mesh.net //