Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 13 May 2009 13:36:48 -0500

TCP Maintainers & Minor Extenders: The WGLC came and went on the
Early Retransmit draft without a single comment.  If it really is
perfect, then someone should speak up and say so :).

As the chairs, we don't have a good feeling about forwarding this
draft up for publication without any discussion in the WG, so we
are proposing to hold it here until at least a handful of people
submit comments on it. 

Please review and provide WGLC feedback on this draft so that it
can make progress:
http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Eddy, Wesley M. (GRC-RCN0)[Verizon]
>Sent: Tuesday, April 14, 2009 11:46 AM
>To: [email-masked]
>Cc: [email-masked]; Josh Blanton; [email-masked]
>Subject: [tcpm] WGLC on draft-ietf
>
>We'd like to start a 2-week TCPM working group last call on the
>early retransmit draft:
>http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01
>I don't think the document itself says it, but our charter has
>this for an Experimental target.
>
>WGLC comments would be appreciated by April 30.
>
>The document has been cooking for a long time in TSVWG before
>TCPM took it, and the authors think it's pretty mature based
>on the progress on it there and in TCPM since it was taken
>up by TCPM at IETF 69.
>
>---------------------------
>Wes Eddy
>Network & Systems Architect
>Verizon FNS / NASA GRC
>Office: (216) 433-6682
>---------------------------
>
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 May 2009 16:04:38 +0200

> perfect, then someone should speak up and say so :).

I think the non-SACK stuff should be removed and that the use of SACK  
should be made mandatory.

First of all, this doesn't matter in practice because everybody (for a  
large value of "everybody") supports SACK today anyway.

Second, allowing people to pick and choose arbitrarily is a bad  
precedent and undermines our work.

I would like to see the fast retransmit threshold be dependent on the  
actually observed reordering, but I don't think that would work in the  
common use case addressed here, were the whole session is over after a  
handful of segments.

---

From: Mark Allman <[email-masked]>
Date: Thu, 14 May 2009 10:21:22 -0400

> I think the non-SACK stuff should be removed and that the use of
> SACK  should be made mandatory.
> 
> First of all, this doesn't matter in practice because everybody (for
> a  large value of "everybody") supports SACK today anyway.

We wondered about this at some point in the past and I don't think we
ever developed consensus that completely cutting to SACK was a good
idea.

Personally, I have no problem with it as SACK is clearly the way to go
and, as you note, it is widely supported.  So, I am personally on-board
if the WG wants us to chop those sections out.  (I do not, however,
speak for my co-authors on this.  I don't recall their hit.)

(We just finished putting together a wide-ranging study of traffic from
DSL customers and found 97% of the connections trying to use SACK (i.e.,
in the SYN) and 82% of the connections ultimately using SACK (i.e., also
in the SYN+ACK).  On a host-level we find 82-94% of the hosts use SACK
(the variation is across datasets and also across host counting
techniques since we cannot simply use IP address or even DSL line-id
because of NATs).)

> precedent and undermines our work.

(I don't know that I buy this angle, however.)

> common use case addressed here, were the whole session is over after a

Right... this is a pretty constrained case.  See RFC 4653 for a more
general way to address reordering.

allman

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Thu, 14 May 2009 09:22:41 -0500

Making SACK mandatory is far outside the scope of this draft
and the WGLC ... I think it should be in a separate thread if
we want to consider it, and not impact the near-term progress
of this draft, as this is a much larger (and harder) topic.

The authors can probably speak to the second point about
pegging the retransmit threshold to the observed reordering,
but I would guess that the challenge there lies in measuring
the observed reordering within resource limitations.

>From: Iljitsch van Beijnum [mailto:[email-masked]]
>Sent: Thursday, May 14, 2009 10:05 AM
>To: Eddy, Wesley M. (GRC-MS00)[Verizon]
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]; Blanton
>Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 May 2009 16:27:39 +0200

On 14 mei 2009, at 16:22, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> and the WGLC ...

Obviously I meant within the scope of the draft.

So if you want to implement this draft, you can only do that on a  
system that also implements SACK.

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Thu, 14 May 2009 09:30:13 -0500

Oh, well that makes more sense; for some reason it wasn't
so obvious to me :).  Thanks for clarifying.

>Sent: Thursday, May 14, 2009 10:28 AM
>Cc: [email-masked]

---

From: Mark Allman <[email-masked]>
Date: Thu, 14 May 2009 10:30:24 -0400

> of this draft, as this is a much larger (and harder) topic.

Perhaps we took this comment two different ways.  I took it to suggest
only specifying the SACK variant of early retransmit---which I believe
would be perfectly within he purview of this draft.

> the observed reordering within resource limitations.

Per my previous message ER is so scoped to particular situations that
this isn't all that possible.  We sketch some thoughts to protect
against pathological reordering in the appendix.  Our intent for this
document is that it be experimental and so it is not clear to me what
more we can or should do before this goes experimental.  But, obviously,
we're happy to have input.

allman

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 May 2009 16:44:38 +0200

