From ycheng@google.com Sun Dec 1 10:08:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C388A1ADFF2 for ; Sun, 1 Dec 2013 10:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E920wmAqnxFn for ; Sun, 1 Dec 2013 10:08:42 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 17EBF1ADFEF for ; Sun, 1 Dec 2013 10:08:41 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so19521134iec.35 for ; Sun, 01 Dec 2013 10:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HiWqUClHCUah+Jh0LtPEAUnGuC+/7wQtFdP9qwvUnnQ=; b=iqJZ5KHJfDYxFLWQmjQ0bLQ1UCiSA/2/h14tpJNr6HC48E033FxR+AcdRvPPH83BCV brKDIP9pZ+FADKY3xdJxQb3JIj+7/K3c/XSYnTmzHyB5TXWA61MXOSALbldU00L2RFas yJWkWN9RqqXrPSPwjCXGMlh3chUHzMPK4/TqNiSgBfzJme/NO/LGCKd8a2XnAr+0t2ZU 2f6Z9e+ncduLgYjRPB9Khmtjvl5JxOsH9DNpdW7XZtAgZaLcQbsHOyTKUDD9c6Qz02yB MVweX7NQkpI/oKMg1AWarTR76kB2EjXwfY5QkhZPuZN3sdJSWJoRKKnf2dEH1LoYcb4b etbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HiWqUClHCUah+Jh0LtPEAUnGuC+/7wQtFdP9qwvUnnQ=; b=NfU43lS8xhrbh+F3MTz4JB2t6JdfT0ym1GMVMe3K/+dEmdUq/gSQHKGmAfkRKPHk/v YhDMG5QlKR8uzcDVydPrj+lap2r1HY80OE8bEYBuPVEjOcLAs3mVWVkVg+baolom9gmA w4JM9tHrjFQQPdY0SOjHt/CX59XujhCmpze428g3rUdT8N0bAtA3ZuWMbytkfKtR3oc9 0X0YWluK7bw/mVRD92WZpwDt8JW1rhXmsTWsRQYpapJGebkz4+HldjSI6EZfFal54DIS lNImP9DodaBYtMTZtc/aBnSZFSVCVTlPQtwP3jcdSy5L6calaWt3p5OVSSfcPrLOlzeU eTBQ== X-Gm-Message-State: ALoCoQmzpA+10bhM+iVIf/PaXJXSMQ2EJNQzdgs222PxrBEojxDMK1+PiZfAyf0cKm/qqzuQq5r02ML8DNwbxM67mGk3aNzsWBKkMGutj4oQhWAb123MZ8bHWAA2WldU23As86CkAxdVK8uYUdnV4zr7aHs88qH7o64Vje9DGata1ZEdEGK4GjTH2iUAv3qUJLSFG7nGCZel X-Received: by 10.50.164.130 with SMTP id yq2mr14164234igb.53.1385921319859; Sun, 01 Dec 2013 10:08:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Sun, 1 Dec 2013 10:07:58 -0800 (PST) In-Reply-To: <529A1B65.4070008@erg.abdn.ac.uk> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> <2B85C60B-2301-4B1D-8176-044DAEA817A6@erg.abdn.ac.uk> <528B9E16.70602@erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D13C310@FR712WXCHMBA15.zeu.alcatel-lucent.com> <763b3f8541277a7690bf859a87e69265.squirrel@www.erg.abdn.ac.uk> <529A1B65.4070008@erg.abdn.ac.uk> From: Yuchung Cheng Date: Sun, 1 Dec 2013 10:07:58 -0800 Message-ID: To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=089e0139fceef51fd604ec7cf345 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 18:08:45 -0000 --089e0139fceef51fd604ec7cf345 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst wrote: > > Sorry for the delay (I was unwell), so this email is to restart. > I think we got a long way through discussing things, so I've > summarised below all the points as I understand from my side, > so we and others know where we have arrived and can fix others. > > I support the experimentation with TFO, although I would argue > we do need to write more about how the proposed changes in this > ID will modify STD behaviour and explicitly say how to "negatively" > cache path info that indicates TFO should not be used. > > I would like to see documented the cases where this could > @@potentially@@ be worse than STD mechanisms. The ID already > has some good documentation, but I think it needs a little > more detail especially the set of potential issues that we > expect to be mitigated by a cache at both the client and server > - especially when and why do we need to revoke the cookie > to prevent potentially bad pathologies from being > repeated in a short time between a pair of clients and servers > that keep starting up new connections. > > --- > > The points below hopefully help us see what we can agree on: > > a) Case: cached RTT greater than minRTO > The current text says "RECOMMEND that the client caches the MSS > and RTT to the server to enhance performance." > > I think ideally we should also explicitly say if the RTT is > not cached TCP SHOULD disable use of TFO (make the cookie > invalid) when the RTT>MinRTO. > > ... & note something about "this prevents a premature RTO > for flows with a long RTT and also provides an acceptable RTT > for pacing" - I feel the current text focuses on performance > improvement for a low RTT, but does not explain why it is > important for large RTTs. > > b) Case: cached RTT less than minRTO and path change > We could just note that this ID does not change the behaviour > that a path change can result in an invalid RTT/RTO value, > and that normal TCP behaviour is expected to recover. > no on a and b. The agreed change is to remove RTT caching in TFO spec. TFO will benefit higher RTT client more. Do I need to explain such a simple logic further? min-RTO is not defined in IETF RFCs, nor do I see your new logic improves TFO b/c ultimately cached RTT can be out-dated. I don't see how tweaking TFO with historical RTT values can make it safer. > > c) Case: receiver-advertised MSS less than 536 bytes. > > This is an unusual corner-case and is not one that I think we need > to engineer for. However, I do think we need to note that an IPv4 > receiver advertised MSS less than 536 would result in > transmission of an unexpected large segment to the receiver. > (I.e. say we noted this, but don't change the recommendation). > Why is that specific to TFO? > > d) Case: receiver-advertised MSS greater than 1460 B, > i.e. allowing TFO with large segments. > > I think we should explicitly say MUST NOT use an MSS that > results in a packet size greater than 1500B. > No. if you send a packet too big you risk it getting lost and wish you get some ICMP warnings. Why is that specific to TFO? > > - AND I think we should caution that we do not have current > experience of the effect of this behaviour. We could note > it as an area for further experimentation? I'm not sure what > we agreed? > ok. Sending SYN-data is indeed a new behavior and an area for further experimentation. I think that's why TFO-draft is experimental. I could add more words about this in the "areas for experimentation". > > > e) Case: A sender overwhelms a path with limited capacity. > This is the corner case where a SYN may fail. The issue is most > severe for links that suffer major overload (think low-speed > large multiplexing). > > First SORRY - I'd like to avoid "slightly" and "significantly" > wording - we discussed on the thread - instead what matters > to me really is: > > This draft updates the congestion-control behaviour while the > sender is waiting acknowledgement for a SYN. This will result in > more data (up to one IW of segments) being sent before the sender > receives the ACK for the SYN. This could result in additional > congestion on links that have a high loss rate where the initial > ACK would have been lost, which in standard behaviour would have > resulted in a lower initial congestion window. > I can merge the text above into the draft. > > - personally I see the effect as important to document, > but is OK for experimentation with an IW of 3 (see (g)). > > f) The cookie-less experimental method will likely also need a negative > cache to disable inappropriate TFO usage. > > I'd like to see an explicit note for the future experimentation > something a bit like this would be good: > > "Even if cookie-less methods are found, it is expected that a > future method will still need a way to detect conditions where > TFO should not be used due to path properties and some > equivalent method may then be needed to disable TFO." > ok. > > g) I am unsure that allowing TFO to use IW=10 is safe! > > Best wishes, > > Gorry > > --089e0139fceef51fd604ec7cf345 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst = <gorry@erg.abd= n.ac.uk> wrote:

Sorry for the delay (I was unwell), so this email is to restart.
I think we got a long way through discussing things, so I've
summarised below all the points as I understand from my side,
so we and others know where we have arrived and can fix others.

I support the experimentation with TFO, although I would argue
we do need to write more about how the proposed changes in this
ID will modify STD behaviour and explicitly say how to "negatively&quo= t;
cache path info that indicates TFO should not be used.

I would like to see documented the cases where this could
@@potentially@@ be worse than STD mechanisms. The ID already
has some good documentation, but I think it needs a little
more detail especially the set of potential issues that we
expect to be mitigated by a cache at both the client and server
- especially when and why do we need to revoke the cookie
to prevent potentially bad pathologies from being
repeated in a short time between a pair of clients and servers
that keep starting up new connections.

---

The points below hopefully help us see what we can agree on:

a) Case: cached RTT greater than minRTO
=A0 =A0The current text says "RECOMMEND that the client caches the MSS=
=A0 =A0and RTT to the server to enhance performance."

=A0 =A0I think ideally we should also explicitly say if the RTT is
=A0 =A0not cached TCP SHOULD disable use of TFO (make the cookie
=A0 =A0invalid) when the RTT>MinRTO.

=A0 =A0... & note something about =A0"this prevents a premature RT= O
=A0 =A0for flows with a long RTT and also provides an acceptable RTT
=A0 =A0for pacing" - I feel the current text focuses on performance =A0 =A0improvement for a low RTT, but does not explain why it is
=A0 =A0important for large RTTs.

b) Case: cached RTT less than minRTO and path change
=A0 =A0We could just note that this ID does not change the behaviour
=A0 =A0that a path change can result in an invalid RTT/RTO value,
=A0 =A0and that normal TCP behaviour is expected to recover.
no on a and b.

The agreed change is to= remove RTT caching in TFO spec.
TFO will benefit higher RTT clie= nt more. Do I need to explain such a simple logic further?

min-RTO is not defined in IETF RFCs, nor do= I see your new logic improves TFO b/c ultimately cached RTT can be out-dat= ed. I don't see how tweaking TFO with historical RTT values can make it= safer.
=A0

c) Case: receiver-advertised MSS less than 536 bytes.

=A0 =A0This is an unusual corner-case and is not one that I think we need =A0 =A0to engineer for. However, I do think we need to note that an IPv4 =A0 =A0receiver advertised MSS less than 536 would result in
=A0 =A0transmission of an unexpected large segment to the receiver.
=A0 =A0(I.e. say we noted this, but don't change the recommendation).
Why is that specific to TFO?
=A0

d) Case: receiver-advertised MSS greater than 1460 B,
=A0 =A0i.e. allowing TFO with large segments.

=A0 =A0I think we should explicitly say MUST NOT use an MSS that
=A0 =A0results in a packet size greater than 1500B.
No= . if you send a packet too big you risk it getting lost and wish you get so= me ICMP warnings. Why is that specific to TFO?
=A0

=A0 =A0- AND I think we should caution that we do not have current
=A0 =A0experience of the effect of this behaviour. We could note
=A0 =A0it as an area for further experimentation? I'm not sure what
=A0 =A0we agreed?
ok. Sending SYN-data is indeed a new= behavior and an area for further experimentation. I think that's why T= FO-draft is experimental. I could add more words about this in the "ar= eas for experimentation".
=A0


e) Case: A sender overwhelms a path with limited capacity.
=A0 =A0This is the corner case where a SYN may fail. The issue is most
=A0 =A0severe for links that suffer major overload (think low-speed
=A0 =A0large multiplexing).

=A0 =A0First SORRY - I'd like to avoid "slightly" and "s= ignificantly"
=A0 =A0wording =A0- we discussed on the thread - instead what matters
=A0 =A0to me really is:

=A0 =A0This draft updates the congestion-control behaviour while the
=A0 =A0sender is waiting acknowledgement for a SYN. This will result in
=A0 =A0more data (up to one IW of segments) being sent before the sender =A0 =A0receives the ACK for the SYN. This could result in additional
=A0 =A0congestion on links that have a high loss rate where the initial
=A0 =A0ACK would have been lost, which in standard behaviour would have
=A0 =A0resulted in a lower initial congestion window.
= I can merge the text above into the draft.
=A0

=A0 =A0- personally I see the effect as important to document,
=A0 =A0but is OK for experimentation with an IW of 3 (see (g)).

f) The cookie-less experimental method will likely also need a negative
=A0 =A0cache to disable inappropriate TFO usage.

=A0 =A0I'd like to see an explicit note for the future experimentation<= br> =A0 =A0something a bit like this would be good:

=A0 "Even if cookie-less methods are found, it is expected that a
=A0 =A0future method will still need a way to detect conditions where
=A0 =A0TFO should not be used due to path properties and some
=A0 =A0equivalent method may then be needed to disable TFO."
ok.
=A0

g) I am unsure that allowing TFO to use IW=3D10 is safe!

Best wishes,

Gorry


--089e0139fceef51fd604ec7cf345-- From erkrishna.khanal@gmail.com Mon Dec 2 02:38:09 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B1F1AE301 for ; Mon, 2 Dec 2013 02:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpvy-iaxBIgr for ; Mon, 2 Dec 2013 02:38:07 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1741AE17B for ; Mon, 2 Dec 2013 02:38:06 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so12644650obc.29 for ; Mon, 02 Dec 2013 02:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JudT+1NwZS2zAGZUmMKknjXIgVKI098jEQtQ8x5UMOU=; b=TK+Tp10xjC58YJMxTtw1ozRV0TXyct1k1NQurasg42f2gDNtwS+V06Sxia2Hle5J5p 8O/eetAId3WEhx4UebzzCEgyh6uIAeR2mFjS308MAayiM70t6R4TxQjPfcDdG/PBomN5 txfgAjOwBGSpGa2GWh2bCwH5emXg1Aj6gMZ0+p9pGcVcAIcuuDw2Wbjd3v1WUkWDX4gw m+PfObbQPoM6v0ubdPrdQk8nHgrOnzp+yFIk7819ILMaEtGoMHY2ukkZ5HAUOm92nhvK T2h1kD7pCNLNOfe9qnd4bGYUhDO2bzvPTbwA1Dm64LuuYLkPf+kdl3geiqwYWX3AuqP0 Fx/A== MIME-Version: 1.0 X-Received: by 10.60.134.14 with SMTP id pg14mr136627oeb.66.1385980684667; Mon, 02 Dec 2013 02:38:04 -0800 (PST) Received: by 10.182.135.1 with HTTP; Mon, 2 Dec 2013 02:38:04 -0800 (PST) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25EEEF6D@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F25EEEF6D@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 2 Dec 2013 16:08:04 +0530 Message-ID: From: Krishna Khanal To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=047d7b47286860119804ec8ac660 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] ECN and synCookie X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:38:09 -0000 --047d7b47286860119804ec8ac660 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Richard for the details and these link to the drafts. On Thu, Nov 28, 2013 at 4:11 PM, Scheffenegger, Richard wrot= e: > Hi Krishna, > > > > as the exact way how a Syn-Cookie is formed is an arbitrary choice by the > server doing this, I don=E2=80=99t see that this couldn=E2=80=99t be achi= eved. Also, it > doesn=E2=80=99t need any standards action. > > > > > > Changing the Semantics of the TCP ECN handshake however, would change the > semantics; I=E2=80=99m one of the co-authors of the AccECN drafts, where = a > different signaling is to be defined. The point you make has not yet > brought forward as a requirement to be included in > http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-04. But as we have > not yet settled on any specific encoding to go with these requirements, > something along the lines below could probably be easily added. > > > > For example, what you ask would probably be easy to implement both with > http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-02 and > http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option-01 . > > > > You may also look into the work here > http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback-01 to see > how it could interact. > > > > > > As a side note, even within RFC3168, your (active open) client would have > two (non-standard) options to convey the use of ECN again back to the > (passive open) server. One would be to set the ECT(0) or ECT(1) codepoint > in the ACK =E2=80=93 though RFC1368 doesn=E2=80=99t allow that on pure AC= Ks; the other one > would be to signal CWR in the pure ACK. However, as both approaches are n= ot > specific (and the use of ECT on pure ACKs may have other implications for > the network), you cann=E2=80=99t rely on the server to react properly. > > > > Of course, any data segment from the client to the server would > legitimately contain ECT(0), ECT(1) or CE, and the server could =E2=80=9C= late=E2=80=9D > enable ECN support after receiving such a segment, if the session was set > up using Syn-Cookies. Up to that point (the first ECN-marked segment from > the client), the server could send regular, non-ECN segments, and I think > such a session would be fully compliant =E2=80=93 just not make use of EC= N until > the first indication of ECN from the client=E2=80=A6 > > > > > > Best regards, > > > > Richard Scheffenegger > > > > *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Krishna Khanal > *Sent:* Donnerstag, 28. November 2013 06:28 > *To:* tcpm@ietf.org > *Subject:* [tcpm] ECN and synCookie > > > > > > A server with synCookie support generally replies the important options > received on SYN from > > client on its SYN+ACK packet to client after encoding it in its ISS. Sinc= e > the number of options > > exchanged in SYN are growing, there are some alternate ways to remember > this, like echoing > > the options in timestamp so that it can be offloaded from ISS. > > > > One of the option exchanged in handshake is ECN. When a server receives a > SYN with ECE+CWR > > set, it replies with ECE. if server has synCookie enabled, it must > remember this on ISS as well. > > > > What about echoing back the ECE option on final ack? If client receives > SYN+ACK with ECE, it can > > set ECE on final ack and send it to server. > > > > With this, there are two advantages: > > 1. no need to encode the ECN capability on syncookie > > 2. if the path is asymmetric (though path can change anytime), client can > inform server about it, > > if the ECE is not set on final ack, server can ignore ECN even if its > enabled. > > > > Were there any discussions in the past on this? Does this make any sense? > > > > Regards, > > Krishna > > > > > --047d7b47286860119804ec8ac660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Richard for the details and these link to the draft= s.


On Th= u, Nov 28, 2013 at 4:11 PM, Scheffenegger, Richard <rs@netapp.com> wrote:

Hi Krishna,=

=C2=A0

as the exa= ct way how a Syn-Cookie is formed is an arbitrary choice by the server doin= g this, I don=E2=80=99t see that this couldn=E2=80=99t be achieved. Also, it doesn=E2=80=99t need any standards action.

=C2= =A0

=C2= =A0

Changing t= he Semantics of the TCP ECN handshake however, would change the semantics; = I=E2=80=99m one of the co-authors of the AccECN drafts, where a different signaling is to be defined. The point you make has not yet brought forward= as a requirement to be included in http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-04.= But as we have not yet settled on any specific encoding to go with these r= equirements, something along the lines below could probably be easily added.

=C2= =A0

For exampl= e, what you ask would probably be easy to implement both with http://tools.ietf.org/html/draft-kuehlewind-tcpm-accura= te-ecn-02 and http://tools.ietf.org/html/dra= ft-kuehlewind-tcpm-accurate-ecn-option-01 .

=C2= =A0

You may al= so look into the work here http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fa= llback-01 to see how it could interact.

=C2= =A0

=C2= =A0

As a side = note, even within RFC3168, your (active open) client would have two (non-st= andard) options to convey the use of ECN again back to the (passive open) server. One would be to set the ECT(0) or ECT(1) codepoint = in the ACK =E2=80=93 though RFC1368 doesn=E2=80=99t allow that on pure ACKs= ; the other one would be to signal CWR in the pure ACK. However, as both ap= proaches are not specific (and the use of ECT on pure ACKs may have other implications for the network), you cann=E2=80=99t= rely on the server to react properly.

=C2= =A0

Of course,= any data segment from the client to the server would legitimately contain = ECT(0), ECT(1) or CE, and the server could =E2=80=9Clate=E2=80=9D enable EC= N support after receiving such a segment, if the session was set up using Sy= n-Cookies. Up to that point (the first ECN-marked segment from the client),= the server could send regular, non-ECN segments, and I think such a sessio= n would be fully compliant =E2=80=93 just not make use of ECN until the first indication of ECN from the client=E2= =80=A6

=C2= =A0

=C2= =A0

Best regar= ds,

=C2= =A0

Richard Scheffenegger

=C2=A0

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Krishna Khanal
Sent: Donnerstag, 28. November 2013 06:28
To: tcpm@ietf.org=
Subject: [tcpm] ECN and synCookie

=C2=A0

=C2=A0

A server with synCookie support generally replies the impo= rtant options received on SYN from

client on its SYN+ACK packet to client after encoding it i= n its ISS. Since the number of options

exchanged in SYN are growing, there are some alternate way= s to remember this, like echoing=C2=A0

the options in timestamp so that it can be offloaded from = ISS.

=C2=A0

One of the option exchanged in handshake is ECN. When a se= rver receives a SYN with ECE+CWR

set, it replies with ECE. if server has synCookie enabled,= it must remember this on ISS as well.

=C2=A0

What about echoing back the ECE option on final ack? If cl= ient receives SYN+ACK with ECE, it can

set ECE on final ack and send it to server.<= u>

=C2=A0

With this, there are two advantages:<= /p>

1. no need to encode the ECN capability on syncookie

2. if the path is=C2=A0asymmetric (though path can change = anytime), client can inform server about it,=C2=A0

if the ECE is not set on final ack, server can ignore ECN = even if its enabled.

=C2=A0

Were there any discussions in the past on this? Does this = make any sense?

=C2=A0

Regards,

Krishna

=C2=A0

=C2=A0


--047d7b47286860119804ec8ac660-- From michael.scharf@alcatel-lucent.com Mon Dec 2 05:49:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512821AE481 for ; Mon, 2 Dec 2013 05:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 672kA37BmYuu for ; Mon, 2 Dec 2013 05:49:30 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0C1AE47D for ; Mon, 2 Dec 2013 05:49:29 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rB2DnLPN010106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Dec 2013 07:49:22 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rB2Dn6TV012955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 14:49:20 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.70]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 2 Dec 2013 14:49:12 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng , Gorry Fairhurst Thread-Topic: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: AQHO7sBndOaHz/07X0aAbiel8ahxGJpA3r7g Date: Mon, 2 Dec 2013 13:49:11 +0000 Message-ID: <655C07320163294895BBADA28372AF5D140964@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> <2B85C60B-2301-4B1D-8176-044DAEA817A6@erg.abdn.ac.uk> <528B9E16.70602@erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D13C310@FR712WXCHMBA15.zeu.alcatel-lucent.com> <763b3f8541277a7690bf859a87e69265.squirrel@www.erg.abdn.ac.uk> <529A1B65.4070008@erg.abdn.ac.uk> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D140964FR712WXCHMBA15zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:49:35 -0000 --_000_655C07320163294895BBADA28372AF5D140964FR712WXCHMBA15zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments, with chair hat off... a)+b): I have no strong opinion on whether the connection initiator (client) shoul= d cache the RTT, or not. It seems partly orthogonal to TFO. If the RTO expi= res spuriously, the document recommends to retransmit without data in SYN, = i.e., the amount of bytes sent into the network is the same as for regular = TCP. From a congestion control perspective, the result is more or less the = same. However, after having followed this discussion, I wonder why the document d= oes not comment at all about RTT estimation at the connection acceptor (ser= ver). With TFO, the connection acceptor (server) is allowed to send a full = IW of data back to the connection initiator (client), following the SYN-ACK= . However, at that point in time, the connection acceptor (server) has no r= ecent RTT measurement, right? This is different to the traditional TCP hand= shake, in which an RTT measurement is available before data is sent into th= e network. The fact that TFO allows sending of a full IW of data before an= RTT estimation is available should be mentioned as a warning sign, IMHO. F= or instance, it will make it more difficult to apply pacing. c)+d): In almost all existing use of regular TCP, the endpoints negotiate the MSS = before actually sending any data, because adding data to SYNs doesn't make = a lot of sense without TFO. Therefore, "MSS clamping" in middleboxes usuall= y works for regular TCP, and it may avoid PMTUD procedures in many cases. W= ith TFO, the situation can be more complex. In addition to the case of MSS<= 536 bytes raised by Gorry, it is also not clear to me what a middlebox shou= ld do if it receives a TFO SYN with data, and if this segment is larger tha= n the "MSS clamping" value of that middlebox. This corner case can occur e.= g. after path routing changes. Therefore, I agree with Gorry that the docum= ent should at least mention that MSS issues may require further experimenta= tion. Thanks Michael From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng Sent: Sunday, December 01, 2013 7:08 PM To: Gorry Fairhurst Cc: tcpm@ietf.org; draft-ietf-tcpm-fastopen@tools.ietf.org Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tc= pm-fastopen-05 On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst > wrote: Sorry for the delay (I was unwell), so this email is to restart. I think we got a long way through discussing things, so I've summarised below all the points as I understand from my side, so we and others know where we have arrived and can fix others. I support the experimentation with TFO, although I would argue we do need to write more about how the proposed changes in this ID will modify STD behaviour and explicitly say how to "negatively" cache path info that indicates TFO should not be used. I would like to see documented the cases where this could @@potentially@@ be worse than STD mechanisms. The ID already has some good documentation, but I think it needs a little more detail especially the set of potential issues that we expect to be mitigated by a cache at both the client and server - especially when and why do we need to revoke the cookie to prevent potentially bad pathologies from being repeated in a short time between a pair of clients and servers that keep starting up new connections. --- The points below hopefully help us see what we can agree on: a) Case: cached RTT greater than minRTO The current text says "RECOMMEND that the client caches the MSS and RTT to the server to enhance performance." I think ideally we should also explicitly say if the RTT is not cached TCP SHOULD disable use of TFO (make the cookie invalid) when the RTT>MinRTO. ... & note something about "this prevents a premature RTO for flows with a long RTT and also provides an acceptable RTT for pacing" - I feel the current text focuses on performance improvement for a low RTT, but does not explain why it is important for large RTTs. b) Case: cached RTT less than minRTO and path change We could just note that this ID does not change the behaviour that a path change can result in an invalid RTT/RTO value, and that normal TCP behaviour is expected to recover. no on a and b. The agreed change is to remove RTT caching in TFO spec. TFO will benefit higher RTT client more. Do I need to explain such a simple= logic further? min-RTO is not defined in IETF RFCs, nor do I see your new logic improves T= FO b/c ultimately cached RTT can be out-dated. I don't see how tweaking TFO= with historical RTT values can make it safer. c) Case: receiver-advertised MSS less than 536 bytes. This is an unusual corner-case and is not one that I think we need to engineer for. However, I do think we need to note that an IPv4 receiver advertised MSS less than 536 would result in transmission of an unexpected large segment to the receiver. (I.e. say we noted this, but don't change the recommendation). Why is that specific to TFO? d) Case: receiver-advertised MSS greater than 1460 B, i.e. allowing TFO with large segments. I think we should explicitly say MUST NOT use an MSS that results in a packet size greater than 1500B. No. if you send a packet too big you risk it getting lost and wish you get = some ICMP warnings. Why is that specific to TFO? - AND I think we should caution that we do not have current experience of the effect of this behaviour. We could note it as an area for further experimentation? I'm not sure what we agreed? ok. Sending SYN-data is indeed a new behavior and an area for further exper= imentation. I think that's why TFO-draft is experimental. I could add more = words about this in the "areas for experimentation". e) Case: A sender overwhelms a path with limited capacity. This is the corner case where a SYN may fail. The issue is most severe for links that suffer major overload (think low-speed large multiplexing). First SORRY - I'd like to avoid "slightly" and "significantly" wording - we discussed on the thread - instead what matters to me really is: This draft updates the congestion-control behaviour while the sender is waiting acknowledgement for a SYN. This will result in more data (up to one IW of segments) being sent before the sender receives the ACK for the SYN. This could result in additional congestion on links that have a high loss rate where the initial ACK would have been lost, which in standard behaviour would have resulted in a lower initial congestion window. I can merge the text above into the draft. - personally I see the effect as important to document, but is OK for experimentation with an IW of 3 (see (g)). f) The cookie-less experimental method will likely also need a negative cache to disable inappropriate TFO usage. I'd like to see an explicit note for the future experimentation something a bit like this would be good: "Even if cookie-less methods are found, it is expected that a future method will still need a way to detect conditions where TFO should not be used due to path properties and some equivalent method may then be needed to disable TFO." ok. g) I am unsure that allowing TFO to use IW=3D10 is safe! Best wishes, Gorry --_000_655C07320163294895BBADA28372AF5D140964FR712WXCHMBA15zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some comme= nts, with chair hat off…

 = ;

a)+b):=

 = ;

I have no = strong opinion on whether the connection initiator (client) should cache th= e RTT, or not. It seems partly orthogonal to TFO. If the RTO expires spuriously, the document recommends to retransmit without data in = SYN, i.e., the amount of bytes sent into the network is the same as for reg= ular TCP. From a congestion control perspective, the result is more or less= the same.

 = ;

However, a= fter having followed this discussion, I wonder why the document does not co= mment at all about RTT estimation at the connection acceptor (server). With TFO, the connection acceptor (server) is allowed to send a = full IW of data back to the connection initiator (client), following the SY= N-ACK. However, at that point in time, the connection acceptor (server) has= no recent RTT measurement, right? This is different to the traditional TCP handshake, in which an RTT measur= ement is available before data is sent into the network.  The fact tha= t TFO allows sending of a full IW of data before an RTT estimation is avail= able should be mentioned as a warning sign, IMHO. For instance, it will make it more difficult to apply pacing.<= o:p>

 = ;

