Subject: [tcpm] WGLC: comments on 2581bis

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 02 Dec 2007 18:20:53 -0800

I have a few comments/questions...

---
1) SMSS
- I think the document should also refer to PLPMTUD as a valid 
IETF-specified way to choose a segment size.
---
2) RMSS
- The wording in the draft is not clear  whether this is an upper bound 
to the SMSS, or just one of many ways to discover a sensible SMSS.
- Is the default RMSS still 536 bytes also for IPv6, since [RFC1122]
does not apply in this context to IPv6.
---
3) ECN
- The document speaks only of loss, but I'm assuming that this applies
equally to ECN. If that is so, perhaps we should explicitly say so up-front.
---

My other comments duplicated some of those already sent:-)

Gorry

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 04 Dec 2007 14:29:41 -0500

Gorry-

Thanks for the comments.

> IETF-specified way to choose a segment size.

Fair enough.  I am adding a reference.

> ---
> 2) RMSS
> - The wording in the draft is not clear  whether this is an upper
> bound to the SMSS, or just one of many ways to discover a sensible
> SMSS.

The latter.  I guess I am not quite sure what to do with this comment.

> does not apply in this context to IPv6.

I think so.  Are you suggesting here that we specify a different value
when we're going over IPv6?  I am not sure if that is a 2581bis thing or
a 1122bis thing.

> equally to ECN. If that is so, perhaps we should explicitly say so up-front.

In the intro to section 3 I have put these words:

    Also note that the algorithms specified in this document work in
    terms of using loss as the signal of congestion.  Explicit
    Congestion Notification (ECN) could also be used as discussed in
    [RFC3168].

Does this work?

allman

---

From: John Heffner <[email-masked]>
Date: Tue, 04 Dec 2007 16:59:04 -0500

> when we're going over IPv6?  I am not sure if that is a 2581bis thing or

In principle, the TCP's MSS may be independent of MTU, even though in 
most reasonable implementations it's going to be at least as large 
(minus headers).  I think 536 applies to IPv6 as well.  Linux uses this 
value hard-coded for both IPv4 and IPv6.

   -John

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 04 Dec 2007 21:17:39 -0800

> Gorry-
<snip>
 > when we're going over IPv6?
 >
I queried if this should have been different for v6, because I'd have 
expected it was safe to use 1220.

 > I am not sure if that is a 2581bis thing or a 1122bis thing.
RFC 2460, only says:
  " For example, in
    IPv4, TCP's MSS option is computed as the maximum packet size (a
    default value or a value learned through Path MTU Discovery) minus 40
    octets (20 octets for the minimum-length IPv4 header and 20 octets
    for the minimum-length TCP header).  When using TCP over IPv6, the
    MSS must be computed as the maximum packet size minus 60 octets,
    extension headers) is 20 octets longer than a minimum-length IPv4
    header."
- All of which is true, but does not explicitly update TCP's default 
MSS. Looking at code, it seems 1024 is not uncommon.... Well that was 
fun, if you know better, do improve the text, otherwise I expect the 
current text is fine.

 >     Congestion Notification (ECN) could also be used as discussed in
Yes, that would be fine - I'd prefer /defined in [3168]/specified in 
[3168]/ or something of the like.

 > allman
 >
 >
 > ------------------------------------------------------------------------
 >

best wishes,

Gorry

---

From: Ted Faber <[email-masked]>
Date: Fri, 14 Dec 2007 17:51:35 -0800

On Mon, Nov 26, 2007 at 04:47:20PM -0800, Ted Faber wrote:
> Mark and I would like to start a WGLC for the revision of 2581 from
> Proposed Standard to Draft Standard.
> 
> As you know, this is a central document in TCP and the revision pretty
> much just recognized that and adds an implementation report.  The
> implementation report notes that basically all TCPs support the
> algorithms in the document interoperably.  We believe this is ready for
> publication.
> 
> Other than the addition of the report, changes to the document from the
> published Proposed Standard are minimal.
> 
> Please read and let us know if you agree or disagree and why.  This will
> be a long WGLC to accomodate for the IETF meeting next week and the
> holiday season.  The WGLC will end 21 Dec 2007.
> 

Just a reminder: this WGLC ends 21 Dec 2007.  Please comment if you have
an opinion - including an opinion that the draft is publishable.

Thanks!

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Markku Kojo <[email-masked]>
Date: Sat, 22 Dec 2007 05:04:19 +0200 (EET)

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