On 14 mei 2009, at 16:24, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> Oh, and thanks for replying to the WGLC :).  Other than the
> comments you raised, do you think the draft looks good to
> publish?

I don't like the part about tracking the seqnum edges.

Why would someone send 400 byte packets when the MSS is 1400+?

How does this interact with the Nagle algorithm?

---

From: Mark Allman <[email-masked]>
Date: Fri, 15 May 2009 08:38:19 -0400

> Why would someone send 400 byte packets when the MSS is 1400+?

Something interactive like ssh.  Why do we give apps the chance to turn
off Nagle?  It's a big, ugly world with a vast range of behavior.

> How does this interact with the Nagle algorithm?

As sketched in the draft ...

  + You can use a byte-based variant of ER which assumes MSS-sized
    packets.  As discussed in the draft this *can* have precision
    problems in terms of determining the number of packets outstanding
    in the network and therefore when ER should and should not be used.
    In particular, if Nagle is turned off and so short packets are being
    sent then ER can get confused (see two examples in section 2.1.

  + Given that there can be a lack of precision we note that a TCP could
    in fact track the three packets on the right side of the window
    (four sequence numbers) to fully grok how many packets are in the
    network [*] and therefore to more accurately trigger ER.  This in
    particular helps when Nagle is in use.  I am not clear what you are
    getting at by an 'interaction'.  I don't think ER interacts with
    Nagle, but the packet-based variant does cope with Nagle.

    [*] Obviously tracking only the right side of the window doesn't
        give you a fine-grained notion of how many packets are in the
        network in total.  It tells you that either (a) there are at
        least four (and so we're out of the ER regime) or (b) there are
        less than four outstanding packets and how many there actually
        are.  So, it works for ER's purpose.

allman

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 May 2009 16:24:30 +0200

> off Nagle?  It's a big, ugly world with a vast range of behavior.

Yes, but you don't want all that behavior to be reflected in the  
decision tree in your TCP implementation.

Would it be possible to specify a single behavior that is simple,  
provides the intended benefits in the common cases that compromise 90%  
or more of all cases and doesn't do worse than what we have today in  
the remaining cases?

---

From: Mark Allman <[email-masked]>
Date: Mon, 18 May 2009 11:22:41 -0400

> > Something interactive like ssh.  Why do we give apps the chance to
> > turn off Nagle?  It's a big, ugly world with a vast range of
> > behavior.
> 

I guess I have lost track of what you really don't like here.  Early
retransmit depends on having a notion of how many *packets* are
outstanding.  However, since TCP work in terms of *bytes* this is not
readily apparent.  When you get down to it all the draft says is that
you have to somehow figure out how many packets are outstanding and to
do so you can do estimation on one end of the spectrum to full tracking
on the other end.  These options both have their pros and cons and so we
leave it to the implementer to puzzle through these for their own
implementation.

Sure, it would be nice if I could tie a "method [foo] is always best,
use it" bow around this question.  But, I don't know what [foo] is.
Perhaps that can be viewed as part of the experiment here.  If you know
what [foo] is and why then certainly tell us because that's useful
information.  But, in the absence of such an answer that is based on
observations of actual network behavior (i.e., as opposed to simple
conjecture or our all-too-often-wrong mental models of how networks
work) my inclination here is to leave the draft as it is and let the
implementers choose and then we can go look at those those choices are
working after some period of time.

> or more of all cases and doesn't do worse than what we have today in

If don't view any of ER as complicated in any form.  But, certainly
YMMV.  Further, note that ER provides additional opportunities to
retransmit some packet and I do not expect it to be worse that what we
have today.  (The only chance of it being worse is that reordering could
cause needless retransmits that both waste network resources and reduce
the cwnd (although the impact of both of these is likely very minor
within the well-defined scope of ER).)

allman

---

From: Joshua Blanton <[email-masked]>
Date: Mon, 18 May 2009 12:14:21 -0400

Iljitsch van Beijnum wrote:
> or more of all cases and doesn't do worse than what we have today in the 
> remaining cases?

Is that not what section 2.1 describes?  Note that the
boundary-tracking method is *optional* - as is the byte-counting
method - so if an implementor feels that boundary tracking is an
unacceptable burden, it can be left out.  Similarly, if an
implementor feels that the byte-counting method is too inexact, the
boundary-tracking version may be chosen.

Josh

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 25 May 2009 07:11:25 +0900 (JST)

Hi, I've read the draft and I have one very minor comment about it.
It seems to me that the definition of "outstading data/segments" in the document
is a bit ambigious. If it simply defines "data/segments sent but not yet acknowledged",
the data/segments in SACK blocks can be excluded from the definition.

I prefer to have something like the following explanation in the document.
outstanding data/segement is data/segments sent but not yet acknowledged with 
cumulative ACKs and does not include data/segments in SACK blocks.

Thanks,
--
Yoshifumi Nishida
[email-masked]

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01
Date: Wed, 13 May 2009 13:36:48 -0500
Message-ID: <[email-masked]>