c)+d):=

 = ;

In almost = all existing use of regular TCP, the endpoints negotiate the MSS before act= ually sending any data, because adding data to SYNs doesn’t make a lot of sense without TFO. Therefore, “MSS clamping” in = middleboxes usually works for regular TCP, and it may avoid PMTUD procedure= s in many cases. With TFO, the situation can be more complex. In addition t= o the case of MSS<536 bytes raised by Gorry, it is also not clear to me what a middlebox should do if it receives a TFO= SYN with data, and if this segment is larger than the “MSS clamping&= #8221; value of that middlebox. This corner case can occur e.g. after path = routing changes. Therefore, I agree with Gorry that the document should at least mention that MSS issues may require furt= her experimentation.

 = ;

Thanks

 = ;

Michael

 = ;

 = ;

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng
Sent: Sunday, December 01, 2013 7:08 PM
To: Gorry Fairhurst
Cc: tcpm@ietf.org; draft-ietf-tcpm-fastopen@tools.ietf.org
Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-= ietf-tcpm-fastopen-05

 

 

 

On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst <= ;gorry@erg.abdn.a= c.uk> wrote:


Sorry for the delay (I was unwell), so this email is to restart.
I think we got a long way through discussing things, so I've
summarised below all the points as I understand from my side,
so we and others know where we have arrived and can fix others.

I support the experimentation with TFO, although I would argue
we do need to write more about how the proposed changes in this
ID will modify STD behaviour and explicitly say how to "negatively&quo= t;
cache path info that indicates TFO should not be used.

I would like to see documented the cases where this could
@@potentially@@ be worse than STD mechanisms. The ID already
has some good documentation, but I think it needs a little
more detail especially the set of potential issues that we
expect to be mitigated by a cache at both the client and server
- especially when and why do we need to revoke the cookie
to prevent potentially bad pathologies from being
repeated in a short time between a pair of clients and servers
that keep starting up new connections.

---

The points below hopefully help us see what we can agree on:

a) Case: cached RTT greater than minRTO
   The current text says "RECOMMEND that the client caches t= he MSS
   and RTT to the server to enhance performance."

   I think ideally we should also explicitly say if the RTT is    not cached TCP SHOULD disable use of TFO (make the cookie
   invalid) when the RTT>MinRTO.

   ... & note something about  "this prevents a pre= mature RTO
   for flows with a long RTT and also provides an acceptable RTT<= br>    for pacing" - I feel the current text focuses on performa= nce
   improvement for a low RTT, but does not explain why it is
   important for large RTTs.


b) Case: cached RTT less than minRTO and path change
   We could just note that this ID does not change the behaviour<= br>    that a path change can result in an invalid RTT/RTO value,
   and that normal TCP behaviour is expected to recover.

no on a and b.

 

The agreed change is to remove RTT caching in TFO sp= ec.

TFO will benefit higher RTT client more. Do I need t= o explain such a simple logic further?

 

min-RTO is not defined in IETF RFCs, nor do I see yo= ur new logic improves TFO b/c ultimately cached RTT can be out-dated. I don= 't see how tweaking TFO with historical RTT values can make it safer.<= /o:p>

 


c) Case: receiver-advertised MSS less than 536 bytes.

   This is an unusual corner-case and is not one that I think we = need
   to engineer for. However, I do think we need to note that an I= Pv4
   receiver advertised MSS less than 536 would result in
   transmission of an unexpected large segment to the receiver.    (I.e. say we noted this, but don't change the recommendation).=

Why is that specific to TFO?

 


d) Case: receiver-advertised MSS greater than 1460 B,
   i.e. allowing TFO with large segments.

   I think we should explicitly say MUST NOT use an MSS that
   results in a packet size greater than 1500B.

No. if you send a packet too big you risk it getting= lost and wish you get some ICMP warnings. Why is that specific to TFO?

 


   - AND I think we should caution that we do not have current    experience of the effect of this behaviour. We could note
   it as an area for further experimentation? I'm not sure what    we agreed?

ok. Sending SYN-data is indeed a new behavior and an= area for further experimentation. I think that's why TFO-draft is experime= ntal. I could add more words about this in the "areas for experimentat= ion".

 



e) Case: A sender overwhelms a path with limited capacity.
   This is the corner case where a SYN may fail. The issue is mos= t
   severe for links that suffer major overload (think low-speed    large multiplexing).

   First SORRY - I'd like to avoid "slightly" and "= ;significantly"
   wording  - we discussed on the thread - instead what matt= ers
   to me really is:

   This draft updates the congestion-control behaviour while the<= br>    sender is waiting acknowledgement for a SYN. This will result = in
   more data (up to one IW of segments) being sent before the sen= der
   receives the ACK for the SYN. This could result in additional<= br>    congestion on links that have a high loss rate where the initi= al
   ACK would have been lost, which in standard behaviour would ha= ve
   resulted in a lower initial congestion window.

I can merge the text above into the draft.

 


   - personally I see the effect as important to document,
   but is OK for experimentation with an IW of 3 (see (g)).

f) The cookie-less experimental method will likely also need a negative
   cache to disable inappropriate TFO usage.

   I'd like to see an explicit note for the future experimentatio= n
   something a bit like this would be good:

  "Even if cookie-less methods are found, it is expected that a    future method will still need a way to detect conditions where=
   TFO should not be used due to path properties and some
   equivalent method may then be needed to disable TFO."

ok.

 


g) I am unsure that allowing TFO to use IW=3D10 is safe!


Best wishes,

Gorry

 

--_000_655C07320163294895BBADA28372AF5D140964FR712WXCHMBA15zeu_-- From touch@isi.edu Mon Dec 2 10:50:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0151ADBCA for ; Mon, 2 Dec 2013 10:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTv6aggw3aMs for ; Mon, 2 Dec 2013 10:50:58 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 42DB61ADAEA for ; Mon, 2 Dec 2013 10:50:58 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id rB2IoHcj005653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Dec 2013 10:50:27 -0800 (PST) Message-ID: <529CD66F.8030806@isi.edu> Date: Mon, 02 Dec 2013 10:50:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Krishna Khanal , tcpm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] ECN and synCookie X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:50:59 -0000 On 11/27/2013 9:27 PM, Krishna Khanal wrote: > > One of the option exchanged in handshake is ECN. When a server receives > a SYN with ECE+CWR > set, it replies with ECE. if server has synCookie enabled, it must > remember this on ISS as well. > > What about echoing back the ECE option on final ack? If client receives > SYN+ACK with ECE, it can > set ECE on final ack and send it to server. > > With this, there are two advantages: > 1. no need to encode the ECN capability on syncookie > 2. if the path is asymmetric (though path can change anytime), client > can inform server about it, > if the ECE is not set on final ack, server can ignore ECN even if its > enabled. > > Were there any discussions in the past on this? Does this make any sense? We've talked at various times on this list about the potential to start options in mid-stream, i.e., after then SYN exchange. The big problem is that the three-way handshake ensures agreement only during the initial SYN exchange. Doing that afterwards has a lot of problems - how to handle retransmission, packets sent until the state is coordinated, etc. Joe From ycheng@google.com Mon Dec 2 16:33:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9F1ADEC0 for ; Mon, 2 Dec 2013 16:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuBzuVQa-PWu for ; Mon, 2 Dec 2013 16:33:07 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 055711ADFD8 for ; Mon, 2 Dec 2013 16:33:06 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so22995747iec.9 for ; Mon, 02 Dec 2013 16:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tYQyqJ1OWrWEFQiwDhDfIFotYgfShXlnm0f8mU+9dZo=; b=diY3GrQidfHbZYKCihl5NTyYW2lGo5r2lzZr4DiK4nIMX05+s6xvSeko128boTpeZB PHsH+5RPAkr9N0i6QawrbYk66Mp5TSFXaFMObr9BIsiuGAVpzUgQo8ZK0ppWjUtZj/01 EVx40IXPuxC50tR4K8f/ol30mv/a3l4MOOM4ozw8IqD//LzlZu4m1yq/GlPXNvsK485f 1DRkZ9n9NWVJAuPjB6dOTEhuu2yghgIOXnhGNbnP0wzpNYADAXjzQHIbZTVwdBqrHtqv XIOvA4p62y8ic7K+NC1qNelKIQsm5M6cd19JdyP3lngMsUQoAbWG7cNzj1NkMU0yWpI1 268Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tYQyqJ1OWrWEFQiwDhDfIFotYgfShXlnm0f8mU+9dZo=; b=K/N9YSwd3oiEdSox4hEw2vb9cpOJCkGBVFRmW3bIRvcDXUCCTtkJGSSB97agHdE1L3 CnXxkBb8dxFeuwkYNhT3pNveT8TMFY5QvSKjIQXydKF+blH5cWltPZR9IK4OpO5w0NVB sPSk0eB2qjlxYjLi/o3u/H34xxlkEXGHn4bYGHWHPIOcb+0P4GCTDUwHhj+9tV9M0Flt G1oA4WWBNL1b4NesgEJDQs0I7x35zGCNu25TDk79pA3EpxGK9Drr1VJuZ20rhh+RxDZL osWbnllEjsLLgMw2w3hHq0BkuzPOV6VmpNqBiUrAcKsK/ZL+tJhNgYBQcModnjeFw0v2 uMdw== X-Gm-Message-State: ALoCoQlF1S5BAoJf8wvWkIEE5cGjBYP4qgG4v+d6gEefKDUZbrvmGvdhGztM3TzltagEkOE23pr/svLapJHXboa8uuSXW3i2TZbcfAeQ9WQGjYzrmuryPPjelkwUDTs8D8jQftQ0ztl5waTBqDPlK3rujRK/JSWjemOkTjL9ijduxLu7p2tcUX1kwMdyKHtwU++83HqX+mvu X-Received: by 10.50.164.165 with SMTP id yr5mr38243igb.38.1386030784421; Mon, 02 Dec 2013 16:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.170.3 with HTTP; Mon, 2 Dec 2013 16:32:24 -0800 (PST) In-Reply-To: <655C07320163294895BBADA28372AF5D140964@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> <2B85C60B-2301-4B1D-8176-044DAEA817A6@erg.abdn.ac.uk> <528B9E16.70602@erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D13C310@FR712WXCHMBA15.zeu.alcatel-lucent.com> <763b3f8541277a7690bf859a87e69265.squirrel@www.erg.abdn.ac.uk> <529A1B65.4070008@erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D140964@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 2 Dec 2013 16:32:24 -0800 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=089e01229ed48db5b404ec9670d3 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 00:33:10 -0000 --089e01229ed48db5b404ec9670d3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Dec 2, 2013 at 5:49 AM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > Some comments, with chair hat off=85 > > > > a)+b): > > > > I have no strong opinion on whether the connection initiator (client) > should cache the RTT, or not. It seems partly orthogonal to TFO. If the R= TO > expires spuriously, the document recommends to retransmit without data in > SYN, i.e., the amount of bytes sent into the network is the same as for > regular TCP. From a congestion control perspective, the result is more or > less the same. > > > > However, after having followed this discussion, I wonder why the document > does not comment at all about RTT estimation at the connection acceptor > (server). With TFO, the connection acceptor (server) is allowed to send a > full IW of data back to the connection initiator (client), following the > SYN-ACK. However, at that point in time, the connection acceptor (server) > has no recent RTT measurement, right? This is different to the traditiona= l > TCP handshake, in which > correct > an RTT measurement is available before data is sent into the network. Th= e > fact that TFO allows sending of a full IW of data before an RTT estimatio= n > is available should be mentioned as a warning sign, IMHO. For instance, i= t > will make it more difficult to apply pacing. > I can add that point about RTT estimation. > > > c)+d): > > > > In almost all existing use of regular TCP, the endpoints negotiate the MS= S > before actually sending any data, because adding data to SYNs doesn=92t m= ake > a lot of sense without TFO. Therefore, =93MSS clamping=94 in middleboxes > usually works for regular TCP, and it may avoid PMTUD procedures in many > cases. With TFO, the situation can be more > I need more information about the MSS clamping feature. My understanding (which can be wrong) of MSS clamping is that the middle-box is transparently reducing the value in the MSS option in the SYN packet. If so the connection that negotiate the cookie, should receive and cache the reduced value, which will be used by the later Fast Open connection. It is possible the middle-box lowers the MSS prior the to SYN-data. In that case it is equivalent to sending a SYN-data, or a data packet on a new path that has lower MTU. In that case, the remedy is ICMP error or ultimately a timeout. When recurring SYN-data timeouts happen, then the client should disable Fast Open (temporarily) due to the negative caching suggested in the draft. > complex. In addition to the case of MSS<536 bytes raised by Gorry, it is > also not clear to me what a middlebox should do if it receives a TFO SYN > with data, and if this segment is larger than the =93MSS clamping=94 valu= e of > that middlebox. This corner case can occur e.g. after path routing change= s. > Therefore, I agree with Gorry that the document should at least mention > that MSS issues may require further experimentation. > As replied earlier, I will document SYN-data / middlebox issue as the "area of experimentation" in the previous email. > > > Thanks > > > > Michael > > > > > > *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Yuchung Cheng > *Sent:* Sunday, December 01, 2013 7:08 PM > *To:* Gorry Fairhurst > *Cc:* tcpm@ietf.org; draft-ietf-tcpm-fastopen@tools.ietf.org > *Subject:* Re: [tcpm] Summary of mt comments/questions WGLC for > draft-ietf-tcpm-fastopen-05 > > > > > > > > On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst > wrote: > > > Sorry for the delay (I was unwell), so this email is to restart. > I think we got a long way through discussing things, so I've > summarised below all the points as I understand from my side, > so we and others know where we have arrived and can fix others. > > I support the experimentation with TFO, although I would argue > we do need to write more about how the proposed changes in this > ID will modify STD behaviour and explicitly say how to "negatively" > cache path info that indicates TFO should not be used. > > I would like to see documented the cases where this could > @@potentially@@ be worse than STD mechanisms. The ID already > has some good documentation, but I think it needs a little > more detail especially the set of potential issues that we > expect to be mitigated by a cache at both the client and server > - especially when and why do we need to revoke the cookie > to prevent potentially bad pathologies from being > repeated in a short time between a pair of clients and servers > that keep starting up new connections. > > --- > > The points below hopefully help us see what we can agree on: > > a) Case: cached RTT greater than minRTO > The current text says "RECOMMEND that the client caches the MSS > and RTT to the server to enhance performance." > > I think ideally we should also explicitly say if the RTT is > not cached TCP SHOULD disable use of TFO (make the cookie > invalid) when the RTT>MinRTO. > > ... & note something about "this prevents a premature RTO > for flows with a long RTT and also provides an acceptable RTT > for pacing" - I feel the current text focuses on performance > improvement for a low RTT, but does not explain why it is > important for large RTTs. > > > b) Case: cached RTT less than minRTO and path change > We could just note that this ID does not change the behaviour > that a path change can result in an invalid RTT/RTO value, > and that normal TCP behaviour is expected to recover. > > no on a and b. > > > > The agreed change is to remove RTT caching in TFO spec. > > TFO will benefit higher RTT client more. Do I need to explain such a > simple logic further? > > > > min-RTO is not defined in IETF RFCs, nor do I see your new logic improves > TFO b/c ultimately cached RTT can be out-dated. I don't see how tweaking > TFO with historical RTT values can make it safer. > > > > > c) Case: receiver-advertised MSS less than 536 bytes. > > This is an unusual corner-case and is not one that I think we need > to engineer for. However, I do think we need to note that an IPv4 > receiver advertised MSS less than 536 would result in > transmission of an unexpected large segment to the receiver. > (I.e. say we noted this, but don't change the recommendation). > > Why is that specific to TFO? > > > > > d) Case: receiver-advertised MSS greater than 1460 B, > i.e. allowing TFO with large segments. > > I think we should explicitly say MUST NOT use an MSS that > results in a packet size greater than 1500B. > > No. if you send a packet too big you risk it getting lost and wish you > get some ICMP warnings. Why is that specific to TFO? > > > > > - AND I think we should caution that we do not have current > experience of the effect of this behaviour. We could note > it as an area for further experimentation? I'm not sure what > we agreed? > > ok. Sending SYN-data is indeed a new behavior and an area for further > experimentation. I think that's why TFO-draft is experimental. I could ad= d > more words about this in the "areas for experimentation". > > > > > > e) Case: A sender overwhelms a path with limited capacity. > This is the corner case where a SYN may fail. The issue is most > severe for links that suffer major overload (think low-speed > large multiplexing). > > First SORRY - I'd like to avoid "slightly" and "significantly" > wording - we discussed on the thread - instead what matters > to me really is: > > This draft updates the congestion-control behaviour while the > sender is waiting acknowledgement for a SYN. This will result in > more data (up to one IW of segments) being sent before the sender > receives the ACK for the SYN. This could result in additional > congestion on links that have a high loss rate where the initial > ACK would have been lost, which in standard behaviour would have > resulted in a lower initial congestion window. > > I can merge the text above into the draft. > > > > > - personally I see the effect as important to document, > but is OK for experimentation with an IW of 3 (see (g)). > > f) The cookie-less experimental method will likely also need a negative > cache to disable inappropriate TFO usage. > > I'd like to see an explicit note for the future experimentation > something a bit like this would be good: > > "Even if cookie-less methods are found, it is expected that a > future method will still need a way to detect conditions where > TFO should not be used due to path properties and some > equivalent method may then be needed to disable TFO." > > ok. > > > > > g) I am unsure that allowing TFO to use IW=3D10 is safe! > > > Best wishes, > > Gorry > > > --089e01229ed48db5b404ec9670d3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 2, 2013 at 5:49 AM, Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:

Some comme= nts, with chair hat off=85

=A0=

a)+b):<= /u>

=A0=

I have no = strong opinion on whether the connection initiator (client) should cache th= e RTT, or not. It seems partly orthogonal to TFO. If the RTO expires spuriously, the document recommends to retransmit without data in = SYN, i.e., the amount of bytes sent into the network is the same as for reg= ular TCP. From a congestion control perspective, the result is more or less= the same.

=A0=

However, a= fter having followed this discussion, I wonder why the document does not co= mment at all about RTT estimation at the connection acceptor (server). With TFO, the connection acceptor (server) is allowed to send a = full IW of data back to the connection initiator (client), following the SY= N-ACK. However, at that point in time, the connection acceptor (server) has= no recent RTT measurement, right? This is different to the traditional TCP handshake, in which

correct=A0
=

an RT= T measurement is available before data is sent into the network. =A0The fac= t that TFO allows sending of a full IW of data before an RTT estimation is = available should be mentioned as a warning sign, IMHO. For instance, it will make it more difficult to apply pacing.<= /span>

I can add that point about RTT esti= mation.
=A0

=A0=

c)+d):<= /u>

=A0=

In almost = all existing use of regular TCP, the endpoints negotiate the MSS before act= ually sending any data, because adding data to SYNs doesn=92t make a lot of sense without TFO. Therefore, =93MSS clamping=94 in middlebo= xes usually works for regular TCP, and it may avoid PMTUD procedures in man= y cases. With TFO, the situation can be more

I need more information about the MSS clamping feature.=A0
<= br>
My understanding (which can be wrong) of MSS clamping is that= the middle-box is transparently reducing the value in the MSS option in th= e SYN packet. If so the connection that negotiate the cookie, should receiv= e and cache the reduced value, which will be used by the later Fast Open co= nnection.

It is possible the middle-box lowers the MSS prior the = to SYN-data. In that case it is equivalent to sending a SYN-data, or a data= packet on a new path that has lower MTU. In that case, the remedy is ICMP = error or ultimately a timeout. When recurring SYN-data timeouts happen, the= n the client should disable Fast Open (temporarily) due to the negative cac= hing suggested in the draft.
=A0

complex. In addition to the case of MSS<536 bytes raised by= Gorry, it is also not clear to me what a middlebox should do if it receives a TFO= SYN with data, and if this segment is larger than the =93MSS clamping=94 v= alue of that middlebox. This corner case can occur e.g. after path routing = changes. Therefore, I agree with Gorry that the document should at least mention that MSS issues may require furt= her experimentation.

As replied ear= lier, I will document SYN-data / middlebox issue as the "area of exper= imentation" in the previous email.
=A0

=A0=

Thanks<= /u>

=A0=

Michael=

=A0=

=A0=

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng
Sent: Sunday, December 01, 2013 7:08 PM
To: Gorry Fairhurst
Cc: tcpm@ietf.org= ; draft-ietf-tcpm-fastopen@tools.ietf.org
Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-= ietf-tcpm-fastopen-05

=A0

=A0

=A0

On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst <= ;gorry@erg.abdn.a= c.uk> wrote:


Sorry for the delay (I was unwell), so this email is to restart.
I think we got a long way through discussing things, so I've
summarised below all the points as I understand from my side,
so we and others know where we have arrived and can fix others.

I support the experimentation with TFO, although I would argue
we do need to write more about how the proposed changes in this
ID will modify STD behaviour and explicitly say how to "negatively&quo= t;
cache path info that indicates TFO should not be used.

I would like to see documented the cases where this could
@@potentially@@ be worse than STD mechanisms. The ID already
has some good documentation, but I think it needs a little
more detail especially the set of potential issues that we
expect to be mitigated by a cache at both the client and server
- especially when and why do we need to revoke the cookie
to prevent potentially bad pathologies from being
repeated in a short time between a pair of clients and servers
that keep starting up new connections.

---

The points below hopefully help us see what we can agree on:

a) Case: cached RTT greater than minRTO
=A0 =A0The current text says "RECOMMEND that the client caches the MSS=
=A0 =A0and RTT to the server to enhance performance."

=A0 =A0I think ideally we should also explicitly say if the RTT is
=A0 =A0not cached TCP SHOULD disable use of TFO (make the cookie
=A0 =A0invalid) when the RTT>MinRTO.

=A0 =A0... & note something about =A0"this prevents a premature RT= O
=A0 =A0for flows with a long RTT and also provides an acceptable RTT
=A0 =A0for pacing" - I feel the current text focuses on performance =A0 =A0improvement for a low RTT, but does not explain why it is
=A0 =A0important for large RTTs.


b) Case: cached RTT less than minRTO and path change
=A0 =A0We could just note that this ID does not change the behaviour
=A0 =A0that a path change can result in an invalid RTT/RTO value,
=A0 =A0and that normal TCP behaviour is expected to recover.<= /p>

no on a and b.

=A0

The agreed change is to remove RTT caching in TFO sp= ec.

TFO will benefit higher RTT client more. Do I need t= o explain such a simple logic further?

=A0

min-RTO is not defined in IETF RFCs, nor do I see yo= ur new logic improves TFO b/c ultimately cached RTT can be out-dated. I don= 't see how tweaking TFO with historical RTT values can make it safer.

=A0


c) Case: receiver-advertised MSS less than 536 bytes.

=A0 =A0This is an unusual corner-case and is not one that I think we need =A0 =A0to engineer for. However, I do think we need to note that an IPv4 =A0 =A0receiver advertised MSS less than 536 would result in
=A0 =A0transmission of an unexpected large segment to the receiver.
=A0 =A0(I.e. say we noted this, but don't change the recommendation).

Why is that specific to TFO?

=A0


d) Case: receiver-advertised MSS greater than 1460 B,
=A0 =A0i.e. allowing TFO with large segments.

=A0 =A0I think we should explicitly say MUST NOT use an MSS that
=A0 =A0results in a packet size greater than 1500B.

No. if you send a packet too big you risk it getting= lost and wish you get some ICMP warnings. Why is that specific to TFO?<= /u>

=A0


=A0 =A0- AND I think we should caution that we do not have current
=A0 =A0experience of the effect of this behaviour. We could note
=A0 =A0it as an area for further experimentation? I'm not sure what
=A0 =A0we agreed?

ok. Sending SYN-data is indeed a new behavior and an= area for further experimentation. I think that's why TFO-draft is expe= rimental. I could add more words about this in the "areas for experime= ntation".

=A0



e) Case: A sender overwhelms a path with limited capacity.
=A0 =A0This is the corner case where a SYN may fail. The issue is most
=A0 =A0severe for links that suffer major overload (think low-speed
=A0 =A0large multiplexing).

=A0 =A0First SORRY - I'd like to avoid "slightly" and "s= ignificantly"
=A0 =A0wording =A0- we discussed on the thread - instead what matters
=A0 =A0to me really is:

=A0 =A0This draft updates the congestion-control behaviour while the
=A0 =A0sender is waiting acknowledgement for a SYN. This will result in
=A0 =A0more data (up to one IW of segments) being sent before the sender =A0 =A0receives the ACK for the SYN. This could result in additional
=A0 =A0congestion on links that have a high loss rate where the initial
=A0 =A0ACK would have been lost, which in standard behaviour would have
=A0 =A0resulted in a lower initial congestion window.

I can merge the text above into the draft.=

=A0


=A0 =A0- personally I see the effect as important to document,
=A0 =A0but is OK for experimentation with an IW of 3 (see (g)).

f) The cookie-less experimental method will likely also need a negative
=A0 =A0cache to disable inappropriate TFO usage.

=A0 =A0I'd like to see an explicit note for the future experimentation<= br> =A0 =A0something a bit like this would be good:

=A0 "Even if cookie-less methods are found, it is expected that a
=A0 =A0future method will still need a way to detect conditions where
=A0 =A0TFO should not be used due to path properties and some
=A0 =A0equivalent method may then be needed to disable TFO."=

ok.

=A0


g) I am unsure that allowing TFO to use IW=3D10 is safe!


Best wishes,

Gorry

=A0


