Re: [tcpm] WGLC: 2581bis

[Markku Kojo <[e-mail]>]

Ted, Mark, all,

I'd like to see this document to advance to DS. However, 
after reading the draft and taking a look at a few traces
from Linux TCP implementation it seems that there is one issue
that may need some attention first.

Looking into the Linux TCP behavior (that differs from what the 
draft specifies) seems to reveal an issue with the draft in its 
usage of FlightSize as a bad estimate for the amount of outstanding
data in the *network* and consequently inappropriate adjustment of 
ssthresh (and cwnd). That is, replacing cwnd with FlightSize in 
equation 4 seem to have resulted in similar kind of problems as there
were earlier when cwnd was used in the equation:

  When Limited Transmit alg (step 1 of fast rexmit & fast recovery
  alg in Section 3.2) is used with the current definition of 
  FlightSize and equation 4, ssthresh and cwnd will be assigned
  larger value than what would be appropriate. The reason is 
  that FlightSize is increased in step 1 and it is then used in 
  step 2 and 3 to determine the new value of ssthresh and cwnd. 
  However, allowing Limited Transmit to send a new data segment
  on the arrival of the 1st and 2nd dupack rests on the assumption
  that a dupack indicates that a segment has left the network
  and thereby the number of outstanding segments in the network
  remains unchanged (like cwnd remains). 

  This means that using Limited Transmit results in less reduction
  in ssthresh and cwnd compared to the case where Limited Transmit
  is not in use. As the difference in the new ssthresh (and cwnd) 
  value is only (at most) one MSS, this does not make TCP 
  significantly more aggressive with large windows, but with a small
  window size the difference is significant. For example, with cwnd 
  of 4 segments and a single segment loss, a TCP sender applying 
  Limited Transmit per current spec continues with cwnd of 3 
  segments while a TCP sender not applying Limited Transmit halves
  its cwnd and continues with cwnd of 2 segments. This may have
  a significant effect on a bottleneck link that is shared by a
  number of connections proceeding with a small window.

  One simple possibility of fixing this is to redefine equation 4 as

     ssthresh = max ( min(FlightSize,cwnd) / 2, 2*SMSS) 


  Similar problems in correctly determining a new value of ssthresh 
  may occur also in other cases where the actual amount of outstanding
  data (significanly) differs from FlightSize, i.e., when TCP sender 
  is already in loss recovery.

  Linux does not experience this problem with FlightSize as it 
  maintains a more accurate estimate (akin to pipe variable in RFC 
  3517) for the amount of outstanding data, and uses it to determine
  the new value of ssthresh (and cwnd) when entering loss recovery.


Other comments/suggestions:


1. Section 3.1, 3rd para:

  It might be useful also note that the purpose of the slow start 
  algorithm is to (re)start the ack clock (in addition to determining
  the available capacity).   


2. Section 3.1: 

  "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 is held
   constant." 

   Should be clarified that this applies only when the retransmission
   timer expires again for the same segment, not when retransmission
   timer expires for a fast retransmitted segment.


3. Section 3.2, 1st step of the fast retransmit and fast recovery alg:

 It would be useful to note that allowing a TCP sender to send a 
 new data segment on the 1st and 2nd dupack is in violation to
 the definition of cwnd in Section 2:

   "At any given time, a TCP MUST NOT send data with a sequence 
    number higher than the sum of the highest acknowledged sequence
    number and the minimum of cwnd and rwnd."


4. Section 4.3:

  "Loss in two successive windows of data, or the loss of a 
   retransmission,  should be taken as two indications of congestion
   and, therefore, cwnd (and ssthresh) MUST be lowered twice in this 
   case."

  Lowering ssthresh twice on the loss of a retransmission triggered
  by an RTO would be in contradiction with what is said in Section 3.1 
  (see item 2 above). Should clarify that this is valid only with the
  loss of a fast retransmit (or the loss of a retransmission in fast 
  recovery with an advanced loss recovery alg such as NewReno or 
  SACK-based fast recovery) 


Thanks,

/Markku


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