--089e01229ed48db5b404ec9670d3-- From michael.scharf@alcatel-lucent.com Tue Dec 3 01:32:09 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B1F1AE0E2 for ; Tue, 3 Dec 2013 01:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVDcgdukZB8d for ; Tue, 3 Dec 2013 01:32:03 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AD0811AE0D8 for ; Tue, 3 Dec 2013 01:32:03 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rB39Vpuk012461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 03:31:54 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rB39Va2D007486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 10:31:50 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.70]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 3 Dec 2013 10:31:49 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Thread-Topic: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: AQHO778+Jt7y7dUEY0eFjqJOFz+7ZppCMsjQ Date: Tue, 3 Dec 2013 09:31:48 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1417C2@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> <2B85C60B-2301-4B1D-8176-044DAEA817A6@erg.abdn.ac.uk> <528B9E16.70602@erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D13C310@FR712WXCHMBA15.zeu.alcatel-lucent.com> <763b3f8541277a7690bf859a87e69265.squirrel@www.erg.abdn.ac.uk> <529A1B65.4070008@erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D140964@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D1417C2FR712WXCHMBA15zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:32:10 -0000 --_000_655C07320163294895BBADA28372AF5D1417C2FR712WXCHMBA15zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yuchung, I guess one of the key points here is that in corner cases the cached MSS v= alue might be outdated. For instance, this could happen if a load balancer = sits in front of two middleboxes that are (mis-) configured with two differ= ent MSS clamping values. And legacy middlebox may not expect data in the SYN and behave different to= what one could expect. I am not sure whether this is a real-world problem.= But, indeed, it seems like an area where further experimentation could pro= vide better insight (including the potential outcome that this is not a pro= blem). I strongly agree that this should be added to the experimentation se= ction. Thanks Michael From: Yuchung Cheng [mailto:ycheng@google.com] Sent: Tuesday, December 03, 2013 1:32 AM To: Scharf, Michael (Michael) Cc: Gorry Fairhurst; tcpm@ietf.org; draft-ietf-tcpm-fastopen@tools.ietf.org Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tc= pm-fastopen-05 On Mon, Dec 2, 2013 at 5:49 AM, Scharf, Michael (Michael) > wrote: Some comments, with chair hat off... a)+b): I have no strong opinion on whether the connection initiator (client) shoul= d cache the RTT, or not. It seems partly orthogonal to TFO. If the RTO expi= res spuriously, the document recommends to retransmit without data in SYN, = i.e., the amount of bytes sent into the network is the same as for regular = TCP. From a congestion control perspective, the result is more or less the = same. However, after having followed this discussion, I wonder why the document d= oes not comment at all about RTT estimation at the connection acceptor (ser= ver). With TFO, the connection acceptor (server) is allowed to send a full = IW of data back to the connection initiator (client), following the SYN-ACK= . However, at that point in time, the connection acceptor (server) has no r= ecent RTT measurement, right? This is different to the traditional TCP hand= shake, in which correct an RTT measurement is available before data is sent into the network. The = fact that TFO allows sending of a full IW of data before an RTT estimation = is available should be mentioned as a warning sign, IMHO. For instance, it = will make it more difficult to apply pacing. I can add that point about RTT estimation. c)+d): In almost all existing use of regular TCP, the endpoints negotiate the MSS = before actually sending any data, because adding data to SYNs doesn't make = a lot of sense without TFO. Therefore, "MSS clamping" in middleboxes usuall= y works for regular TCP, and it may avoid PMTUD procedures in many cases. W= ith TFO, the situation can be more I need more information about the MSS clamping feature. My understanding (which can be wrong) of MSS clamping is that the middle-bo= x is transparently reducing the value in the MSS option in the SYN packet. = If so the connection that negotiate the cookie, should receive and cache th= e reduced value, which will be used by the later Fast Open connection. It is possible the middle-box lowers the MSS prior the to SYN-data. In that= case it is equivalent to sending a SYN-data, or a data packet on a new pat= h that has lower MTU. In that case, the remedy is ICMP error or ultimately = a timeout. When recurring SYN-data timeouts happen, then the client should = disable Fast Open (temporarily) due to the negative caching suggested in th= e draft. complex. In addition to the case of MSS<536 bytes raised by Gorry, it is al= so not clear to me what a middlebox should do if it receives a TFO SYN with= data, and if this segment is larger than the "MSS clamping" value of that = middlebox. This corner case can occur e.g. after path routing changes. Ther= efore, I agree with Gorry that the document should at least mention that MS= S issues may require further experimentation. As replied earlier, I will document SYN-data / middlebox issue as the "area= of experimentation" in the previous email. Thanks Michael From: tcpm [mailto:tcpm-bounces@ietf.org] On = Behalf Of Yuchung Cheng Sent: Sunday, December 01, 2013 7:08 PM To: Gorry Fairhurst Cc: tcpm@ietf.org; draft-ietf-tcpm-fastopen@tools.iet= f.org Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-ietf-tc= pm-fastopen-05 On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst > wrote: Sorry for the delay (I was unwell), so this email is to restart. I think we got a long way through discussing things, so I've summarised below all the points as I understand from my side, so we and others know where we have arrived and can fix others. I support the experimentation with TFO, although I would argue we do need to write more about how the proposed changes in this ID will modify STD behaviour and explicitly say how to "negatively" cache path info that indicates TFO should not be used. I would like to see documented the cases where this could @@potentially@@ be worse than STD mechanisms. The ID already has some good documentation, but I think it needs a little more detail especially the set of potential issues that we expect to be mitigated by a cache at both the client and server - especially when and why do we need to revoke the cookie to prevent potentially bad pathologies from being repeated in a short time between a pair of clients and servers that keep starting up new connections. --- The points below hopefully help us see what we can agree on: a) Case: cached RTT greater than minRTO The current text says "RECOMMEND that the client caches the MSS and RTT to the server to enhance performance." I think ideally we should also explicitly say if the RTT is not cached TCP SHOULD disable use of TFO (make the cookie invalid) when the RTT>MinRTO. ... & note something about "this prevents a premature RTO for flows with a long RTT and also provides an acceptable RTT for pacing" - I feel the current text focuses on performance improvement for a low RTT, but does not explain why it is important for large RTTs. b) Case: cached RTT less than minRTO and path change We could just note that this ID does not change the behaviour that a path change can result in an invalid RTT/RTO value, and that normal TCP behaviour is expected to recover. no on a and b. The agreed change is to remove RTT caching in TFO spec. TFO will benefit higher RTT client more. Do I need to explain such a simple= logic further? min-RTO is not defined in IETF RFCs, nor do I see your new logic improves T= FO b/c ultimately cached RTT can be out-dated. I don't see how tweaking TFO= with historical RTT values can make it safer. c) Case: receiver-advertised MSS less than 536 bytes. This is an unusual corner-case and is not one that I think we need to engineer for. However, I do think we need to note that an IPv4 receiver advertised MSS less than 536 would result in transmission of an unexpected large segment to the receiver. (I.e. say we noted this, but don't change the recommendation). Why is that specific to TFO? d) Case: receiver-advertised MSS greater than 1460 B, i.e. allowing TFO with large segments. I think we should explicitly say MUST NOT use an MSS that results in a packet size greater than 1500B. No. if you send a packet too big you risk it getting lost and wish you get = some ICMP warnings. Why is that specific to TFO? - AND I think we should caution that we do not have current experience of the effect of this behaviour. We could note it as an area for further experimentation? I'm not sure what we agreed? ok. Sending SYN-data is indeed a new behavior and an area for further exper= imentation. I think that's why TFO-draft is experimental. I could add more = words about this in the "areas for experimentation". e) Case: A sender overwhelms a path with limited capacity. This is the corner case where a SYN may fail. The issue is most severe for links that suffer major overload (think low-speed large multiplexing). First SORRY - I'd like to avoid "slightly" and "significantly" wording - we discussed on the thread - instead what matters to me really is: This draft updates the congestion-control behaviour while the sender is waiting acknowledgement for a SYN. This will result in more data (up to one IW of segments) being sent before the sender receives the ACK for the SYN. This could result in additional congestion on links that have a high loss rate where the initial ACK would have been lost, which in standard behaviour would have resulted in a lower initial congestion window. I can merge the text above into the draft. - personally I see the effect as important to document, but is OK for experimentation with an IW of 3 (see (g)). f) The cookie-less experimental method will likely also need a negative cache to disable inappropriate TFO usage. I'd like to see an explicit note for the future experimentation something a bit like this would be good: "Even if cookie-less methods are found, it is expected that a future method will still need a way to detect conditions where TFO should not be used due to path properties and some equivalent method may then be needed to disable TFO." ok. g) I am unsure that allowing TFO to use IW=3D10 is safe! Best wishes, Gorry --_000_655C07320163294895BBADA28372AF5D1417C2FR712WXCHMBA15zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yuchung= ,

 = ;

I guess on= e of the key points here is that in corner cases the cached MSS value might= be outdated. For instance, this could happen if a load balancer sits in front of two middleboxes that are (mis-) configured with two diffe= rent MSS clamping values.

 = ;

And legacy= middlebox may not expect data in the SYN and behave different to what one = could expect. I am not sure whether this is a real-world problem. But, indeed, it seems like an area where further experimentation could pro= vide better insight (including the potential outcome that this is not a pro= blem). I strongly agree that this should be added to the experimentation se= ction.

 = ;

Thanks

 = ;

Michael

 = ;

 = ;

From: Yuchung = Cheng [mailto:ycheng@google.com]
Sent: Tuesday, December 03, 2013 1:32 AM
To: Scharf, Michael (Michael)
Cc: Gorry Fairhurst; tcpm@ietf.org; draft-ietf-tcpm-fastopen@tools.i= etf.org
Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-= ietf-tcpm-fastopen-05

 

 

 

On Mon, Dec 2, 2013 at 5:49 AM, Scharf, Michael (Mic= hael) <michael.scharf@alcatel-lucent.com> wrote:

Some comments, with chai= r hat off…

 =

a)+b):

 =

I have no strong opinion= on whether the connection initiator (client) should cache the RTT, or not. It seems partly orthogonal to TFO. If the RTO expires spuriou= sly, the document recommends to retransmit without data in SYN, i.e., the a= mount of bytes sent into the network is the same as for regular TCP. From a= congestion control perspective, the result is more or less the same.

 =

However, after having fo= llowed this discussion, I wonder why the document does not comment at all about RTT estimation at the connection acceptor (server). With TFO,= the connection acceptor (server) is allowed to send a full IW of data back= to the connection initiator (client), following the SYN-ACK. However, at t= hat point in time, the connection acceptor (server) has no recent RTT measurement, right? This is different = to the traditional TCP handshake, in which

correct 

an RTT measurement is av= ailable before data is sent into the network.  The fact that TFO allows sending of a full IW of data before an RTT estimation is availa= ble should be mentioned as a warning sign, IMHO. For instance, it will make= it more difficult to apply pacing.

I can add that point about RTT estimation.

 

 =

c)+d):

 =

In almost all existing u= se of regular TCP, the endpoints negotiate the MSS before actually sending any data, because adding data to SYNs doesn’t make a lot of = sense without TFO. Therefore, “MSS clamping” in middleboxes usu= ally works for regular TCP, and it may avoid PMTUD procedures in many cases= . With TFO, the situation can be more

I need more information about the MSS clamping featu= re. 

 

My understanding (which can be wrong) of MSS clampin= g is that the middle-box is transparently reducing the value in the MSS opt= ion in the SYN packet. If so the connection that negotiate the cookie, shou= ld receive and cache the reduced value, which will be used by the later Fast Open connection.

 

It is possible the middle-box lowers the MSS prior t= he to SYN-data. In that case it is equivalent to sending a SYN-data, or a d= ata packet on a new path that has lower MTU. In that case, the remedy is IC= MP error or ultimately a timeout. When recurring SYN-data timeouts happen, then the client should disable Fa= st Open (temporarily) due to the negative caching suggested in the draft.

 

complex. In addition to = the case of MSS<536 bytes raised by Gorry, it is also not clear to me what a middlebox should do if it receives a TFO SYN with data, and i= f this segment is larger than the “MSS clamping” value of that = middlebox. This corner case can occur e.g. after path routing changes. Ther= efore, I agree with Gorry that the document should at least mention that MSS issues may require further experimentatio= n.

As replied earlier, I will document SYN-data / middl= ebox issue as the "area of experimentation" in the previous email= .

 

 =

Thanks=

 =

Michael

 =

 =

From: tcpm [mailto:tcpm-bo= unces@ietf.org] On Behalf Of Yuchung Cheng
Sent: Sunday, December 01, 2013 7:08 PM
To: Gorry Fairhurst
Cc: tcpm@ietf.org= ; draft-ietf-tcpm-fastopen@tools.ietf.org
Subject: Re: [tcpm] Summary of mt comments/questions WGLC for draft-= ietf-tcpm-fastopen-05

 

 

 

On Sat, Nov 30, 2013 at 9:07 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> w= rote:


Sorry for the delay (I was unwell), so this email is to restart.
I think we got a long way through discussing things, so I've
summarised below all the points as I understand from my side,
so we and others know where we have arrived and can fix others.

I support the experimentation with TFO, although I would argue
we do need to write more about how the proposed changes in this
ID will modify STD behaviour and explicitly say how to "negatively&quo= t;
cache path info that indicates TFO should not be used.

I would like to see documented the cases where this could
@@potentially@@ be worse than STD mechanisms. The ID already
has some good documentation, but I think it needs a little
more detail especially the set of potential issues that we
expect to be mitigated by a cache at both the client and server
- especially when and why do we need to revoke the cookie
to prevent potentially bad pathologies from being
repeated in a short time between a pair of clients and servers
that keep starting up new connections.

---

The points below hopefully help us see what we can agree on:

a) Case: cached RTT greater than minRTO
   The current text says "RECOMMEND that the client caches t= he MSS
   and RTT to the server to enhance performance."

   I think ideally we should also explicitly say if the RTT is    not cached TCP SHOULD disable use of TFO (make the cookie
   invalid) when the RTT>MinRTO.

   ... & note something about  "this prevents a pre= mature RTO
   for flows with a long RTT and also provides an acceptable RTT<= br>    for pacing" - I feel the current text focuses on performa= nce
   improvement for a low RTT, but does not explain why it is
   important for large RTTs.


b) Case: cached RTT less than minRTO and path change
   We could just note that this ID does not change the behaviour<= br>    that a path change can result in an invalid RTT/RTO value,
   and that normal TCP behaviour is expected to recover.

no on a and b.

 

The agreed change is to remove RTT caching in TFO spec.=

TFO will benefit higher RTT client more. Do I need to explain such= a simple logic further?

 

min-RTO is not defined in IETF RFCs, nor do I see your new logic i= mproves TFO b/c ultimately cached RTT can be out-dated. I don't see how twe= aking TFO with historical RTT values can make it safer.

 


c) Case: receiver-advertised MSS less than 536 bytes.

   This is an unusual corner-case and is not one that I think we = need
   to engineer for. However, I do think we need to note that an I= Pv4
   receiver advertised MSS less than 536 would result in
   transmission of an unexpected large segment to the receiver.    (I.e. say we noted this, but don't change the recommendation).=

Why is that specific to TFO?

 


d) Case: receiver-advertised MSS greater than 1460 B,
   i.e. allowing TFO with large segments.

   I think we should explicitly say MUST NOT use an MSS that
   results in a packet size greater than 1500B.

No. if you send a packet too big you risk it getting lost and wish= you get some ICMP warnings. Why is that specific to TFO?

 


   - AND I think we should caution that we do not have current    experience of the effect of this behaviour. We could note
   it as an area for further experimentation? I'm not sure what    we agreed?

ok. Sending SYN-data is indeed a new behavior and an area for furt= her experimentation. I think that's why TFO-draft is experimental. I could = add more words about this in the "areas for experimentation".

 



e) Case: A sender overwhelms a path with limited capacity.
   This is the corner case where a SYN may fail. The issue is mos= t
   severe for links that suffer major overload (think low-speed    large multiplexing).

   First SORRY - I'd like to avoid "slightly" and "= ;significantly"
   wording  - we discussed on the thread - instead what matt= ers
   to me really is:

   This draft updates the congestion-control behaviour while the<= br>    sender is waiting acknowledgement for a SYN. This will result = in
   more data (up to one IW of segments) being sent before the sen= der
   receives the ACK for the SYN. This could result in additional<= br>    congestion on links that have a high loss rate where the initi= al
   ACK would have been lost, which in standard behaviour would ha= ve
   resulted in a lower initial congestion window.

I can merge the text above into the draft.

 


   - personally I see the effect as important to document,
   but is OK for experimentation with an IW of 3 (see (g)).

f) The cookie-less experimental method will likely also need a negative
   cache to disable inappropriate TFO usage.

   I'd like to see an explicit note for the future experimentatio= n
   something a bit like this would be good:

  "Even if cookie-less methods are found, it is expected that a    future method will still need a way to detect conditions where=
   TFO should not be used due to path properties and some
   equivalent method may then be needed to disable TFO."

ok.

 


g) I am unsure that allowing TFO to use IW=3D10 is safe!


Best wishes,

Gorry

 

 

--_000_655C07320163294895BBADA28372AF5D1417C2FR712WXCHMBA15zeu_-- From Alexander.Zimmermann@netapp.com Tue Dec 3 09:31:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617F91A1F72 for ; Tue, 3 Dec 2013 09:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q05eRJsQf9v1 for ; Tue, 3 Dec 2013 09:31:24 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A86991A1F4E for ; Tue, 3 Dec 2013 09:31:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,819,1378882800"; d="asc'?scan'208";a="123356837" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 03 Dec 2013 09:31:22 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.58]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 09:31:21 -0800 From: "Zimmermann, Alexander" To: Bob Braden Thread-Topic: New Version Notification for draft-ietf-tcpm-tcp-rfc4614bis-00.txt Thread-Index: AQHOlQLuFACvQF3RkEGBancmssUYfJmiKhkAgKHM8YA= Date: Tue, 3 Dec 2013 17:31:21 +0000 Message-ID: <2A9167C6-8786-4262-8CB3-6779C819F07A@netapp.com> References: <20130809131743.28970.80342.idtracker@ietfa.amsl.com> <52166910.8080005@isi.edu> In-Reply-To: <52166910.8080005@isi.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_C359A26A-682D-47F8-8444-C74C7776010A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Martin Duke , "tcpm@ietf.org Extensions" , "ted faber braden@isi.edu" , Ethan Blanton Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-tcp-rfc4614bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:31:28 -0000 --Apple-Mail=_C359A26A-682D-47F8-8444-C74C7776010A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Bob, thank very much for your review. I incorparte all of your comments. Please find details below. Alex Am 22.08.2013 um 21:40 schrieb Bob Braden : > I promised Alex I would give 4614bis a read through. This message=20 > contains my comments but does > not include the typos that I saw. Another day. >=20 > Nothing I have to say should be taken as disapproval of the document = as=20 > a whole. The authors did a really good job disentangling what has = become=20 > a muddy maze of RFCs! =46rom 30,000 feet, it may reflects a defect in = the=20 > IETF processes, resulting in conflict and fragmentation of protocol=20 > specs. It would seem to be a daunting task for a TCP implementer to=20 > figure out what to implement, even with your excellent document. Hopefully the situation becomes better with RFC793bis. >=20 > Bob Braden =97=97 >=20 > COMMENTS ON draft 4614bis >=20 > o I was nearly done with RFC 1122 when Dave Crocker spoke up and = complained that it was nearly impossible to find a particular = requirement. He was clearly right, so I dove back in and produced the = Summary charts that appear at the end of each section of 1122. Reading = 4614bis, I had Dave's problem. The explanation of RFCxxxx would contain = a reference to RFCyyyy, but it was very difficult and time consuming to = locate the description of yyyy, which is often in a different section of = the document. I think you should fix this somehow. I totally agree with you. Very good idea! > One way might be to add the bis section number to the reference = entries. Since the references and the sectionss are ordered by RFC #, it = would be an easy 2-step lookup from yyyy to a section number to the = roadmap entry for yyyy. The other approach would simply put section ref = the in text -- ".... RFCyyyy (see n.m) =85" The references are automatically generated by xml2rfc script. Therefore, = I take option 2. >=20 > o First paragraph p 4: says 5681 is "nearly universally deployed" but = later it is listed (quite properly, I would > think) in section 2 as MUST. That would seem to supercede the = deployment frequency. Something like "For instance, RFC 5681 is = considered part of the required core functionality of TCP, although RFC = 5681 is only a Draft Stndard=93. Fixed. >=20 > o 3rd paragraph of 5681 (p 6) is confusing; turn it around so the = sentence begins with 5681 and ends with 1122. Fixed. >=20 > o Nit: "Jumbograms" is inconsistently capitalized Fixed. >=20 > o First paragraph p9: omit word "traditionally" as misleading. It is = fundamental to VJ CC. OK. >=20 > o RFC 6633 p.10: Out of order. > and: s/provides recommendations/recommends/ Fixed and fixed. >=20 > o Section 3.3: s/provides performance improvement/improves = performance/ Text no longer exist. No changes here. >=20 > o Discussion of RFC 2883, p 11: So, the receiver infers it has = unnecessarily retransmitted a packet. What is it supposed to do with = that information? This is not a part of RFC 2883. However, I add a sentence :-) >=20 > o RFC 4015 12: Seems weird that this is a standards track document and = classified as a SHOULD in your section 3.4, yet it seems that the Eifel = algorithm is defined in an Experimental RFC 3522 in section 4.3. At = least comment on the connection in one or the other. In the old TCP roadmap Eifel Response (RFC 4015) was not part of section = 3 (recommended enhancements), but part of section 4. The reasoning was the = following: 1. RFC 4015 operates on the output of a detection algorithm, for which there is currently no available mechanism on the standards track. 2. The working group was not aware of any wide deployment and use of RFC 4015. 3. The consensus of the working group, after a discussion of the known Intellectual Property Rights claims on the techniques described in RFC 4015, identified this section of the roadmap as an appropriate location. Today, point 1 and 2 are no longer true, for which I moved RFC 4015 to section 3. On the other hand Eifel Destection is still an experimental RFC, and therefore still in section 4 (like the DSACK detection as = well). In the introduction of Section 3.4. we give the reader a hint that some of the algorithms are non STD track. The IETF defined multiple algorithms because there are tradeoffs in whether or not certain TCP options need to be implemented, and concerns about IPR status. The Standards Track documents in this section are closely related to the Experimental documents in Section 4.4 also addressing this topic. >=20 > o First sentence 3.7 (p. 14): s/and/from/ Fixed. >=20 > o RFC 4953 (p 14): s/resets (RSTs)/reset (send RST)/ Done. >=20 > o RFC 5827 (p18) "(and SCTP)" raises the interesting question: can one = say that all the discussion in section 4.2 hold for SCTP as well as TCP? Uff, maybe=85 Some of the algos like F-RTO, IW10 and the like also exist = for SCTP, but to be honest, I do not like to open a can of worms :-) >=20 > o I am mystified by Multipath TCP RFCs being scattered into 4.4, 6.2, = 6.4, and 6.5. They all seem to be Experimental. Do you have some reason = for these choices?? This is not (fully) true. RFCs that specify the MPTCP itself are = experimental and part of section 4.5 (the numbering has changed). This are RFC 6356 = and RFC 6824. Any other MPTCP doc is informational (RFC 6182, RFC 6181 RFC 6897), and = which is the reason why we listed them in section 6 (support documents). In the introduction of the MPTCP section (sec. 4.5), we give the reader = a hint that also support docs exist that are not part of this section. The documents listed in this section specify the Multipath TCP scheme, while the documents in Sections 7.2, 7.4, and 7.5 provide some additional background information. >=20 > o RFC 1693. Surely "use more specialized transport protocols" cannot = be the right answer. Is it likely that these specialized protocols = implement all the appropriate TCP congestion control and avoidance, etc? = I think not. We clarified that sentence from: "use more specialized transport protocols" to: "use specialized transport protocols other than TCP, such as PR-SCTP [RFC 3758]." >=20 > o RFC 1705 (p 22) Is it worthwhile to point out that this is > the identifier/locator split that has been the subject of much > discussion? We added: "Later work on splitting locator and identifier values is summarized well in RFC 6115, but no resulting changes to TCP have occurred." >=20 > o RFC 6013 (p 22): s/is publish in 2011/was published in 2011/ Fixed. >=20 > o RFC 761: s/mostly the/mostly to the/ Fixed. >=20 > RFC 872: s/ON-A/on-a/ Fixed. >=20 > RFC 896: This was a trememdously important RFC at the time. I believe = that it first introduced the term and the concept of > congestion collapse.=20 >=20 > Furthermore, it defined an algorithm for > efficient transmission of small packets that is still called > the Nagle Algorithm or simply "Nagle=93. I add a sentence about the Nagle algorithm. > RFC 3439: the word "extents" is obviously wrong. Also, 'primary=20 > mechanism" does not sound right. How about "... complexity is the = primary impediment to efficient scaling=93 Funny. The authors of RFC3439 use the word =84extent=93 in their = abstract. Anyway, I changed it into =84updates" >=20 > RFC 2757: ... long thin networks (i.e., networks with low bandwidth = and high delay) =85 added >=20 > ZRFC 3366 and 3819 appear to cover roughly the same ground. I assume = they are both the result of Phil Karn's passionate pleas. > In any case, if I am right it would be nice to point out the > kinship in the Roadmap. In the 3819 description, we added: "RFC 3366 specifically focuses on ARQ mechanisms, while RFC 3819 more widely covers additional aspects of the underlying layers." >=20 > o RFC4774: It is unclear that this belongs here; how abou 6.2? I guess you mean 7.2. Architectural Guidelines. Right? > Also, suggest s/co- existence in an Internet that may include/\ > co-existence with/ Fixed. >=20 > o RFC 5033: Since this document seems to be opposing 2914, ouldn't = it be better to move 5033 to section 6.2 where > 2914 appears? My comment to Wes=85 What do you think? I would like to take the other way around. Move 2914 where 5033 appears. and Wes=85 This is a good point. I took the opportunity now to re-look at both of them, and I actually think that 2914 is still pretty good where it's at, though I think we should add a note to it that mentions 5033. Something like: "Later work on TCP has included several more aggressive mechanisms than Reno TCP includes, and RFC 5033 provides additional guidance on use of such algorithms. The fundamental architectural discussion in RFC 2914 remains valid, regarding the standards process role in defining protocol aspects that are critical to performance and avoiding congestion collapse scenarios." >=20 > o RFC 2525: s/in doing so// Fixed >=20 > o RFC 1337; missing space in title Fixed >=20 > o Header prediction p35: was the typo "acpacket" in Van's message? No ;-) >=20 > I am glad youi included Van's message. I have a mailbox on disk in = which I collected Van's messages over a number of years. I > always hoped to find time to do a light editing and publish it > on the web (Van did give me permission) All together, it is a > course in the subtleties of protocols! >=20 > o Forward Acknowledgement(FACK): Did you define fast retransmit > somewhere earlier? Yes in the description of RFC 5681. > A backward ref to it would be helpful here. added >=20 > Cheers, >=20 > Bob Braden --Apple-Mail=_C359A26A-682D-47F8-8444-C74C7776010A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKeFWcACgkQdyiq39b9uS6vlgCfc3FodeytfvIZ08Mhd2k5irzH O1sAn3dUs5zwWwR+sbEe2Dbp7k5/fxU3 =rpYO -----END PGP SIGNATURE----- --Apple-Mail=_C359A26A-682D-47F8-8444-C74C7776010A-- From internet-drafts@ietf.org Tue Dec 3 09:35:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BFE1A1F4E; Tue, 3 Dec 2013 09:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKarZYcbmczg; Tue, 3 Dec 2013 09:35:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B081AE11D; Tue, 3 Dec 2013 09:35:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131203173526.16289.54957.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2013 09:35:26 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:35:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : A Roadmap for Transmission Control Protocol (TCP) Specif= ication Documents Author(s) : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-02.txt Pages : 51 Date : 2013-12-03 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-tcp-rfc4614bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Alexander.Zimmermann@netapp.com Tue Dec 3 09:43:53 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8E51ACC91 for ; Tue, 3 Dec 2013 09:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmfpxTWp-WP9 for ; Tue, 3 Dec 2013 09:43:50 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E150C1ABD2A for ; Tue, 3 Dec 2013 09:43:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,819,1378882800"; d="asc'?scan'208";a="123363105" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 03 Dec 2013 09:43:48 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.58]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 09:43:47 -0800 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-02.txt Thread-Index: AQHO8E4mIITs4SrP+0KVdViVnN9v+ZpDQ++A Date: Tue, 3 Dec 2013 17:43:47 +0000 Message-ID: References: <20131203173526.16289.54957.idtracker@ietfa.amsl.com> In-Reply-To: <20131203173526.16289.54957.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_E979021E-1AAD-4556-829C-08A6ACC97E10"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:43:53 -0000 --Apple-Mail=_E979021E-1AAD-4556-829C-08A6ACC97E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This version: * includes Bob=92s feedback * an update of the MIB section Am 03.12.2013 um 18:35 schrieb Internet-Drafts@ietf.org: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. >=20 > Title : A Roadmap for Transmission Control Protocol = (TCP) Specification Documents > Author(s) : Martin Duke > Robert Braden > Wesley M. Eddy > Ethan Blanton > Alexander Zimmermann > Filename : draft-ietf-tcpm-tcp-rfc4614bis-02.txt > Pages : 51 > Date : 2013-12-03 >=20 > Abstract: > This document contains a "roadmap" to the Requests for Comments = (RFC) > documents relating to the Internet's Transmission Control Protocol > (TCP). This roadmap provides a brief summary of the documents > defining TCP and various TCP extensions that have accumulated in the > RFC series. This serves as a guide and quick reference for both TCP > implementers and other parties who desire information contained in > the TCP-related RFCs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-tcp-rfc4614bis-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_E979021E-1AAD-4556-829C-08A6ACC97E10 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKeGFMACgkQdyiq39b9uS6VIgCglDEh8gIAcqgTBRNX9QK5FD/+ AUkAni61IusubIMNIA3+ygWT6OE6DYen =NTCx -----END PGP SIGNATURE----- --Apple-Mail=_E979021E-1AAD-4556-829C-08A6ACC97E10-- From martin.h.duke@gmail.com Tue Dec 3 16:01:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028211ADDA0 for ; Tue, 3 Dec 2013 16:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyIKoLlPeLvX for ; Tue, 3 Dec 2013 16:01:03 -0800 (PST) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 87DEA1ADFA9 for ; Tue, 3 Dec 2013 16:01:03 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id oz11so11003870veb.21 for ; Tue, 03 Dec 2013 16:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=11PlG3GQpDY50Bt+CUwbD0o76aBMncl5MnggugUXiuo=; b=Ln7/BWleEzJK4/Y1zsHo8/WtGNTzCRrBgavzmcFGTK2IuIqb3jFbQ9Yqk0OoqvzaI5 j9ZFZ2RGeiWDijXXAEwkcfkyc+kw/mx5YRHLZW66g+/im8wYRiW64nGZpp/SmUco+fXb hZSJSPaXxYZZW51GdJZ3iD8bfKFecIxnsVUeStUOjgxyRpZTwJPj+wXu7336dSwoxy5g AHfhkxj6A9dlKzoVesOeNUCqavg6GaWtSFEkntAwN43hLo9PUgTLsS5jpmNIMHr3UPx6 ohlIYGvJyp3mhypAEmf8gFMWT3sEZ5MSmFIeMIs8qZj/sSkthtOfpLGt0/NAcUMRjF+X FGYQ== MIME-Version: 1.0 X-Received: by 10.52.116.74 with SMTP id ju10mr48240883vdb.20.1386115260498; Tue, 03 Dec 2013 16:01:00 -0800 (PST) Received: by 10.220.160.130 with HTTP; Tue, 3 Dec 2013 16:01:00 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 16:01:00 -0800 Message-ID: From: Martin Duke To: "Zimmermann, Alexander" Content-Type: multipart/alternative; boundary=20cf307d01dcb87bf204ecaa1b48 Cc: "tcpm@ietf.org Extensions" , " Blanton" , "Braden " Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 00:01:07 -0000 --20cf307d01dcb87bf204ecaa1b48 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comments inline. On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexander < Alexander.Zimmermann@netapp.com> wrote: > > Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar < > janardhan.iyengar@fandm.edu>: > > > > > Comments: > > - Page 6: "This is generally regarded as the least common denominator > among TCP flavors currently found running on Internet hosts." I thought > that the least-common denominator was NewReno. Is that incorrect? > > This is C&P text from the original roadmap. Since I=92m not the author of > this section, I have problems to value your comment. > If the WG has (now) feeling that NewReno and not Reno is the least common > denominator I can delete the sentence. NP. > Perhaps others with more field experience feel differently, but by a reading of the RFCs, 6582 explains NewReno, and explicitly does not obsolete 5681. I take that to mean that a host can run Reno and still be compliant. > > > - Page 7: What do you mean by "Fundamental Changes"? As in changes to > RFC 793? If so, can the Section be called that -- "Changes to RFC 0793"? = At > least state it clearly in the intro paragraph to this section. Without a > clear explanation, it is difficult to see why 5482 is a Fundamental Chang= e. > > From the introduction text of section 3 of the old roadmap: > > "3. Recommended Enhancements > This section describes recommended TCP modifications that improve > performance and security. RFCs 1323 and 3168 represent fundamental > changes to the protocol. =85 > " > > So, the authors of the RFC4614 saw this two RFCs as fundamental changes. > The only thing that I did, was the creation of a new section with exactly > this > wording. > > Nevertheless you (and also Yuchung) are right that RFC 5482 is *not* a > fundamental change. > Therefore I move RFC 5482 out of this section, but leave the title as it > is. > > Personally, I do not like the title "Changes to RFC 0793=93 since there a= re > some other > RFC that also make changes to 793 but do not belong to this section. > For reference, the original 4614 had three RFCs at the beginning of Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168 (ECN). As far as I can recall, this was because (a) they didn't fit neatly into a grouping with other RFCs and we didn't want subsections with 1 RFC; and (b) 1323 and 3168 are really important and should be at the front. It's only 1323 and 3168 that we describe as "fundamental," as a way of introducing them instead of any sort of formal taxonomy. I agree that 3168 fits in well under congestion control; as for the two now in 3.1, I'd just as soon we rename the section as "Miscellaneous changes" or "general changes" or even "large packets and windows". I'm open to people's suggestions for naming. I'm aesthetically displeased with 5482 out there by itself in its own subsection, and would probably prefer it in "miscellaneous changes," but if others feel differently it isn't a big deal to me. > > - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, 3.5 should > be reorganized into two sections: Congestion Control, and Loss Recovery. > > Yes and no. Yuchung suggested to re-organize section 3.2 and 3.3, but > *not* 3.4 and 3.5. > In version 01 we have now: > > 3.2. Congestion Control Extensions > 3.3. Loss Recovery Extensions > 3.4. Detection and Prevention of Spurious Retransmissions > > and the same structure in sec 4. (which was not suggested by Yuchung ;-)) > > Strictly speaking, sec 3.4 is a subcategory of sec. 3.3. You are right. > But for a better > structuring, I suggest that we put every spurious detection/reaction algo > into a separate > sub-section. A reader can find the docs in question much easier. BTW, we > did the same > thing with MPTCP. All MPTCP docs belongs in some way to CC and LR too, bu= t > have their > own sub-section. > I concur with Alexander's answers to this comment and all that followed. > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > --20cf307d01dcb87bf204ecaa1b48 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Comm= ents inline.

On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexander <Alexander.Zimmermann@netapp.com> wrote:

Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar <janardhan.iyengar@fandm.edu>:

>
> Comments:
> =A0 - Page 6: "This is generally regarded as the least common den= ominator among TCP flavors currently found running on Internet hosts."= I thought that the least-common denominator was NewReno. Is that incorrect= ?

This is C&P text from the original roadmap. Since I=92m not the author = of this section, I have problems to value your comment.
If the WG has (now) feeling that NewReno and not Reno is the least common d= enominator I can delete the sentence. NP.

Perhaps others with more field experience feel differently, but by a rea= ding of the RFCs, 6582 explains NewReno, and explicitly does not obsolete 5= 681. I take that to mean that a host can run Reno and still be compliant.
=A0

> =A0 - Page 7: What do you mean by "Fundamental Changes"? As = in changes to RFC 793? If so, can the Section be called that -- "Chang= es to RFC 0793"? At least state it clearly in the intro paragraph to t= his section. Without a clear explanation, it is difficult to see why 5482 i= s a Fundamental Change.

>From the introduction text of section 3 of the old roadmap:

"3. =A0Recommended Enhancements
=A0 =A0This section describes recommended TCP modifications that improve =A0 =A0performance and security. =A0RFCs 1323 and 3168 represent fundamenta= l
=A0 =A0changes to the protocol. =85
"

So, the authors of the RFC4614 saw this two RFCs as fundamental changes. The only thing that I did, was the creation of a new section with exactly t= his
wording.

Nevertheless you (and also Yuchung) are right that RFC 5482 is *not* a fund= amental change.
Therefore I move RFC 5482 out of this section, but leave the title as it is= .

Personally, I do not like the title "Changes to RFC 0793=93 since ther= e are some other
RFC that also make changes to 793 but do not belong to this section.

For reference, the original 4614 had three RF= Cs at the beginning of Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumb= ograms), and 3168 (ECN). =A0As far as I can recall, this was because (a) th= ey didn't fit neatly into a grouping with other RFCs and we didn't = want subsections with 1 RFC; and (b) 1323 and 3168 are really important and= should be at the front. It's only 1323 and 3168 that we describe as &q= uot;fundamental," as a way of introducing them instead of any sort of = formal taxonomy.

I agree that 3168 fits in well under congestion control= ; as for the two now in 3.1, I'd just as soon we rename the section as = "Miscellaneous changes" or "general changes" or even &q= uot;large packets and windows". I'm open to people's suggestio= ns for naming.

I'm aesthetically displeased with 5482 out there by= itself in its own subsection, and would probably prefer it in "miscel= laneous changes," but if others feel differently it isn't a big de= al to me.
=A0
> =A0 - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, = 3.5 should be reorganized into two sections: Congestion Control, and Loss R= ecovery.

Yes and no. Yuchung suggested to re-organize section 3.2 and 3.3, but *not*= 3.4 and 3.5.
In version 01 we have now:

3.2. =A0Congestion Control Extensions
3.3. =A0Loss Recovery Extensions
3.4. =A0Detection and Prevention of Spurious Retransmissions

and the same structure in sec 4. (which was not suggested by Yuchung ;-))
Strictly speaking, sec 3.4 is a subcategory of sec. 3.3. You are right. But= for a better
structuring, I suggest that we put every spurious detection/reaction algo i= nto a separate
sub-section. A reader can find the docs in question much easier. =A0BTW, we= did the same
thing with MPTCP. All MPTCP docs belongs in some way to CC and LR too, but = have their
own sub-section.

I concur with Alexande= r's answers to this comment and all that followed.
=A0
<= div><snip>

> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--20cf307d01dcb87bf204ecaa1b48-- From rs@netapp.com Wed Dec 4 03:44:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3351AE246 for ; Wed, 4 Dec 2013 03:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4Ku6-eGTiz6 for ; Wed, 4 Dec 2013 03:44:50 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE281ADFA0 for ; Wed, 4 Dec 2013 03:44:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,824,1378882800"; d="scan'208,217";a="82870506" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 04 Dec 2013 03:44:38 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.147]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 03:44:39 -0800 From: "Scheffenegger, Richard" To: Martin Duke , "Zimmermann, Alexander" Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 Thread-Index: AQHOyqa+UyT2s6nVz06Pnxd/rZ78M5owaueAgBONvACAAD1+IA== Date: Wed, 4 Dec 2013 11:44:37 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25F02E8E@SACEXCMBX02-PRD.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F25F02E8ESACEXCMBX02PRDh_" MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , "Braden " , " Blanton" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:44:55 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F25F02E8ESACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the vast majority of implementations uses NewReno - I checked a num= ber of major OS TCP stacks a few months ago; there might be some very low-e= nd and simple TCP stacks for small SoC/embedded systems, that may do Reno s= till, but even the lowly embedded gear I play around as a hobby with is run= ning NewReno :) Richard Scheffenegger From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Martin Duke Sent: Mittwoch, 04. Dezember 2013 01:01 To: Zimmermann, Alexander Cc: tcpm@ietf.org Extensions; Blanton; Braden Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 Comments inline. On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexander > wrote: Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar >: > > Comments: > - Page 6: "This is generally regarded as the least common denominator a= mong TCP flavors currently found running on Internet hosts." I thought that= the least-common denominator was NewReno. Is that incorrect? This is C&P text from the original roadmap. Since I'm not the author of thi= s section, I have problems to value your comment. If the WG has (now) feeling that NewReno and not Reno is the least common d= enominator I can delete the sentence. NP. Perhaps others with more field experience feel differently, but by a readin= g of the RFCs, 6582 explains NewReno, and explicitly does not obsolete 5681= . I take that to mean that a host can run Reno and still be compliant. > - Page 7: What do you mean by "Fundamental Changes"? As in changes to R= FC 793? If so, can the Section be called that -- "Changes to RFC 0793"? At = least state it clearly in the intro paragraph to this section. Without a cl= ear explanation, it is difficult to see why 5482 is a Fundamental Change. >From the introduction text of section 3 of the old roadmap: "3. Recommended Enhancements This section describes recommended TCP modifications that improve performance and security. RFCs 1323 and 3168 represent fundamental changes to the protocol. ... " So, the authors of the RFC4614 saw this two RFCs as fundamental changes. The only thing that I did, was the creation of a new section with exactly t= his wording. Nevertheless you (and also Yuchung) are right that RFC 5482 is *not* a fund= amental change. Therefore I move RFC 5482 out of this section, but leave the title as it is= . Personally, I do not like the title "Changes to RFC 0793" since there are s= ome other RFC that also make changes to 793 but do not belong to this section. For reference, the original 4614 had three RFCs at the beginning of Section= 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168 (ECN). As f= ar as I can recall, this was because (a) they didn't fit neatly into a grou= ping with other RFCs and we didn't want subsections with 1 RFC; and (b) 132= 3 and 3168 are really important and should be at the front. It's only 1323 = and 3168 that we describe as "fundamental," as a way of introducing them in= stead of any sort of formal taxonomy. I agree that 3168 fits in well under congestion control; as for the two now= in 3.1, I'd just as soon we rename the section as "Miscellaneous changes" = or "general changes" or even "large packets and windows". I'm open to peopl= e's suggestions for naming. I'm aesthetically displeased with 5482 out there by itself in its own subse= ction, and would probably prefer it in "miscellaneous changes," but if othe= rs feel differently it isn't a big deal to me. > - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, 3.5 should be= reorganized into two sections: Congestion Control, and Loss Recovery. Yes and no. Yuchung suggested to re-organize section 3.2 and 3.3, but *not*= 3.4 and 3.5. In version 01 we have now: 3.2. Congestion Control Extensions 3.3. Loss Recovery Extensions 3.4. Detection and Prevention of Spurious Retransmissions and the same structure in sec 4. (which was not suggested by Yuchung ;-)) Strictly speaking, sec 3.4 is a subcategory of sec. 3.3. You are right. But= for a better structuring, I suggest that we put every spurious detection/reaction algo i= nto a separate sub-section. A reader can find the docs in question much easier. BTW, we d= id the same thing with MPTCP. All MPTCP docs belongs in some way to CC and LR too, but = have their own sub-section. I concur with Alexander's answers to this comment and all that followed. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --_000_012C3117EDDB3C4781FD802A8C27DD4F25F02E8ESACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

I think th= e vast majority of implementations uses NewReno – I checked a number = of major OS TCP stacks a few months ago; there might be some very low-end and simple TCP stacks for small SoC/embedded systems, that may do = Reno still, but even the lowly embedded gear I play around as a hobby with = is running NewReno J

 = ;

 = ;

 = ;

Richard Scheffenegger

 <= /p>

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Martin Duke
Sent: Mittwoch, 04. Dezember 2013 01:01
To: Zimmermann, Alexander
Cc: tcpm@ietf.org Extensions; <elb@psg.com> Blanton; Braden &l= t;braden@isi.edu>
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00=

 

Comments inline.

 

On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexand= er <Alexander.Zimmermann@netapp.com> wrote:


Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar <janardhan.iyengar@fandm.edu>:

>
> Comments:
>   - Page 6: "This is generally regarded as the least common = denominator among TCP flavors currently found running on Internet hosts.&qu= ot; I thought that the least-common denominator was NewReno. Is that incorr= ect?

This is C&P text from the original roadmap. Since I’m not the aut= hor of this section, I have problems to value your comment.
If the WG has (now) feeling that NewReno and not Reno is the least common d= enominator I can delete the sentence. NP.

 

Perhaps others with more field experience feel diffe= rently, but by a reading of the RFCs, 6582 explains NewReno, and explicitly= does not obsolete 5681. I take that to mean that a host can run Reno and s= till be compliant.

 


>   - Page 7: What do you mean by "Fundamental Changes"? = As in changes to RFC 793? If so, can the Section be called that -- "Ch= anges to RFC 0793"? At least state it clearly in the intro paragraph t= o this section. Without a clear explanation, it is difficult to see why 5482 is a Fundamental Change.

>From the introduction text of section 3 of the old roadmap:

"3.  Recommended Enhancements
   This section describes recommended TCP modifications that impr= ove
   performance and security.  RFCs 1323 and 3168 represent f= undamental
   changes to the protocol. …
"

So, the authors of the RFC4614 saw this two RFCs as fundamental changes. The only thing that I did, was the creation of a new section with exactly t= his
wording.

Nevertheless you (and also Yuchung) are right that RFC 5482 is *not* a fund= amental change.
Therefore I move RFC 5482 out of this section, but leave the title as it is= .

Personally, I do not like the title "Changes to RFC 0793“ since = there are some other
RFC that also make changes to 793 but do not belong to this section.

 

For reference, the original 4614 had three RFCs at t= he beginning of Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms)= , and 3168 (ECN).  As far as I can recall, this was because (a) they d= idn't fit neatly into a grouping with other RFCs and we didn't want subsections with 1 RFC; and (b) 1323 and 3168 are = really important and should be at the front. It's only 1323 and 3168 that w= e describe as "fundamental," as a way of introducing them instead= of any sort of formal taxonomy.

 

I agree that 3168 fits in well under congestion cont= rol; as for the two now in 3.1, I'd just as soon we rename the section as &= quot;Miscellaneous changes" or "general changes" or even &qu= ot;large packets and windows". I'm open to people's suggestions for naming.

 

I'm aesthetically displeased with 5482 out there by = itself in its own subsection, and would probably prefer it in "miscell= aneous changes," but if others feel differently it isn't a big deal to= me.

 

>   - I'll echo Yuchung's earlier comment th= at 3.2, 3.3, 3.4, 3.5 should be reorganized into two sections: Congestion C= ontrol, and Loss Recovery.

Yes and no. Yuchung suggested to re-organize section 3.2 and 3.3, but *not*= 3.4 and 3.5.
In version 01 we have now:

3.2.  Congestion Control Extensions
3.3.  Loss Recovery Extensions
3.4.  Detection and Prevention of Spurious Retransmissions

and the same structure in sec 4. (which was not suggested by Yuchung ;-))
Strictly speaking, sec 3.4 is a subcategory of sec. 3.3. You are right. But= for a better
structuring, I suggest that we put every spurious detection/reaction algo i= nto a separate
sub-section. A reader can find the docs in question much easier.  BTW,= we did the same
thing with MPTCP. All MPTCP docs belongs in some way to CC and LR too, but = have their
own sub-section.

 

I concur with Alexander's answers to this comment an= d all that followed.

 

<snip>


> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F25F02E8ESACEXCMBX02PRDh_-- From martin.h.duke@gmail.com Wed Dec 4 10:21:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6161AE194 for ; Wed, 4 Dec 2013 10:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFSftk_x0RJc for ; Wed, 4 Dec 2013 10:21:23 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id CB2851AE26D for ; Wed, 4 Dec 2013 10:21:21 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id ie18so11734215vcb.38 for ; Wed, 04 Dec 2013 10:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8xkqFqrlDxbs0YPM7dImUmQTbh44SbkrYux+zYDA0gg=; b=PLfAZcFoGlphXUy3kwdMxXoE1610nGRDJY+5EZHtRsU6oABw9bCACDUjrqibwboLv8 EO02JoGDu5bmzMSVq1EMAKnlt99S4HzuIj7y0+bda68jKyR7lWrQkNttnII5FoST5NkF EAB217nUkbJIoGeeMmqumudX8ttms9kS4mBeEGHUzF0hcRqXSG9gDw9t02Nh9QGUEHJR R1DZVW/RLCbVQk+2ayA4UncGGkaPaB8F+FJP/stVZjkOmcCNwYgyCCUhRVNQDA6X1hAH jNpQWLGuO5bXH+q+h29/7xIg85iMjSpZ11dwdaY2K71wHWV1SmdYcDV+sw/bCYgpPJM5 81EA== MIME-Version: 1.0 X-Received: by 10.220.19.134 with SMTP id a6mr1454327vcb.36.1386181278604; Wed, 04 Dec 2013 10:21:18 -0800 (PST) Received: by 10.220.160.130 with HTTP; Wed, 4 Dec 2013 10:21:18 -0800 (PST) In-Reply-To: <87CC9397-9DE3-4CC4-B432-4B931355BFF7@netapp.com> References: <87CC9397-9DE3-4CC4-B432-4B931355BFF7@netapp.com> Date: Wed, 4 Dec 2013 10:21:18 -0800 Message-ID: From: Martin Duke To: "Zimmermann, Alexander" Content-Type: multipart/alternative; boundary=001a11c3ae1cb4ce8104ecb97add Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RFC 4614 bis comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 18:21:26 -0000 --001a11c3ae1cb4ce8104ecb97add Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 20, 2013 at 2:29 AM, Zimmermann, Alexander < Alexander.Zimmermann@netapp.com> wrote: > > > Section 3.4: So I take it that, based on its inclusion in Section 3, we > specifically recommend F-RTO and Eifel Response over the alternatives? If > that is not the intent here than this section must be substantially revis= ed. > > IMO the roadmap =84recommend=93 nothing; it=92s a survey. From the introd= uction: > > =84This document is not an update of RFC 1122 and is not a rigorous > standard for what needs to be implemented in TCP. This document is > merely an informational roadmap that captures, organizes, and > summarizes most of the RFC documents that a TCP implementer, > experimenter, or student should be aware of. Particular comments or > broad categorizations that this document makes about individual > mechanisms and behaviors are not to be taken as definitive, nor > should the content of this document alone influence implementation > decisions.=93 > > and > > =84Note that the category of an RFC does not necessarily reflect its > current relevance. For instance, RFC 5681 is nearly universally > deployed although it is only a Draft Standard. Similarly, some > Informational RFCs contain significant technical proposals for > changing TCP.=93 > > If it is not clear that we do not make any implementation recommendation > in this doc, we should instead work on introduction. > > Further, the introductions says: > > "This roadmap is divided into three main sections. Section 2 lists > the RFCs that describe absolutely required TCP behaviors for proper > functioning and interoperability. Further RFCs that describe > strongly encouraged, but non-essential, behaviors are listed in > Section 3. Experimental extensions that are not yet standard > practices, but that potentially could be in the future, are described > in Section 4.=93 > > IMO its clear, why for example Eifel response is in sec 4.4, since > it is an Experimental draft. > I disagree with this interpretation. Section 3 is entitled "Recommended Enhancements". Given the Informational nature of this RFC, it's probably incorrect to use the word "recommended", but I think the phrase "strong encouraged" is appropriate. The original intent was taht implementers really ought to use the RFCs in Section 3 in a modern TCP implementation even if they're not strictly required. If something is not well-understood as a common feature of modern implementations it should be in Section 4, whether it's experimental, information, or proposed standard. --001a11c3ae1cb4ce8104ecb97add Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 20, 2013 at 2:29 AM, Zimmermann, Alexander <Alexander.Zimmermann@netapp.com> wrote:
=A0
<snip>

>
> Section 3.4: So I take it that, based on its inclusion in Section 3, w= e specifically recommend F-RTO and Eifel Response over the alternatives? If= that is not the intent here than this section must be substantially revise= d.

IMO the roadmap =84recommend=93 nothing; it=92s a survey. From the introduc= tion:

=84This document is not an update of RFC 1122 and is not a rigorous
standard for what needs to be implemented in TCP. =A0This document is
merely an informational roadmap that captures, organizes, and
summarizes most of the RFC documents that a TCP implementer,
experimenter, or student should be aware of. =A0Particular comments or
broad categorizations that this document makes about individual
mechanisms and behaviors are not to be taken as definitive, nor
should the content of this document alone influence implementation
decisions.=93

and

=84Note that the category of an RFC does not necessarily reflect its
current relevance. =A0For instance, RFC 5681 is nearly universally
deployed although it is only a Draft Standard. =A0Similarly, some
Informational RFCs contain significant technical proposals for
changing TCP.=93

If it is not clear that we do not make any implementation recommendation in this doc, we should instead work on introduction.

Further, the introductions says:

"This roadmap is divided into three main sections. =A0Section 2 lists<= br> the RFCs that describe absolutely required TCP behaviors for proper
functioning and interoperability. =A0Further RFCs that describe
strongly encouraged, but non-essential, behaviors are listed in
Section 3. =A0Experimental extensions that are not yet standard
practices, but that potentially could be in the future, are described
in Section 4.=93

IMO its clear, why for example Eifel response is in sec 4.4, since
it is an Experimental draft.

I disagree with this interpretation. Section 3 is entitled "Recommen= ded Enhancements". Given the Informational nature of this RFC, it'= s probably incorrect to use the word "recommended", but I think t= he phrase "strong encouraged" is appropriate. The original intent= was taht implementers really ought to use the RFCs in Section 3 in a moder= n TCP implementation even if they're not strictly required. If somethin= g is not well-understood as a common feature of modern implementations it s= hould be in Section 4, whether it's experimental, information, or propo= sed standard.
--001a11c3ae1cb4ce8104ecb97add-- From Alexander.Zimmermann@netapp.com Thu Dec 5 01:50:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1251ADD02 for ; Thu, 5 Dec 2013 01:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW-QLJSksXLx for ; Thu, 5 Dec 2013 01:50:43 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id EA9431ADBF7 for ; Thu, 5 Dec 2013 01:50:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,831,1378882800"; d="asc'?scan'208,217";a="124213260" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 05 Dec 2013 01:50:39 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.58]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 01:50:38 -0800 From: "Zimmermann, Alexander" To: Martin Duke , Wesley Eddy Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 Thread-Index: AQHOyqa+XaYrLixeXU6FriXTRq34OJowat2AgBONxgCAAjcRgA== Date: Thu, 5 Dec 2013 09:50:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_3B573011-FCE0-4D8E-8361-4AE10FE95AAF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , " Blanton" , "Braden " Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:50:48 -0000 --Apple-Mail=_3B573011-FCE0-4D8E-8361-4AE10FE95AAF Content-Type: multipart/alternative; boundary="Apple-Mail=_11B6237A-F1F4-4D6C-B3CE-8D1BF9CB072D" --Apple-Mail=_11B6237A-F1F4-4D6C-B3CE-8D1BF9CB072D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline. Am 04.12.2013 um 01:01 schrieb Martin Duke : > Comments inline. >=20 > On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexander = wrote: >=20 > Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar = : >=20 > > > > Comments: > > - Page 6: "This is generally regarded as the least common = denominator among TCP flavors currently found running on Internet = hosts." I thought that the least-common denominator was NewReno. Is that = incorrect? >=20 > This is C&P text from the original roadmap. Since I=92m not the author = of this section, I have problems to value your comment. > If the WG has (now) feeling that NewReno and not Reno is the least = common denominator I can delete the sentence. NP. >=20 > Perhaps others with more field experience feel differently, but by a = reading of the RFCs, 6582 explains NewReno, and explicitly does not = obsolete 5681. I take that to mean that a host can run Reno and still be = compliant. =46rom standardization point of view is this correct, so I will let the = text as it is. If somebody strongly disagree, he can provide me some text and I will = incorporate it :-) > =20 >=20 > > - Page 7: What do you mean by "Fundamental Changes"? As in changes = to RFC 793? If so, can the Section be called that -- "Changes to RFC = 0793"? At least state it clearly in the intro paragraph to this section. = Without a clear explanation, it is difficult to see why 5482 is a = Fundamental Change. >=20 > =46rom the introduction text of section 3 of the old roadmap: >=20 > "3. Recommended Enhancements > This section describes recommended TCP modifications that improve > performance and security. RFCs 1323 and 3168 represent fundamental > changes to the protocol. =85 > " >=20 > So, the authors of the RFC4614 saw this two RFCs as fundamental = changes. > The only thing that I did, was the creation of a new section with = exactly this > wording. >=20 > Nevertheless you (and also Yuchung) are right that RFC 5482 is *not* a = fundamental change. > Therefore I move RFC 5482 out of this section, but leave the title as = it is. >=20 > Personally, I do not like the title "Changes to RFC 0793=93 since = there are some other > RFC that also make changes to 793 but do not belong to this section. >=20 > For reference, the original 4614 had three RFCs at the beginning of = Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168 = (ECN). As far as I can recall, this was because (a) they didn't fit = neatly into a grouping with other RFCs and we didn't want subsections = with 1 RFC; and (b) 1323 and 3168 are really important and should be at = the front. It's only 1323 and 3168 that we describe as "fundamental," as = a way of introducing them instead of any sort of formal taxonomy. >=20 > I agree that 3168 fits in well under congestion control; as for the = two now in 3.1, I'd just as soon we rename the section as "Miscellaneous = changes" or "general changes" or even "large packets and windows". I'm = open to people's suggestions for naming. =84Fundamental changes=93 reflects more the importance of RFC 1323, =84General changes=93 is maybe more suitable for RFC 2675. I=92m fine with both of them. Wes? >=20 > I'm aesthetically displeased with 5482 out there by itself in its own = subsection, and would probably prefer it in "miscellaneous changes," but = if others feel differently it isn't a big deal to me. The upcoming draft-ietf-tcpm-rtorestart-01 is also a candidate for the = new TCP Timeouts section. Since RFC 5482 is still not deployed I will move this section into sec. = 4 and integrate the upcoming RFC in RTO Restart too. OK? > =20 > > - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, 3.5 = should be reorganized into two sections: Congestion Control, and Loss = Recovery. >=20 > Yes and no. Yuchung suggested to re-organize section 3.2 and 3.3, but = *not* 3.4 and 3.5. > In version 01 we have now: >=20 > 3.2. Congestion Control Extensions > 3.3. Loss Recovery Extensions > 3.4. Detection and Prevention of Spurious Retransmissions >=20 > and the same structure in sec 4. (which was not suggested by Yuchung = ;-)) >=20 > Strictly speaking, sec 3.4 is a subcategory of sec. 3.3. You are = right. But for a better > structuring, I suggest that we put every spurious detection/reaction = algo into a separate > sub-section. A reader can find the docs in question much easier. BTW, = we did the same > thing with MPTCP. All MPTCP docs belongs in some way to CC and LR too, = but have their > own sub-section. >=20 > I concur with Alexander's answers to this comment and all that = followed. > =20 > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 --Apple-Mail=_11B6237A-F1F4-4D6C-B3CE-8D1BF9CB072D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Inline.

Am 04.12.2013 um 01:01 = schrieb Martin Duke <martin.h.duke@gmail.com>:
Comments inline.

On Thu, Nov = 21, 2013 at 5:24 AM, Zimmermann, Alexander <Alexander.Zimmermann@netapp.com> = wrote:

Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar <janardhan.iyengar@fandm.edu>:

>
> Comments:
>   - Page 6: "This is generally regarded as the least common = denominator among TCP flavors currently found running on Internet = hosts." I thought that the least-common denominator was NewReno. Is that = incorrect?

This is C&P text from the original roadmap. Since I=92m not the = author of this section, I have problems to value your comment.
If the WG has (now) feeling that NewReno and not Reno is the least = common denominator I can delete the sentence. = NP.



 

>   - Page 7: What do you mean by "Fundamental Changes"? As in = changes to RFC 793? If so, can the Section be called that -- "Changes to = RFC 0793"? At least state it clearly in the intro paragraph to this = section. Without a clear explanation, it is difficult to see why 5482 is = a Fundamental Change.

=46rom the introduction text of section 3 of the old roadmap:

"3.  Recommended Enhancements
   This section describes recommended TCP modifications that = improve
   performance and security.  RFCs 1323 and 3168 = represent fundamental
   changes to the protocol. =85
"

So, the authors of the RFC4614 saw this two RFCs as fundamental = changes.
The only thing that I did, was the creation of a new section with = exactly this
wording.

Nevertheless you (and also Yuchung) are right that RFC 5482 is *not* a = fundamental change.
Therefore I move RFC 5482 out of this section, but leave the title as it = is.

Personally, I do not like the title "Changes to RFC 0793=93 since there = are some other
RFC that also make changes to 793 but do not belong to this = section.

For reference, the original = 4614 had three RFCs at the beginning of Section 3 -- 1323 (timestamps, = etc), 2675 (IPv6 jumbograms), and 3168 (ECN).  As far as I can = recall, this was because (a) they didn't fit neatly into a grouping with = other RFCs and we didn't want subsections with 1 RFC; and (b) 1323 and = 3168 are really important and should be at the front. It's only 1323 and = 3168 that we describe as "fundamental," as a way of introducing them = instead of any sort of formal taxonomy.

I agree that 3168 fits in well under congestion = control; as for the two now in 3.1, I'd just as soon we rename the = section as "Miscellaneous changes" or "general changes" or even "large = packets and windows". I'm open to people's suggestions for = naming.

=84Fundame= ntal changes=93 reflects more the importance of RFC = 1323,
=84General changes=93 is maybe more suitable for RFC = 2675. I=92m fine
with both of = them.

Wes?


I'm aesthetically displeased with 5482 out there by = itself in its own subsection, and would probably prefer it in = "miscellaneous changes," but if others feel differently it isn't a big = deal to me.

The = upcoming draft-ietf-tcpm-rtorestart-01 is also a candidate for the = new TCP Timeouts section.
Since RFC 5482 is still not = deployed I will move this section into sec. 4 and integrate = the
upcoming RFC in RTO Restart too. OK?

 
>   - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, = 3.5 should be reorganized into two sections: Congestion Control, and = Loss Recovery.

Yes and no. Yuchung suggested to re-organize section 3.2 and 3.3, but = *not* 3.4 and 3.5.
In version 01 we have now:

3.2.  Congestion Control Extensions
3.3.  Loss Recovery Extensions
3.4.  Detection and Prevention of Spurious Retransmissions

and the same structure in sec 4. (which was not suggested by Yuchung = ;-))

Strictly speaking, sec 3.4 is a subcategory of sec. 3.3. You are right. = But for a better
structuring, I suggest that we put every spurious detection/reaction = algo into a separate
sub-section. A reader can find the docs in question much easier. =  BTW, we did the same
thing with MPTCP. All MPTCP docs belongs in some way to CC and LR too, = but have their
own sub-section.

I concur with = Alexander's answers to this comment and all that = followed.
 
<snip>

> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm



= --Apple-Mail=_11B6237A-F1F4-4D6C-B3CE-8D1BF9CB072D-- --Apple-Mail=_3B573011-FCE0-4D8E-8361-4AE10FE95AAF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKgTG0ACgkQdyiq39b9uS4ReACfdk8QDToHFoNfkEQd3U+zV0oH Gv4AoMoif25YxqSG8e2of3Q9kgk22bKm =bmlG -----END PGP SIGNATURE----- --Apple-Mail=_3B573011-FCE0-4D8E-8361-4AE10FE95AAF-- From wes@mti-systems.com Thu Dec 5 06:59:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED92E1ADF30 for ; Thu, 5 Dec 2013 06:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxL-lBgyQ4pa for ; Thu, 5 Dec 2013 06:59:13 -0800 (PST) Received: from atl4mhob02.myregisteredsite.com (atl4mhob02.myregisteredsite.com [209.17.115.40]) by ietfa.amsl.com (Postfix) with ESMTP id 959E41AC863 for ; Thu, 5 Dec 2013 06:59:13 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id rB5Ex9IQ021697 for ; Thu, 5 Dec 2013 09:59:09 -0500 Received: (qmail 8588 invoked by uid 0); 5 Dec 2013 14:59:09 -0000 X-TCPREMOTEIP: 107.46.32.37 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.32.37) by 0 with ESMTPA; 5 Dec 2013 14:59:08 -0000 Message-ID: <52A094B7.9050706@mti-systems.com> Date: Thu, 05 Dec 2013 09:59:03 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Zimmermann, Alexander" , Martin Duke References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "tcpm@ietf.org Extensions" , " Blanton" , "Braden " Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:59:15 -0000 On 12/5/2013 4:50 AM, Zimmermann, Alexander wrote: > >> >> For reference, the original 4614 had three RFCs at the beginning of >> Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168 >> (ECN). As far as I can recall, this was because (a) they didn't fit >> neatly into a grouping with other RFCs and we didn't want subsections >> with 1 RFC; and (b) 1323 and 3168 are really important and should be >> at the front. It's only 1323 and 3168 that we describe as >> "fundamental," as a way of introducing them instead of any sort of >> formal taxonomy. >> >> I agree that 3168 fits in well under congestion control; as for the >> two now in 3.1, I'd just as soon we rename the section as >> "Miscellaneous changes" or "general changes" or even "large packets >> and windows". I'm open to people's suggestions for naming. > > „Fundamental changes“ reflects more the importance of RFC 1323, > „General changes“ is maybe more suitable for RFC 2675. I’m fine > with both of them. > > Wes? > I don't have a strong preference, but it seems to me that we failed to explain a commonality between 1323 and 2675, which is that both define how to re-interpret pieces of the basic TCP header and options. 1323 has Window Scaling which re-interprets the advertised receive window, and 2675 specifies that MSS or urgent pointer fields of 65,535 are to be treated specially. So, to me, that is why both can easily be grouped as "fundamental changes". I think we could add a sentence at the beginning of section 3.1 to explain this, as it would be more informative than the current 2 sentences there, which are largely just summarizing text later on in the descriptions of both documents, and not actually explaining the reason why they're fundamental changes. -- Wes Eddy MTI Systems From internet-drafts@ietf.org Thu Dec 5 14:32:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF5D1AE217; Thu, 5 Dec 2013 14:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qP1GpNXUrPj; Thu, 5 Dec 2013 14:32:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 394761AE026; Thu, 5 Dec 2013 14:32:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205223249.7176.23116.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 14:32:49 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-18.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 22:32:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-18.txt Pages : 48 Date : 2013-12-05 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, PAWS (Protection Against Wrapped Sequences) and RTTM (Round Trip Time Measurement), that are also described herein. This document obsoletes RFC1323 and describes changes from it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Thu Dec 5 14:37:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632511AE13B for ; Thu, 5 Dec 2013 14:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGB4QT-ZrwC2 for ; Thu, 5 Dec 2013 14:37:01 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id D222E1AE0B8 for ; Thu, 5 Dec 2013 14:37:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,836,1378882800"; d="scan'208";a="124511955" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 05 Dec 2013 14:36:58 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.147]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 14:36:58 -0800 From: "Scheffenegger, Richard" To: "David Borman (David.Borman@quantum.com)" , "tcpm (tcpm@ietf.org)" , "Pasi Sarolahti (pasi.sarolahti@iki.fi)" Thread-Topic: New Version Notification for draft-ietf-tcpm-1323bis-18.txt Thread-Index: AQHO8gnvNa6DR5zezk2uvYSFaA+8Z5pGL/gg Date: Thu, 5 Dec 2013 22:36:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25F0BDBC@SACEXCMBX02-PRD.hq.netapp.com> References: <20131205223249.7176.41889.idtracker@ietfa.amsl.com> In-Reply-To: <20131205223249.7176.41889.idtracker@ietfa.amsl.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-18.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 22:37:04 -0000 SGksDQoNClRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgYWxsIG9mIHRoZSBBbWVyaWNhbiAvIGJyaXRp c2ggRW5nbGlzaCBpc3N1ZXMgcG9pbnRlZCBvdXQgYnkgRGF2aWQgZHVyaW5nIFdHTEMsIGFkZGVk IHRoZSAib2Jzb2xldGVzIDEzMjMiIGhlYWRlciwgYW5kIGZpeGVkIG1vc3Qgb2YgdGhlIG90aGVy IG5pdHMgKG1vc3RseSBvdXRkYXRlZCBhbmQgdW51c2VkIHJlZmVyZW5jZXMpIGZvdW5kIGluIHRo ZSBsYXN0IHR3byB3ZWVrcy4NCg0KTm8gY2hhbmdlIG9mIHRleHQgb3IgY29udGVudCBiZXR3ZWVu IC0xNyBhbmQgLTE4Lg0KDQoNClJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogRG9ubmVyc3RhZywgMDUuIERlemVt YmVyIDIwMTMgMjM6MzMNCj4gVG86IFZhbiBKYWNvYnNvbjsgU2NoZWZmZW5lZ2dlciwgUmljaGFy ZDsgUm9iZXJ0IFQuQnJhZGVuOyBEYXZpZCBCb3JtYW47DQo+IEJvYiBCcmFkZW4NCj4gU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRjcG0tMTMyM2Jpcy0x OC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi10Y3BtLTEz MjNiaXMtMTgudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseQ0KPiBzdWJtaXR0ZWQgYnkgRGF2aWQg Qm9ybWFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1l OgkgZHJhZnQtaWV0Zi10Y3BtLTEzMjNiaXMNCj4gUmV2aXNpb246CSAxOA0KPiBUaXRsZToJCSBU Q1AgRXh0ZW5zaW9ucyBmb3IgSGlnaCBQZXJmb3JtYW5jZQ0KPiBDcmVhdGlvbiBkYXRlOgkgMjAx My0xMi0wNQ0KPiBHcm91cDoJCSB0Y3BtDQo+IE51bWJlciBvZiBwYWdlczogNDgNCj4gVVJMOiAg ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LXRjcG0tDQo+IDEzMjNiaXMtMTgudHh0DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRjcG0tMTMyM2Jpcw0KPiBIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS0xMzIzYmlz LTE4DQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi10Y3BtLTEzMjNiaXMtDQo+IDE4DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzZXQgb2YgVENQIGV4dGVuc2lvbnMgdG8gaW1wcm92ZQ0K PiAgICBwZXJmb3JtYW5jZSBvdmVyIHBhdGhzIHdpdGggYSBsYXJnZSBiYW5kd2lkdGggKiBkZWxh eSBwcm9kdWN0IGFuZCB0bw0KPiAgICBwcm92aWRlIHJlbGlhYmxlIG9wZXJhdGlvbiBvdmVyIHZl cnkgaGlnaC1zcGVlZCBwYXRocy4gIEl0IGRlZmluZXMNCj4gICAgdGhlIFRDUCBXaW5kb3cgU2Nh bGUgKFdTKSBvcHRpb24gYW5kIHRoZSBUQ1AgVGltZXN0YW1wcyAoVFMpIG9wdGlvbg0KPiAgICBh bmQgdGhlaXIgc2VtYW50aWNzLiAgVGhlIFdpbmRvdyBTY2FsZSBvcHRpb24gaXMgdXNlZCB0byBz dXBwb3J0DQo+ICAgIGxhcmdlciByZWNlaXZlIHdpbmRvd3MsIHdoaWxlIHRoZSBUaW1lc3RhbXBz IG9wdGlvbiBjYW4gYmUgdXNlZCBmb3INCj4gICAgYXQgbGVhc3QgdHdvIGRpc3RpbmN0IG1lY2hh bmlzbXMsIFBBV1MgKFByb3RlY3Rpb24gQWdhaW5zdCBXcmFwcGVkDQo+ICAgIFNlcXVlbmNlcykg YW5kIFJUVE0gKFJvdW5kIFRyaXAgVGltZSBNZWFzdXJlbWVudCksIHRoYXQgYXJlIGFsc28NCj4g ICAgZGVzY3JpYmVkIGhlcmVpbi4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJG QzEzMjMgYW5kIGRlc2NyaWJlcyBjaGFuZ2VzIGZyb20gaXQuDQo+IA0KPiANCj4gDQo+IA0KPiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From pasi.sarolahti@iki.fi Sun Dec 8 05:36:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A581ADF89 for ; Sun, 8 Dec 2013 05:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5SNgc11P-CC for ; Sun, 8 Dec 2013 05:36:55 -0800 (PST) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 17A811ADF58 for ; Sun, 8 Dec 2013 05:36:53 -0800 (PST) Received: from pasisarahtismbp.lan (80.223.92.46) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 527750DA02F409A1 for tcpm@ietf.org; Sun, 8 Dec 2013 15:36:48 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Pasi Sarolahti In-Reply-To: <28952_1384786256_528A2950_28952_4143_1_F109A0B9-250A-49F7-8C8A-60ED14FBDC6D@iki.fi> Date: Sun, 8 Dec 2013 15:36:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28952_1384786256_528A2950_28952_4143_1_F109A0B9-250A-49F7-8C8A-60ED14FBDC6D@iki.fi> To: "tcpm@ietf.org (tcpm@ietf.org)" X-Mailer: Apple Mail (2.1822) Subject: [tcpm] Concluding WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 13:36:59 -0000 Hi, The WGLC on draft-ietf-tcpm-1323bis concluded a few days ago. No new = comments were made during the WGLC, apart from the editorial nits that = are now addressed in the latest version, as pointed out by Richard in = his Email. We will now proceed with submitting the document to the IESG. Below is a draft write-up for the document (pending some final = nit-checking). Many thanks to the authors for the effort, particularly to Richard, for = helping to get the draft completed, as well as to the working group = participants for the review cycles and active discussion! - Pasi --------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This draft replaces earlier RFC 1323 that also was a Proposed Standard. The title page header currently says "Standards Track". (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document replaces RFC 1323, making minor fixes and clarifications to the original document. The document specifies three performance enhancing extensions to TCP, using two TCP options. The first is window scale option, that allows representation of receive window sizes larger than 2^16 bytes originally allowed by the 16-bit window field. The second option is TCP timestamps option that allows round-trip time measurement on each TCP segment, and third is an algorithm to detect and reject old duplicate segments that happen to match the current TCP window (Protect Against Wrapped Sequence numbers). Working Group Summary This document has been a chartered TCPM working group item since year 2008. It has not been under significant controversy, but the progress has been slow because of earlier lack of WG (and authoring) cycles. Since adding a new co-editor, the progress on the draft became faster in the working group. Document Quality The predecessor of this document, RFC 1323, was published in 1992, and is deployed in most TCP implementations. This document includes fixes and clarifications based on the gained deployment experience. The recent versions of the document have been reviewed and discussed by multiple working group participants. Personnel Document Shepherd is Pasi Sarolahti. Reponsible Area Director is Martin Stiemerling (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has read the latest version of the document and the recent mailing list discussion, and thinks the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. =20 (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Document shepherd does not have concerns about the document (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. To be confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed on this document (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20= The recent versions of the document were extensively discussed on the TCPM mailing list, by several members of the community, for example regarding the normative language about how to handle packets without TCP timestamps option after use of timestamps has been negotiated (which is considered a corner case in today's implementations). The current approach is not unanimously supported by all working group participants, but the WG chairs think it represents the rough consensus of the WG. There were also some opinions suggesting that some of the benefits could be achieved with less TCP option overhead. The WG chairs concluded that considering the original scope of the document (fixes and clarifications to RFC 1323), and its large existing deployment base, it is important to publish the current document, but keep the discussion open for future enhancements. (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are informational references to obsolete RFCs 1072 and RFC 1185. These are left in for documenting the history behind this document, and are included intentionally. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in = the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no new IANA considerations, even though the document specifies two TCP options, because the needed numbers have already been allocated when publishing RFC 1323. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registeries needed. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No automated checks needed. From Alexander.Zimmermann@netapp.com Tue Dec 10 07:01:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3552D1ADFE5 for ; Tue, 10 Dec 2013 07:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz9qAmRUXl8w for ; Tue, 10 Dec 2013 07:01:47 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 626C31ADF90 for ; Tue, 10 Dec 2013 07:01:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,865,1378882800"; d="asc'?scan'208";a="85896068" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 10 Dec 2013 07:01:42 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.58]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 07:01:41 -0800 From: "Zimmermann, Alexander" To: Wesley Eddy Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 Thread-Index: AQHOyqa+XaYrLixeXU6FriXTRq34OJowat2AgBONxgCAAjcRgIAAVi2AgAfcZIA= Date: Tue, 10 Dec 2013 15:01:41 +0000 Message-ID: References: <52A094B7.9050706@mti-systems.com> In-Reply-To: <52A094B7.9050706@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_E7648E85-9EC1-4C02-BFA5-40E4C9955930"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:01:49 -0000 --Apple-Mail=_E7648E85-9EC1-4C02-BFA5-40E4C9955930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Wes, Am 05.12.2013 um 15:59 schrieb Wesley Eddy : > On 12/5/2013 4:50 AM, Zimmermann, Alexander wrote: >>=20 >>>=20 >>> For reference, the original 4614 had three RFCs at the beginning of >>> Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and = 3168 >>> (ECN). As far as I can recall, this was because (a) they didn't fit >>> neatly into a grouping with other RFCs and we didn't want = subsections >>> with 1 RFC; and (b) 1323 and 3168 are really important and should be >>> at the front. It's only 1323 and 3168 that we describe as >>> "fundamental," as a way of introducing them instead of any sort of >>> formal taxonomy. >>>=20 >>> I agree that 3168 fits in well under congestion control; as for the >>> two now in 3.1, I'd just as soon we rename the section as >>> "Miscellaneous changes" or "general changes" or even "large packets >>> and windows". I'm open to people's suggestions for naming. >>=20 >> =84Fundamental changes=93 reflects more the importance of RFC 1323, >> =84General changes=93 is maybe more suitable for RFC 2675. I=92m fine >> with both of them. >>=20 >> Wes? >>=20 >=20 >=20 > I don't have a strong preference, but it seems to me that we > failed to explain a commonality between 1323 and 2675, which > is that both define how to re-interpret pieces of the basic > TCP header and options. 1323 has Window Scaling which > re-interprets the advertised receive window, and 2675 specifies > that MSS or urgent pointer fields of 65,535 are to be treated > specially. >=20 > So, to me, that is why both can easily be grouped as "fundamental > changes". I think we could add a sentence at the beginning of > section 3.1 to explain this, as it would be more informative than > the current 2 sentences there, which are largely just summarizing > text later on in the descriptions of both documents, and not > actually explaining the reason why they're fundamental changes. I agree. I add the following text: RFCs 1323 and 2675 represent fundamental changes to TCP by redefining how parts of the basic TCP header and options are interpreted. RFC 1323 defines the Window Scale Option, which re-interprets the advertised receive window. RFC 2675 specifies that MSS option and urgent pointer fields with a value of 65,535 are to be treated specially. >=20 > --=20 > Wes Eddy > MTI Systems --Apple-Mail=_E7648E85-9EC1-4C02-BFA5-40E4C9955930 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKnLNUACgkQdyiq39b9uS7MhgCdHvoU5ga9tXPZVSX+6Yq+9P85 D2EAoM09Nn5+J0I2IeNDj8sJuHJuG1Rz =yMTQ -----END PGP SIGNATURE----- --Apple-Mail=_E7648E85-9EC1-4C02-BFA5-40E4C9955930-- From Alexander.Zimmermann@netapp.com Tue Dec 10 07:53:41 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223941ADF96 for ; Tue, 10 Dec 2013 07:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEHsAMTyj3MX for ; Tue, 10 Dec 2013 07:53:39 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF6D1ADF7C for ; Tue, 10 Dec 2013 07:53:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,865,1378882800"; d="asc'?scan'208,217";a="85920647" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 10 Dec 2013 07:53:34 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.58]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 07:53:33 -0800 From: "Zimmermann, Alexander" To: Martin Duke Thread-Topic: [tcpm] RFC 4614 bis comments Thread-Index: AQHO5dtfE62pBCLVnU67DTOrIIt3zJpE9aUAgAlEs4A= Date: Tue, 10 Dec 2013 15:53:31 +0000 Message-ID: <2E1A2374-CA2F-4DA4-8CC5-56C1C768C930@netapp.com> References: <87CC9397-9DE3-4CC4-B432-4B931355BFF7@netapp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_1B27A675-F87B-4EE6-9CF3-CA9C72AE671A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RFC 4614 bis comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:53:41 -0000 --Apple-Mail=_1B27A675-F87B-4EE6-9CF3-CA9C72AE671A Content-Type: multipart/alternative; boundary="Apple-Mail=_372A161A-16DB-49A2-B467-2F968864B27E" --Apple-Mail=_372A161A-16DB-49A2-B467-2F968864B27E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Martin, Am 04.12.2013 um 19:21 schrieb Martin Duke : >=20 >=20 >=20 > On Wed, Nov 20, 2013 at 2:29 AM, Zimmermann, Alexander = wrote: > =20 > >=20 > > > > Section 3.4: So I take it that, based on its inclusion in Section 3, = we specifically recommend F-RTO and Eifel Response over the = alternatives? If that is not the intent here than this section must be = substantially revised. >=20 > IMO the roadmap =84recommend=93 nothing; it=92s a survey. =46rom the = introduction: >=20 > =84This document is not an update of RFC 1122 and is not a rigorous > standard for what needs to be implemented in TCP. This document is > merely an informational roadmap that captures, organizes, and > summarizes most of the RFC documents that a TCP implementer, > experimenter, or student should be aware of. Particular comments or > broad categorizations that this document makes about individual > mechanisms and behaviors are not to be taken as definitive, nor > should the content of this document alone influence implementation > decisions.=93 >=20 > and >=20 > =84Note that the category of an RFC does not necessarily reflect its > current relevance. For instance, RFC 5681 is nearly universally > deployed although it is only a Draft Standard. Similarly, some > Informational RFCs contain significant technical proposals for > changing TCP.=93 >=20 > If it is not clear that we do not make any implementation = recommendation > in this doc, we should instead work on introduction. >=20 > Further, the introductions says: >=20 > "This roadmap is divided into three main sections. Section 2 lists > the RFCs that describe absolutely required TCP behaviors for proper > functioning and interoperability. Further RFCs that describe > strongly encouraged, but non-essential, behaviors are listed in > Section 3. Experimental extensions that are not yet standard > practices, but that potentially could be in the future, are described > in Section 4.=93 >=20 > IMO its clear, why for example Eifel response is in sec 4.4, since > it is an Experimental draft. >=20 > I disagree with this interpretation. Section 3 is entitled = "Recommended Enhancements". Given the Informational nature of this RFC, = it's probably incorrect to use the word "recommended", but I think the = phrase "strong encouraged" is appropriate. I don=92t think that we are not on same page here :-) As I wrote, I also = believe that we should not recommend something. IMO the only thing we should changed is the title of Section 3 to = =84Strong Encouraged Enhancements=93. > The original intent was taht implementers really ought to use the RFCs = in Section 3 in a modern TCP implementation even if they're not strictly = required. If something is not well-understood as a common feature of = modern implementations it should be in Section 4, whether it's = experimental, information, or proposed standard. Which is still true in the current Draft. Alex --Apple-Mail=_372A161A-16DB-49A2-B467-2F968864B27E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Martin,

Am 04.12.2013 um 19:21 schrieb Martin Duke = <martin.h.duke@gmail.com>:



On Wed, Nov 20, 2013 at 2:29 AM, Zimmermann, = Alexander <Alexander.Zimmermann@netapp.com> = wrote:
 
<snip>

>
> Section 3.4: So I take it that, based on its inclusion in Section = 3, we specifically recommend F-RTO and Eifel Response over the = alternatives? If that is not the intent here than this section must be = substantially revised.

IMO the roadmap =84recommend=93 nothing; it=92s a survey. =46rom the = introduction:

=84This document is not an update of RFC 1122 and is not a rigorous
standard for what needs to be implemented in TCP.  This document = is
merely an informational roadmap that captures, organizes, and
summarizes most of the RFC documents that a TCP implementer,
experimenter, or student should be aware of.  Particular comments = or
broad categorizations that this document makes about individual
mechanisms and behaviors are not to be taken as definitive, nor
should the content of this document alone influence implementation
decisions.=93

and

=84Note that the category of an RFC does not necessarily reflect its
current relevance.  For instance, RFC 5681 is nearly = universally
deployed although it is only a Draft Standard.  Similarly, some
Informational RFCs contain significant technical proposals for
changing TCP.=93

If it is not clear that we do not make any implementation = recommendation
in this doc, we should instead work on introduction.

Further, the introductions says:

"This roadmap is divided into three main sections.  Section 2 = lists
the RFCs that describe absolutely required TCP behaviors for proper
functioning and interoperability.  Further RFCs that describe
strongly encouraged, but non-essential, behaviors are listed in
Section 3.  Experimental extensions that are not yet standard
practices, but that potentially could be in the future, are = described
in Section 4.=93

IMO its clear, why for example Eifel response is in sec 4.4, since
it is an Experimental draft.

I disagree with this interpretation. Section 3 is entitled = "Recommended Enhancements". Given the Informational nature of this RFC, = it's probably incorrect to use the word "recommended", but I think the = phrase "strong encouraged" is appropriate. =

I don=92t = think that we are not on same page here :-) As I wrote, I also believe = that we should not = recommend
something.

IMO the only = thing we should changed is the title of Section 3 to =84Strong = Encouraged  = Enhancements=93.



The original intent was taht implementers really ought to use the RFCs in Section 3 = in a modern TCP implementation even if they're not strictly required. If = something is not well-understood as a common feature of modern = implementations it should be in Section 4, whether it's experimental, information, or proposed standard.

Which is still true in the current = Draft.

Alex

= --Apple-Mail=_372A161A-16DB-49A2-B467-2F968864B27E-- --Apple-Mail=_1B27A675-F87B-4EE6-9CF3-CA9C72AE671A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKnOPsACgkQdyiq39b9uS6jVACfVVChdzIlfl192ivBbn6vh658 1M0AnjJ4Y9TlFtIRQNHq9YsLVqy+DB27 =3U+M -----END PGP SIGNATURE----- --Apple-Mail=_1B27A675-F87B-4EE6-9CF3-CA9C72AE671A-- From dab@weston.borman.com Tue Dec 10 08:35:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA851AE15E for ; Tue, 10 Dec 2013 08:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXQhctBGkCjT for ; Tue, 10 Dec 2013 08:35:26 -0800 (PST) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 322001AE1CE for ; Tue, 10 Dec 2013 08:35:25 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id rBAGZIL7028261; Tue, 10 Dec 2013 10:35:19 -0600 (CST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: David Borman In-Reply-To: Date: Tue, 10 Dec 2013 10:35:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <45880C31-6DD2-4C7B-80F9-E44982FBB130@weston.borman.com> References: <28952_1384786256_528A2950_28952_4143_1_F109A0B9-250A-49F7-8C8A-60ED14FBDC6D@iki.fi> To: Pasi Sarolahti X-Mailer: Apple Mail (2.1822) Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:35:27 -0000 My thanks also to Richard for his diligence. It=92s been over a year = and a half and 17 revisions since he took over as the editor of 1323bis. = At the time he probably didn=92t fully realize what he was getting = into, but he has persevered through it all. It=92ll be great to see = this finally published as an RFC! -David Borman On Dec 8, 2013, at 7:36 AM, Pasi Sarolahti = wrote: > Hi, >=20 > The WGLC on draft-ietf-tcpm-1323bis concluded a few days ago. No new = comments were made during the WGLC, apart from the editorial nits that = are now addressed in the latest version, as pointed out by Richard in = his Email. We will now proceed with submitting the document to the IESG. >=20 > Below is a draft write-up for the document (pending some final = nit-checking). >=20 > Many thanks to the authors for the effort, particularly to Richard, = for helping to get the draft completed, as well as to the working group = participants for the review cycles and active discussion! >=20 > - Pasi >=20 > --------- From martin.h.duke@gmail.com Tue Dec 10 11:15:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9781AE18C for ; Tue, 10 Dec 2013 11:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf8JMRDZo_7x for ; Tue, 10 Dec 2013 11:15:49 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD91AC4A3 for ; Tue, 10 Dec 2013 11:15:48 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id c14so5303264vea.28 for ; Tue, 10 Dec 2013 11:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vn6G0extsxQleHUxFniPdCZoWRc1xJajgn3LugX1NFg=; b=cgoWSe69Qu/QLACGR/beprQXXKHasyGRjJfsYZj+P6j2nkZmXmbEpv6SlHIzWEfrd1 cqpOc2on9Obs6oxe6+a/fCzK9jSEUUpmxVs22cNBJ9NM5ZrdsU2b26+2S4t0NqDY3l5K LPcMQ8ojVHBc/qHL1G7VqN/M2gDGPHwwMR7DeJmh3TrKwPw+SC1ui9B1BJblKKvXYzn+ IKC5kB9+IIPCJgZ4/CYTMw1Yp8MWUiFhx2WxGnbSIqhtePnT0mHAbMgK7kP/KmFKciyb khljUR8FZlIqOtnHCNmOr0thw3r9EEnJ/9q9KsWzJmFJJZDIx8tn0MKtEFi5vcUToUsS AjrA== MIME-Version: 1.0 X-Received: by 10.58.188.42 with SMTP id fx10mr528017vec.51.1386702943492; Tue, 10 Dec 2013 11:15:43 -0800 (PST) Received: by 10.220.160.130 with HTTP; Tue, 10 Dec 2013 11:15:43 -0800 (PST) Received: by 10.220.160.130 with HTTP; Tue, 10 Dec 2013 11:15:43 -0800 (PST) In-Reply-To: References: <52A094B7.9050706@mti-systems.com> Date: Tue, 10 Dec 2013 11:15:43 -0800 Message-ID: From: Martin Duke To: Alexander Zimmermann Content-Type: multipart/alternative; boundary=089e013a27a65bd00704ed32f067 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:15:51 -0000 --089e013a27a65bd00704ed32f067 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I concur. On Dec 10, 2013 7:01 AM, "Zimmermann, Alexander" < Alexander.Zimmermann@netapp.com> wrote: > Hi Wes, > > Am 05.12.2013 um 15:59 schrieb Wesley Eddy : > > > On 12/5/2013 4:50 AM, Zimmermann, Alexander wrote: > >> > >>> > >>> For reference, the original 4614 had three RFCs at the beginning of > >>> Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168 > >>> (ECN). As far as I can recall, this was because (a) they didn't fit > >>> neatly into a grouping with other RFCs and we didn't want subsections > >>> with 1 RFC; and (b) 1323 and 3168 are really important and should be > >>> at the front. It's only 1323 and 3168 that we describe as > >>> "fundamental," as a way of introducing them instead of any sort of > >>> formal taxonomy. > >>> > >>> I agree that 3168 fits in well under congestion control; as for the > >>> two now in 3.1, I'd just as soon we rename the section as > >>> "Miscellaneous changes" or "general changes" or even "large packets > >>> and windows". I'm open to people's suggestions for naming. > >> > >> =84Fundamental changes=93 reflects more the importance of RFC 1323, > >> =84General changes=93 is maybe more suitable for RFC 2675. I=92m fine > >> with both of them. > >> > >> Wes? > >> > > > > > > I don't have a strong preference, but it seems to me that we > > failed to explain a commonality between 1323 and 2675, which > > is that both define how to re-interpret pieces of the basic > > TCP header and options. 1323 has Window Scaling which > > re-interprets the advertised receive window, and 2675 specifies > > that MSS or urgent pointer fields of 65,535 are to be treated > > specially. > > > > So, to me, that is why both can easily be grouped as "fundamental > > changes". I think we could add a sentence at the beginning of > > section 3.1 to explain this, as it would be more informative than > > the current 2 sentences there, which are largely just summarizing > > text later on in the descriptions of both documents, and not > > actually explaining the reason why they're fundamental changes. > > I agree. I add the following text: > > RFCs 1323 and 2675 represent fundamental changes to TCP > by redefining how parts of the basic TCP header and options are > interpreted. RFC 1323 defines the Window Scale Option, which > re-interprets the advertised receive window. RFC 2675 specifies > that MSS option and urgent pointer fields with a value of > 65,535 are to be treated specially. > > > > > -- > > Wes Eddy > > MTI Systems > > --089e013a27a65bd00704ed32f067 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I concur.

On Dec 10, 2013 7:01 AM, "Zimmermann, Alexa= nder" <Alexander= .Zimmermann@netapp.com> wrote:
Hi Wes,

Am 05.12.2013 um 15:59 schrieb Wesley Eddy <wes@mti-systems.com>:

> On 12/5/2013 4:50 AM, Zimmermann, Alexander wrote:
>>
>>>
>>> For reference, the original 4614 had three RFCs at the beginni= ng of
>>> Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), a= nd 3168
>>> (ECN). =A0As far as I can recall, this was because (a) they di= dn't fit
>>> neatly into a grouping with other RFCs and we didn't want = subsections
>>> with 1 RFC; and (b) 1323 and 3168 are really important and sho= uld be
>>> at the front. It's only 1323 and 3168 that we describe as<= br> >>> "fundamental," as a way of introducing them instead = of any sort of
>>> formal taxonomy.
>>>
>>> I agree that 3168 fits in well under congestion control; as fo= r the
>>> two now in 3.1, I'd just as soon we rename the section as<= br> >>> "Miscellaneous changes" or "general changes&quo= t; or even "large packets
>>> and windows". I'm open to people's suggestions fo= r naming.
>>
>> =84Fundamental changes=93 reflects more the importance of RFC 1323= ,
>> =84General changes=93 is maybe more suitable for RFC 2675. I=92m f= ine
>> with both of them.
>>
>> Wes?
>>
>
>
> I don't have a strong preference, but it seems to me that we
> failed to explain a commonality between 1323 and 2675, which
> is that both define how to re-interpret pieces of the basic
> TCP header and options. =A01323 has Window Scaling which
> re-interprets the advertised receive window, and 2675 specifies
> that MSS or urgent pointer fields of 65,535 are to be treated
> specially.
>
> So, to me, that is why both can easily be grouped as "fundamental=
> changes". =A0I think we could add a sentence at the beginning of<= br> > section 3.1 to explain this, as it would be more informative than
> the current 2 sentences there, which are largely just summarizing
> text later on in the descriptions of both documents, and not
> actually explaining the reason why they're fundamental changes.
I agree. I add the following text:

RFCs 1323 and 2675 represent fundamental changes to TCP
by redefining how parts of the basic TCP header and options are
interpreted. RFC 1323 defines the Window Scale Option, which
re-interprets the advertised receive window. RFC 2675 specifies
that MSS option and urgent pointer fields with a value of
65,535 are to be treated specially.

>
> --
> Wes Eddy
> MTI Systems

--089e013a27a65bd00704ed32f067-- From internet-drafts@ietf.org Wed Dec 11 07:35:43 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898D61ADFEF; Wed, 11 Dec 2013 07:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs5s7S0R5NwQ; Wed, 11 Dec 2013 07:35:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3499C1ADFCF; Wed, 11 Dec 2013 07:35:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211153541.15285.26498.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 07:35:41 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:35:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : A Roadmap for Transmission Control Protocol (TCP) Specif= ication Documents Author(s) : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-03.txt Pages : 52 Date : 2013-12-11 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-tcp-rfc4614bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michael.scharf@alcatel-lucent.com Mon Dec 16 04:20:43 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52F11AE2F5 for ; Mon, 16 Dec 2013 04:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBNJkiK8_Cvr for ; Mon, 16 Dec 2013 04:20:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A659B1ADF97 for ; Mon, 16 Dec 2013 04:20:40 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rBGCKZPO021381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Dec 2013 06:20:37 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBGCKXal003446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 13:20:34 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.70]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 16 Dec 2013 13:20:34 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCPM session request for IETF 89 Thread-Index: AQHO+lk3n9Vg9cEmgku8B9iTRU2cAQ== Date: Mon, 16 Dec 2013 12:20:33 +0000 Message-ID: <655C07320163294895BBADA28372AF5D14DFBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "tcpm-chairs@tools.ietf.org tcpm-chairs@tools.ietf.org" Subject: [tcpm] TCPM session request for IETF 89 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 12:20:43 -0000 SGkgYWxsLA0KDQpJIGp1c3QgcmVxdWVzdGVkIHRoZSBUQ1BNIHNlc3Npb24gZm9yIExvbmRvbiAo c2VlIGJlbG93KS4gSXQgaXMgYmFzaWNhbGx5IG91ciB1c3VhbCAyLjVoIHJlcXVlc3QsIHdpdGgg dGhyZWUgZGlmZmVyZW5jZXMgY29tcGFyZWQgdG8gdGhlIGxhc3QgcmVxdWVzdDoNCg0KKiBJIGFk ZGVkIHRoZSBBUU0gYXMgYSBzZWNvbmQgcHJpb3JpdHkgY29uZmxpY3QNCg0KKiBJIGFza2VkIGZv ciBNZWV0ZWNobyBzdXBwb3J0LCBiYXNlZCBvbiBteSBwZXJzb25hbCBleHBlcmllbmNlIHdpdGgg cmVtb3RlbHkgYXR0ZW5kaW5nIHRoZSBsYXN0IFRDUE0gbWVldGluZy4gVGhlIE1lZXRlY2hvIGF1 ZGlvIHN0cmVhbSBoYXMgYSB2ZXJ5IHNtYWxsIGxhZywgY29tcGFyZWQgdG8gdGhlIG5vcm1hbCBz dHJlYW0gdGhhdCBoYXJkbHkgYWxsb3dzIHRvIHBvc3QgSmFiYmVyIGNvbW1lbnRzIGluIHRpbWUu DQoNCiogVGhlIHRhcHMgQm9GIGlzIG1lbnRpb25lZCBhcyBhIGNvbmZsaWN0Lg0KDQpJIHRoaW5r IHRoZSBjaGFpcnMgaGF2ZW4ndCBjaGVja2VkIHRoZSBUQ1BNIGNvbmZsaWN0IGxpc3QgcmVjZW50 bHkgd2l0aCB0aGUgV0cuIEluIGNhc2UgdGhhdCB5b3UgaGF2ZSBhbnkgY29tbWVudHMgb3IgdGhv dWdodHMgb24gdGhlIHJlcXVlc3QsIHBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93Lg0KDQpUaGFu a3MNCg0KTWljaGFlbA0KIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV29ya2luZyBHcm91cCBOYW1lOiBUQ1AgTWFpbnRlbmFu Y2UgYW5kIE1pbm9yIEV4dGVuc2lvbnMNCkFyZWEgTmFtZTogVHJhbnNwb3J0IEFyZWENClNlc3Np b24gUmVxdWVzdGVyOiBNaWNoYWVsIFNjaGFyZg0KDQpOdW1iZXIgb2YgU2Vzc2lvbnM6IDENCkxl bmd0aCBvZiBTZXNzaW9uKHMpOiAgMi41IEhvdXJzDQpOdW1iZXIgb2YgQXR0ZW5kZWVzOiA3MA0K Q29uZmxpY3RzIHRvIEF2b2lkOiANCiBGaXJzdCBQcmlvcml0eTogY29uZXggbXB0Y3AgdHN2YXJl YSB0c3Z3ZyBpY2NyZyBybWNhdCBodHRwYmlzIGlwcG0NCiBTZWNvbmQgUHJpb3JpdHk6IGFsdG8g cnRjd2ViIGxtYXAgYXFtDQoNCg0KDQpTcGVjaWFsIFJlcXVlc3RzOg0KICBJdCB0aGUgJnF1b3Q7 dHJhbnNwb3J0IHNlcnZpY2VzICh0YXBzKSZxdW90OyBCT0YgaXMgYXBwcm92ZWQsIGl0IHdpbGwg YmUgYSBmaXJzdCBwcmlvcml0eSBjb25mbGljdC4NCg0KVENQTSBoYXMgbm90IHVzZWQgTWVldGVj aG8gYmVmb3JlLCBidXQgd2UmIzM5O2QgbGlrZSB0byB0cnkgaXQuDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From internet-drafts@ietf.org Mon Dec 16 13:21:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467371ADDA0; Mon, 16 Dec 2013 13:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxQtJx2whine; Mon, 16 Dec 2013 13:21:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9291AC404; Mon, 16 Dec 2013 13:21:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131216212147.12138.49892.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2013 13:21:47 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 21:21:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Author(s) : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-04.txt Pages : 21 Date : 2013-12-16 Abstract: This document proposes an update to RFC 5681 to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It updates TCP to allow a TCP sender to restart quickly following either an idle or rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. NOTE: The standards status of this WG document is under review for consideration as either Experimental (EXP) or Proposed Standard (PS). This decision will be made later as the document is finalised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Mon Dec 16 13:28:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64C1ADE84 for ; Mon, 16 Dec 2013 13:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaZO10NKoUjE for ; Mon, 16 Dec 2013 13:28:17 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD741AD8EC for ; Mon, 16 Dec 2013 13:28:17 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 01CC12B42D4 for ; Mon, 16 Dec 2013 21:28:16 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 16 Dec 2013 21:28:16 -0000 Message-ID: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> Date: Mon, 16 Dec 2013 21:28:16 -0000 From: gorry@erg.abdn.ac.uk To: tcpm@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 21:28:23 -0000 We've submitted a revised ID for new-cwv. There are 2 main updates: - The draft now firmly recommends the use of pacing. We will provide performance data on pacing for the next IETF. - The draft has a small amendment to the algorithm to ensure that the NVP does not inhibit cwnd growth when a sender fully consumes the cwnd. There was previously a corner case in the measurement of pipeACK when a flow started or resumed that could result making newCWV more conservative than standard TCP (e.g. for a bulk flow). We think the correction is within the original spirit of new CWV. We'd welcome feedback on these or any other aspects. Best wishes, the new CWV authors -------------------------------------------------------------------------- Hi, The IETF datatracker draft submission service has received your draft draft-ietf-tcpm-newcwv-04, and requires a confirmation step in order to be able to complete the posting of the draft. Please follow this link to the page where you can confirm the posting: Confirmation URL: http://datatracker.ietf.org/submit/status/56402/confirm/c575579feb585d58d82af80a319918630e8d0529/ Best regards, The IETF Secretariat through the draft submission service From ycheng@google.com Mon Dec 16 19:55:53 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDE41AE009 for ; Mon, 16 Dec 2013 19:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-Otw24z8DR8 for ; Mon, 16 Dec 2013 19:55:51 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id D4BDF1AE088 for ; Mon, 16 Dec 2013 19:55:51 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id ut6so5392364igb.5 for ; Mon, 16 Dec 2013 19:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yZD+pGeqJlh8cCbzAuepIBhLycz5BnuR8zf+S+p0T5k=; b=YUVCDVOgH+WpZoredaWW1c7SuoxM6BySIW/pjJFVj5YHOjLcZ0rdCoglPucq6JeLsu iODEvTbzBtrReX1waJZOkIWmzpOIxxAEFV5FLoHYYPvAliUfiwSGSNDgYIcIPMpM7UZB oNYFXKfc7rPAFKxWy+/qnRc8MIogaw35vtFMh6j20tokmAGF8jluuIBE4puIr9iL0d/P pSTumg7YSZYvE3Qncwh01HIKAo+gIoXYGCuDhC7R3jOseCPza5QNqZhGsag7wa0Ndcs9 Z3DdjN4DdtmSIga1HPlCelrZDnuQ80mqP3p7MkxKjsiBbRuAgRaD/9BKv9z/o+vkmT+z h4tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yZD+pGeqJlh8cCbzAuepIBhLycz5BnuR8zf+S+p0T5k=; b=H+7rI8Tv4UU6+vkeris/1jZHoLm4ppZL5SiTJgx7uWZlx/6gcGjh/7pGdiU83HTclv WjY6EfGlhdRGAVT/Wi9gkJPctlEkXuKhNDnMxmzGe8BtbxAN9TvXmOauaAbbX0RRP6zi 6LBq8hwx6NFi/EZL3BLOqe41e16KdWn4w0lZDd8O/VEEhqR7TgDqa/wSGCLtnD08jKC3 XnJuuryJNooTZz9JpOyLSvMInO4bumhOCvdn0rJidjoHc5QjN3v5YaYY2niepBo6OIQX hGJ+mvTeS4lNIycvABeQbEM3L736VvpFn+AW5u1vis4RO4Ofs5C0p9Tcxm+I666ffjjp oEWw== X-Gm-Message-State: ALoCoQlkKKFcfToWjB4MxjJdlsdX6KbWapE/e7+aQu021FikjlvlfxYvgC5i5/mp4Ooie51sXhU9bIF+CLpvZsJSZQB1JqmJMvevA5+z5m9CdFOlIMSKzGjdsTYBYApzpKPIx+0IykOG33fyfVfcyxfxch7zl4vN+WCt7aPMkkhORka5ifqflMZsWhPEe/81uZyYZ3z87lja X-Received: by 10.50.78.200 with SMTP id d8mr1198040igx.38.1387252550614; Mon, 16 Dec 2013 19:55:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.170.3 with HTTP; Mon, 16 Dec 2013 19:55:10 -0800 (PST) In-Reply-To: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> References: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> From: Yuchung Cheng Date: Mon, 16 Dec 2013 19:55:10 -0800 Message-ID: To: Gorry Fairhurst Content-Type: text/plain; charset=UTF-8 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 03:55:53 -0000 On Mon, Dec 16, 2013 at 1:28 PM, wrote: > > We've submitted a revised ID for new-cwv. > > There are 2 main updates: > > - The draft now firmly recommends the use of pacing. We will provide > performance data on pacing for the next IETF. > > - The draft has a small amendment to the algorithm to ensure that the NVP > does not inhibit cwnd growth when a sender fully consumes the cwnd. There > was previously a corner case in the measurement of pipeACK when a flow > started or resumed that could result making newCWV more conservative than > standard TCP (e.g. for a bulk flow). We think the correction is within the > original spirit of new CWV. > > We'd welcome feedback on these or any other aspects. I appreciate the new section on burst mitigation but why standard track? The change has pro-found impact on congestion control as it changes how cwnd increases per ACK and after idle. There are a lot to experiment before we know this works well in real networks. > > Best wishes, > > the new CWV authors > > -------------------------------------------------------------------------- > > > Hi, > > The IETF datatracker draft submission service has received your draft > draft-ietf-tcpm-newcwv-04, and requires a > confirmation step in order to be able to complete the posting of > the draft. > > Please follow this link to the page where you can confirm the posting: > Confirmation URL: > http://datatracker.ietf.org/submit/status/56402/confirm/c575579feb585d58d82af80a319918630e8d0529/ > > > Best regards, > > The IETF Secretariat > through the draft submission service > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gorry@erg.abdn.ac.uk Tue Dec 17 00:28:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6931AE125 for ; Tue, 17 Dec 2013 00:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNS880_ovbaM for ; Tue, 17 Dec 2013 00:28:37 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 746701AE134 for ; Tue, 17 Dec 2013 00:28:34 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9DAC82B432B; Tue, 17 Dec 2013 08:28:32 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 17 Dec 2013 08:28:32 -0000 Message-ID: In-Reply-To: References: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> Date: Tue, 17 Dec 2013 08:28:32 -0000 From: gorry@erg.abdn.ac.uk To: "Yuchung Cheng" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 08:28:39 -0000 > On Mon, Dec 16, 2013 at 1:28 PM, wrote: >> >> We've submitted a revised ID for new-cwv. >> >> There are 2 main updates: >> >> - The draft now firmly recommends the use of pacing. We will provide >> performance data on pacing for the next IETF. >> >> - The draft has a small amendment to the algorithm to ensure that the >> NVP >> does not inhibit cwnd growth when a sender fully consumes the cwnd. >> There >> was previously a corner case in the measurement of pipeACK when a flow >> started or resumed that could result making newCWV more conservative >> than >> standard TCP (e.g. for a bulk flow). We think the correction is within >> the >> original spirit of new CWV. >> >> We'd welcome feedback on these or any other aspects. > > I appreciate the new section on burst mitigation but why standard track? > The previous discussions on STD track centres on whether we would include require a burst mitigation section, so this is now a good question. > The change has pro-found impact on congestion control as it changes > how cwnd increases per ACK and after idle. There are a lot to > experiment before we know this works well in real networks. > Are you referring to the new ack-mitigation section - requiring pacing after idle? Gorry >> >> Best wishes, >> >> the new CWV authors >> >> -------------------------------------------------------------------------- >> >> >> Hi, >> >> The IETF datatracker draft submission service has received your draft >> draft-ietf-tcpm-newcwv-04, and requires a >> confirmation step in order to be able to complete the posting of >> the draft. >> >> Please follow this link to the page where you can confirm the posting: >> Confirmation URL: >> http://datatracker.ietf.org/submit/status/56402/confirm/c575579feb585d58d82af80a319918630e8d0529/ >> >> >> Best regards, >> >> The IETF Secretariat >> through the draft submission service >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From ycheng@google.com Tue Dec 17 07:59:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1A1AE14F for ; Tue, 17 Dec 2013 07:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88q_4Xrw-3x1 for ; Tue, 17 Dec 2013 07:59:23 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7263B1AE177 for ; Tue, 17 Dec 2013 07:59:23 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so8569861ieb.4 for ; Tue, 17 Dec 2013 07:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KgTOCyXXmJ72/UfidUCyOJxzjeWVngO42sUDKWiiszI=; b=PX81gn+QQScJ8jAIZpp1pSE3iEYk7ZmHJioYvWFjMgB2xDz+9oEkrNDTlYWvASHOiI Ghbyx7IcI16UatCxJXYnLS4WncMa3ADo6SZjuk75HQzwtVP9kt6MrT4l/IU+wwFI8SK/ p4ZNx3cHXVrk9xWa8jQ8gUZ4bxtY/k3iKHo/5EU1zgGoGQJQiVveegcZndurOeYGjTL5 AJJY9TDS57pxiErzCfQUXrpIJvNU4IwiYmOKIUKhTCNsOFiBg7gImOQ+QF7vrNfeFYsd U1dDvsxLpM7jg5AD4d7Pt6mGrXBVGplFOzJpJSh9Whkr2JJkOSvQH9GmOZ2ttnQhlMYg 462A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KgTOCyXXmJ72/UfidUCyOJxzjeWVngO42sUDKWiiszI=; b=PUEowXLy/htT0AqMfyKPHPVt9WwExSc0te0K97VQoTIvudjMxXu1U2nKZ+YhXgfZQj VjNGr6RuUlbXIDkHQHRBDKJ2lGgTJfLsuLNfBEIduylygYiswk+tXZ9y7/WxjjliGbNa B8lEnrh0tnu8YsKQMuivjvn/BVALLTPsnAi0CZnFBUUM5sFxON1OFsRJQ0T0Ef/CL81l zVyjMOGBVq7+8gHztHeZTD3hVeN5/vIuE9q+iuTMe+h+IS0b/OMbWRV6Xc5Y0g7LxntT bzpVvye7u58hgDMWLSMfIz7H/Kdkui0tg1Lt0xSVygYZ/W7ie7h0XznXTi3Ewg8d0zcA WW+g== X-Gm-Message-State: ALoCoQlgbQN2FMSZL3ZUma+gTRN0ByeA7cOUETL7eSE8O+Uh+epllJ17KhjA6Dd7uJ0v237N1weXi23GGdTajWJX/mPWHyVJ94c82J1VYmEB0GeAY7hLl6bfXLvn71nrmiZ0FuKKnjc5hvWdZ59eUc9ZkcCTlxvWTYivLfQ/5h4YBUaVTtYb+cv4APObVjQ+5CObGuodeybK X-Received: by 10.50.138.40 with SMTP id qn8mr3793042igb.38.1387295962076; Tue, 17 Dec 2013 07:59:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.170.3 with HTTP; Tue, 17 Dec 2013 07:58:41 -0800 (PST) In-Reply-To: References: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> From: Yuchung Cheng Date: Tue, 17 Dec 2013 07:58:41 -0800 Message-ID: To: Gorry Fairhurst Content-Type: text/plain; charset=UTF-8 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 15:59:25 -0000 On Tue, Dec 17, 2013 at 12:28 AM, wrote: >> On Mon, Dec 16, 2013 at 1:28 PM, wrote: >>> >>> We've submitted a revised ID for new-cwv. >>> >>> There are 2 main updates: >>> >>> - The draft now firmly recommends the use of pacing. We will provide >>> performance data on pacing for the next IETF. >>> >>> - The draft has a small amendment to the algorithm to ensure that the >>> NVP >>> does not inhibit cwnd growth when a sender fully consumes the cwnd. >>> There >>> was previously a corner case in the measurement of pipeACK when a flow >>> started or resumed that could result making newCWV more conservative >>> than >>> standard TCP (e.g. for a bulk flow). We think the correction is within >>> the >>> original spirit of new CWV. >>> >>> We'd welcome feedback on these or any other aspects. >> >> I appreciate the new section on burst mitigation but why standard track? >> > The previous discussions on STD track centres on whether we would include > require a burst mitigation section, so this is now a good question. > >> The change has pro-found impact on congestion control as it changes >> how cwnd increases per ACK and after idle. There are a lot to >> experiment before we know this works well in real networks. >> > Are you referring to the new ack-mitigation section - requiring pacing > after idle? I am referring to the main changes proposed in the draft, not just pacing after idle. > > Gorry > >>> >>> Best wishes, >>> >>> the new CWV authors >>> >>> -------------------------------------------------------------------------- >>> >>> >>> Hi, >>> >>> The IETF datatracker draft submission service has received your draft >>> draft-ietf-tcpm-newcwv-04, and requires a >>> confirmation step in order to be able to complete the posting of >>> the draft. >>> >>> Please follow this link to the page where you can confirm the posting: >>> Confirmation URL: >>> http://datatracker.ietf.org/submit/status/56402/confirm/c575579feb585d58d82af80a319918630e8d0529/ >>> >>> >>> Best regards, >>> >>> The IETF Secretariat >>> through the draft submission service >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> > > From gorry@erg.abdn.ac.uk Tue Dec 17 08:10:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8DA1AE156 for ; Tue, 17 Dec 2013 08:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTIieSuag5oG for ; Tue, 17 Dec 2013 08:10:36 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 009421AE056 for ; Tue, 17 Dec 2013 08:10:35 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 44DC62B4520; Tue, 17 Dec 2013 16:10:34 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E64482B432B; Tue, 17 Dec 2013 16:10:32 +0000 (GMT) Message-ID: <52B07778.7090504@erg.abdn.ac.uk> Date: Tue, 17 Dec 2013 16:10:32 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Yuchung Cheng References: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 16:10:40 -0000 On 17/12/2013 15:58, Yuchung Cheng wrote: > On Tue, Dec 17, 2013 at 12:28 AM, wrote: >>> On Mon, Dec 16, 2013 at 1:28 PM, wrote: >>>> >>>> We've submitted a revised ID for new-cwv. >>>> >>>> There are 2 main updates: >>>> >>>> - The draft now firmly recommends the use of pacing. We will provide >>>> performance data on pacing for the next IETF. >>>> >>>> - The draft has a small amendment to the algorithm to ensure that the >>>> NVP >>>> does not inhibit cwnd growth when a sender fully consumes the cwnd. >>>> There >>>> was previously a corner case in the measurement of pipeACK when a flow >>>> started or resumed that could result making newCWV more conservative >>>> than >>>> standard TCP (e.g. for a bulk flow). We think the correction is within >>>> the >>>> original spirit of new CWV. >>>> >>>> We'd welcome feedback on these or any other aspects. >>> >>> I appreciate the new section on burst mitigation but why standard track? >>> >> The previous discussions on STD track centres on whether we would include >> require a burst mitigation section, so this is now a good question. >> >>> The change has pro-found impact on congestion control as it changes >>> how cwnd increases per ACK and after idle. There are a lot to >>> experiment before we know this works well in real networks. >>> >> Are you referring to the new ack-mitigation section - requiring pacing >> after idle? > I am referring to the main changes proposed in the draft, not just > pacing after idle. > OK, so this algorithm hasn't changed much for a couple of IETFs. Do you have concerns about relaxing the Standard behaviour (collapsing to IW after one RTO), and that letting apps maintain a higher cwnd has dangers? Or do you think the algorithm may keep to high a cwnd when non-validated? Or is it something else? - I'm happy to document/discuss (potential) concerns. >> >> Gorry >> >>>> >>>> Best wishes, >>>> >>>> the new CWV authors >>>> >>>> -------------------------------------------------------------------------- >>>> >>>> >>>> Hi, >>>> >>>> The IETF datatracker draft submission service has received your draft >>>> draft-ietf-tcpm-newcwv-04, and requires a >>>> confirmation step in order to be able to complete the posting of >>>> the draft. >>>> >>>> Please follow this link to the page where you can confirm the posting: >>>> Confirmation URL: >>>> http://datatracker.ietf.org/submit/status/56402/confirm/c575579feb585d58d82af80a319918630e8d0529/ >>>> >>>> >>>> Best regards, >>>> >>>> The IETF Secretariat >>>> through the draft submission service >>>> >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> >> > From ycheng@google.com Tue Dec 17 08:40:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAA01AE00E for ; Tue, 17 Dec 2013 08:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCl8lAI6hdmG for ; Tue, 17 Dec 2013 08:40:33 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 571A61ADF73 for ; Tue, 17 Dec 2013 08:40:33 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so8662342ief.20 for ; Tue, 17 Dec 2013 08:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jfY5eP+DSX3yvdbyaUD7GSF0toJ+76kT436m5YHtPeE=; b=X1EWdCw2fC0CZN6YOuRV3k0wEzi2kuY1H7COVXDVzovwbLkyVeShnRid/FjE7IlFrl JZXDrGDFwVIRExjh060c4y2NnyYRYYweHx2vfgAatXeffXO0i4cJg0V+Zu7aADJng2NN I70OHeQ+PHh7LDA98cBhlTR94mE2xydBmFOxkFK3p2+tAfuqN0VaB61grcqsUyv5hLmb OvAMwCXujpKRh3KaGAOReD0pFoPAc1DZmUGN+sdnWV7rNkgI31O6DrlIXCgETrNV1rMU WAaBYsr5NL0MfzsjpOnUss2HcOL15C1prdZgd2Wgae67lhmazXSlfpMk3Ot7/0Z5LOND PPIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jfY5eP+DSX3yvdbyaUD7GSF0toJ+76kT436m5YHtPeE=; b=ZK75IAHqpbuLRIYzkLsKM5a9yq06ipdJ0VUOHfn+w5VdkLtJWz/RlT20rXTzUQwhsS bdL74wsYTOhpef70LOTmvxqwN9BQ/fTi9wOL9rk3FlCkVFTLNldwezg/vz45oRWiuRFG U/mpkkjz70L6icRtXDLp635WiOuJmtO77pD6dZls3QYmAdl9hiU86dfpFrYixuypBXcC j0aWVcBk993ZBu2l2tgU/Vdo6xAT6LzwIflqBrQy5fCwOQsDi7XfDUsPO5nE9nNeaUoS vgQm4E2ZqsPy2kVRg0ImUMJKG54l4UWeovZBwtGEskAB9XDsGEN/c1PiXA1AxStx5yxt /J2Q== X-Gm-Message-State: ALoCoQlh0jp8d+LzWFa4BC3l82BK+2xUNJydp+rvkQRln3TntDQqAAMe/s9LL2gVMQMGyojvitkN8TUlHuI+DnzW+c28+X+LrKIlIhttpG7JA3EZUkHffpOeNwwYAa6NSiKTd6iFdnm/+uGBjIwAp0bniBSpNESiwfUVlfgRP3sRHzEbX6PuGwn6FZEf/5gJR98rltEYBa3W X-Received: by 10.50.143.10 with SMTP id sa10mr4041663igb.8.1387298431955; Tue, 17 Dec 2013 08:40:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.170.3 with HTTP; Tue, 17 Dec 2013 08:39:51 -0800 (PST) In-Reply-To: <52B07778.7090504@erg.abdn.ac.uk> References: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> <52B07778.7090504@erg.abdn.ac.uk> From: Yuchung Cheng Date: Tue, 17 Dec 2013 08:39:51 -0800 Message-ID: To: Gorry Fairhurst Content-Type: text/plain; charset=UTF-8 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 16:40:35 -0000 On Tue, Dec 17, 2013 at 8:10 AM, Gorry Fairhurst wrote: > On 17/12/2013 15:58, Yuchung Cheng wrote: >> >> On Tue, Dec 17, 2013 at 12:28 AM, wrote: >>>> >>>> On Mon, Dec 16, 2013 at 1:28 PM, wrote: >>>>> >>>>> >>>>> We've submitted a revised ID for new-cwv. >>>>> >>>>> There are 2 main updates: >>>>> >>>>> - The draft now firmly recommends the use of pacing. We will provide >>>>> performance data on pacing for the next IETF. >>>>> >>>>> - The draft has a small amendment to the algorithm to ensure that the >>>>> NVP >>>>> does not inhibit cwnd growth when a sender fully consumes the cwnd. >>>>> There >>>>> was previously a corner case in the measurement of pipeACK when a flow >>>>> started or resumed that could result making newCWV more conservative >>>>> than >>>>> standard TCP (e.g. for a bulk flow). We think the correction is within >>>>> the >>>>> original spirit of new CWV. >>>>> >>>>> We'd welcome feedback on these or any other aspects. >>>> >>>> >>>> I appreciate the new section on burst mitigation but why standard track? >>>> >>> The previous discussions on STD track centres on whether we would include >>> require a burst mitigation section, so this is now a good question. >>> >>>> The change has pro-found impact on congestion control as it changes >>>> how cwnd increases per ACK and after idle. There are a lot to >>>> experiment before we know this works well in real networks. >>>> >>> Are you referring to the new ack-mitigation section - requiring pacing >>> after idle? >> >> I am referring to the main changes proposed in the draft, not just >> pacing after idle. >> > OK, so this algorithm hasn't changed much for a couple of IETFs. > > Do you have concerns about relaxing the Standard behaviour (collapsing to IW > after one RTO), and that letting apps maintain a higher cwnd has dangers? > > Or do you think the algorithm may keep to high a cwnd when non-validated? > > Or is it something else? something else. I thought standard means people have used it, found it working, and like how it works. May I am wrong. > > - I'm happy to document/discuss (potential) concerns. > > >>> >>> Gorry >>> >>>>> >>>>> Best wishes, >>>>> >>>>> the new CWV authors >>>>> >>>>> >>>>> -------------------------------------------------------------------------- >>>>> >>>>> >>>>> Hi, >>>>> >>>>> The IETF datatracker draft submission service has received your draft >>>>> draft-ietf-tcpm-newcwv-04, and requires a >>>>> confirmation step in order to be able to complete the posting of >>>>> the draft. >>>>> >>>>> Please follow this link to the page where you can confirm the posting: >>>>> Confirmation URL: >>>>> >>>>> http://datatracker.ietf.org/submit/status/56402/confirm/c575579feb585d58d82af80a319918630e8d0529/ >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> The IETF Secretariat >>>>> through the draft submission service >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> >>> >>> >> > From prvs=00649d8c91=per.hurtig@kau.se Wed Dec 18 02:29:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2D01AE1FF for ; Wed, 18 Dec 2013 02:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KmsO3cf9520 for ; Wed, 18 Dec 2013 02:29:57 -0800 (PST) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) by ietfa.amsl.com (Postfix) with ESMTP id DFA221AE0A2 for ; Wed, 18 Dec 2013 02:29:56 -0800 (PST) X-Spam-Processed: mail.kau.se, Wed, 18 Dec 2013 11:29:39 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: perhurt@kau.se X-MDRemoteIP: 130.243.26.38 X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se From: Per Hurtig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Dec 2013 11:29:45 +0100 Message-Id: To: tcpm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Cc: Michael Welzl Subject: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 10:29:59 -0000 Hi all, Following the discussions in Vancouver, there are two outstanding issues = related to the RTO restart draft that we would like feedback on: (i) Should we have a section in the draft describing a socket option? This was suggested during the tcpm meeting, but we also got comments in = the hallway that maybe this was not needed. Controlling RTO restart on a per = socket basis may be useful, but it is partly an implementation decision. Our = current Linux patch has both a sysctl and a socket option to aid in = experimentation. Looking at other RFCs the SCTP RFCs are quite careful to define socket = options whereas the TCP RFCs often leave it out. We don't have any strong = opinions regarding this. We are more than happy to add an API section if the = working group wants one, but we are not sure that it is necessary. (ii) Should we apply RTO restart for all segments or only when the = amount of outstanding data is too small to support fast retransmit? This discussion has been going for a long time, both on and off the = list. Our first version of the draft did the modified restart for all segments. = However, in discussions with various people it soon became apparent that from a performance perspective it would be rather bad to do it this way, as it increases the risk of having RTOs (with deep cuts in the cwnd and so = on). As long as you technically can recover a loss using fast retransmit you = should do that. Thus, in scenarios where it is possible to use fast retransmit, it = would only be contra productive to lower the value of the retransmission = timer. On the other hand, when it's impossible to use fast retransmit then it's a good = thing :) This is the rationale behind the current draft. The suggestion by some for applying RTO restart to all segments is based = on the rationale that this would simplify the algorithm, and would avoid = further complicating an already complex RTO management. The authors' suggestion is to leave the algorithm as it currently is, as = we believe this to be the right approach. The additional condition is by = itself not very complex. We believe any general issues with and needed reworking of = the RTO management belongs as a separate work item. Cheers, Per= From touch@isi.edu Wed Dec 18 08:42:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E331AE41A for ; Wed, 18 Dec 2013 08:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVik5A-mXNDv for ; Wed, 18 Dec 2013 08:42:51 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C80AD1AD6BF for ; Wed, 18 Dec 2013 08:42:51 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rBIGgKVS004350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Dec 2013 08:42:24 -0800 (PST) Message-ID: <52B1D06F.1050708@isi.edu> Date: Wed, 18 Dec 2013 08:42:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Per Hurtig , tcpm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Michael Welzl Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 16:42:53 -0000 On 12/18/2013 2:29 AM, Per Hurtig wrote: > (i) Should we have a section in the draft describing a socket option? > > This was suggested during the tcpm meeting, but we also got comments in the > hallway that maybe this was not needed. Controlling RTO restart on a per socket > basis may be useful, but it is partly an implementation decision. Our current > Linux patch has both a sysctl and a socket option to aid in experimentation. > Looking at other RFCs the SCTP RFCs are quite careful to define socket options > whereas the TCP RFCs often leave it out. We don't have any strong opinions > regarding this. We are more than happy to add an API section if the working > group wants one, but we are not sure that it is necessary. IMO, you should definitely indicate whether this variant should be default, whether it should apply to all connections, and whether it should be configurable to apply to specific connections. That is, IMO, required as part of the API of this protocol - and yes, as with RFC 793, I think such APIs are mandatory for all protocols (despite IETF confusion on this point, esp. in the past). However, describing it as a "socket option" or specifying the Unix-style interface should be at best in an appendix as one example, but I would prefer to not include that level of detail at all. I definitely feel strongly that RFC2119 keywords should never be used to describe such APIs in the context of a specific OS. Joe From ycheng@google.com Wed Dec 18 10:59:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36081AE187 for ; Wed, 18 Dec 2013 10:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRVfp0zk5r2G for ; Wed, 18 Dec 2013 10:59:06 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EE9921AE194 for ; Wed, 18 Dec 2013 10:59:05 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so80711ief.34 for ; Wed, 18 Dec 2013 10:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8eW65aqGg6UMBycyssNqij8m3OS/MNmIsUi4ebyjbV0=; b=fQHdkRx/RpIKq9JBxrRG/dZMVRrhYOu3r6YCOXZIv+g9EHjHq1x/708HnJGgL/j8sP WjfXzDJOKpJUzzPr37UDe8o9aBzSeGUBQYHjjqVNyAjqULkabMmM3kEMv/RHzxXtiAHs 7xJDmUL+4NCsmm6rndh5kuD/0MoBBwKQYl1zqQ6+TN4HxK4TGpf9q9qWa0C2omcWShv0 OWobZ3DkEua7XuOpfpMNT4+vzc4ZP2DJhyZGR9weI5VhsFVRvkJXNSeS2CZhIp0qHWw4 2TUlUEV/KoVP+hk67FO7tXnX8eIsyCAla0RCBK2GRXj6LrHhgbyEhpYa9bZ7bdmLqaiC oMFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8eW65aqGg6UMBycyssNqij8m3OS/MNmIsUi4ebyjbV0=; b=VSe9lBn7oTrDTmE/32coUU9A50K0rS7Dmobxuns6lrJ+6IAYuSPFfNeDNGpNbmuGDJ oXnvQGiKSLZJxZsXUJrsnUMItIf5OzA5n3l32SpBHu07DsEznrB+L44i6YC1zzaesGNr g6uYLjWVXNftxglIIajGv/Vqg57Zz8dv0fKipoKA6c+7lDdJk9DpFGywuxFq6SxP/2fV EpDic4GdrOstqqme079AtlXpqbFxbKrmpdll6Puytjirjf6tIvk1vi+r0HCUzGaTvzxo 79uHivQ9FGheFR20n+sOlRLOVhN4fnsa4Q+7pqGBE1Dp627nz5tR7Kc+Y3jv5Z/JlOjR Yfow== X-Gm-Message-State: ALoCoQk8WdPFIHCPnknVNBW54oRYjZvZU6xGQ3Mt3qqGn0BdxhcaThc89L7oFQOp7CiVq44QlFThdY/SNPTKrX9y8J4Emff2+/5Y7rMMxP2X/G6UoMQc0ORT9q66AAel1j7JovqjdaglogyIQI24bEKfJGocG3Vxg9qzIr81qvl3M9gYY0bkzuRCwnmMisw3NVUbR17nZMmW X-Received: by 10.50.78.199 with SMTP id d7mr9487790igx.8.1387393144373; Wed, 18 Dec 2013 10:59:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.170.3 with HTTP; Wed, 18 Dec 2013 10:58:24 -0800 (PST) In-Reply-To: References: From: Yuchung Cheng Date: Wed, 18 Dec 2013 10:58:24 -0800 Message-ID: To: Per Hurtig Content-Type: text/plain; charset=UTF-8 Cc: "tcpm@ietf.org Extensions" , Michael Welzl Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 18:59:09 -0000 On Wed, Dec 18, 2013 at 2:29 AM, Per Hurtig wrote: > Hi all, > > Following the discussions in Vancouver, there are two outstanding issues related > to the RTO restart draft that we would like feedback on: > > (i) Should we have a section in the draft describing a socket option? > > This was suggested during the tcpm meeting, but we also got comments in the > hallway that maybe this was not needed. Controlling RTO restart on a per socket > basis may be useful, but it is partly an implementation decision. Our current What're the useful cases in your mind? > Linux patch has both a sysctl and a socket option to aid in experimentation. > Looking at other RFCs the SCTP RFCs are quite careful to define socket options > whereas the TCP RFCs often leave it out. We don't have any strong opinions > regarding this. We are more than happy to add an API section if the working > group wants one, but we are not sure that it is necessary. > > > (ii) Should we apply RTO restart for all segments or only when the amount of > outstanding data is too small to support fast retransmit? > > This discussion has been going for a long time, both on and off the list. Our > first version of the draft did the modified restart for all segments. However, > in discussions with various people it soon became apparent that from a > performance perspective it would be rather bad to do it this way, as it > increases the risk of having RTOs (with deep cuts in the cwnd and so on). As > long as you technically can recover a loss using fast retransmit you should do > that. Thus, in scenarios where it is possible to use fast retransmit, it would > only be contra productive to lower the value of the retransmission timer. On the > other hand, when it's impossible to use fast retransmit then it's a good thing :) > This is the rationale behind the current draft. > The suggestion by some for applying RTO restart to all segments is based on the > rationale that this would simplify the algorithm, and would avoid further > complicating an already complex RTO management. > > The authors' suggestion is to leave the algorithm as it currently is, as we > believe this to be the right approach. The additional condition is by itself not > very complex. We believe any general issues with and needed reworking of the RTO Fine if you want to be conservative (and complicate things). Part of these compilation comes from resetting cwnd on timeout. It's like a time-ticking bomb for TCP performance. Consider the case where the entire cwnd is delivered except the last one. There is no point to re-slow-start to restore the ack clock, because you already have cwnd-1 acks last round. I plan to implement rto-restart idea in Linux as base of a new loss recovery, but probably not the cwnd checking part. When an RTO fires it's time to retransmit. The need to check cwnd implies my timer is problematic. > management belongs as a separate work item. > > > Cheers, > Per > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Thu Dec 19 01:24:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623A01AE0F3 for ; Thu, 19 Dec 2013 01:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.44 X-Spam-Level: X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LrizlgwfZi3 for ; Thu, 19 Dec 2013 01:24:19 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 63CBA1AE129 for ; Thu, 19 Dec 2013 01:24:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,512,1384329600"; d="scan'208";a="130648078" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 19 Dec 2013 01:24:17 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.147]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 01:24:17 -0800 From: "Scheffenegger, Richard" To: Yuchung Cheng , Per Hurtig Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 Thread-Index: AQHO+9xAhlrV8y0Ac0WO9u6v6uElH5pa1KQAgABp/LA= Date: Thu, 19 Dec 2013 09:24:16 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , Michael Welzl Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 09:24:22 -0000 Hi Per, >> (i) Should we have a section in the draft describing a socket option? > > What're the useful cases in your mind? I don't think that a granularity on a per-session level would really do any= good; having a global sysctl (or similar) to influence the overall behavio= r of the stack is fine. But from a troubleshooting point of view, I doubt t= hat such a fine level of control will do any good. >> (ii) Should we apply RTO restart for all segments or only when the >> amount of outstanding data is too small to support fast retransmit? > > Part of these compilation comes from resetting cwnd on timeout. It's like > a time-ticking bomb for TCP performance. Consider the case where the > entire cwnd is delivered except the last one. There is no point to re- > slow-start to restore the ack clock, because you already have > cwnd-1 acks last round. >=20 > I plan to implement rto-restart idea in Linux as base of a new loss > recovery, but probably not the cwnd checking part. When an RTO fires it's > time to retransmit. The need to check cwnd implies my timer is > problematic. Provided that you have other means (ie TS) to detect if the ACK was due to = an spurious retransmit (RTO) or genuinely needed, I'm not sure if that comp= lexity of checking the currently outstanding segments really is needed. As Yuchung points out, removing this would reduce the complexity of the alg= orithm. If spurious retransmits are a problem, and they often are, the stac= k requires some other way of dealing with those anyway, because "fixing" on= ly rto-restart won't address all the other (currently happening) instances = of spurious rtos... Seasons greetings, Richard Scheffenegger From michawe@ifi.uio.no Thu Dec 19 01:35:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB31AE2A0 for ; Thu, 19 Dec 2013 01:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9q8JZK2ogPT for ; Thu, 19 Dec 2013 01:35:02 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8E81AE265 for ; Thu, 19 Dec 2013 01:35:02 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Vta0Q-0004q3-7s; Thu, 19 Dec 2013 10:34:58 +0100 Received: from 089144207237.atnat0016.highway.bob.at ([89.144.207.237] helo=[192.168.1.2]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Vta0P-0004H4-GZ; Thu, 19 Dec 2013 10:34:58 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 19 Dec 2013 10:34:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4329FC84-000C-48AF-B1A2-06E40785F34C@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 13 sum msgs/h 7 total rcpts 11090 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8103BF7C97C333D340F1095607CBEA67C05ADC2A X-UiO-SPAM-Test: remote_host: 89.144.207.237 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 20 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 09:35:05 -0000 On 19. des. 2013, at 10:24, "Scheffenegger, Richard" = wrote: >=20 > Hi Per, >=20 >>> (i) Should we have a section in the draft describing a socket = option? >>=20 >> What're the useful cases in your mind? >=20 > I don't think that a granularity on a per-session level would really = do any good; having a global sysctl (or similar) to influence the = overall behavior of the stack is fine. But from a troubleshooting point = of view, I doubt that such a fine level of control will do any good. +1 Cheers, Michael From prvs=00657a3d1d=anna.brunstrom@kau.se Thu Dec 19 02:27:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1A1AE2AC for ; Thu, 19 Dec 2013 02:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWmaVYzimlif for ; Thu, 19 Dec 2013 02:27:22 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) by ietfa.amsl.com (Postfix) with ESMTP id 872DC1AE2A0 for ; Thu, 19 Dec 2013 02:27:22 -0800 (PST) X-Spam-Processed: mail.kau.se, Thu, 19 Dec 2013 11:27:04 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.155.87 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: tcpm@ietf.org Message-ID: <52B2CA03.8070208@kau.se> Date: Thu, 19 Dec 2013 11:27:15 +0100 From: =?ISO-8859-1?Q?Anna_Brunstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: tcpm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 10:27:25 -0000 Hi, On 2013-12-18 19:58, Yuchung Cheng wrote: > On Wed, Dec 18, 2013 at 2:29 AM, Per Hurtig wrote: >> Hi all, >> >> Following the discussions in Vancouver, there are two outstanding issues related >> to the RTO restart draft that we would like feedback on: >> >> (i) Should we have a section in the draft describing a socket option? >> >> This was suggested during the tcpm meeting, but we also got comments in the >> hallway that maybe this was not needed. Controlling RTO restart on a per socket >> basis may be useful, but it is partly an implementation decision. Our current > What're the useful cases in your mind? The one case we had in mind was if an application with a bursty send pattern worried about spuriou RTOs would benefit from the possibility to turn it off. But based on the feedback on the list so far and some further internal discussions, all authors agree that the added complexity will not be worthwhile and just having it on as a default is our suggestion. >> Linux patch has both a sysctl and a socket option to aid in experimentation. >> Looking at other RFCs the SCTP RFCs are quite careful to define socket options >> whereas the TCP RFCs often leave it out. We don't have any strong opinions >> regarding this. We are more than happy to add an API section if the working >> group wants one, but we are not sure that it is necessary. >> >> (ii) Should we apply RTO restart for all segments or only when the amount of >> outstanding data is too small to support fast retransmit? >> >> This discussion has been going for a long time, both on and off the list. Our >> first version of the draft did the modified restart for all segments. However, >> in discussions with various people it soon became apparent that from a >> performance perspective it would be rather bad to do it this way, as it >> increases the risk of having RTOs (with deep cuts in the cwnd and so on). As >> long as you technically can recover a loss using fast retransmit you should do >> that. Thus, in scenarios where it is possible to use fast retransmit, it would >> only be contra productive to lower the value of the retransmission timer. On the >> other hand, when it's impossible to use fast retransmit then it's a good thing :) >> This is the rationale behind the current draft. >> The suggestion by some for applying RTO restart to all segments is based on the >> rationale that this would simplify the algorithm, and would avoid further >> complicating an already complex RTO management. >> >> The authors' suggestion is to leave the algorithm as it currently is, as we >> believe this to be the right approach. The additional condition is by itself not >> very complex. We believe any general issues with and needed reworking of the RTO > Fine if you want to be conservative (and complicate things). > > Part of these compilation comes from resetting cwnd on timeout. It's > like a time-ticking bomb for TCP performance. Consider the case where > the entire cwnd is delivered except the last one. There is no point to > re-slow-start to restore the ack clock, because you already have > cwnd-1 acks last round. Agreed. The time-ticking bomb is why we suggest the conservative approach. Anna > I plan to implement rto-restart idea in Linux as base of a new loss > recovery, but probably not the cwnd checking part. When an RTO fires > it's time to retransmit. The need to check cwnd implies my timer is > problematic. > >> management belongs as a separate work item. >> >> >> Cheers, >> Per >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From prvs=00657a3d1d=anna.brunstrom@kau.se Thu Dec 19 02:42:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16C1AE0A3 for ; Thu, 19 Dec 2013 02:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG7ggGgNzr5m for ; Thu, 19 Dec 2013 02:42:03 -0800 (PST) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) by ietfa.amsl.com (Postfix) with ESMTP id D9FE91AC85E for ; Thu, 19 Dec 2013 02:42:02 -0800 (PST) X-Spam-Processed: mail.kau.se, Thu, 19 Dec 2013 11:41:45 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.155.87 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <52B2CD74.6030408@kau.se> Date: Thu, 19 Dec 2013 11:41:56 +0100 From: =?ISO-8859-1?Q?Anna_Brunstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: rs@netapp.com References: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 10:42:05 -0000 Hi, On 2013-12-19 10:24, Scheffenegger, Richard wrote: >>> (ii) Should we apply RTO restart for all segments or only when the >>> amount of outstanding data is too small to support fast retransmit? >> Part of these compilation comes from resetting cwnd on timeout. It's like >> a time-ticking bomb for TCP performance. Consider the case where the >> entire cwnd is delivered except the last one. There is no point to re- >> slow-start to restore the ack clock, because you already have >> cwnd-1 acks last round. >> >> I plan to implement rto-restart idea in Linux as base of a new loss >> recovery, but probably not the cwnd checking part. When an RTO fires it's >> time to retransmit. The need to check cwnd implies my timer is >> problematic. > Provided that you have other means (ie TS) to detect if the ACK was due to an spurious retransmit (RTO) or genuinely needed, I'm not sure if that complexity of checking the currently outstanding segments really is needed. > > As Yuchung points out, removing this would reduce the complexity of the algorithm. If spurious retransmits are a problem, and they often are, the stack requires some other way of dealing with those anyway, because "fixing" only rto-restart won't address all the other (currently happening) instances of spurious rtos... > This is not only about spurious RTOs, it is also about how you recover lost packets. You don't want an RTO for that if a fast retransmit can be done. Also for spurious RTOs, TS isn't always used, and anyway all mechanisms for spurious timeout detection detect and repair the problem *after* it happened ... this is better than nothing, but it's even better to keep the spurious timeout from happening in the first place. It is a simple check, so I think that one line of code is worthwhile. Anna > > Seasons greetings, > > > Richard Scheffenegger > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Thu Dec 19 04:00:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CD91AE176 for ; Thu, 19 Dec 2013 04:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.14 X-Spam-Level: X-Spam-Status: No, score=-7.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUGIcu1NBZqQ for ; Thu, 19 Dec 2013 04:00:29 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A90071AE15C for ; Thu, 19 Dec 2013 04:00:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,512,1384329600"; d="scan'208";a="130686925" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 19 Dec 2013 04:00:28 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.147]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 04:00:27 -0800 From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Anna_Brunstr=F6m?= Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 Thread-Index: AQHO+9xAhlrV8y0Ac0WO9u6v6uElH5pa1KQAgABp/LCAAJ2jAP//jIyw Date: Thu, 19 Dec 2013 12:00:26 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25F471AE@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> <52B2CD74.6030408@kau.se> In-Reply-To: <52B2CD74.6030408@kau.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 12:00:31 -0000 Hi Anna, >> As Yuchung points out, removing this would reduce the complexity of the >> algorithm. If spurious retransmits are a problem, and they often are, th= e >> stack requires some other way of dealing with those anyway, because >> "fixing" only rto-restart won't address all the other (currently >> happening) instances of spurious rtos... >> >=20 > This is not only about spurious RTOs, it is also about how you recover > lost packets. You don't want an RTO for that if a fast retransmit can be > done. But how do you positively know in advance, if a fast retransmit can be done= ? Looking at cwnd alone is not sufficient, as you also need a model of the = receiver (delayed ACK - phase and frequency) and return path (ACK loss, del= ay)... Just because there may exist a chance to do fast retransmits doesn't= imply that fast retransmits will be the most timely loss recovery... =20 > Also for spurious RTOs, TS isn't always used, and anyway all mechanisms > for spurious timeout detection detect and repair the problem *after* it > happened ... this is better than nothing, but it's even better to keep th= e > spurious timeout from happening in the first place. It is a simple check, > so I think that one line of code is worthwhile. Again, without precognition on the sender side, you'll always need some rea= ctive mechanisms; trying to be proactive alone will not always help... Overall, I think making rto-restart dependent on cwnd should be optional, n= ot necessarily normative. Implementers who have repair mechanisms after spu= rious RTOs happened may choose to implement a more simple rto restart; or t= hey may choose to make a better model to trigger RTO (ie. improving the tim= eout calculation utilizing additional information )=20 Richard Scheffenegger From prvs=00657a3d1d=anna.brunstrom@kau.se Thu Dec 19 09:16:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595EE1AE131 for ; Thu, 19 Dec 2013 09:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GbgiS2-gZ8m for ; Thu, 19 Dec 2013 09:16:32 -0800 (PST) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) by ietfa.amsl.com (Postfix) with ESMTP id 135AF1ADDDA for ; Thu, 19 Dec 2013 09:16:31 -0800 (PST) X-Spam-Processed: mail.kau.se, Thu, 19 Dec 2013 18:16:12 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.155.87 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <52B329E9.8090108@kau.se> Date: Thu, 19 Dec 2013 18:16:25 +0100 From: =?ISO-8859-1?Q?Anna_Brunstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> <52B2CD74.6030408@kau.se> <012C3117EDDB3C4781FD802A8C27DD4F25F471AE@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25F471AE@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:16:34 -0000 Hi Richard, On 2013-12-19 13:00, Scheffenegger, Richard wrote: > Hi Anna, > >>> As Yuchung points out, removing this would reduce the complexity of the >>> algorithm. If spurious retransmits are a problem, and they often are, the >>> stack requires some other way of dealing with those anyway, because >>> "fixing" only rto-restart won't address all the other (currently >>> happening) instances of spurious rtos... >>> >> This is not only about spurious RTOs, it is also about how you recover >> lost packets. You don't want an RTO for that if a fast retransmit can be >> done. > But how do you positively know in advance, if a fast retransmit can be done? Looking at cwnd alone is not sufficient, as you also need a model of the receiver (delayed ACK - phase and frequency) and return path (ACK loss, delay)... Just because there may exist a chance to do fast retransmits doesn't imply that fast retransmits will be the most timely loss recovery... It is true that you can not be sure that a fast retransmit will always be triggered, but as it is much preferred you want to give it as good of a chance as possible. As a side note, it is not the cwnd, but the number of outstanding segments that is used. >> Also for spurious RTOs, TS isn't always used, and anyway all mechanisms >> for spurious timeout detection detect and repair the problem *after* it >> happened ... this is better than nothing, but it's even better to keep the >> spurious timeout from happening in the first place. It is a simple check, >> so I think that one line of code is worthwhile. > > Again, without precognition on the sender side, you'll always need some reactive mechanisms; trying to be proactive alone will not always help... True, but this does not mean that you should not use proactive methods when possible! Preventing the problem is good even if you cannot prevent every instance. In this case the prevention is also very simple... > > Overall, I think making rto-restart dependent on cwnd should be optional, not necessarily normative. Implementers who have repair mechanisms after spurious RTOs happened may choose to implement a more simple rto restart; or they may choose to make a better model to trigger RTO (ie. improving the timeout calculation utilizing additional information ) If you create your own RTO calculation you are not following RFC 6298 anyway and you can do as you wish also with RTO restart I guess? As RTO restart updates a RECOMMENDED algorithm I guess you also have some freedom from that. Anna > Richard Scheffenegger > > From michael.scharf@ALCATEL-LUCENT.COM Fri Dec 20 05:45:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31041AD945 for ; Fri, 20 Dec 2013 05:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTLHDHo2_X6A for ; Fri, 20 Dec 2013 05:45:26 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A50CD1AE2BF for ; Fri, 20 Dec 2013 05:45:21 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rBKDYpSc023597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Dec 2013 07:45:17 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBKDQYbM026093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Dec 2013 14:26:42 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.70]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 20 Dec 2013 14:26:37 +0100 From: "Scharf, Michael (Michael)" To: =?iso-8859-1?Q?Anna_Brunstr=F6m?= , "Scheffenegger, Richard" Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 Thread-Index: AQHO+9wfPN8LwItoDEaZyPysraqmvZpaPcUAgADx6wCAABW0AIAAFe4AgABYSYCAAWBPww== Date: Fri, 20 Dec 2013 13:26:37 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1504C4@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> <52B2CD74.6030408@kau.se> <012C3117EDDB3C4781FD802A8C27DD4F25F471AE@SACEXCMBX02-PRD.hq.netapp.com>, <52B329E9.8090108@kau.se> In-Reply-To: <52B329E9.8090108@kau.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 13:45:29 -0000 Hi,=0A= =0A= Two questions related to this discussion:=0A= =0A= - Wouldn't it make sense to use RFC 2119 language in the algorithm, given t= hat different options seem to exist?=0A= =0A= - An implementation question: Is there any real data on the complexity of t= he condition under discussion? For instance, could determining the number o= f outstanding packets for each ACK require traversing the whole SACK scoreb= oard, in cases where it would not be required today? That probably depends = on what state the TCP sender keeps already today. Still, if this condition = had significant side effects in certain stacks, it would be relevant to und= erstand them IMHO.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Anna Brunstr= =F6m [anna.brunstrom@kau.se]=0A= Gesendet: Donnerstag, 19. Dezember 2013 18:16=0A= Bis: Scheffenegger, Richard=0A= Cc: tcpm@ietf.org=0A= Betreff: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01=0A= =0A= Hi Richard,=0A= =0A= On 2013-12-19 13:00, Scheffenegger, Richard wrote:=0A= > Hi Anna,=0A= >=0A= >>> As Yuchung points out, removing this would reduce the complexity of the= =0A= >>> algorithm. If spurious retransmits are a problem, and they often are, t= he=0A= >>> stack requires some other way of dealing with those anyway, because=0A= >>> "fixing" only rto-restart won't address all the other (currently=0A= >>> happening) instances of spurious rtos...=0A= >>>=0A= >> This is not only about spurious RTOs, it is also about how you recover= =0A= >> lost packets. You don't want an RTO for that if a fast retransmit can be= =0A= >> done.=0A= > But how do you positively know in advance, if a fast retransmit can be do= ne? Looking at cwnd alone is not sufficient, as you also need a model of th= e receiver (delayed ACK - phase and frequency) and return path (ACK loss, d= elay)... Just because there may exist a chance to do fast retransmits doesn= 't imply that fast retransmits will be the most timely loss recovery...=0A= =0A= It is true that you can not be sure that a fast retransmit will always=0A= be triggered, but as it is much preferred you want to give it as good of=0A= a chance as possible.=0A= =0A= As a side note, it is not the cwnd, but the number of outstanding=0A= segments that is used.=0A= =0A= >> Also for spurious RTOs, TS isn't always used, and anyway all mechanisms= =0A= >> for spurious timeout detection detect and repair the problem *after* it= =0A= >> happened ... this is better than nothing, but it's even better to keep t= he=0A= >> spurious timeout from happening in the first place. It is a simple check= ,=0A= >> so I think that one line of code is worthwhile.=0A= >=0A= > Again, without precognition on the sender side, you'll always need some r= eactive mechanisms; trying to be proactive alone will not always help...=0A= =0A= True, but this does not mean that you should not use proactive methods=0A= when possible! Preventing the problem is good even if you cannot prevent=0A= every instance. In this case the prevention is also very simple...=0A= =0A= >=0A= > Overall, I think making rto-restart dependent on cwnd should be optional,= not necessarily normative. Implementers who have repair mechanisms after s= purious RTOs happened may choose to implement a more simple rto restart; or= they may choose to make a better model to trigger RTO (ie. improving the t= imeout calculation utilizing additional information )=0A= =0A= If you create your own RTO calculation you are not following RFC 6298=0A= anyway and you can do as you wish also with RTO restart I guess? As RTO=0A= restart updates a RECOMMENDED algorithm I guess you also have some=0A= freedom from that.=0A= =0A= Anna=0A= =0A= > Richard Scheffenegger=0A= >=0A= >=0A= =0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From ycheng@google.com Fri Dec 20 08:37:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF01ADEB5 for ; Fri, 20 Dec 2013 08:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVwyyR98i5ll for ; Fri, 20 Dec 2013 08:37:37 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 58FE91ADBCF for ; Fri, 20 Dec 2013 08:37:37 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so3362754iec.19 for ; Fri, 20 Dec 2013 08:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=bsVNMWX7fT4r0Q261Jopty3t2o3uljZJ0S54Uo3WGeY=; b=druFbmMu7RYuwVqlIMXUs6ldn1gzYgn0FgMid6h5sCKol6GL69ut7emhEabjOuoJEc tIKOzi1iNlI3sQ/RRo501galU4OgjM6tvKDzwK/FxA+rs5+I54mb/fY6YzJBfGkjtHI+ 5VNlWCy1NW2Oc1ZJsg86V8KD2oiUGcL3ofzQ4TRQbTbCJ0ldRcvxpLrLsiHrVBgVGA3y kSaq+8IjqXyX9esDNNDTYIHKotPP4NEW4r69Y9AyARSkaXfAuCln7+i2MF9ZdfxlS5kW lkeiBr4fgQ6JGzd8HGY/ETW2kV2qt4F3BkHRAYKEX6wJmH8Qlnbb3ejJhRGi04DDlSZS Dq1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=bsVNMWX7fT4r0Q261Jopty3t2o3uljZJ0S54Uo3WGeY=; b=X+2cn6NIr+6MI+MhfBF3XgFnOA2GsmlvC8YWOEs+k8DpgRu1rWm616/rDzt5eSGezg QmgTCXjcnpck91DwlJj7fhusU5cyjzZDWRA2+KHJ9X9dLcfJpemOWlEzmEYGU5AsDzYJ 5VFu0lk6wymplAx/pUjsbWjLDDenuQ90oU2Ubh2z4NQwPOH75ZQywtkl4s21nkjznPBO TCIcWvJwUNGwtCYoJMr+jlEAmlvW9Jyz3d2WsRclRv2Ek0I9O/+BPL8q5UHu2vedR8lN 8mYeOv6dDczWEc//MJEh0SGUxGJ1bNikeB+OL+a9QOgJcas53wVwo3ZTBdmqMxWTIYmy UEdA== X-Gm-Message-State: ALoCoQl1JLlu+KgcllqQCriI5NWHWonlZVOXhuTaTvexeQYD1/9zVe8k71MWEmPh6lbjyPiPUyX2w6piDHpsn6IAmEOincbocalvo8jx5gyM2ay5rJajo90bDsspmVgzz1cuSeqhIXpydyhUiHYG76sWfpYm+ki/CHV5FDhffPJefjpcnVR7Nm7MzBzZoSZftV4ESzCmJULd X-Received: by 10.43.138.148 with SMTP id is20mr6146561icc.23.1387557455096; Fri, 20 Dec 2013 08:37:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.170.3 with HTTP; Fri, 20 Dec 2013 08:36:54 -0800 (PST) In-Reply-To: <655C07320163294895BBADA28372AF5D1504C4@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F25F46778@SACEXCMBX02-PRD.hq.netapp.com> <52B2CD74.6030408@kau.se> <012C3117EDDB3C4781FD802A8C27DD4F25F471AE@SACEXCMBX02-PRD.hq.netapp.com> <52B329E9.8090108@kau.se> <655C07320163294895BBADA28372AF5D1504C4@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Fri, 20 Dec 2013 08:36:54 -0800 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 16:37:39 -0000 On Fri, Dec 20, 2013 at 5:26 AM, Scharf, Michael (Michael) wrote: > Hi, > > Two questions related to this discussion: > > - Wouldn't it make sense to use RFC 2119 language in the algorithm, given= that different options seem to exist? > > - An implementation question: Is there any real data on the complexity of= the condition under discussion? For instance, could determining the number= of outstanding packets for each ACK require traversing the whole SACK scor= eboard, in cases where it would not be required today? That probably depend= s on what state the TCP sender keeps already today. Still, if this conditio= n had significant side effects in certain stacks, it would be relevant to u= nderstand them IMHO. Not for Linux. it keeps these counters when it updates sack scoreboard, and other stacks probably do that cause it's fairly simple. > > Thanks > > Michael > > ________________________________________ > Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Anna Brunstr= =C3=B6m [anna.brunstrom@kau.se] > Gesendet: Donnerstag, 19. Dezember 2013 18:16 > Bis: Scheffenegger, Richard > Cc: tcpm@ietf.org > Betreff: Re: [tcpm] Comments on draft-ietf-tcpm-rtorestart-01 > > Hi Richard, > > On 2013-12-19 13:00, Scheffenegger, Richard wrote: >> Hi Anna, >> >>>> As Yuchung points out, removing this would reduce the complexity of th= e >>>> algorithm. If spurious retransmits are a problem, and they often are, = the >>>> stack requires some other way of dealing with those anyway, because >>>> "fixing" only rto-restart won't address all the other (currently >>>> happening) instances of spurious rtos... >>>> >>> This is not only about spurious RTOs, it is also about how you recover >>> lost packets. You don't want an RTO for that if a fast retransmit can b= e >>> done. >> But how do you positively know in advance, if a fast retransmit can be d= one? Looking at cwnd alone is not sufficient, as you also need a model of t= he receiver (delayed ACK - phase and frequency) and return path (ACK loss, = delay)... Just because there may exist a chance to do fast retransmits does= n't imply that fast retransmits will be the most timely loss recovery... > > It is true that you can not be sure that a fast retransmit will always > be triggered, but as it is much preferred you want to give it as good of > a chance as possible. > > As a side note, it is not the cwnd, but the number of outstanding > segments that is used. > >>> Also for spurious RTOs, TS isn't always used, and anyway all mechanisms >>> for spurious timeout detection detect and repair the problem *after* it >>> happened ... this is better than nothing, but it's even better to keep = the >>> spurious timeout from happening in the first place. It is a simple chec= k, >>> so I think that one line of code is worthwhile. >> >> Again, without precognition on the sender side, you'll always need some = reactive mechanisms; trying to be proactive alone will not always help... > > True, but this does not mean that you should not use proactive methods > when possible! Preventing the problem is good even if you cannot prevent > every instance. In this case the prevention is also very simple... > >> >> Overall, I think making rto-restart dependent on cwnd should be optional= , not necessarily normative. Implementers who have repair mechanisms after = spurious RTOs happened may choose to implement a more simple rto restart; o= r they may choose to make a better model to trigger RTO (ie. improving the = timeout calculation utilizing additional information ) > > If you create your own RTO calculation you are not following RFC 6298 > anyway and you can do as you wish also with RTO restart I guess? As RTO > restart updates a RECOMMENDED algorithm I guess you also have some > freedom from that. > > Anna > >> Richard Scheffenegger >> >> > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From renaud.sallantin@enseeiht.fr Fri Dec 20 09:23:09 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCCE1AE020 for ; Fri, 20 Dec 2013 09:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmmCpXjirQd9 for ; Fri, 20 Dec 2013 09:23:06 -0800 (PST) Received: from n7smtp.enseeiht.fr (n7smtp.enseeiht.fr [147.127.176.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B51ADFFB for ; Fri, 20 Dec 2013 09:23:05 -0800 (PST) Received: from imap.enseeiht.fr (imap.enseeiht.fr [147.127.176.21]) by n7smtp.enseeiht.fr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id rBKHN1eU025682; Fri, 20 Dec 2013 18:23:01 +0100 Received: from [147.127.81.87] (pc-irt11.enseeiht.fr [147.127.81.87]) by imap.enseeiht.fr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id rBKHMwna012032; Fri, 20 Dec 2013 18:23:00 +0100 Message-ID: <52B47CF2.7000903@enseeiht.fr> Date: Fri, 20 Dec 2013 18:22:58 +0100 From: Renaud Sallantin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: tcpm@ietf.org, BAUDOIN Cedric , CHAPUT Emmanuel , ARNAL Fabrice , BEYLOT Andre-luc , Dubois Emmanuel References: <52B43F60.3050300@enseeiht.fr> <7816_1387555744_52B46BA0_7816_3111_1_e0a82880-10af-42f6-ac2a-ff0807ea6d19@THSONEA01HUB02P.one.grp> In-Reply-To: <7816_1387555744_52B46BA0_7816_3111_1_e0a82880-10af-42f6-ac2a-ff0807ea6d19@THSONEA01HUB02P.one.grp> Content-Type: multipart/alternative; boundary="------------040003060200010804070900" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (n7smtp.enseeiht.fr [147.127.176.11]); Fri, 20 Dec 2013 18:23:01 +0100 (CET) X-Scanned-By: MIMEDefang 2.64 on 147.127.176.11 Subject: Re: [tcpm] =?iso-8859-1?q?last_version_du_mail=3B_derni=E8re_relectur?= =?iso-8859-1?q?e?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 17:23:09 -0000 This is a multi-part message in MIME format. --------------040003060200010804070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We would like to share and discuss with you a mechanism we called "Initial Spreading" (IS). The idea consists in the combination of high IW (e.g. IW=10), jointly with a spacing of those segments over, at most, the first RTT of the connection. After the sending of the IW, we switch back to the scheduling of the TCP algorithms... Our motivation lays in the fact that raising IW, as largely discussed previously, is good, unless the network is congested. In that case, IS prevents the large initial burst to occur, and to this respect is not too aggressive for the network, but still avoids the drawbacks of solutions such as Pacing. We have shown we can achieve a sounding compromise to the enhancement of the TCP connection startup, in various environments : LAN, wireless and LFN networks (including satellite access which was our initial target). We recently presented this work to the LCN'13 conference in Sydney, supported by extensive NS2 simulations. (R. Sallantin, C. Baudoin, E. Chaput, E. Dubois, F. Arnal, and A. Beylot, "Initial spreading: a fast start-up tcp mechanism," proceedings of LCN, October 23, 2013.) The paper hasn't been published yet on IEEEXplore but should be available soon. A draft version of this work is available here : http://www.irit.fr/publis/IRT/InitialSpreading.pdf Finally, we have implemented this scheme in the Linux-kernel. Preliminary results validate the proposed scheme and our simulation experiments. We will open the sources and provide related packages by the end of January. We are also working on the optimization of the interval between successive segments during the first RTT, taking into account impact of bursts and implementation constraints. We would be more than happy to receive at this stage your feedback. Renaud Sallantin Thales Alenia Space/CNES/TeSA PhD --------------040003060200010804070900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

We would like to share and discuss with you a mechanism we called “Initial Spreading” (IS).

The idea consists in the combination of high IW (e.g. IW=10), jointly with a spacing of those segments over, at most, the first RTT of the connection. After the sending of the IW, we switch back to the scheduling of the TCP algorithms…

Our motivation lays in the fact that raising IW, as largely discussed previously, is good, unless the network is congested.

In that case, IS prevents the large initial burst to occur, and to this respect is not too aggressive for the network, but still avoids the drawbacks of solutions such as Pacing.

We have shown we can achieve a sounding compromise to the enhancement of the TCP connection startup, in various environments : LAN, wireless and LFN networks (including satellite access which was our initial target).

We recently presented this work to the LCN’13 conference in Sydney, supported by extensive NS2 simulations.
(R. Sallantin, C. Baudoin, E. Chaput, E. Dubois, F. Arnal, and A. Beylot, “Initial spreading: a fast start-up tcp mechanism,” proceedings of LCN, October 23, 2013.)

The paper hasn’t been published yet on IEEEXplore but should be available soon. A draft version of this work  is available  here :

http://www.irit.fr/publis/IRT/InitialSpreading.pdf

Finally, we have implemented this scheme in the Linux-kernel. Preliminary results validate the proposed scheme and our simulation experiments. We will open the sources and provide related packages by the end of January.

We are also working on the optimization of the interval between successive segments during the first RTT, taking into account impact of bursts and implementation constraints.

We would be more than happy to receive at this stage your feedback.

Renaud Sallantin
Thales Alenia Space/CNES/TeSA PhD


--------------040003060200010804070900-- From michael.scharf@alcatel-lucent.com Sun Dec 22 07:12:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBA51AE411 for ; Sun, 22 Dec 2013 07:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnDeijBAQYjA for ; Sun, 22 Dec 2013 07:12:31 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id A77BD1AE40D for ; Sun, 22 Dec 2013 07:12:30 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id rBMFCNmC027001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 22 Dec 2013 09:12:24 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBMFCMBr002271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 16:12:22 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.70]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sun, 22 Dec 2013 16:12:22 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng , Gorry Fairhurst Thread-Topic: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] Thread-Index: AQHO+0E+rBLtQlqU506MJ3iG607V9ppYfb8AgAAIMYCAB8vIoA== Date: Sun, 22 Dec 2013 15:12:22 +0000 Message-ID: <655C07320163294895BBADA28372AF5D152007@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <8f78ebda09f5e658aa0cd61a38019a88.squirrel@www.erg.abdn.ac.uk> <52B07778.7090504@erg.abdn.ac.uk> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 15:12:34 -0000 > >>>> I appreciate the new section on burst mitigation but why standard > track? > >>>> > >>> The previous discussions on STD track centres on whether we would > include > >>> require a burst mitigation section, so this is now a good question. > >>> > >>>> The change has pro-found impact on congestion control as it > changes > >>>> how cwnd increases per ACK and after idle. There are a lot to > >>>> experiment before we know this works well in real networks. > >>>> > >>> Are you referring to the new ack-mitigation section - requiring > pacing > >>> after idle? > >> > >> I am referring to the main changes proposed in the draft, not just > >> pacing after idle. > >> > > OK, so this algorithm hasn't changed much for a couple of IETFs. > > > > Do you have concerns about relaxing the Standard behaviour > (collapsing to IW > > after one RTO), and that letting apps maintain a higher cwnd has > dangers? > > > > Or do you think the algorithm may keep to high a cwnd when non- > validated? > > > > Or is it something else? > something else. >=20 > I thought standard means people have used it, found it working, and > like how it works. May I am wrong. A general remark... Section 4.1.1 of RFC 2026 defines Proposes Standard as follows: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. According to the second paragraph, implementation or operational experience= is formally *not* required. However, there is the third paragraph, and TCP= is probably a core Internet protocol with significant operational impact o= n the Internet ;) According to related past discussions, my understanding is that a large par= t of the TCPM community wants to have implementation and operational experi= ence for all TCPM standards track documents. That is a high bar, and it may= be one of the reasons why TCPM publishes many documents as experimental (f= irst). (See also MPTCP as another example.) In my personal view, publishing a proposed standard in TCPM that has low li= kelihood of Internet-scale deployment doesn't make a lot of sense. This is = my general thinking, and it is entirely independent of this specific discus= sion of draft-ietf-tcpm-newcwv.=20 Michael From apopov@palermo.edu Mon Dec 23 10:33:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3861AE22F for ; Mon, 23 Dec 2013 10:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkEFRheyYWV9 for ; Mon, 23 Dec 2013 10:33:07 -0800 (PST) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBED1AE234 for ; Mon, 23 Dec 2013 10:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1387823567; bh=q3yOy7RnNWj9rKhhnjgQDhBWZYUXvZPRfu5xMNjmVS0=; h=Date:From:To:Subject; b=Y3Y0cpYnVeIkHZXG9xbYLnRSiclO89K1tqa4Wnl5zJnu40zRnKb5fS07R+s48oJG6 8gffJi1AFAOVbz6EOY8elUGwrjzletOJltO6SyVlisD82WjRm6C0Kb1W//1YebbbcO rAQkhqqc5koXUgrTxzCrEb+Kc0rsz4/p6fscNXqA= Received: from maxwell.palermo.edu (localhost [127.0.0.1]) by maxwell.palermo.edu (8.14.4/8.13.8) with ESMTP id rBNIWlOq008495 for ; Mon, 23 Dec 2013 15:32:47 -0300 Received: from [10.30.0.3] ( [10.30.0.3]) by maxwell.palermo.edu with ESMTP id GQ9TKQS6.700671.0 Message-ID: <52B8829B.9050308@palermo.edu> Date: Mon, 23 Dec 2013 15:36:11 -0300 From: Alejandro Popovsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="------------070107020408020105080403" X-Authorization-Id: who=apopov X-Host: 10.30.0.3 Subject: [tcpm] end of burst, delayed acks, and push flag X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 18:33:10 -0000 This is a multi-part message in MIME format. --------------070107020408020105080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The delayed ack generation may bother when applied to the last segment of a burst. There is no 'end of burst indication' from regular senders, i.e. senders with no tail probing (TLP), nor end of burst reordering (Scheffenegger). But on many implementations, the operating system sets the push flag when sending the last byte of a write(...) function call. So push flag helps to identify the end of a burst. So a way to prevent the problem, could be to disable the ack delay for a/'/push' data segment coming after at least one 'non-push' data segment. Best regards, Alejandro. --------------070107020408020105080403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The delayed ack generation may bother when applied to the last segment of a burst.

There is no 'end of burst indication' from regular senders, i.e.  senders with no
tail probing (TLP), nor end of burst reordering (Scheffenegger).

But on many implementations, the operating system sets the push flag when sending
the last byte of a write(...) function call. So push flag helps to identify the end of a burst.

So a way to prevent the problem, could be to disable the ack delay for a 'push' data segment
coming after at least one 'non-push' data segment.

Best regards, Alejandro.


--------------070107020408020105080403-- From touch@isi.edu Mon Dec 23 11:12:26 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D077D1AE266 for ; Mon, 23 Dec 2013 11:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhZq742M2gdz for ; Mon, 23 Dec 2013 11:12:24 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B82621AE256 for ; Mon, 23 Dec 2013 11:12:24 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rBNJBonS008732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Dec 2013 11:11:50 -0800 (PST) Message-ID: <52B88AF6.5010808@isi.edu> Date: Mon, 23 Dec 2013 11:11:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alejandro Popovsky , tcpm@ietf.org References: <52B8829B.9050308@palermo.edu> In-Reply-To: <52B8829B.9050308@palermo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] end of burst, delayed acks, and push flag X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 19:12:27 -0000 On 12/23/2013 10:36 AM, Alejandro Popovsky wrote: > The delayed ack generation may bother when applied to the last segment > of a burst. That's not clear at all - see below. > There is no 'end of burst indication' from regular senders, i.e. senders > with no tail probing (TLP), nor end of burst reordering (Scheffenegger). > > But on many implementations, the operating system sets the push flag > when sending > the last byte of a write(...) function call. So push flag helps to > identify the end of a burst. It might want to set the PUSH flag on the last write in a sequence of write() calls in a burst, but the PUSH flag applies to the last write() call, not to a byte within the write(). > So a way to prevent the problem, could be to disable the ack delay for > a/'/push' data segment > coming after at least one 'non-push' data segment. First, let's assume Nagle is off, as it should be for bursty traffic. One side (named 'Alba') sends bursts packets to the other (named 'Nisar'). Let's further assume that the burst is an odd number of packets (if it's even, then delayed ACK will work fine). Alba sends 1 packet to Nisar (this is the degenerate case; if it works for 1, it'll work for larger numbers). Nisar waits to ACK. One of three things happens next: - a timeout (500 ms later), when Nisar sends the ACK for the burst - Nisar has something to send to Alba, at which point Nisar will include the most recent ACK anyway (AFAICT) - Alba has something to send to Nisar, at which point she will send the first packet of it (because the window is always at least 3 packets) at which point Nisar will ACK the last burst and the new packet I.e., the only way this stalls is when Alba's window is smaller than 1 packet. Otherwise, not getting the ACK of the last bursts costs Alba at most one packet of capacity during the first round-trip of the next burst. I'm not sure that PUSH is the right way to fix this; just because it's the end of a burst doesn't mean there won't be another burst in much less than 500 ms, and using PUSH the way you describe could cause bursty sources to circumvent delayed ACK, in which case their window would grow faster than those that use delayed ACK today. I don't see how that's worth one packet. Joe > Best regards, Alejandro. > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From M.Lloyd@f5.com Mon Dec 30 14:24:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362281AE2DD for ; Mon, 30 Dec 2013 14:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjkGOO6L5Ge5 for ; Mon, 30 Dec 2013 14:24:54 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5581AE29B for ; Mon, 30 Dec 2013 14:24:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,576,1384300800"; d="scan'208";a="95363067" X-IPAS-Result: AqMEAGfxwVLAqArr/2dsb2JhbABOCg6DNVW5dIEwdIIlAQEBAQIBAQEBNzQQBwQCAQgNBAQBAQEKFAkHJwsUCQgCBAESCId0FcctEwSOQSs4BoMdgRMEnwOOFj+CKg Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 30 Dec 2013 22:24:47 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Mon, 30 Dec 2013 14:24:47 -0800 From: Mark Lloyd To: Joe Touch , Alejandro Popovsky , "tcpm@ietf.org" Thread-Topic: [tcpm] end of burst, delayed acks, and push flag Thread-Index: AQHPAA1vZGK/TnAIP0y4eGuxr+zxJZpiq6sAgAqpVFA= Date: Mon, 30 Dec 2013 22:24:46 +0000 Message-ID: <2A08B7ACA17C9F4BAA8D5395DF908D73A30FE932@SEAEMBX01.olympus.F5Net.com> References: <52B8829B.9050308@palermo.edu> <52B88AF6.5010808@isi.edu> In-Reply-To: <52B88AF6.5010808@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] end of burst, delayed acks, and push flag X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 22:24:56 -0000 Is the RFC mandated super high Min-RTO time in play here?=20 -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch Sent: Monday, December 23, 2013 11:12 AM To: Alejandro Popovsky; tcpm@ietf.org Subject: Re: [tcpm] end of burst, delayed acks, and push flag On 12/23/2013 10:36 AM, Alejandro Popovsky wrote: > The delayed ack generation may bother when applied to the last segment=20 > of a burst. That's not clear at all - see below. > There is no 'end of burst indication' from regular senders, i.e.=20 > senders with no tail probing (TLP), nor end of burst reordering (Scheffen= egger). > > But on many implementations, the operating system sets the push flag=20 > when sending the last byte of a write(...) function call. So push flag=20 > helps to identify the end of a burst. It might want to set the PUSH flag on the last write in a sequence of write() calls in a burst, but the PUSH flag applies to the last write() cal= l, not to a byte within the write(). > So a way to prevent the problem, could be to disable the ack delay for=20 > a/'/push' data segment coming after at least one 'non-push' data=20 > segment. First, let's assume Nagle is off, as it should be for bursty traffic. One side (named 'Alba') sends bursts packets to the other (named 'Nisar'). Let's further assume that the burst is an odd number of packets (if it's ev= en, then delayed ACK will work fine). Alba sends 1 packet to Nisar (this is the degenerate case; if it works for = 1, it'll work for larger numbers). Nisar waits to ACK. One of three things happens next: - a timeout (500 ms later), when Nisar sends the ACK for the burst - Nisar has something to send to Alba, at which point Nisar will include the most recent ACK anyway (AFAICT) - Alba has something to send to Nisar, at which point she will send the first packet of it (because the window is always at least 3 packets) at which point Nisar will ACK the last burst and the new packet I.e., the only way this stalls is when Alba's window is smaller than 1 pack= et. Otherwise, not getting the ACK of the last bursts costs Alba at most on= e packet of capacity during the first round-trip of the next burst. I'm not sure that PUSH is the right way to fix this; just because it's the = end of a burst doesn't mean there won't be another burst in much less than = 500 ms, and using PUSH the way you describe could cause bursty sources to c= ircumvent delayed ACK, in which case their window would grow faster than th= ose that use delayed ACK today. I don't see how that's worth one packet. Joe > Best regards, Alejandro. > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm