From nishida@sfc.wide.ad.jp Fri Mar 1 00:28:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD5721F8899 for ; Fri, 1 Mar 2013 00:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVl32hioQBYX for ; Fri, 1 Mar 2013 00:28:40 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 1B27A21F85B2 for ; Fri, 1 Mar 2013 00:28:39 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id AFF7F27811C for ; Fri, 1 Mar 2013 17:28:37 +0900 (JST) Received: by mail-la0-f48.google.com with SMTP id fq13so2694411lab.35 for ; Fri, 01 Mar 2013 00:28:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.45.140 with SMTP id n12mr8300213lam.36.1362126515159; Fri, 01 Mar 2013 00:28:35 -0800 (PST) Received: by 10.114.4.39 with HTTP; Fri, 1 Mar 2013 00:28:35 -0800 (PST) In-Reply-To: <51201A00.4060608@si6networks.com> References: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> <51201A00.4060608@si6networks.com> Date: Fri, 1 Mar 2013 00:28:35 -0800 Message-ID: From: Yoshifumi Nishida To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New I-D "On the Validation of TCP Sequence Numbers" (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2013 08:28:41 -0000 Hello, I think this is interesting, but I'm wondering why we haven't realized this for long time and how most implementations deal with simultaneous open properly. BTW, I'm also wondering why the Line 8 and 9 in 3.1 have SYN flags. Aren't they just ACKs? Thanks, -- Yoshifumi On Sat, Feb 16, 2013 at 3:45 PM, Fernando Gont wrote: > Folks, > > We have just published a new IETF I-D entitled "On the Validation of TCP > Sequence Numbers". The I-D is available at: > . > > The abstract of the I-D is: > > ---- cut here ---- > When TCP receives packets that lie outside of the receive window, the > corresponding packets are dropped and either an ACK, RST or no > response is generated due to the out-of-window packet, with no > further processing of the packet. Most of the time, this works just > fine and TCP remains stable, especially when a TCP connection has > unidirectional data flow. However, there are three scenarios in > which packets that are outside of the receive window should still > have their ACK field processed, or else a packet war will take place. > The aforementioned issues have affected a number of popular TCP > implementations, typically leading to connection failures, system > crashes, or other undesirable behaviors. This document describes the > three scenarios in which the aforementioned issues might arise, and > formally updates RFC 793 such that these potential problems are > mitigated. > ---- cut here ---- > > It discusses a problem that has affected a number of popular TCP > implementations, and aims to formally update RFC 793 to mitigate these > issues. > > Any comments will be welcome. > > Thanks! > > Best regards, > Fernando > > > > > -------- Original Message -------- > From: internet-drafts@ietf.org > To: fgont@si6networks.com > Cc: david.borman@quantum.com > Subject: New Version Notification for > draft-gont-tcpm-tcp-seq-validation-00.txt > Message-ID: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> > Date: Sat, 16 Feb 2013 15:02:18 -0800 > > > A new version of I-D, draft-gont-tcpm-tcp-seq-validation-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Filename: draft-gont-tcpm-tcp-seq-validation > Revision: 00 > Title: On the Validation of TCP Sequence Numbers > Creation date: 2013-02-16 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-00.txt > Status: > http://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation > Htmlized: > http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-00 > > > Abstract: > When TCP receives packets that lie outside of the receive window, the > corresponding packets are dropped and either an ACK, RST or no > response is generated due to the out-of-window packet, with no > further processing of the packet. Most of the time, this works just > fine and TCP remains stable, especially when a TCP connection has > unidirectional data flow. However, there are three scenarios in > which packets that are outside of the receive window should still > have their ACK field processed, or else a packet war will take place. > The aforementioned issues have affected a number of popular TCP > implementations, typically leading to connection failures, system > crashes, or other undesirable behaviors. This document describes the > three scenarios in which the aforementioned issues might arise, and > formally updates RFC 793 such that these potential problems are > mitigated. > > > > > > The IETF Secretariat > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Fri Mar 1 00:42:31 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA9221F88CF for ; Fri, 1 Mar 2013 00:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.504 X-Spam-Level: X-Spam-Status: No, score=-7.504 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQj57HZcO0SZ for ; Fri, 1 Mar 2013 00:42:30 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id DBA5221F85A0 for ; Fri, 1 Mar 2013 00:42:22 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r218fxHI003408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Mar 2013 09:42:20 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 1 Mar 2013 09:42:14 +0100 From: "Scharf, Michael (Michael)" To: Yoshifumi Nishida , Fernando Gont Date: Fri, 1 Mar 2013 09:42:13 +0100 Thread-Topic: [tcpm] New I-D "On the Validation of TCP Sequence Numbers" (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt) Thread-Index: Ac4WVsvAjIt7cwhGT1qSzqmeVLTDCAAAQ56A Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D639F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> <51201A00.4060608@si6networks.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New I-D "On the Validation of TCP Sequence Numbers" (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2013 08:42:31 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Yoshifumi Nishida > Sent: Friday, March 01, 2013 9:29 AM > To: Fernando Gont > Cc: tcpm@ietf.org > Subject: Re: [tcpm] New I-D "On the Validation of TCP=20 > Sequence Numbers" (Fwd: New Version Notification for=20 > draft-gont-tcpm-tcp-seq-validation-00.txt) >=20 > Hello, I think this is interesting, but I'm wondering why we=20 > haven't realized this for long time and how most=20 > implementations deal with simultaneous open properly. I wonder on that as well. I just want to add that there is a new RFC 793 er= rata (reported 2012-07-31 by Botong Huang): http://www.rfc-editor.org/errata_search.php?rfc=3D793&eid=3D3305 At first sight, it seems that this reports the same problem, right? Michael > BTW, I'm also wondering why the Line 8 and 9 in 3.1 have SYN flags. > Aren't they just ACKs? >=20 > Thanks, > -- > Yoshifumi >=20 >=20 > On Sat, Feb 16, 2013 at 3:45 PM, Fernando Gont=20 > wrote: > > Folks, > > > > We have just published a new IETF I-D entitled "On the=20 > Validation of=20 > > TCP Sequence Numbers". The I-D is available at: > >=20 > alidation-00.txt>. > > > > The abstract of the I-D is: > > > > ---- cut here ---- > > When TCP receives packets that lie outside of the=20 > receive window, the > > corresponding packets are dropped and either an ACK, RST or no > > response is generated due to the out-of-window packet, with no > > further processing of the packet. Most of the time,=20 > this works just > > fine and TCP remains stable, especially when a TCP connection has > > unidirectional data flow. However, there are three scenarios in > > which packets that are outside of the receive window should still > > have their ACK field processed, or else a packet war=20 > will take place. > > The aforementioned issues have affected a number of popular TCP > > implementations, typically leading to connection failures, system > > crashes, or other undesirable behaviors. This document=20 > describes the > > three scenarios in which the aforementioned issues might=20 > arise, and > > formally updates RFC 793 such that these potential problems are > > mitigated. > > ---- cut here ---- > > > > It discusses a problem that has affected a number of popular TCP=20 > > implementations, and aims to formally update RFC 793 to=20 > mitigate these=20 > > issues. > > > > Any comments will be welcome. > > > > Thanks! > > > > Best regards, > > Fernando > > > > > > > > > > -------- Original Message -------- > > From: internet-drafts@ietf.org > > To: fgont@si6networks.com > > Cc: david.borman@quantum.com > > Subject: New Version Notification for > > draft-gont-tcpm-tcp-seq-validation-00.txt > > Message-ID: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> > > Date: Sat, 16 Feb 2013 15:02:18 -0800 > > > > > > A new version of I-D, draft-gont-tcpm-tcp-seq-validation-00.txt > > has been successfully submitted by Fernando Gont and posted to the=20 > > IETF repository. > > > > Filename: draft-gont-tcpm-tcp-seq-validation > > Revision: 00 > > Title: On the Validation of TCP Sequence Numbers > > Creation date: 2013-02-16 > > Group: Individual Submission > > Number of pages: 15 > > URL: > >=20 > http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation > > -00.txt > > Status: > > http://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation > > Htmlized: > > http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-00 > > > > > > Abstract: > > When TCP receives packets that lie outside of the=20 > receive window, the > > corresponding packets are dropped and either an ACK, RST or no > > response is generated due to the out-of-window packet, with no > > further processing of the packet. Most of the time,=20 > this works just > > fine and TCP remains stable, especially when a TCP connection has > > unidirectional data flow. However, there are three scenarios in > > which packets that are outside of the receive window should still > > have their ACK field processed, or else a packet war=20 > will take place. > > The aforementioned issues have affected a number of popular TCP > > implementations, typically leading to connection failures, system > > crashes, or other undesirable behaviors. This document=20 > describes the > > three scenarios in which the aforementioned issues might=20 > arise, and > > formally updates RFC 793 such that these potential problems are > > mitigated. > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > 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 fgont@si6networks.com Fri Mar 1 02:46:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EFA21F85E2 for ; Fri, 1 Mar 2013 02:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk2LT51twEPn for ; Fri, 1 Mar 2013 02:46:01 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEEB21F84D9 for ; Fri, 1 Mar 2013 02:46:01 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UBNTN-0001YB-P3; Fri, 01 Mar 2013 11:45:55 +0100 Message-ID: <513085CB.7050806@si6networks.com> Date: Fri, 01 Mar 2013 07:41:15 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> <51201A00.4060608@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "tcpm@ietf.org" Subject: Re: [tcpm] New I-D "On the Validation of TCP Sequence Numbers" (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2013 10:46:02 -0000 Hi, Yoshifumi, On 03/01/2013 05:28 AM, Yoshifumi Nishida wrote: > Hello, I think this is interesting, but I'm wondering why we haven't > realized this for long time That depends on what you mean by "we". If "we" is some subset of implementers, then "we" did realize about this a long time ago -- for instance, *BSDs implement the behavior described in our I-D. Why this has never resulted in an RFC update is a different question -- with the most simple answer being "none has ever proposed that". > and how most implementations deal with > simultaneous open properly. Some don't handle simultaneous opens -- e.g., at least some versions of Windows. > BTW, I'm also wondering why the Line 8 and 9 in 3.1 have SYN flags. > Aren't they just ACKs? It assumes that the SYN flag is "adhered" to the SEQ being sent (i.e., the flag is always set when a segment with SEQ=100 (A -> B) or SEQ=300 (B -> A) is sent) -- but I'll reproduce the scenario with some buggy implementation and see what they actually send on the wire. Thanks, -- -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From anna.brunstrom@kau.se Sat Mar 2 03:43:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1116521F90E2 for ; Sat, 2 Mar 2013 03:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n1sfbF98qvQ for ; Sat, 2 Mar 2013 03:43:58 -0800 (PST) Received: from smtprelay-b31.telenor.se (smtprelay-b31.telenor.se [213.150.131.20]) by ietfa.amsl.com (Postfix) with ESMTP id 37AB721F90BC for ; Sat, 2 Mar 2013 03:43:58 -0800 (PST) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b31.telenor.se (Postfix) with ESMTP id 6871DEA65D for ; Sat, 2 Mar 2013 12:43:57 +0100 (CET) X-SENDER-IP: [85.231.110.138] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhURAKDlMVFV526KPGdsb2JhbAANN8JFgREDAQEBATiCUwEBAQEDAQEBNTYKAQwECxEEAQEBCRYIBwkDAgECARUGFgMJCAYNAQUCAQGIG64IkwSNVoE8CwcGgzoDl2GSVoFo X-IronPort-AV: E=Sophos;i="4.84,768,1355094000"; d="scan'208";a="509137304" Received: from c-8a6ee755.06-34-6b736411.cust.bredbandsbolaget.se (HELO [192.168.1.101]) ([85.231.110.138]) by ipb1.telenor.se with ESMTP; 02 Mar 2013 12:43:57 +0100 Message-ID: <5131E5FE.1090201@kau.se> Date: Sat, 02 Mar 2013 12:43:58 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20130218094851.31807.44373.idtracker@ietfa.amsl.com> <512554CE.9090608@kau.se> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6325@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6325@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 02 Mar 2013 11:43:59 -0000 Hi Michael, We are currently running experiments with the patch so we do not have anything published with it yet. Some earlier results with RTO restart in SCTP, when applied to all packets, can be found in: Hurtig, P. and Brunstrom, A. "SCTP: designed for timely message delivery?", Springer Telecommunication Systems, August 2011. http://link.springer.com/article/10.1007%2Fs11235-010-9321-3 BR, Anna On 2013-02-26 17:48, Scharf, Michael (Michael) wrote: > Anna, > > Thanks a lot for sharing this patch! > > Is there already some report of experiments with that patch (e. g., a paper)? > > I'd be interested in that (as individual contributor). > > Thanks > > Michael > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Anna Brunstrom >> Sent: Wednesday, February 20, 2013 11:57 PM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-00.txt >> >> Hi all, >> >> A kernel patch for the Linux 3.7 kernel that implements the >> RTO restart draft is available from >> http://riteproject.eu/projects/wp1-end-systems-and-application >> s/rto-restart/. >> Please try it out and see how it works in your context. >> >> Comments on the draft itself are of course also welcome. >> >> Best Regards, >> Anna >> >> >> On 2013-02-18 10:48, internet-drafts@ietf.org wrote: >>> 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. >>> Title : TCP and SCTP RTO Restart >>> Author(s) : Per Hurtig >>> Anna Brunstrom >>> Andreas Petlund >>> Michael Welzl >>> Filename : draft-ietf-tcpm-rtorestart-00.txt >>> Pages : 10 >>> Date : 2013-02-18 >>> >>> Abstract: >>> This document describes a modified algorithm for >> managing the TCP and >>> SCTP retransmission timers that provides faster loss >> recovery when a >>> connection's amount of outstanding data is small. The >> modification >>> allows the transport to restart its retransmission timer more >>> aggressively in situations where fast retransmit cannot be used. >>> This enables faster loss detection and recovery for >> connections that >>> are short-lived or application-limited. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-00 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 touch@isi.edu Mon Mar 4 11:43:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282EF21F8ED5 for ; Mon, 4 Mar 2013 11:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.833 X-Spam-Level: X-Spam-Status: No, score=-104.833 tagged_above=-999 required=5 tests=[AWL=1.766, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MNvaUllzS85 for ; Mon, 4 Mar 2013 11:43:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3360C21F8ED4 for ; Mon, 4 Mar 2013 11:43:32 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r24Jf8ao019767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Mar 2013 11:41:18 -0800 (PST) Message-ID: <5134F8D5.7050503@isi.edu> Date: Mon, 04 Mar 2013 11:41:09 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: multipart/mixed; boundary="------------030606080702050500050004" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] preview of draft-ietf-tcpm-experimental-options-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2013 19:43:34 -0000 This is a multi-part message in MIME format. --------------030606080702050500050004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, all, Attached is a preview of the 05 update to this doc. The update includes the following, all at the request of the IESG: - more specific and stronger requirements for using this mechanism (MUST rather than SHOULD) - clarification of the trade-offs in using 16- vs 32-bit ExIDs - clarification of the IANA process for assignment Please post if you have a position on these changes. Thanks, Joe --------------030606080702050500050004 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-tcpm-experimental-options-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-tcpm-experimental-options-05.txt" TCPM Working Group J. Touch Internet Draft USC/ISI Intended status: Proposed Standard March 1, 2013 Expires: September 2013 Shared Use of Experimental TCP Options draft-ietf-tcpm-experimental-options-05.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 1, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Touch Expires September 1, 2013 [Page 1] Internet-Draft Shared Use of Experimental TCP Options March 2013 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection. It uses a new IANA TCP experiment identifier, and is also robust to experiments that are not registered and those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................4 3. TCP Experimental Option Structure..............................4 3.1. Selecting an ExID.........................................6 3.2. Impact on TCP Option Processing...........................7 4. Reducing the Impact of False Positives.........................7 5. Migration to Assigned Options..................................8 6. Rationale......................................................8 7. Security Considerations........................................9 8. IANA Considerations............................................9 9. References....................................................10 9.1. Normative References.....................................10 9.2. Informative References...................................10 10. Acknowledgments..............................................11 1. Introduction TCP includes options to enable new protocol capabilities that can be activated only where needed and supported [RFC793]. The space for identifying such options is small - 256 values, of which 30 are assigned at the time this document was published [IANA]. Two of these codepoints are allocated to support experiments (253, 254) [RFC4727]. These values are intended for testing purposes or anytime an assigned codepoint is either not warranted or available, e.g., based on the maturity status of the defined capability (i.e., Experimental or Informational, rather than Standards Track). The term "experimental TCP options" refers here to options that use the TCP experimental option codepoints [RFC4727]. Such experiments can be described in any type of RFC - Experimental, Informational, etc., and are intended to be used both in controlled environments Touch Expires September 1, 2013 [Page 2] Internet-Draft Shared Use of Experimental TCP Options March 2013 and in are allowed in public deployments (when not enabled as default) [RFC3692]. Nothing prohibits deploying multiple experiments in the same environment - controlled or public. Further, some protocols are specified in Experimental or Informational RFCs, which either include parameters or design choices not yet understood or which might not be widely deployed [RFC2026]. TCP options in such RFCs are typically not eligible for assigned TCP option codepoints [RFC2780], and so there is a need to share use of the experimental option codepoints. There is currently no mechanism to support shared use of the TCP experimental option codepoints, either by different experiments on different connections, or for more than two experimental options in the same connection. Experimental options 253 and 254 are already deployed in operational code to support an early version of TCP authentication. Option 253 is also documented for the experimental TCP Cookie Transaction option [RFC6013]. This shared use results in collisions in which a single codepoint can appear multiple times in a single TCP segment and for which each use is ambiguous. Other codepoints have been used without assignment (known as "squatting"), notably 31-32 (TCP cookie transactions, as originally distributed and in its API doc) and 76-78 (tcpcrypt) [Bi11][Si11]. Commercial products reportedly also use unassigned options 33, 69- 70, and 76-78 as well. Even though these uses are unauthorized, they currently impact legitimate assignees. Both such misuses (squatting on both experimental and assigned codepoints) are expected to continue, but there are several approaches which can alleviate the impact on cooperating protocol designers. One proposal relaxes the requirements for assignment of TCP options, allowing them to be assigned more readily for protocols that have not been standardized through the IETF process [RFC5226]. Another proposal assigns a larger pool to the TCP experiment option codepoints and manages their sharing through IANA coordination [Ed11]. The approach proposed in this document does not require additional TCP option codepoints, and is robust to those who choose either not to support it or not to register their experiments. The solution adds a field to the structure of the experimental TCP option. This field is populated with an "experiment identifier" (ExID) defined as part of a specific option experiment. The ExID helps reduce the probability of a collision of independent experimental uses of the same option codepoint, both for those who follow this document (using registered ExIDs) and those who do not (squatters who either ignore this extension or do not register their ExIDs). Touch Expires September 1, 2013 [Page 3] Internet-Draft Shared Use of Experimental TCP Options March 2013 The solution proposed in this document is recommended for all new protocols that use TCP experimental option codepoints. The techniques used here may also help share other experimental codepoints, but that issue is out of scope for this document. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 3. TCP Experimental Option Structure TCP options have the current common structure [RFC793], in which the first byte is the codepoint (Kind) and the second byte is the length of the option in bytes (Length): 0 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ | Kind | Length | ... | +--------+--------+--------+--------+ | ... +-------- Figure 1 TCP Option Structure [RFC793] This document extends the option structure for experimental codepoints (253, 254) with an experiment identifier (ExID), which is either 2 or 4 bytes in length. The ExID is used to differentiate different experiments, and is the first field after the Kind and Length, as follows: Touch Expires September 1, 2013 [Page 4] Internet-Draft Shared Use of Experimental TCP Options March 2013 0 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ | Kind | Length | ExID | +--------+--------+--------+--------+ | option contents... +--------+--------+--------+--- Figure 2 TCP Experimental Option with a 16-bit ExID 0 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ | Kind | Length | ExID | +--------+--------+--------+--------+ | ExID (con't) | option contents... +--------+--------+--------+--- Figure 3 TCP Experimental Option with a 32-bit ExID This mechanism is encouraged for all TCP options that are not yet eligible for assigned codepoints: >> Protocols requiring new TCP option codepoints that are not eligible for assigned values SHOULD use the existing TCP experimental option codepoints (253, 254) with ExIDs as described in this document. This mechanism is encouraged for all TCP options using the current experimental codepoints in controlled environments: >> All protocols using the TCP experimental option codepoints (253, 254), even those deployed in controlled environments, SHOULD use ExIDs as described in this document. This mechanism is required for all TCP options using the current experimental codepoints that are publicly deployed, whether enabled by default or not: >> All protocols using the TCP experimental option codepoints (253, 254) that are deployed outside controlled environments, such as in the public Internet, MUST use ExIDs as described in this document. Once a TCP option uses the mechanism in this document, registration of the ExID with IANA is required: Touch Expires September 1, 2013 [Page 5] Internet-Draft Shared Use of Experimental TCP Options March 2013 >> All protocols using ExIDs as described in this document MUST register those ExIDs with IANA. 3.1. Selecting an ExID ExIDs are selected at design time, when the protocol designer first implements or specifies the experimental option. ExIDs can be either 16-bits or 32-bits. In both cases, the value is stored in the header in network-standard (big-endian) byte order. ExIDs combine properties of IANA registered codepoints with "magic numbers". >> All ExIDs MUST be either 16-bits or 32-bits long. Use of the ExID, whether 16-bit or 32-bit, helps reduce the probability of a false positive collision with those who either do not register their experiment or who do not implement this mechanism. ExIDs are registered with IANA using "first-come, first-served" priority based on the first two bytes. Those two bytes are thus sufficient to interpret which experimental option is contained in the option field. >> All ExIDs MUST be unique based on their first 16 bits. The second two bytes serve as a "magic number". A magic number is a self-selected codepoint whose primary value is its unlikely collision with values selected by others. Magic numbers are used in other protocols, e.g., BOOTP [RFC951] and DHCP [RFC2131]. Using the additional magic number bytes helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non-experiment) TCP option codepoint is assigned. Use of the same alignment reduces the potential for implementation errors, especially in using the same word-alignment padding, if the same software is later modified to use a conventional codepoint. Use of the longer, 32-bit ExID further decreases the probability of such a false positive compared to those using shorter, 16-bit ExIDs. Use of the ExID does consume TCP option space but enables concurrent use of the experimental codepoints and provides protection against false positives, leaving less space for other options (including other experiments). Use of the longer, 32-bit ExID consumes more space, but provides more protection against false positives. Touch Expires September 1, 2013 [Page 6] Internet-Draft Shared Use of Experimental TCP Options March 2013 3.2. Impact on TCP Option Processing The ExID number is considered part of the TCP option, not the TCP option header. The presence of the ExID increases the effective option Length field by the size of the ExID. The presence of this ExID is thus transparent to implementations that do not support TCP options where it is used. During TCP processing, ExIDs in experimental options are matched against the ExIDs for each implemented protocol. The remainder of the option is specified by the particular experimental protocol. >> Experimental options that have ExIDs that do not match implemented protocols MUST be ignored. The ExID mechanism must be coordinated during connection establishment, just as with any TCP option. >> TCP ExID, if used in any TCP segment of a connection, MUST be present in TCP SYN segments of that connection. >> TCP experimental option ExIDS, if used in any TCP segment of a connection, SHOULD be used in all TCP segments of that connection in which any experimental option is present. Use of an ExID uses additional space in the TCP header and requires additional protocol processing by experimental protocols. Because these are experiments, neither consideration is a substantial impediment; a finalized protocol can avoid both issues with the assignment of a dedicated option codepoint later. 4. Reducing the Impact of False Positives False positives occur where the ExID of one experiment matches the value of an option that does not use ExIDs or if two experiments select the same ExID. Such collisions can cause an option to be interpreted by the incorrect processing routine. Use of checksums or signatures may help an experiment use the shorter ExID while reducing the corresponding increased potential for false positives. >> Experiments that are not robust to ExID false positives SHOULD implement other detection measures, such as checksums or minimal digital signatures over the experimental options they support. Touch Expires September 1, 2013 [Page 7] Internet-Draft Shared Use of Experimental TCP Options March 2013 5. Migration to Assigned Options Some experiments may transition from experiment, and become eligible for an assigned TCP option codepoint. This document does not recommend a specific migration plan to transition from use of the experimental TCP options/ExIDs to use of an assigned codepoint. However, once an assigned codepoint is allocated, use of an ExID represents unnecessary overhead. As a result: >> Once a TCP option codepoint is assigned to a protocol, that protocol SHOULD NOT continue to use an ExID as part of that assigned codepoint. This document does not recommend whether or how an implementation of an assigned codepoint can be backward-compatible with use of the experimental codepoint/ExID. However, some implementers may be tempted to include both the experimental and assigned codepoint in the same segment, e.g., in a SYN to support backward-compatibility during connection establishment. This is a poor use limited resources and so to ensure conservation of the TCP option space: >> A TCP segment MUST NOT contain both an assigned TCP option codepoint and a TCP experimental option codepoint for the same protocol. Instead, a TCP that intends backward compatibility might send multiple SYNs with alternates of the same option and discard all but the most desired successful connection. Although this approach may resolve more slowly or require additional effort at the endpoints, it is preferable to excessively consuming TCP option space. 6. Rationale The ExIDs described in this document combine properties of IANA first-come/first-served (FCFS) registered values with magic numbers. Although IANA FCFS registries are common, so too are those who either fail to register or who 'squat' by deliberately using codepoints that are assigned to others. The approach in this document is intended to recognize this reality and be more robust to its consequences than would be a conventional IANA FCFS registry. Existing ID spaces were considered as ExIDs in the development of this mechanism, including IEEE Organizationally Unique Identifier Touch Expires September 1, 2013 [Page 8] Internet-Draft Shared Use of Experimental TCP Options March 2013 (OUI) and IANA Private Enterprise Numbers (PENs) [802] [OUI] [RFC1065]. OUIs are 24-bit identifiers that are combined with 24 to 40-bits of privately-assigned space to create identifiers that commonly assigned to a unique piece of hardware. OUIs are already longer than the smaller ExID value, and obtaining an OUI is costly (currently $1,885.00 USD). An OUI could be obtained for each experiment, but this could be considered expensive. An OUI already assigned to an organization could be shared if extended (to support multiple experiments within an organization), but this would either require coordination within an organization or an IANA registry; the former is prohibitive, and the latter is more complicated than to have IANA manage the entire space. PENs were originally used in SNMP [RFC1157]. PENs are identifiers that can be obtained without cost from IANA [PEN]. Despite the current registry, the size of the PEN assignment space is currently undefined, and has only recently been proposed (as 32-bits) [Li12]. PENs are currently assigned to organizations, and there is no current process for assigning them to individuals. Finally, if 32- bits as expected, they would be larger than needed in many cases. 7. Security Considerations The mechanism described in this document is not intended to provide (nor does it weaken existing) security for TCP option processing. 8. IANA Considerations This document calls for IANA to create a new TCP experimental option Experiment Identifier (ExID) registry. The registry records both 16- bit and 32-bit ExIDs, as well as a name and e-mail contact for each entry. Entries are assigned on a First-Come, First-Served (FCFS) basis [RFC5226]. The registry operates FCFS on the first two bytes of the ExID (in network-standard order) but records the entire ExID (in network-standard order). Some examples are: o 0x12340000 collides with a previous registration of 0x1234abcd o 0x5678 collides with a previous registration of 0x56780123 o 0xabcd1234 collides it a previous registration of 0xabcd Touch Expires September 1, 2013 [Page 9] Internet-Draft Shared Use of Experimental TCP Options March 2013 IANA will advise applicants of duplicate entries to select an alternate value, as per typical FCFS processing. IANA will record known duplicate uses to assist the community in both debugging assigned uses as well as correcting unauthorized duplicate uses. IANA should impose no requirements on making a registration other than indicating the desired codepoint and providing a point of contact. A short description or acronym for the use is desired, but should not be required. 9. References 9.1. Normative References [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, Sep. 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, Nov. 2006. 9.2. Informative References [802] "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802-2001, 8 March 2002. [Bi11] Bittau, A., D. Boneh, M. Hamburg, M. Handley, D. Mazieres, Q. Slack, "Cryptographic protection of TCP Streams (tcpcrypt)", work in progress, draft-bittau-tcp-crypt-03, Sep. 3, 2012. [Ed11] Eddy, W., "Additional TCP Experimental-Use Options", work in progress, draft-eddy-tcpm-addl-exp-options-00, Aug. 16, 2011. [IANA] IANA web pages, http://www.iana.org/ [Li12] Liang, P., A. Melnikov, "Private Enterprise Number (PEN) practices and Internet Assigned Numbers: Authority (IANA) considerations for registration procedures", draft-liang- iana-pen-01, (work in progress), June 2012. Touch Expires September 1, 2013 [Page 10] Internet-Draft Shared Use of Experimental TCP Options March 2013 [OUI] IEEE OUI registry, http://standards.ieee.org/develop/regauth/oui/ [PEN] IANA Private Enterprise Numbers, http://www.iana.org/assignments/enterprise-numbers [RFC951] Croft, B., J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 951, Sept. 1985. [RFC1065] Rose, M., K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, August 1988. [RFC1157] Case, J., M. Fedor, M. Schoffstall, J. Davin, "A Simple Network Management Protocol (SNMP)", RFC 1157, May 1990. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, Oct. 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar. 1997. [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, Mar. 2000. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, Jan. 2004. [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, Jan. 2011. [Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets Application Program Interface (API)", work in progress, draft-simpson-tcpct-api-04, Apr. 7, 2011. 10. Acknowledgments This document was motivated by discussions on the IETF TCPM mailing list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi Sarolathi, and Michael Scharf provided detailed feedback. This document was prepared using 2-Word-v2.0.template.dot. Touch Expires September 1, 2013 [Page 11] Internet-Draft Shared Use of Experimental TCP Options March 2013 Authors' Addresses Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A. Phone: +1 (310) 448-9151 Email: touch@isi.edu Touch Expires September 1, 2013 [Page 12] --------------030606080702050500050004-- From Karen.Nielsen@tieto.com Tue Mar 5 05:19:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24221F8654 for ; Tue, 5 Mar 2013 05:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4JZsEZTbiUc for ; Tue, 5 Mar 2013 05:19:18 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9814021F8648 for ; Tue, 5 Mar 2013 05:19:17 -0800 (PST) X-AuditID: 83cfa826-b7f386d000004d8b-bb-5135f0d4d9c9 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 08.A7.19851.4D0F5315; Tue, 5 Mar 2013 15:19:16 +0200 (EET) Received: from EXMB03.eu.tieto.com ([169.254.1.113]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 5 Mar 2013 15:19:15 +0200 From: To: , Date: Tue, 5 Mar 2013 15:19:14 +0200 Thread-Topic: Increasing Initial CWND and CWND setting after fast recovery Thread-Index: Ac4ZpAgD72VLHAdbTp6QJtZzmPAWEQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B25F0230139EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsXSfL5DS/fKB9NAg4Ndohbnz11itdh2cj6T A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgynh4ey9TwVezivM77zI3MO436GLk5JAQMJF4 9ug2K4QtJnHh3nq2LkYuDiGBlYwSpyZMYIVwJjNKrHv2jRGkik1AXmLu3lXsILaIgI7EhF+9 YHEWARWJnT+OsoDYwgKuEqdfXWSFqPGS2NzQxwhh60lc+j4TrJdXwEfi+cnlTCA2I9Dm76fW gNnMAuISt57MZ4K4SEBiyZ7zzBC2qMTLx/9YIepFJe60r2eEqM+XOLvmOhPETEGJkzOfsExg FJqFZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYz8qUlJBmZ6JZmpJfl6 yfm5mxjBsbFCbQfjswdShxgFOBiVeHgjjpsECrEmlhVX5h5ilORgUhLlFXlkGijEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhHf+e6Acb0piZVVqUT5MSpqDRUmc9+kcg0AhgfTEktTs1NSC1CKY rAwHh5IEb/U7oEbBotT01Iq0zJwShDQTByfIcB6g4XNBaniLCxJzizPTIfKnGBWlxHl3gyQE QBIZpXlwvbDU9YpRHOgVYd4WkCoeYNqD634FNJgJaLBHqAnI4JJEhJRUA6Nq7M47yTGPJswu /973XobRlWl+/7pdEfHcnxKflfS/DzZ7vS6J78LU1xkVr+0Y3duOTu2ZKd8jeuzZdJnUPY+c 5AymWLh1nVikKjrfv/H/PjVekana274L9e1v1F2ocL/2wb+JVXwXCiwj1Vr2TF4W5Xnn3/rd 5YuCDlptTjVSjL53qXZr9RMlluKMREMt5qLiRADRSOM/OAMAAA== Subject: [tcpm] Increasing Initial CWND and CWND setting after fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2013 13:19:19 -0000 --_000_CF340E42AED0874C81947E18863DE77B25F0230139EXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC5681 following RFC3390 increased the initial window of TCP to 4MTU/MSS, = but left the loss window after Fast Recovery by bounded only by 2MTU from below, by formula (4) of RFC5681. I.e., ssthre= ss =3D MAX (flightsize/2, 2MSS) SCTP, from RFC2960 to RFC4960, however led the increase of the IW from 2 MT= U to 4 MTU by RFC3390 impact also the loss window after Fast Recovery, by setting ssthresh=3D MAX(cwnd/2, 4MTU). (This increase may have been partly unfounded (?), nevertheless it was done= with this motivation, e.g. see RFC4460) draft-ietf-tcmp-initcwnd-08.txt mentions that the increase of the IW does N= OT apply to the loss window after retransmit timeout, but it is otherwise silent about the window after Fast Recovery. For the sake o= f TCP alone, but also in light of the different paths taken by TCP and SCTP after RFC3390, then I wonder if it would not be beneficiary to clarify that= the proposed increase also does NOT apply for the loss window after Fast R= ecovery. If, on the contrary, the proposed increase of the windows MAY apply also to= the loss window after Fast Recovery, presumably with the disclaimer that it must not increase the CWND as it is said for the restart= window, then I would very much appreciate such clarification. I hope that you can help clarify the issue. Thanks. BR, Karen Nielsen --_000_CF340E42AED0874C81947E18863DE77B25F0230139EXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=

 

RFC5681 following RFC33= 90 increased the initial window of TCP to 4MTU/MSS, but left the loss windo= w after Fast Recovery

by bounded only by 2= MTU from below, by formula (4) of RFC5681. I.e., ssthress =3D MAX (flightsi= ze/2, 2MSS)

 

SCTP, from RFC2960 to RFC4960, however led the increase of the IW= from 2 MTU to 4 MTU by RFC3390 impact also the loss window after Fast Reco= very,

by setting ssthresh=3D MAX(cwnd/2, 4= MTU).

(This increase may have been partly = unfounded (?), nevertheless it was done with this motivation, e.g. see RFC4= 460)

 

draft-ietf-tcmp-initcwnd-08.txt mentions that the increase of the IW do= es NOT apply to the loss window after retransmit timeout, but

it is otherwise silent about the window after Fast Reco= very. For the sake of TCP alone, but also in light of the different paths t= aken by TCP and SCTP

after RFC3390, then = I wonder if it would not be beneficiary to clarify that the proposed increa= se also does NOT apply for the loss window after Fast Recovery.<= /span>

 

If, on the co= ntrary, the proposed increase of the windows MAY apply also to the loss win= dow after Fast Recovery, presumably with the

disclaimer that it must not increase the CWND as it is said for the res= tart window, then I would very much appreciate such clarification.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I hope tha= t you can help clarify the issue.

Thanks.<= o:p>

 

BR= , Karen Nielsen

= --_000_CF340E42AED0874C81947E18863DE77B25F0230139EXMB03eutieto_-- From mallman@icir.org Tue Mar 5 05:50:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25AC21F88E5 for ; Tue, 5 Mar 2013 05:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mars7AosKxoL for ; Tue, 5 Mar 2013 05:50:24 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9051921F87E7 for ; Tue, 5 Mar 2013 05:50:24 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r25DoL3B003933; Tue, 5 Mar 2013 05:50:21 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AED03AA45EE; Tue, 5 Mar 2013 08:50:21 -0500 (EST) To: Karen.Nielsen@tieto.com From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Self Esteem X-URL-0: http://www.icir.org/mallman-files/Document75870.jpg X-URL-1: http://www.icir.org/mallman-files/Document63385.xls X-URL-2: http://www.icir.org/mallman-files/Document69496.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma63515-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 05 Mar 2013 08:50:21 -0500 Sender: mallman@icir.org Message-Id: <20130305135021.AED03AA45EE@lawyers.icir.org> Cc: tcpm@ietf.org, mattmathis@google.com Subject: Re: [tcpm] Increasing Initial CWND and CWND setting after fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 13:50:25 -0000 ----------ma63515-1 Content-Type: text/plain Content-Disposition: inline You are conflating the "loss window" and the ssthresh setting. I.e.: > RFC5681 following RFC3390 increased the initial window of TCP to > 4MTU/MSS, but left the loss window after Fast Recovery > by bounded only by 2MTU from below, by formula (4) of RFC5681. I.e., > ssthress = MAX (flightsize/2, 2MSS) this is incorrect. This is setting **ssthresh** not the **loss window**. At this point the congestion window (called the "loss window" at this instant) is set to 1 MSS. The loss window (i.e., what the cwnd is set to after an RTO) almost has to be 1 MSS. At least we need some way to get down to a minimum congestion window---which would be 1 MSS (I guess we could get all the way down to 1 byte if we wanted, but that seems like splitting hairs). That is the reason the loss window remains at 1 MSS while 3390 allows the initial congestion window (IW) and the restart congestion window (RW) to be larger than 1 MSS. The behavior of ssthresh is independent of cwnd and is not altered in 3390. allman ----------ma63515-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlE1+B0ACgkQWyrrWs4yIs7fuACeJQT7hPszI8DfM5AFJ+ALwsag XPEAnApfvFFzmUJ8Tch50F4kfdgenS/F =m1WI -----END PGP SIGNATURE----- ----------ma63515-1-- From Karen.Nielsen@tieto.com Tue Mar 5 05:59:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790A621F871D for ; Tue, 5 Mar 2013 05:59:25 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lYyT5cWz0iO for ; Tue, 5 Mar 2013 05:59:25 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 80B6B21F8653 for ; Tue, 5 Mar 2013 05:59:24 -0800 (PST) X-AuditID: 83cfa826-b7f386d000004d8b-35-5135fa3b7d92 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb06.tieto.com (SMTP Mailer) with SMTP id CE.1C.19851.B3AF5315; Tue, 5 Mar 2013 15:59:23 +0200 (EET) Received: from EXMB03.eu.tieto.com ([169.254.1.113]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 5 Mar 2013 15:59:23 +0200 From: To: Date: Tue, 5 Mar 2013 15:59:21 +0200 Thread-Topic: [tcpm] Increasing Initial CWND and CWND setting after fast recovery Thread-Index: Ac4ZqGXc6BKhgc64QLaZlbjBa1HHmQAAD37Q Message-ID: References: <20130305135021.AED03AA45EE@lawyers.icir.org> In-Reply-To: <20130305135021.AED03AA45EE@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXSfL5DS9f6l2mgwcZ/chbT1kxjsjh/7hKr xbaT85kcmD0WbCr1+HfoJrPHkiU/mQKYo7hsUlJzMstSi/TtErgyzp76y1ywmL+id8IPlgbG fp4uRg4OCQETiZbvYV2MnECmmMSFe+vZuhi5OIQEVjJKXH16ixkkISQwmVFicnMyiM0mIC8x d+8qdpBeEaCGOZM4QExmAR2Jny9CQSpYBFQkfi7oB+sUFgiWaLl0GMwWEQiRWP1gFxOEbSRx Y8kKVpBWXgEfiUtTHCEW1Ur8WrKWCSTMKWAlcXQ1WDUj0J7vp9aA2cwC4hK3nsxngjhYQGLJ nvPMELaoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4Wuwel4BQYmTM5+wTGAUm4Vk7Cwk LbOQtMxC0rKAkWUVI39qUpKBmV5JZmpJvl5yfu4mRnDsrFDbwfjsgdQhRgEORiUe3ojjJoFC rIllxZW5hxglOZiURHlFHpkGCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhDf0AlONNSaysSi3K h0lJc7AoifM+nWMQKCSQnliSmp2aWpBaBJOV4eBQkuDl+wnUKFiUmp5akZaZU4KQZuLgBBnO AzRcD6SGt7ggMbc4Mx0if4pRUUqclwckIQCSyCjNg+uFpbZXjOJArwjzioFU8QDTIlz3K6DB TECDPUJNQAaXJCKkpBoYI9w3nHL1Fc2azVk0salsiXrvx0SBfRl7RLVubxat/3uyI5A97Nv1 13Z1DnIRe6dlTXtZ+Dap9vf8U2Exkq6XNZduPXE/rN/vU9yufWyvRbMknx0+x3x4vZFFQrrP ZCMJkU2BXpXSrmvbgg+cqXNwfOR70qmmcaL+wXm6ESttjyz5c/peX4S/EktxRqKhFnNRcSIA VRws/EgDAAA= Cc: tcpm@ietf.org, mattmathis@google.com Subject: Re: [tcpm] Increasing Initial CWND and CWND setting after fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2013 13:59:25 -0000 Hi, Thanks. I am sorry for using the term loss window in connection with fast retransmi= ssion as this seems to cause confusion. I am not speaking about the CWND setting after RTO retransmission. I agree = that the loss window after an RTO is 1 MTU. I am speaking about the resulting CWND after a fast recovery process where = packet loss is repaired using fast retransmission.=20 The CWND after loss recovery is governed by the set of ssthresh by formula = (4) of RFC5681 to MAX (flightsize/2, 2MSS) as=20 CWND=3Dssthresh is performed as part for the recovery process. Or where did I go wrong ? BR, Karen -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org]=20 Sent: 5. marts 2013 14:50 To: Nielsen Karen Cc: tcpm@ietf.org; mattmathis@google.com Subject: Re: [tcpm] Increasing Initial CWND and CWND setting after fast rec= overy=20 You are conflating the "loss window" and the ssthresh setting. I.e.: > RFC5681 following RFC3390 increased the initial window of TCP to=20 > 4MTU/MSS, but left the loss window after Fast Recovery by bounded only=20 > by 2MTU from below, by formula (4) of RFC5681. I.e., ssthress =3D MAX=20 > (flightsize/2, 2MSS) this is incorrect. This is setting **ssthresh** not the **loss window**. = At this point the congestion window (called the "loss window" at this instant) is set to 1 MSS. The loss window (i.e., what the cwnd is set to after an RTO) almost has to = be 1 MSS. At least we need some way to get down to a minimum congestion wi= ndow---which would be 1 MSS (I guess we could get all the way down to 1 byt= e if we wanted, but that seems like splitting hairs). That is the reason the loss window remains at 1 MSS while 3390 allows the i= nitial congestion window (IW) and the restart congestion window (RW) to be larger than 1 MSS. The behavior of ssthresh is independent of c= wnd and is not altered in 3390. allman From Karen.Nielsen@tieto.com Wed Mar 6 00:56:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E970D21F8868 for ; Wed, 6 Mar 2013 00:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHv9XsJXP5rr for ; Wed, 6 Mar 2013 00:56:30 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by ietfa.amsl.com (Postfix) with ESMTP id 187CC21F8555 for ; Wed, 6 Mar 2013 00:56:29 -0800 (PST) X-AuditID: 83cfa826-b7f386d000004d8b-4a-513704b93585 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 51.F2.19851.9B407315; Wed, 6 Mar 2013 10:56:25 +0200 (EET) Received: from EXMB03.eu.tieto.com ([169.254.1.113]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Wed, 6 Mar 2013 10:56:24 +0200 From: To: Date: Wed, 6 Mar 2013 10:56:23 +0200 Thread-Topic: [tcpm] Increasing Initial CWND and CWND setting after fast recovery Thread-Index: Ac4ZqGXc6BKhgc64QLaZlbjBa1HHmQAnvkVg Message-ID: References: <20130305135021.AED03AA45EE@lawyers.icir.org> In-Reply-To: <20130305135021.AED03AA45EE@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXSfL5DSXcni3mgwYEVihbT1kxjsth2cj6T A5PHv0M3mT2WLPnJFMAUxWWTkpqTWZZapG+XwJXR/a6XqWAxa8Xjm9OYGhg7WboYOTgkBEwk Lj3k6mLkBDLFJC7cW8/WxcjFISSwklGi4esyKGcyo8SD3ScYQarYBOQl5u5dxQ7SLALUMWcS B0iYWUBYYtHpXlYQm0VAReJ4x2E2EFtYIFii5dJhZhBbRCBEYvWDXUwQtpHElckdYDavgI/E 7E/NYPVCArUSv5asZQIZzylgJXF0NVgJI9Cm76fWMEGsEpe49WQ+E8TNAhJL9pxnhrBFJV4+ /scKUS8qcad9PSNEvY7Egt2f2CBsbYllC18zQ6wVlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYx8qcmJRmY6ZVkppbk6yXn525iBMfLCrUdjM8eSB1iFOBgVOLhtVAyCxRiTSwrrsw9xCjJ waQkyuvEZB4oxJeUn1KZkVicEV9UmpNafIhRgoNZSYSX6wxQOW9KYmVValE+TEqag0VJnPfp HINAIYH0xJLU7NTUgtQimKwMB4eSBO93kKGCRanpqRVpmTklCGkmDk6Q4TxAw0WYgWp4iwsS c4sz0yHypxgVpYBGMwAlBEASGaV5cL2wdPaKURzoFWFeWZB2HmAqhOt+BTSYCWiwR6gJyOCS RISUVAOj4KnipKp1i+/1MS3PDeg8l1j8luustdSMnSethdZM0Yq9+GYu/6WjGZ5uv/iYH3Ym Ncbq6jn0P/4tpHk6QkHAin3JmznfXp3pjX6ZvX3Cx//LHe0nsdVqrd0ydfkh++t7Zy2sWGrD VL3a6ET0uv3qd4M+eKxMjt1/6c/OjPZVE6zn7im/8eu3nhJLcUaioRZzUXEiAJMfTNxCAwAA Cc: tcpm@ietf.org Subject: Re: [tcpm] Increasing Initial CWND and CWND setting after fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 08:56:31 -0000 Hi, >The behavior of ssthresh is independent of cwnd and is not altered in 3390= . The behavior of CWND after Fast Recovery RFC5681 is not independent of ssth= resh or at least both are controlled by the formula (4) ssthresh =3D max (FlightSize / 2, 2*SMSS) I wonder if one, as for the restart window, would say that an implementatio= n when Loss Recovery completes MAY set: CWND =3D max (prior FlightSize / 2, 10*SMSS) if this does not increase the = CWND compared to what is was when the loss was detected. BUT if one should NOT do anything of the sort, then I think that it would b= eneficiary for this to be clarified. BR, Karen >allman From michael.scharf@alcatel-lucent.com Wed Mar 6 07:04:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B041D21F8A25 for ; Wed, 6 Mar 2013 07:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.366 X-Spam-Level: X-Spam-Status: No, score=-9.366 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AL9tNrTg6iU for ; Wed, 6 Mar 2013 07:04:09 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5021F89E2 for ; Wed, 6 Mar 2013 07:04:09 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26F3Rav026915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 16:04:06 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 6 Mar 2013 16:03:41 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "tcpm (tcpm@ietf.org)" Date: Wed, 6 Mar 2013 16:03:40 +0100 Thread-Topic: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt Thread-Index: AQHOCgRuOFN715fmA0Si5G36KS1/CZh39XFQgCCgV8A= Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6B2F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20130213160856.6352.31413.idtracker@ietfa.amsl.com> <012C3117EDDB3C4781FD802A8C27DD4F249F8C28@SACEXCMBX06-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F249F8C28@SACEXCMBX06-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 15:04:10 -0000 All, Since this document really needs feeback/review, please find attached three= comments from my side (as individual contributor): * Section 1.3 1323bis states: Therefore, for each of the extensions defined below, it is recommended that TCP options will be sent on non-SYN segments only after an exchange of options on the SYN segments has indicated that both sides understand the extension. The original statement in 1323 is: Therefore, for each of the extensions defined below, TCP options will be sent on non-SYN segments only when an exchange of options on the SYN segments has indicated that both sides understand the extension. We discussed in the past quite a bit about late enablement of the timesta= mps option, and I think that the outcome was to be conservative, as also=20 explained in that section in 1323bis. However, reading this new text now again, I wonder if Section 1.3 should = distinguish between timestamp and window scale option. Window scale options in non-SY= Ns are not allowed by Section 3.1 ("This option is sent only in a SYN segment"), i. = e., the statement in Section 1.3 did not really apply even in the original 1323 t= ext. But with the text change in 1323bis, we could maybe fix this. * Word "new": 1323bis uses at various places the term "new" option from the original 13= 23 text (e. g., "The scale factor is carried in a new TCP option, Window Scale."). I am n= ot sure about the general IETF handling for -bis documents, but given that 1323 options are= very widely deployed, I could imagine removing the word "new" where applicable. * Appendix G Editorial nit: I think that the list of changes compared to 1323 could b= e sorted somehow (e. g. by increasing number of the section where the change occured, or by protocol vs. edito= rial changes...). Thanks Michael =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Scheffenegger, Richard > Sent: Wednesday, February 13, 2013 5:26 PM > To: tcpm (tcpm@ietf.org) > Cc: Alexander Zimmermann (zimmermann@nets.rwth-aachen.de);=20 > david.borman@quantum.com; braden@isi.edu; Matthew Mathis=20 > (mattmathis@google.com); van@packetdesign.com > Subject: Re: [tcpm] New Version Notification for=20 > draft-ietf-tcpm-1323bis-05.txt >=20 > Hi, >=20 > I have updated the draft with the comments from the last IETF=20 > (mainly trimmed much of the historic discussions and=20 > rationale in the introduction section, leaving alone the=20 > detailed discussions and implementers guidelines in the later=20 > sections describing the options and mechanisms, after the=20 > comments from Matt). >=20 > So, it really isn't that much shorter overall, but there is=20 > less text to read before the real technical content starts. >=20 > As this is a WG item, there'll probably be a short slot in=20 > the next TCPM to get live feedback too! >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >=20 >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Mittwoch, 13. Februar 2013 17:09 > > To: Scheffenegger, Richard > > Cc: braden@isi.edu; david.borman@quantum.com; van@packetdesign.com > > Subject: New Version Notification for draft-ietf-tcpm-1323bis-05.txt > >=20 > >=20 > > A new version of I-D, draft-ietf-tcpm-1323bis-05.txt has been=20 > > successfully submitted by Richard Scheffenegger and posted=20 > to the IETF repository. > >=20 > > Filename: draft-ietf-tcpm-1323bis > > Revision: 05 > > Title: TCP Extensions for High Performance > > Creation date: 2013-02-13 > > Group: tcpm > > Number of pages: 43 > > URL: =20 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm- > > 1323bis-05.txt > > Status: =20 > http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis > > Htmlized: =20 > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-05 > > Diff: =20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis- > > 05 > >=20 > > Abstract: > > This document specifies a set of TCP extensions to improve > > performance over paths with a large bandwidth*delay=20 > product and to > > provide reliable operation over very high-speed paths. =20 > It defines > > TCP options for scaled windows and timestamps. The=20 > timestamps are > > used for two distinct mechanisms, RTTM (Round Trip Time=20 > Measurement) > > and PAWS (Protection Against Wrapped Sequences). > >=20 > > This document updates and obsoletes RFC 1323. > >=20 > >=20 > >=20 > >=20 > > The IETF Secretariat >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From rs@netapp.com Wed Mar 6 08:13:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C921F8A89 for ; Wed, 6 Mar 2013 08:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIy4-4+SEd7c for ; Wed, 6 Mar 2013 08:13:44 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 893B721F87C4 for ; Wed, 6 Mar 2013 08:13:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,795,1355126400"; d="scan'208";a="28492890" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 06 Mar 2013 08:13:41 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r26GDegw018224; Wed, 6 Mar 2013 08:13:41 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.57]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 08:13:40 -0800 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm (tcpm@ietf.org)" Thread-Topic: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt Thread-Index: Ac4ahYBDH20he0orQ9+MlrwwEcGy8Q== Date: Wed, 6 Mar 2013 16:13:39 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A497A2@SACEXCMBX02-PRD.hq.netapp.com> 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 Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 16:13:45 -0000 Hello Michael, thank you for your comments. Re Section 1.3, as the next paragraph already talks specifically about the = timestamp option, making the distinction clear sounds good. I believe that = part of text originated when the RFC was also including the SACK option (wh= ich was split off). How about this wording: : The window scale option negotiates fundamental parameters of the TCP session. Therefore, it is only sent during the initial handshake. Furthermore, the window scale option will be sent in a segment only if the corresponding option was received in the initial segment. The timestamps option may appear in any data or ACK segment, adding 12 bytes to the 20-byte TCP header. It is recommended that this TCP option will be sent on non-SYN segments only after an exchange of options on the SYN segments has indicated that both sides understand the extension. ... : =09 Re: "new" option - caught a few instances (but only scanned for "new").=20 Re: Appendix G:=20 At least the section appended by me is kept in chronological order of the = changes. I think the last editor (David) also appended in chronological ord= er. Sorting them would probably break this ordering, but if the body of the= text is found to be finished, I can follow up on this. Until that time, I = believe a chronological order is easier to maintain... Best regards, Richard Scheffenegger > -----Original Message----- > From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com= ] > Sent: Mittwoch, 06. M=E4rz 2013 16:04 > To: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > Subject: RE: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis- > 05.txt >=20 > All, >=20 > Since this document really needs feeback/review, please find attached > three comments from my side (as individual contributor): >=20 > * Section 1.3 >=20 > 1323bis states: >=20 > Therefore, for each of the extensions defined below, it is recommended > that TCP options will be sent on non-SYN segments only after an > exchange > of options on the SYN segments has indicated that both sides understan= d > the extension. >=20 > The original statement in 1323 is: >=20 > Therefore, for each of the extensions defined below, TCP options will > be > sent on non-SYN segments only when an exchange of options on the SYN > segments has indicated that both sides understand the extension. >=20 > We discussed in the past quite a bit about late enablement of the > timestamps > option, and I think that the outcome was to be conservative, as also > explained in that section in 1323bis. >=20 > However, reading this new text now again, I wonder if Section 1.3 shoul= d > distinguish > between timestamp and window scale option. Window scale options in non- > SYNs are not > allowed by Section 3.1 ("This option is sent only in a SYN segment"), i= . > e., the > statement in Section 1.3 did not really apply even in the original 1323 > text. > But with the text change in 1323bis, we could maybe fix this. >=20 > * Word "new": >=20 > 1323bis uses at various places the term "new" option from the original > 1323 text (e. g., > "The scale factor is carried in a new TCP option, Window Scale."). I am > not sure about the > general IETF handling for -bis documents, but given that 1323 options > are very widely deployed, I > could imagine removing the word "new" where applicable. >=20 > * Appendix G >=20 > Editorial nit: I think that the list of changes compared to 1323 could > be sorted somehow (e. g. by increasing > number of the section where the change occured, or by protocol vs. > editorial changes...). >=20 > Thanks >=20 > Michael >=20 >=20 >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > > Of Scheffenegger, Richard > > Sent: Wednesday, February 13, 2013 5:26 PM > > To: tcpm (tcpm@ietf.org) > > Cc: Alexander Zimmermann (zimmermann@nets.rwth-aachen.de); > > david.borman@quantum.com; braden@isi.edu; Matthew Mathis > > (mattmathis@google.com); van@packetdesign.com > > Subject: Re: [tcpm] New Version Notification for > > draft-ietf-tcpm-1323bis-05.txt > > > > Hi, > > > > I have updated the draft with the comments from the last IETF (mainly > > trimmed much of the historic discussions and rationale in the > > introduction section, leaving alone the detailed discussions and > > implementers guidelines in the later sections describing the options > > and mechanisms, after the comments from Matt). > > > > So, it really isn't that much shorter overall, but there is less text > > to read before the real technical content starts. > > > > As this is a WG item, there'll probably be a short slot in the next > > TCPM to get live feedback too! > > > > Best regards, > > > > Richard Scheffenegger > > > > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Mittwoch, 13. Februar 2013 17:09 > > > To: Scheffenegger, Richard > > > Cc: braden@isi.edu; david.borman@quantum.com; van@packetdesign.com > > > Subject: New Version Notification for draft-ietf-tcpm-1323bis-05.txt > > > > > > > > > A new version of I-D, draft-ietf-tcpm-1323bis-05.txt has been > > > successfully submitted by Richard Scheffenegger and posted > > to the IETF repository. > > > > > > Filename: draft-ietf-tcpm-1323bis > > > Revision: 05 > > > Title: TCP Extensions for High Performance > > > Creation date: 2013-02-13 > > > Group: tcpm > > > Number of pages: 43 > > > URL: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm- > > > 1323bis-05.txt > > > Status: > > http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis > > > Htmlized: > > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-05 > > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis- > > > 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 > > > TCP options for scaled windows and timestamps. The > > timestamps are > > > used for two distinct mechanisms, RTTM (Round Trip Time > > Measurement) > > > and PAWS (Protection Against Wrapped Sequences). > > > > > > This document updates and obsoletes RFC 1323. > > > > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > From michael.scharf@alcatel-lucent.com Wed Mar 6 09:19:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BD721F84BB for ; Wed, 6 Mar 2013 09:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+IyNtk9fh8J for ; Wed, 6 Mar 2013 09:19:40 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id E5A3421F861F for ; Wed, 6 Mar 2013 09:19:32 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26HJ3fi024091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 18:19:25 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 6 Mar 2013 18:19:10 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "tcpm (tcpm@ietf.org)" Date: Wed, 6 Mar 2013 18:19:09 +0100 Thread-Topic: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt Thread-Index: Ac4ahYBDH20he0orQ9+MlrwwEcGy8QACBKkw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6B3B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24A497A2@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24A497A2@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 17:19:40 -0000 Hi Richard, > How about this wording: > : > The window scale option negotiates fundamental parameters=20 > of the TCP > session. Therefore, it is only sent during the initial handshake. > Furthermore, the window scale option will be sent in a > segment only if the corresponding option was received in=20 > the initial > segment. >=20 > The timestamps option may appear in any data or ACK segment, adding > 12 bytes to the 20-byte TCP header. It is recommended=20 > that this TCP > option will be sent on non-SYN segments only after an exchange of > options on the SYN segments has indicated that both sides=20 > understand > the extension. ... Yes, I had something along those lines in mind. Also, it is important to no= te here that Section 1 does not use RFC2119 language, while later sections = are normative. This seems reasonable. But maybe others have some thoughts as well? Michael From iesg-secretary@ietf.org Wed Mar 6 12:07:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4FA11E80CC; Wed, 6 Mar 2013 12:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8W-aQpgfvdx; Wed, 6 Mar 2013 12:07:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8197411E80E6; Wed, 6 Mar 2013 12:07:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.41 Message-ID: <20130306200732.2648.46017.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2013 12:07:32 -0800 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'Increasing TCP's Initial Window' to Experimental RFC (draft-ietf-tcpm-initcwnd-08.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2013 20:07:58 -0000 The IESG has approved the following document: - 'Increasing TCP's Initial Window' (draft-ietf-tcpm-initcwnd-08.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ Technical Summary: This document describes an experimental proposal to increase initial congestion window of TCP to at most 10 segments as well as a fall-back mechanism to limit any negative effects in limited buffer or bandwidth situations. It also provides guidelines to enable/disable this features in addition to some metrics to monitor the effect of this. Working Group Summary: There has been dominant opinions in the WG to increase initial window size of TCP. Question was whether we have a single updated value, or increasing the value gradually with a certain schedule, or defining a mechanics to adjust initial window size over time. We have explored several possibilities and eventually having a single updated value has become the consensus of the WG as other methods have some difficulties for large-scale deployment. Some of the approach in other methods have been merged into the draft during this process. The consensus was clear as no opinion against this proposal has been raised since then. Document Quality: Linux has already incorporated this proposal in the main kernel distribution. This document was reviewed by various people and has been discussed in the WG for nearly three years. The authors have provided results from their extensive experiments with a larger initial window. They also provided data to address questions and concerns by reviewers. In addition, there have been some related experiments by other TCPM contributors, mostly based on simulation. The document has been updated based on feedback from the community. I believe the authors did fairly extensive work for an experimental RFC, even if valid questions are still to be answered. The remaining questions, which need further experiments, are hard to address by the authors alone. Appendix A in the document contains the list for major discussion points of the draft. Personnel: Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Wesley Eddy. RFC Editor Note At the end of the 4th paragraph in section 12, please append: It is recognized that if IW10 is causing harm to other traffic, that this may not be readily apparent to the the software on the hosts using IW10. In some cases a local system or network administrator may be able to detect this, and to selectively disable IW10 in such cases. In the general case, however, since the harm may occur on a remote network, to other cross-traffic, there may be no good way at all for this to be detected or corrected. Current experience and analysis does not indicate whether this is a real issue, beyond a hypothetical one. As use of IW10 becomes more prevalent, monitoring and analysis of flows throughout the network will be needed to assess the impact across the spectrum of scenarios found on the real Internet. From iesg-secretary@ietf.org Wed Mar 6 12:08:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAE111E80E5 for ; Wed, 6 Mar 2013 12:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qefX4ycs4LMe; Wed, 6 Mar 2013 12:07:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9023411E80ED; Wed, 6 Mar 2013 12:07:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.41 X-IETF-Draft-string: draft-ietf-tcpm-initcwnd X-IETF-Draft-revision: 08 Message-ID: <20130306200732.2648.75377.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2013 12:07:32 -0800 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'Increasing TCP's Initial Window' to Experimental RFC (draft-ietf-tcpm-initcwnd-08.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:08:02 -0000 The IESG has approved the following document: - 'Increasing TCP's Initial Window' (draft-ietf-tcpm-initcwnd-08.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ Technical Summary: This document describes an experimental proposal to increase initial congestion window of TCP to at most 10 segments as well as a fall-back mechanism to limit any negative effects in limited buffer or bandwidth situations. It also provides guidelines to enable/disable this features in addition to some metrics to monitor the effect of this. Working Group Summary: There has been dominant opinions in the WG to increase initial window size of TCP. Question was whether we have a single updated value, or increasing the value gradually with a certain schedule, or defining a mechanics to adjust initial window size over time. We have explored several possibilities and eventually having a single updated value has become the consensus of the WG as other methods have some difficulties for large-scale deployment. Some of the approach in other methods have been merged into the draft during this process. The consensus was clear as no opinion against this proposal has been raised since then. Document Quality: Linux has already incorporated this proposal in the main kernel distribution. This document was reviewed by various people and has been discussed in the WG for nearly three years. The authors have provided results from their extensive experiments with a larger initial window. They also provided data to address questions and concerns by reviewers. In addition, there have been some related experiments by other TCPM contributors, mostly based on simulation. The document has been updated based on feedback from the community. I believe the authors did fairly extensive work for an experimental RFC, even if valid questions are still to be answered. The remaining questions, which need further experiments, are hard to address by the authors alone. Appendix A in the document contains the list for major discussion points of the draft. Personnel: Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Wesley Eddy. RFC Editor Note At the end of the 4th paragraph in section 12, please append: It is recognized that if IW10 is causing harm to other traffic, that this may not be readily apparent to the the software on the hosts using IW10. In some cases a local system or network administrator may be able to detect this, and to selectively disable IW10 in such cases. In the general case, however, since the harm may occur on a remote network, to other cross-traffic, there may be no good way at all for this to be detected or corrected. Current experience and analysis does not indicate whether this is a real issue, beyond a hypothetical one. As use of IW10 becomes more prevalent, monitoring and analysis of flows throughout the network will be needed to assess the impact across the spectrum of scenarios found on the real Internet. From michael.scharf@alcatel-lucent.com Thu Mar 7 08:12:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5D121F898A for ; Thu, 7 Mar 2013 08:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.222 X-Spam-Level: X-Spam-Status: No, score=-9.222 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj2eGhLSsF44 for ; Thu, 7 Mar 2013 08:12:35 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0B02121F88F0 for ; Thu, 7 Mar 2013 08:12:29 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r27G92L6005756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Mar 2013 17:12:28 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 7 Mar 2013 17:12:09 +0100 From: "Scharf, Michael (Michael)" To: "tcpm (tcpm@ietf.org)" Date: Thu, 7 Mar 2013 17:12:07 +0100 Thread-Topic: Orlando meeting (slides/agenda/scribes) Thread-Index: Ac4bToPsvbDRmaTARN6Wkfdqhf1ihA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6B73@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Orlando meeting (slides/agenda/scribes) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2013 16:12:35 -0000 Hi all, To all presenters: Please send the slides to the chairs by 6PM on Monday (l= ocal time Orlando). In other words: Don't plan to compile them during the t= echnical plenary ;) The planned TCPM agenda can be found here: https://datatracker.ietf.org/mee= ting/86/agenda/tcpm/ As usual, we need two minute takers and a jabber scribe. We'd appreciate if= volunteers could be found before the meeting. Thanks! Michael From michael.scharf@alcatel-lucent.com Fri Mar 8 00:57:03 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6AA21F8634 for ; Fri, 8 Mar 2013 00:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.307 X-Spam-Level: X-Spam-Status: No, score=-9.307 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myHmmpJGZtRZ for ; Fri, 8 Mar 2013 00:57:03 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B1F9921F8629 for ; Fri, 8 Mar 2013 00:57:02 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r288uYBY020324 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Mar 2013 09:56:59 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 8 Mar 2013 09:56:35 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Fri, 8 Mar 2013 09:56:32 +0100 Thread-Topic: [tcpm] preview of draft-ietf-tcpm-experimental-options-05 Thread-Index: Ac4ZEJQAj4wllLD7T+O86SiEp/SmbACyanVg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6B81@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <5134F8D5.7050503@isi.edu> In-Reply-To: <5134F8D5.7050503@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: Joe Touch Subject: Re: [tcpm] preview of draft-ietf-tcpm-experimental-options-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2013 08:57:03 -0000 Hi all, Just to back what Joe already said: Please have a look at this document, ev= en if it is not officially submitted so far. Also, please let us know any further feedback, preferably before the Orland= o meeting. Thanks Michael (TCPM co-chair)=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Monday, March 04, 2013 8:41 PM > To: tcpm@ietf.org > Subject: [tcpm] preview of draft-ietf-tcpm-experimental-options-05 >=20 > Hi, all, >=20 > Attached is a preview of the 05 update to this doc. >=20 > The update includes the following, all at the request of the IESG: >=20 > - more specific and stronger requirements for using > this mechanism (MUST rather than SHOULD) >=20 > - clarification of the trade-offs in using 16- vs > 32-bit ExIDs >=20 > - clarification of the IANA process for assignment >=20 > Please post if you have a position on these changes. >=20 > Thanks, >=20 > Joe > = From lars@netapp.com Fri Mar 8 02:14:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86021F8628 for ; Fri, 8 Mar 2013 02:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.36 X-Spam-Level: X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI9aFgXAlnqm for ; Fri, 8 Mar 2013 02:14:49 -0800 (PST) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id C037F21F862D for ; Fri, 8 Mar 2013 02:14:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,807,1355126400"; d="scan'208";a="245754892" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 08 Mar 2013 02:14:49 -0800 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r28AEngb025650; Fri, 8 Mar 2013 02:14:49 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Fri, 8 Mar 2013 02:14:49 -0800 From: "Eggert, Lars" To: "tcpm@ietf.org list" Thread-Topic: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK Thread-Index: AQHOG+Od0KlXY7J4d02NvkzE1lwaKw== Date: Fri, 8 Mar 2013 10:14:48 +0000 Message-ID: References: <4371274.S5HZgQNjGG@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <956B3031C4A6B14EBDFCE2A66672E1A9@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tcpm] Fwd: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2013 10:14:54 -0000 Of interest to TCPM as well. Begin forwarded message: > From: Christoph Paasch > Subject: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK > Date: March 8, 2013 10:58:38 GMT+01:00 > To: MultiPath TCP - IETF WG > Reply-To: >=20 > Hello, >=20 > when contacting baidu.com with an MPTCP-enabled host, I get the following= trace [1]: >=20 > 10:38:33.143356 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [SEW]= , seq 2335683601, win 14600, options [mss 1460,sackOK,TS val 1289882 ecr 0,= nop,wscale 7,MPTCP capable csum {0xc3ff03119078160a}], length 0 > 10:38:33.608817 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [S.],= seq 337140084, ack 2335683602, win 14600, options [mss 1380,sackOK,nop,nop= ,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,MPTCP capable csum {0xc3ff= 03119078160a}], length 0 > 10:38:33.608888 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [.], = ack 1, win 14600, options [MPTCP capable csum {0xc3ff03119078160a,0xc3ff031= 19078160a},MPTCP add-addr id 1 130.104.123.102], length 0 > 10:38:33.608966 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [P.],= seq 1:116, ack 1, win 14600, options [MPTCP add-addr id 8 2001:6a8:3080:2:= 21a3:6c82:e826:6625,MPTCP dss ack 2999963583 seq 2999963583 subseq 1 len 11= 5 csum 0x101], length 115 > 10:38:34.075539 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [.], = ack 116, win 5840, length 0 > 10:38:34.081765 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [P.],= seq 1:459, ack 116, win 5840, length 458 >=20 >=20 >=20 > So, baidu.com replies to a SYN+MP_CAPABLE with a SYN/ACK+MP_CAPABLE ! >=20 > What they seem to do is to NOP all the undesired known options and echo t= he unknown ones in the SYN/ACK. (would have been too good to be true that t= hey already support MPTCP ;)) >=20 > The client will think that MPTCP is supported by the server, as the SYN/A= CK has the MP_CAPABLE option. > However, thanks to the fallback described in Section 3.6 of the RFC, the = client will detect that the server actually does not support MPTCP and do a= seamless fallback to regular TCP after it received the first ack without D= ATA-ACK. >=20 >=20 > This shows how important it is that TCP extensions should not only rely o= n the SYN-SYN/ACK exchange to negotiate support for a new TCP option. >=20 >=20 > Cheers, > Christoph >=20 >=20 > [1] I use the modified tcpdump implementation with MPTCP-support: > https://github.com/multipath-tcp/tcpdump >=20 >=20 > --=20 > IP Networking Lab --- http://inl.info.ucl.ac.be > MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be > UCLouvain > -- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From touch@isi.edu Fri Mar 8 07:19:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB2221F84CD for ; Fri, 8 Mar 2013 07:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.344 X-Spam-Level: X-Spam-Status: No, score=-105.344 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWinUlO-vh0m for ; Fri, 8 Mar 2013 07:19:49 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE0B21F84CA for ; Fri, 8 Mar 2013 07:19:48 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r28FJ6Mx014383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Mar 2013 07:19:15 -0800 (PST) Message-ID: <513A016C.7090501@isi.edu> Date: Fri, 08 Mar 2013 07:19:08 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Eggert, Lars" References: <4371274.S5HZgQNjGG@cpaasch-mac> 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: "tcpm@ietf.org list" Subject: Re: [tcpm] Fwd: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2013 15:19:49 -0000 Hi, all, I'll replicate my conclusions on this here: ---- > What they seem to do is to NOP all the undesired known options and > echo the unknown ones in the SYN/ACK. ... That's easy to debug - it's a major error of their stack, and needs to be corrected. There is no reason to address this in mptcp or any other option. > This shows how important it is that TCP extensions should not only > rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP option. I disagree; it shows the impact of an incorrect implementation. "Be generous in what you receive" doesn't include this sort of case. Joe From ananth@nttmcl.com Sat Mar 9 20:21:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2E321F87D3 for ; Sat, 9 Mar 2013 20:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZhdEKaRLYBE for ; Sat, 9 Mar 2013 20:21:00 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 225BA21F87C3 for ; Sat, 9 Mar 2013 20:20:58 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi8so356020wib.13 for ; Sat, 09 Mar 2013 20:20:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=v+J0GBAt0XpvnWm/REd1z4GScFPaC2Uz3yFmNcOv+Tc=; b=n6k0vT9OaUDG0PyiibMHl9O1mOWKDMGQqG85V5Q8quq/y143VypAXNoJN9V5I+Q738 8xtyVyg85Xy1Z2s1zdGIprxUivqKVLnRkmxjt+aNrlg75zHt7/U73eQWhYh89TXPeNtx nrcgIXE+to6JgQGFuYvZ3i+BJTHSfkZ4nbvTeM2s/eS71pHT0XKjpxmqsk6wM3jV2h4n AThUMGSuyuBrMPCA4oPVHaCt4CHg3PVDgAo1PtU/h/NPdRi8MRxqL6yxOZYqjXdYkpB7 Xoh1fGR2ezx8k9JFdfPjghopyosdOYezRQ1Ko8EolvKzwWXNqIY3CqlqgNkN9vidWftK dWfA== MIME-Version: 1.0 X-Received: by 10.194.93.97 with SMTP id ct1mr12155471wjb.48.1362889254725; Sat, 09 Mar 2013 20:20:54 -0800 (PST) Received: by 10.194.221.228 with HTTP; Sat, 9 Mar 2013 20:20:54 -0800 (PST) In-Reply-To: <290E20B455C66743BE178C5C84F124081779FD38E0@EXMB01CMS.surrey.ac.uk> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <290E20B455C66743BE178C5C84F124081779FD38E0@EXMB01CMS.surrey.ac.uk> Date: Sat, 9 Mar 2013 20:20:54 -0800 Message-ID: From: Anantha Ramaiah To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=047d7bf0c332e5858604d78a6182 X-Gm-Message-State: ALoCoQmgjE8zNAesjJN+MTkMTYTjhA5q+v9osR+OBJF3D4DAhZxFzNeSDRqc26IRb0Y1ZQuZ2d6I Cc: tcpm@ietf.org Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 10 Mar 2013 04:21:00 -0000 --047d7bf0c332e5858604d78a6182 Content-Type: text/plain; charset=ISO-8859-1 > > Congestion control is needed when sharing, but when you own and run a > dedicated private link you can simplify and engineer for throughput. Using > Internet technology doesn't mean you're on the shared Internet. > > I share the same thought as above. I believe one could tune TCP based on where you want to run it, but if we go one step further by standardizing this as a general purpose solution, it becomes hard and needs support, take for example quick start, it is a good RFC, but needs support from the middle boxes in the path. Let alone ECN etc., -Anantha --047d7bf0c332e5858604d78a6182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

<Jumping in late>



Congestion control is needed when sharing, but when you own and run a dedic= ated private link you can simplify and engineer for throughput. Using Inter= net technology doesn't mean you're on the shared Internet.


I share the same thought as above. I b= elieve one could tune TCP based on where you want to run it, but if we go o= ne step further by standardizing this =A0as a general purpose solution, =A0= it becomes hard and needs support, take for example quick start, it is a go= od RFC, but needs support from the middle boxes in the path. =A0Let alone E= CN etc., =A0

-Anantha
--047d7bf0c332e5858604d78a6182-- From lastewart@swin.edu.au Sun Mar 10 09:54:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713C521F8816 for ; Sun, 10 Mar 2013 09:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zsF0Ef91erU for ; Sun, 10 Mar 2013 09:54:36 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7F24421F8168 for ; Sun, 10 Mar 2013 09:54:35 -0700 (PDT) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 447A77E84A; Mon, 11 Mar 2013 03:54:34 +1100 (EST) Message-ID: <513CBACA.9080403@swin.edu.au> Date: Mon, 11 Mar 2013 03:54:34 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Nigel Williams , grenville armitage Subject: [tcpm] Multipath TCP for FreeBSD v0.1 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 10 Mar 2013 16:54:39 -0000 Hi all, The CAIA MPTCP team is pleased to announce the initial release of our multipath TCP implementation for FreeBSD 10-CURRENT which is available from [1]. This release contains wire-related protocol code and a lot of core stack infrastructure. It is capable of running regular TCP flows and single or multi-subflow MPTCP flows (with some caveats as documented in the readme [2]). We consider this code to be of alpha quality and plan to release frequent updates going forward as we continue to flesh out additional features and fix the rough edges. That being said, we welcome everyone to start playing with the code and provide feedback, bug reports, fixes, praise and/or abuse ;) The "Multipath TCP for FreeBSD" project team consists of: Nigel Williams: lead R&D engineer Lawrence Stewart: supporting R&D engineer Grenville Armitage: principal investigator & overall project lead Many thanks go to the Cisco University Research Program Fund at Community Foundation Silicon Valley for their support of this work. Have fun with it! Cheers, Lawrence, Nigel & Grenville http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt From iesg-secretary@ietf.org Sun Mar 10 12:47:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D5A1F0C74; Sun, 10 Mar 2013 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgSZDTHEg3bN; Sun, 10 Mar 2013 12:47:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF2F21F8939; Sun, 10 Mar 2013 12:47:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130310194748.24111.99563.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2013 12:47:48 -0700 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'Proportional Rate Reduction for TCP' to Experimental RFC (draft-ietf-tcpm-proportional-rate-reduction-04.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 10 Mar 2013 19:47:56 -0000 The IESG has approved the following document: - 'Proportional Rate Reduction for TCP' (draft-ietf-tcpm-proportional-rate-reduction-04.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/ Technical Summary This document describes an algorithm to improve the accuracy of the amount of data sent by TCP during loss recovery. The existing TCP recovery algorithms can make excess window adjustments in some situations, such as in the presence of heavy losses, and may result in abrupt TCP behavior in the form of packet bursts or increased risk of timeouts. Proportional Rate Reduction aims to minimize the needed window adjustments, to result in more stable TCP congestion control behavior in the presence of losses. Working Group Summary The document was adopted as Experimental TCPM working group item by clear working group consensus, and no opinions against it have been raised during its progress or in the working group last call. Document Quality The algorithm specified in the document has been implemented in Linux and integrated to the main kernel distribution. The algorithm has also been evaluated through measurements, and the evaluation results reported in a paper published in the IMC'11 conference. Different versions of the document have been thoroughly reviewed by TCPM working group members. Personnel Document Shepherd is Pasi Sarolahti . Responsible Area Director is Wesley Eddy . RFC Editor Note (1) Please change the Abstract to: This document describes an experimental Proportional Rate Reduction (PPR) algorithm as an alternative to the widely deployed Fast Recovery and Rate Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments and the actual window size at the end of recovery will be as close as possible to the ssthresh determined by the congestion control algorithm. (2) Please change all occurrences of "PPR" to "PRR". (3) Please change all occurrences of "PRR+SSRB" to "PRR-SSRB" and all occurrences of "PRR+CRB" to "PRR-CRB" (4) On Page 3, please change: "slight difference" to "slight differences" and "discussions algorithms" to "discussions of algorithms" and "of RFC 3517 we are" to "of RFC 3517, we are" (5) On Page 11, please change: "Bound in very" to "Bound is very" From iesg-secretary@ietf.org Sun Mar 10 12:47:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7300221F892D for ; Sun, 10 Mar 2013 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3NTNqfR27hm; Sun, 10 Mar 2013 12:47:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8901F041A; Sun, 10 Mar 2013 12:47:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.42 X-IETF-Draft-string: draft-ietf-tcpm-proportional-rate-reduction X-IETF-Draft-revision: 04 Message-ID: <20130310194748.24111.92089.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2013 12:47:48 -0700 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'Proportional Rate Reduction for TCP' to Experimental RFC (draft-ietf-tcpm-proportional-rate-reduction-04.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 19:47:58 -0000 The IESG has approved the following document: - 'Proportional Rate Reduction for TCP' (draft-ietf-tcpm-proportional-rate-reduction-04.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/ Technical Summary This document describes an algorithm to improve the accuracy of the amount of data sent by TCP during loss recovery. The existing TCP recovery algorithms can make excess window adjustments in some situations, such as in the presence of heavy losses, and may result in abrupt TCP behavior in the form of packet bursts or increased risk of timeouts. Proportional Rate Reduction aims to minimize the needed window adjustments, to result in more stable TCP congestion control behavior in the presence of losses. Working Group Summary The document was adopted as Experimental TCPM working group item by clear working group consensus, and no opinions against it have been raised during its progress or in the working group last call. Document Quality The algorithm specified in the document has been implemented in Linux and integrated to the main kernel distribution. The algorithm has also been evaluated through measurements, and the evaluation results reported in a paper published in the IMC'11 conference. Different versions of the document have been thoroughly reviewed by TCPM working group members. Personnel Document Shepherd is Pasi Sarolahti . Responsible Area Director is Wesley Eddy . RFC Editor Note (1) Please change the Abstract to: This document describes an experimental Proportional Rate Reduction (PPR) algorithm as an alternative to the widely deployed Fast Recovery and Rate Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments and the actual window size at the end of recovery will be as close as possible to the ssthresh determined by the congestion control algorithm. (2) Please change all occurrences of "PPR" to "PRR". (3) Please change all occurrences of "PRR+SSRB" to "PRR-SSRB" and all occurrences of "PRR+CRB" to "PRR-CRB" (4) On Page 3, please change: "slight difference" to "slight differences" and "discussions algorithms" to "discussions of algorithms" and "of RFC 3517 we are" to "of RFC 3517, we are" (5) On Page 11, please change: "Bound in very" to "Bound is very" From rs@netapp.com Mon Mar 11 04:28:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD41C21F87CB for ; Mon, 11 Mar 2013 04:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKG-Tul6E8Xd for ; Mon, 11 Mar 2013 04:28:12 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3343921F87C4 for ; Mon, 11 Mar 2013 04:28:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,822,1355126400"; d="scan'208";a="29754418" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 11 Mar 2013 04:28:11 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2BBSBoR020031; Mon, 11 Mar 2013 04:28:11 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Mon, 11 Mar 2013 04:28:10 -0700 From: "Scheffenegger, Richard" To: "Matthew Mathis (mattmathis@google.com)" , "Yuchung Cheng" , "Nandita Dukkipati (nanditad@google.com)" Thread-Topic: [tcpm] Document Action: 'Proportional Rate Reduction for TCP' to Experimental RFC (draft-ietf-tcpm-proportional-rate-reduction-04.txt) Thread-Index: AQHOHchZ/q/jRap7hUS4MuOsGah2e5igUHUw Date: Mon, 11 Mar 2013 11:28:10 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A7CA4E@SACEXCMBX02-PRD.hq.netapp.com> References: <20130310194748.24111.99563.idtracker@ietfa.amsl.com> In-Reply-To: <20130310194748.24111.99563.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.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: Re: [tcpm] Document Action: 'Proportional Rate Reduction for TCP' to Experimental RFC (draft-ietf-tcpm-proportional-rate-reduction-04.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 11:28:12 -0000 Hi, One late additional nit: Page 11, at the top: If the transmissions are regulated directly by pipe as they are with RFC 6675, such as step discontinuity in the pipe estimator causes a burst of data, which can not be retracted once the pipe estimator is corrected a few ACKs later. Shouldn't the "as" be a "a" in this sentence? Or "such as a"? Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > The IESG > Sent: Sonntag, 10. M=E4rz 2013 20:48 > To: IETF-Announce > Cc: tcpm chair; tcpm mailing list; RFC Editor > Subject: [tcpm] Document Action: 'Proportional Rate Reduction for TCP' to > Experimental RFC (draft-ietf-tcpm-proportional-rate-reduction-04.txt) >=20 > The IESG has approved the following document: > - 'Proportional Rate Reduction for TCP' > (draft-ietf-tcpm-proportional-rate-reduction-04.txt) as Experimental RF= C >=20 > This document is the product of the TCP Maintenance and Minor Extensions > Working Group. >=20 > The IESG contact persons are Wesley Eddy and Martin Stiemerling. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate- > reduction/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > This document describes an algorithm to improve the accuracy of the amoun= t > of data sent by TCP during loss recovery. The existing TCP recovery > algorithms can make excess window adjustments in some situations, such as > in the presence of heavy losses, and may result in abrupt TCP behavior in > the form of packet bursts or increased risk of timeouts. Proportional Rat= e > Reduction aims to minimize the needed window adjustments, to result in > more stable TCP congestion control behavior in the presence of losses. >=20 > Working Group Summary >=20 > The document was adopted as Experimental TCPM working group item by clear > working group consensus, and no opinions against it have been raised > during its progress or in the working group last call. >=20 > Document Quality >=20 > The algorithm specified in the document has been implemented in Linux and > integrated to the main kernel distribution. The algorithm has also been > evaluated through measurements, and the evaluation results reported in a > paper published in the > IMC'11 conference. Different versions of the document have been thoroughl= y > reviewed by TCPM working group members. >=20 > Personnel >=20 > Document Shepherd is Pasi Sarolahti . > Responsible Area Director is Wesley Eddy . >=20 > RFC Editor Note >=20 > (1) > Please change the Abstract to: >=20 > This document describes an experimental Proportional Rate Reduction > (PPR) algorithm as an alternative to the widely deployed Fast Recovery > and Rate Halving algorithms. These algorithms determine the amount > of data sent by TCP during loss recovery. PRR minimizes excess > window adjustments and the actual window size at the end of recovery > will be as close as possible to the ssthresh determined by the > congestion control algorithm. >=20 >=20 > (2) > Please change all occurrences of "PPR" to "PRR". >=20 >=20 > (3) > Please change all occurrences of "PRR+SSRB" to "PRR-SSRB" > and all occurrences of "PRR+CRB" to "PRR-CRB" >=20 >=20 > (4) > On Page 3, please change: > "slight difference" to > "slight differences" > and > "discussions algorithms" to > "discussions of algorithms" > and > "of RFC 3517 we are" to > "of RFC 3517, we are" >=20 >=20 > (5) > On Page 11, please change: > "Bound in very" to > "Bound is very" >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Mon Mar 11 04:52:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50AF21F88C7 for ; Mon, 11 Mar 2013 04:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a0z1MiIaKPW for ; Mon, 11 Mar 2013 04:52:40 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 49B4121F88C6 for ; Mon, 11 Mar 2013 04:52:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,822,1355126400"; d="scan'208,217";a="29759179" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 11 Mar 2013 04:52:38 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2BBqbsi003156; Mon, 11 Mar 2013 04:52:38 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Mon, 11 Mar 2013 04:52:37 -0700 From: "Scheffenegger, Richard" To: Per Hurtig , Michael Welzl Thread-Topic: [tcpm] draft-ietf-tcpm-rtorestart-00 Thread-Index: Ac4eTuu+5AzYwJUkRN25GoPyQl69rQ== Date: Mon, 11 Mar 2013 11:52:36 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A7CD3E@SACEXCMBX02-PRD.hq.netapp.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.117] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F24A7CD3ESACEXCMBX02PRDh_" MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] draft-ietf-tcpm-rtorestart-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 11:52:41 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F24A7CD3ESACEXCMBX02PRDh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In Section 3, wouldn't it make sense to add a comment, that tracking the se= nd times of the last packet that advanced Snd.Una could also be accomplishe= d using the Timestamp option? (With the potential issue that a receiver co= uld manipulate a na=EFve implementation to RTO early, by tweaking TSecr)... Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F24A7CD3ESACEXCMBX02PRDh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

In Section= 3, wouldn’t it make sense to add a comment, that tracking the send t= imes of the last packet that advanced Snd.Una could also be accomplished using the Timestamp option?  (With the potential issue that a receive= r could manipulate a na=EFve implementation to RTO early, by tweaking TSecr= )…

 = ;

Richard Scheffenegger


--_000_012C3117EDDB3C4781FD802A8C27DD4F24A7CD3ESACEXCMBX02PRDh_-- From tsabatini@hotmail.com Mon Mar 11 08:13:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCFF11E8108 for ; Mon, 11 Mar 2013 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awMIlX0y9iRs for ; Mon, 11 Mar 2013 08:13:38 -0700 (PDT) Received: from bay0-omc3-s9.bay0.hotmail.com (bay0-omc3-s9.bay0.hotmail.com [65.54.190.147]) by ietfa.amsl.com (Postfix) with ESMTP id CA7A111E8129 for ; Mon, 11 Mar 2013 08:13:38 -0700 (PDT) Received: from BAY158-W85 ([65.54.190.188]) by bay0-omc3-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Mar 2013 08:13:39 -0700 X-EIP: [7/MtWHzRPklW5hgLut5N9qTk+PxkjvPi] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_09e54b89-44e5-4bec-accb-b49381a2e91a_" From: Anthony Sabatini To: Anantha Ramaiah , "l.wood@surrey.ac.uk" Date: Mon, 11 Mar 2013 11:13:38 -0400 Importance: Normal In-Reply-To: References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, , <290E20B455C66743BE178C5C84F124081779FD38E0@EXMB01CMS.surrey.ac.uk>, MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2013 15:13:39.0122 (UTC) FILETIME=[026AF120:01CE1E6B] Cc: tcpm Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 15:13:40 -0000 --_09e54b89-44e5-4bec-accb-b49381a2e91a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All - Two points. First=2C by delaying the return of the received token in either TDLC or my = changes to TCP you can control the link at quite a fine level. But more importantly second. in TDLC we used an actively managed system whe= re the transmitter was allocated a certain number of credits and then used = them up as they transmitted. The number of credits a message used was 1 pl= us the message length divided by the link speed constant (256 for slow link= s in TDLC=2C 512 for high speed links). Credits were refreshed based on a = certain number of credits per time period (where time period was normally a= second). Both the remote end and intermediate nodes (routers in non TDLC = parlance) could set the refresh rate=2C allowing overall link congestion co= ntrol. What is most important here is the external control of congestion did not h= ave unintended side effects that manipulating the link control does and unl= ike manipulating link control a credit based system does not cause "whipsaw= " effects on the underlying protocol since the refresh rate provides a smoo= thing function. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 Date: Sat=2C 9 Mar 2013 20:20:54 -0800 Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling I= mproved Transmissions Speeds" From: ananth@nttmcl.com To: l.wood@surrey.ac.uk CC: tsabatini@hotmail.com=3B michael.scharf@alcatel-lucent.com=3B lars@neta= pp.com=3B cabo@tzi.org=3B tcpm@ietf.org =0A= =0A= Congestion control is needed when sharing=2C but when you own and run a ded= icated private link you can simplify and engineer for throughput. Using Int= ernet technology doesn't mean you're on the shared Internet. =0A= =0A= I share the same thought as above. I believe one could tune TCP based on wh= ere you want to run it=2C but if we go one step further by standardizing th= is as a general purpose solution=2C it becomes hard and needs support=2C = take for example quick start=2C it is a good RFC=2C but needs support from = the middle boxes in the path. Let alone ECN etc.=2C =0A= -Anantha = --_09e54b89-44e5-4bec-accb-b49381a2e91a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All -

Two points.

= First=2C by delaying the return of the received token in either TDLC or my = changes to TCP you can control the link at quite a fine level.

But m= ore importantly second. in TDLC we used an actively managed system where th= e transmitter was allocated a certain number of credits and then used them = up as they transmitted. =3B The number of credits a message used was 1 = plus the message length divided by the link speed constant (256 for slow li= nks in TDLC=2C 512 for high speed links). =3B Credits were refreshed ba= sed on a certain number of credits per time period (where time period was n= ormally a second). =3B Both the remote end and intermediate nodes (rout= ers in non TDLC parlance) could set the refresh rate=2C allowing overall li= nk congestion control.

What is most important here is the external c= ontrol of congestion did not have unintended side effects that manipulating= the link control does and unlike manipulating link control a credit based = system does not cause "whipsaw" effects on the underlying protocol since th= e refresh rate provides a smoothing function.

Tony

Anthony Sa= batini
200 =3BWest 20th Street
Apt. 1216
New York=2C NY 10011<= br>
Phone: (212) 867-7179
Mobile: (917) 224-8388

 =3B
<= br>
D= ate: Sat=2C 9 Mar 2013 20:20:54 -0800
Subject: Re: [tcpm] "Fujitsu Devel= ops New Data Transfer Protocol Enabling Improved Transmissions Speeds"
F= rom: ananth@nttmcl.com
To: l.wood@surrey.ac.uk
CC: tsabatini@hotmail.= com=3B michael.scharf@alcatel-lucent.com=3B lars@netapp.com=3B cabo@tzi.org= =3B tcpm@ietf.org


<=3BJumping in late>=3B

=

=0A=
=0A= Congestion control is needed when sharing=2C but when you own and run a ded= icated private link you can simplify and engineer for throughput. Using Int= ernet technology doesn't mean you're on the shared Internet.
=0A= =0A=

I share the same thought as above. I b= elieve one could tune TCP based on where you want to run it=2C but if we go= one step further by standardizing this  =3Bas a general purpose soluti= on=2C  =3Bit becomes hard and needs support=2C take for example quick s= tart=2C it is a good RFC=2C but needs support from the middle boxes in the = path.  =3BLet alone ECN etc.=2C  =3B
=0A=

-Anantha
= --_09e54b89-44e5-4bec-accb-b49381a2e91a_-- From michael.scharf@alcatel-lucent.com Mon Mar 11 10:41:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8211E810E; Mon, 11 Mar 2013 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.38 X-Spam-Level: X-Spam-Status: No, score=-9.38 tagged_above=-999 required=5 tests=[AWL=0.869, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKEG-bat5gkO; Mon, 11 Mar 2013 10:41:55 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id F10AB11E80DE; Mon, 11 Mar 2013 10:41:54 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BHfit8014056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 18:41:53 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 11 Mar 2013 18:41:46 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Mon, 11 Mar 2013 18:41:44 +0100 Thread-Topic: TCPM agenda update (draft-ietf-tcpm-experimental-options) Thread-Index: Ac4ef7J5dJhUnmpwTBW0sXGwtggCCw== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDC@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm-chairs@tools.ietf.org" , The IESG Subject: [tcpm] TCPM agenda update (draft-ietf-tcpm-experimental-options) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 17:41:55 -0000 Hi all, Since there has been no TCPM WG feedback on the -05 preview version of draf= t-ietf-tcpm-experimental-options until now, we added an additional short ti= me slot at the beginning of tomorrow morning's TCPM meeting, in order to di= scuss the way to move forward. The updated agenda is: http://www.ietf.org/proceedings/86/agenda/agenda-86-= tcpm Thanks Michael= From michael.scharf@alcatel-lucent.com Mon Mar 11 12:05:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891D121F8EDA for ; Mon, 11 Mar 2013 12:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.496 X-Spam-Level: X-Spam-Status: No, score=-9.496 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEOcQsO6N+2p for ; Mon, 11 Mar 2013 12:05:36 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A9AF321F8EC7 for ; Mon, 11 Mar 2013 12:05:35 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BJ5Wfb004636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 11 Mar 2013 20:05:33 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 11 Mar 2013 20:05:32 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Mon, 11 Mar 2013 20:05:30 +0100 Thread-Topic: draft-ietf-tcpm-fast-open Thread-Index: Ac4ei2ZE3Ezr/UKdRny6hlzWfklkCg== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 19:05:36 -0000 Hi all, With the chair hat off: I've read draft-ietf-tcpm-fast-open. I think that the draft significantly i= mproved, but I still came up with a number of questions: * Section 3, "performing TCP fast open" (and other places): I recall both s= ome meeting as well as mailing list discussion what will happen if draft-ie= tf-tcpm-fast-open is combined with draft-ietf-tcpm-initcwnd. I really wonde= r why there is hardly any text on congestion control implications in the dr= aft. Even if the impact may be minor and congestion control is not the majo= r focus of this draft, I think that implementors and users will wonder like= me about that question and some explanation would help them. The way the d= raft is written right now seems to imply that an application developer may = have to decide whether to experiment with IW10 or with fast open. If an app= developer has to decide this, this will be a non-trivial tradeoff for him,= in particular at design time. * Section 4.1.1: I don't recall a discussion about cookie option size, righ= t? Out of my head, 4 bytes seem reasonable; beyond that I wonder about the = tradeoff between option size consumption and security. I am not sure, but m= aybe even 2 bytes could be sufficient in some cases (see also below)? At le= ast, some guidance on the length would really make sense. * Section 4.1.3: I wonder why the client "MUST" cache cookies. Why is not a= "SHOULD"? At least if the client is short of memory, there might be valid = reasons to "forget" cookies? * Section 4.1.3: "Since TFO is enabled on a per-service port basis but cook= ies are independent of service ports, clients' cache should include remote = port numbers too." Is it possible that there are different cookies for diff= erent service ports on the same server IP? This is probably not what the sp= ecification intends, but I wonder whether it would be a possible system des= ign. I also wonder if that could improve security (e. g., possibly a shorte= r cookie)? * Section 4.2.2: Thanks for adding the text on simultaneous open! I think t= hat this scenario can only occur if fast open is activated on the correspon= ding ports on both endpoints, i. e., it is really a corner case. But are th= e fast open cookie semantics in that corner case indeed clear? In particula= r, I wonder whether one can savely distinguish between a client "Fast Open = Cookie Request Option" (Sect. 4.1.1) and a server "null cookie" (Section 4.= 1.2). * General: The draft explicitly states that API changes are outside the sco= pe of the document. Still, I wonder if that could be discussed briefly in a= n non-normative appendix. * General: This draft is heading for experimental track. Recent IESG feedba= ck suggests that the IESG is interested in statements about the scope of su= ch experiment. Maybe some text on that could be added? (Very obvious is fur= ther real-world experince on the performance benefit.) Editorial nit: Section 2.1, second paragraph: "applications in section 2.1"= looks like a self-reference Thanks Michael From pasi.sarolahti@iki.fi Mon Mar 11 12:06:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5612521F8F69 for ; Mon, 11 Mar 2013 12:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNEk3GVbeZIN for ; Mon, 11 Mar 2013 12:06:57 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id B247F21F8EDA for ; Mon, 11 Mar 2013 12:06:55 -0700 (PDT) Received: from dhcp-46b3.meeting.ietf.org (130.129.70.179) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087139908EB44B1; Mon, 11 Mar 2013 21:06:52 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Mar 2013 15:06:49 -0400 Message-Id: To: Richard Scheffenegger Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: tcpm Subject: [tcpm] Comments on draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 19:06:59 -0000 Hi, (typing as an individual WG participant) I read the latest version of 1323bis, and here are a few comments: * There is some new text in the introduction that says following: "A modern TCP implementation SHOULD implement and make use of the extensions described in this document." I think this is a bit questionable SHOULD. For window scaling I might = say this, but there may be good reasons to not use timestamps always. It = is possible to do per-packet RTTM without timestamps (excluding = retransmissions, of course), and some implementations might want to = spare the option space for something else. So in my opinion, it would be = better to leave this sentence out. * In multiple places the text refers to "new TCP options", but they are = not very new anymore. Better to use just "TCP options" or such in these = places. * There is a new section 3.4 on Addressing Window Retraction. This = section is a bit hard to understand, particularly steps 1) to 5). = Hopefully it would be possible to clarify this section, and why are the = different steps needed. Unfortunately I don't have concrete proposals = how to do that, but hopefully others do. * Section 4.3: RTTM measurement =3D> RTT measurement * I did not check in detail Appendix D: pseudo-code summary, but we = should review it carefully for correctness before passing the document = forward, so that it does not have inconsistencies with the rest of the = text. Another question is, do we actually need the pseudocode in the = document? - Pasi From ycheng@google.com Mon Mar 11 12:29:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569BE21F889D for ; Mon, 11 Mar 2013 12:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqCZ+cwG5Xl8 for ; Mon, 11 Mar 2013 12:29:48 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EBE3121F8838 for ; Mon, 11 Mar 2013 12:29:47 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id er20so4291590lab.4 for ; Mon, 11 Mar 2013 12:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=39rOw9BdcdZY9Ve2jmQT5ZSzKzwpciu5wcUq9KLBqUA=; b=OEDtz9Mdr5lq1FpJpZf4rBFY4v6oxLVwz/w6KMSxQ2+Fgj+n+YcHFYKUW4Us3is/5x qP8dydsCv6tVok+ToR+4rgsPYdt/b7VpbPVMRffVnQtDPeKz9ujInrYBMqXrEK6Vutuk +6f8uEJQeAbEu4+WLZM9Zc5ie3Zm3PSZ0pJd3ofbOdbr39SVQxWEBzrbu2UGb4qxl71j n8DN7tX9lvk4W/g3Acrv+u2+qAUhgN7Sjm+TkCu5/HI2eJqN/etjj/tcb5E+n6n9+lUv oaiPjcB9vZSCLdsOfGNHcXl9/Mgl1j4Oiyvk6+JxRas6pRiDVpxWLzOs3Jz+73qo5Mt5 cRMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=39rOw9BdcdZY9Ve2jmQT5ZSzKzwpciu5wcUq9KLBqUA=; b=JmBBeccZexg9hVvmrUctUcK2vpUkQlpAaRHYY4KdkcQOo+9VLb1TsdtIPbzk8GYg3V imTZShYson3tfaTjwxmMWF6A5Qb3po0nky8fhiXu8R8xpI4LHinQIxinAo67rD+J9cru DO4LwZDM0G0Eq5k8kwtgVgLkiv5gy2d7I+4Xb25F/6G7p69D4kgjCWyT4+VC16CO5laW 5lzk6XkNbCl1I/dWnVdVIn2W76a8YHdkzqLUU544M3/TiZUQpqpnWW+VjFIsF+U+x4PY ile3TBDc4ZnJ0wxtLhet25Wi8WXejRQuXaKPbQGeWsQ8OQi6KpsnC/fUxXcaC5y4efVi yQlg== X-Received: by 10.152.136.20 with SMTP id pw20mr11252278lab.16.1363030183740; Mon, 11 Mar 2013 12:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.7.138 with HTTP; Mon, 11 Mar 2013 12:29:23 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 11 Mar 2013 15:29:23 -0400 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=f46d042f9210eb9e5504d7ab3112 X-Gm-Message-State: ALoCoQkOU+WYv4rGFM6sSxO4pVWvZJcuHdsUBT7aB2YJSKMELuIYS5dbsYbaZShsYh3W31Rur68hdVF+F4yzdnQu8lmhq6YkxsAT+Q3jdlwIZA3zARGp2kMl1S1bPu3trJtHf2VQJjpwQGkKNBSMXTfjphMSPlQ7UAg043bWTpmxWRPG8JDr8y11euHvp8XSJi92dQ0tqlBh Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 19:29:49 -0000 --f46d042f9210eb9e5504d7ab3112 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 11, 2013 at 3:05 PM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > Hi all, > > With the chair hat off: > > I've read draft-ietf-tcpm-fast-open. I think that the draft significantly > improved, but I still came up with a number of questions: > > * Section 3, "performing TCP fast open" (and other places): I recall both > some meeting as well as mailing list discussion what will happen if > draft-ietf-tcpm-fast-open is combined with draft-ietf-tcpm-initcwnd. I > really wonder why there is hardly any text on congestion control > implications in the draft. Even if the impact may be minor and congestion > control is not the major focus of this draft, I think that implementors and > users will wonder like me about that question and some explanation would > help them. The way the draft is written right now seems to imply that an > application developer may have to decide whether to experiment with IW10 or > with fast open. If an app developer has to decide this, this will be a > non-trivial tradeoff for him, in particular at design time. > What's the problem of experimenting both? whatever issue identified in IW10 draft will occur with TFO except it'll happen an RTT earlier, except for this case, which is addressed in the new draft in 4.2.2 "" Note that if SYN-ACK is lost, regular TCP reduces the initial congestion window before sending any data. In this case TFO is slightly more aggressive in the first data round trip even though it does not change the congestion control. """ Maybe you can suggest what exactly to add in the draft because I am not sure what to do. > > * Section 4.1.1: I don't recall a discussion about cookie option size, > right? Out of my head, 4 bytes seem reasonable; beyond that I wonder about > the tradeoff between option size consumption and security. I am not sure, > but maybe even 2 bytes could be sufficient in some cases (see also below)? > At least, some guidance on the length would really make sense. > > * Section 4.1.3: I wonder why the client "MUST" cache cookies. Why is not > a "SHOULD"? At least if the client is short of memory, there might be valid > reasons to "forget" cookies? > > if the client is short of memory, does it matter if a MUST or a SHOULD? :( Happy to change to SHOULD if other co-authors agree. * Section 4.1.3: "Since TFO is enabled on a per-service port basis but > cookies are independent of service ports, clients' cache should include > remote port numbers too." Is it possible that there are different cookies > for different service ports on the same server IP? This is probably not > what the specification intends, but I wonder whether it would be a possible of course, why not? the server applications (on different) may prefer to use different secrets, whatever reason they think. in our Linux implementation but we'd like to keep the option open. > system design. I also wonder if that could improve security (e. g., > possibly a shorter cookie)? > > * Section 4.2.2: Thanks for adding the text on simultaneous open! I think > that this scenario can only occur if fast open is activated on the > corresponding ports on both endpoints, i. e., it is really a corner case. > But are the fast open cookie semantics in that corner case indeed clear? In > particular, I wonder whether one can savely distinguish between a client > "Fast Open Cookie Request Option" (Sect. 4.1.1) and a server "null cookie" > (Section 4.1.2). > I am not sure I understand the problem. When a (simul open) client sends a SYN w/ FO cookie request option, he gets a SYN-ACK that may have the Fast Open cookie option (from the other simul-open client) The null cookie is only used by server responding SYN-ACK to a (simul open) client sending SYN-data with Fast Open cookie option, not FO cookie "request" option. > > * General: The draft explicitly states that API changes are outside the > scope of the document. Still, I wonder if that could be discussed briefly > in an non-normative appendix. > I actually consider doing that but I don't know any previous TCP RFC has done that. I am happy to do that if tcpm list considers this appropriate. > > * General: This draft is heading for experimental track. Recent IESG > feedback suggests that the IESG is interested in statements about the scope > of such experiment. Maybe some text on that could be added? (Very obvious > is further real-world experince on the performance benefit.) > I need some help on this text. maybe an example exp RFC that exactly scopes its experiment. > > Editorial nit: Section 2.1, second paragraph: "applications in section > 2.1" looks like a self-reference > will fix that thx > > Thanks > > Michael > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --f46d042f9210eb9e5504d7ab3112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 11, 2013 at 3:05 PM, Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:
Hi all,

With the chair hat off:

I've read draft-ietf-tcpm-fast-open. I think that the draft significant= ly improved, but I still came up with a number of questions:

* Section 3, "performing TCP fast open" (and other places): I rec= all both some meeting as well as mailing list discussion what will happen i= f draft-ietf-tcpm-fast-open is combined with draft-ietf-tcpm-initcwnd. I re= ally wonder why there is hardly any text on congestion control implications= in the draft. Even if the impact may be minor and congestion control is no= t the major focus of this draft, I think that implementors and users will w= onder like me about that question and some explanation would help them. The= way the draft is written right now seems to imply that an application deve= loper may have to decide whether to experiment with IW10 or with fast open.= If an app developer has to decide this, this will be a non-trivial tradeof= f for him, in particular at design time.
What's the problem of experimenting both? whate= ver issue identified in IW10 draft will occur with TFO except it'll hap= pen an RTT earlier, except for this case, which is addressed in the new dra= ft in 4.2.2=A0

"" Note that if SYN-ACK is lost, regular TCP reduces the in= itial

   congestion window before sending any data. In this case TFO is
   slightly more aggressive in the first data round trip even though
   it does not change the congestion control.
""" =A0

Mayb= e you can suggest what exactly to add in the draft because I am not sure wh= at to do.
=A0

* Section 4.1.1: I don't recall a discussion about cookie option size, = right? Out of my head, 4 bytes seem reasonable; beyond that I wonder about = the tradeoff between option size consumption and security. I am not sure, b= ut maybe even 2 bytes could be sufficient in some cases (see also below)? A= t least, some guidance on the length would really make sense.

* Section 4.1.3: I wonder why the client "MUST" cache cookies. Wh= y is not a "SHOULD"? At least if the client is short of memory, t= here might be valid reasons to "forget" cookies?

if the client is short of memory, does it matte= r if =A0a MUST or a SHOULD? :(
Happy to change to SHOULD if= other co-authors agree.

* Section 4.1.3: "Since TFO is enabled on a per-service port basis but= cookies are independent of service ports, clients' cache should includ= e remote port numbers too." Is it possible that there are different co= okies for different service ports on the same server IP? This is probably n= ot what the specification intends, but I wonder whether it would be a possi= ble
of course, why not? the server applications (on different) may p= refer to use different secrets, whatever reason they think. in our Linux im= plementation but we'd like to keep the option open.=A0
system design. I also wonder if that could improve security (e. g., possibl= y a shorter cookie)?

* Section 4.2.2: Thanks for adding the text on simultaneous open! I think t= hat this scenario can only occur if fast open is activated on the correspon= ding ports on both endpoints, i. e., it is really a corner case. But are th= e fast open cookie semantics in that corner case indeed clear? In particula= r, I wonder whether one can savely distinguish between a client "Fast = Open Cookie Request Option" (Sect. 4.1.1) and a server "null cook= ie" (Section 4.1.2).
I am not sure I understand the problem. When a (sim= ul open) client sends a SYN w/ FO cookie request option, he gets a SYN-ACK = that may have the Fast Open cookie option (from the other simul-open client= )

The null cookie is only used by server resp= onding SYN-ACK to a (simul open) client sending SYN-data with Fast Open coo= kie option, not FO cookie "request" option.
=A0

* General: The draft explicitly states that API changes are outside the sco= pe of the document. Still, I wonder if that could be discussed briefly in a= n non-normative appendix.
I actually consider do= ing that but I don't know any previous TCP RFC has done that. I am happ= y to do that if tcpm list considers this appropriate.
=A0

* General: This draft is heading for experimental track. Recent IESG feedba= ck suggests that the IESG is interested in statements about the scope of su= ch experiment. Maybe some text on that could be added? (Very obvious is fur= ther real-world experince on the performance benefit.)
=A0
I need some help on this text. maybe = an example exp RFC that exactly scopes its experiment. =A0
=A0

Editorial nit: Section 2.1, second paragraph: "applications in section= 2.1" looks like a self-reference

will = fix that thx=A0

Thanks

Michael


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--f46d042f9210eb9e5504d7ab3112-- From wes@mti-systems.com Mon Mar 11 12:56:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B5E21F8DD5 for ; Mon, 11 Mar 2013 12:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWYOTDotKst6 for ; Mon, 11 Mar 2013 12:56:39 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id C353521F8DC5 for ; Mon, 11 Mar 2013 12:56:39 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r2BJucmD024284 for ; Mon, 11 Mar 2013 15:56:38 -0400 Received: (qmail 12431 invoked by uid 0); 11 Mar 2013 19:56:37 -0000 Received: from unknown (HELO ?10.10.0.34?) (wes@mti-systems.com@46.165.196.138) by 0 with ESMTPA; 11 Mar 2013 19:56:37 -0000 Message-ID: <513E36D5.3040701@mti-systems.com> Date: Mon, 11 Mar 2013 15:56:05 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Yuchung Cheng References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 19:56:40 -0000 On 3/11/2013 3:29 PM, Yuchung Cheng wrote: > > * General: This draft is heading for experimental track. Recent IESG > feedback suggests that the IESG is interested in statements about > the scope of such experiment. Maybe some text on that could be > added? (Very obvious is further real-world experince on the > performance benefit.) > > > I need some help on this text. maybe an example exp RFC that exactly > scopes its experiment. > One example I can give you is the LEDBAT spec: http://datatracker.ietf.org/doc/rfc6817/ See section 5. It gives a summary of what some of the open questions were that the WG felt were interesting, and what to look for while using LEDBAT. (I don't know what the FastOpen document does/doesn't say at the moment, but do know that the LEDBAT one was "good enough" for the IESG at the time ... which was relatively recently) -- Wes Eddy MTI Systems From michael.scharf@alcatel-lucent.com Mon Mar 11 13:30:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4313821F9049 for ; Mon, 11 Mar 2013 13:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.543 X-Spam-Level: X-Spam-Status: No, score=-9.543 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDo7yzfNki-H for ; Mon, 11 Mar 2013 13:30:39 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2947D21F9048 for ; Mon, 11 Mar 2013 13:30:39 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BKUWEl008326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 21:30:35 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 11 Mar 2013 21:30:34 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Date: Mon, 11 Mar 2013 21:30:32 +0100 Thread-Topic: [tcpm] draft-ietf-tcpm-fast-open Thread-Index: Ac4ejswKpV8gWCWnSQ6icYyzlIg0CAABVOdw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 20:30:40 -0000 > * Section 3, "performing TCP fast open" (and other=20 > places): I recall both some meeting as well as mailing list=20 > discussion what will happen if draft-ietf-tcpm-fast-open is=20 > combined with draft-ietf-tcpm-initcwnd. I really wonder why=20 > there is hardly any text on congestion control implications=20 > in the draft. Even if the impact may be minor and congestion=20 > control is not the major focus of this draft, I think that=20 > implementors and users will wonder like me about that=20 > question and some explanation would help them. The way the=20 > draft is written right now seems to imply that an application=20 > developer may have to decide whether to experiment with IW10=20 > or with fast open. If an app developer has to decide this,=20 > this will be a non-trivial tradeoff for him, in particular at=20 > design time. > =09 >=20 > What's the problem of experimenting both? whatever issue=20 > identified in IW10 draft will occur with TFO except it'll=20 > happen an RTT earlier, except for this case, which is=20 > addressed in the new draft in 4.2.2=20 >=20 > "" Note that if SYN-ACK is lost, regular TCP reduces the initial >=20 >=20 > congestion window before sending any data. In this case TFO is > slightly more aggressive in the first data round trip even though > it does not change the congestion control. > """ =20 This statement is at some rather "random" position in the protocol spec and= (at least to me) hard to parse. Our past discussion http://www.ietf.org/ma= il-archive/web/tcpm/current/msg07329.html describes more verbosely what thi= s issue is, and whether it matters (or not). Why don't you add a dedicated subsection "Congestion Control Implications" = to Section 5? > Maybe you can suggest what exactly to add in the draft=20 > because I am not sure what to do. This statement=20 " 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the server MUST follow the congestion control [RFC5681], in particular the initial congestion window [RFC3390], to send more data packets." seems to imply to me that a stack either uses fast open or IW10, but MUST n= ot use them both, right? If so, I think that this requires guidance for the= app developer do decide whether to select either IW10 or fast open. If this is not your intention, i. e., it should be allowed that IW10 and fa= st open are combined, this should be explicitly explained in the document, = imho. IW10 will probably be an RFC when this document gets published, and t= heir relationship is pretty apparent. As I said, I really think that people= will ask this question. > * Section 4.1.3: "Since TFO is enabled on a per-service=20 > port basis but cookies are independent of service ports,=20 > clients' cache should include remote port numbers too." Is it=20 > possible that there are different cookies for different=20 > service ports on the same server IP? This is probably not=20 > what the specification intends, but I wonder whether it would=20 > be a possible=20 >=20 > of course, why not? the server applications (on different)=20 > may prefer to use different secrets, whatever reason they=20 > think. in our Linux implementation but we'd like to keep the=20 > option open. ... but that question implies interoperability, because the client SW desig= n depends on what the cookie is about. Not every TCP endpoint is Linux ;) > system design. I also wonder if that could improve=20 > security (e. g., possibly a shorter cookie)? > =09 > * Section 4.2.2: Thanks for adding the text on=20 > simultaneous open! I think that this scenario can only occur=20 > if fast open is activated on the corresponding ports on both=20 > endpoints, i. e., it is really a corner case. But are the=20 > fast open cookie semantics in that corner case indeed clear?=20 > In particular, I wonder whether one can savely distinguish=20 > between a client "Fast Open Cookie Request Option" (Sect.=20 > 4.1.1) and a server "null cookie" (Section 4.1.2). > =09 >=20 > I am not sure I understand the problem. When a (simul open)=20 > client sends a SYN w/ FO cookie request option, he gets a=20 > SYN-ACK that may have the Fast Open cookie option (from the=20 > other simul-open client) If in a simulatenous open both SYNs carry an empty FO cookie option, what i= s the correct behavior? =20 > The null cookie is only used by server responding SYN-ACK to=20 > a (simul open) client sending SYN-data with Fast Open cookie=20 > option, not FO cookie "request" option. I don't understand. In simulateous open, the role of client and server is f= uzzy. And the distinction between client and server is quite inherent to fa= st open. This is why I wonder about that corner case.. Michael= From rs@netapp.com Mon Mar 11 13:36:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD74221F909A for ; Mon, 11 Mar 2013 13:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4yLfFM527HH for ; Mon, 11 Mar 2013 13:36:27 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70121F9092 for ; Mon, 11 Mar 2013 13:36:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,825,1355126400"; d="scan'208";a="29887217" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 11 Mar 2013 13:36:26 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2BKaQdd008266; Mon, 11 Mar 2013 13:36:26 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Mon, 11 Mar 2013 13:36:26 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti , "tcpm (tcpm@ietf.org)" Thread-Topic: Comments on draft-ietf-tcpm-1323bis Thread-Index: AQHOHouY1tSdu599iE+C8gWBCN6f8Jig7Pjw Date: Mon, 11 Mar 2013 20:36:25 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A7F959@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Comments on draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 20:36:27 -0000 Hi Pasi, thanks for reading the Doc! Hmm... actually, that SHOULD should be a "should", as it's in section 1 bef= ore any normative texts. Thanks for spotting, I had missed that. Even if th= at "should" is too strong, I'd rather leave something with "recommend" in t= hat place... The "new TCP" is fixed in the upcoming -07 (after the meeting, also contain= s the updated text section sent around earlier), this was a feedback from M= ichael too! The last paragraphs of section 3.4 is based on the relevant text regarding = window reduction from RFC1122. That particular text was donated by Matt Mat= his IIRC, to make it clear to any implementer, how to code what is describe= d in RFC1122/4.2.2.16... Section 4.3 title reads "RTTM Mechanism" not "RTTM Measurement" :) Regarding Pseudocode: One thing missing there is adding relevant receiver c= ode to allow "late" TS enablement. That pseudo-code was added in 2007 in dr= aft-borman-1323bis-00; TSoffset is also not explicitly included in that sec= tion. As acting editor, I don't have any strong feelings regarding that pseudocod= e section. If the WG feels that the pseudocode (or event processing appendi= x?) aren't necessary, it can be removed easily; if the consensus is that th= e optional "TSoffset" and "late TS enablement" should go into the pseudocod= e, I can add that too. Best regards, Richard Scheffenegger > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@iki.fi] > Sent: Montag, 11. M=E4rz 2013 20:07 > To: Scheffenegger, Richard > Cc: tcpm > Subject: Comments on draft-ietf-tcpm-1323bis >=20 > Hi, >=20 > (typing as an individual WG participant) >=20 > I read the latest version of 1323bis, and here are a few comments: >=20 > * There is some new text in the introduction that says following: > "A modern TCP > implementation SHOULD implement and make use of the extensions > described in this document." > I think this is a bit questionable SHOULD. For window scaling I might say > this, but there may be good reasons to not use timestamps always. It is > possible to do per-packet RTTM without timestamps (excluding > retransmissions, of course), and some implementations might want to spare > the option space for something else. So in my opinion, it would be better > to leave this sentence out. >=20 > * In multiple places the text refers to "new TCP options", but they are > not very new anymore. Better to use just "TCP options" or such in these > places. >=20 > * There is a new section 3.4 on Addressing Window Retraction. This sectio= n > is a bit hard to understand, particularly steps 1) to 5). Hopefully it > would be possible to clarify this section, and why are the different step= s > needed. Unfortunately I don't have concrete proposals how to do that, but > hopefully others do. >=20 > * Section 4.3: RTTM measurement =3D> RTT measurement >=20 > * I did not check in detail Appendix D: pseudo-code summary, but we shoul= d > review it carefully for correctness before passing the document forward, > so that it does not have inconsistencies with the rest of the text. > Another question is, do we actually need the pseudocode in the document? >=20 > - Pasi From ycheng@google.com Mon Mar 11 14:07:46 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806A221F8D2A for ; Mon, 11 Mar 2013 14:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2bXgJdggSe1 for ; Mon, 11 Mar 2013 14:07:45 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id F16B121F8D28 for ; Mon, 11 Mar 2013 14:07:44 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo13so4480363lab.10 for ; Mon, 11 Mar 2013 14:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Xbmew7YagdCxqTbWBxXCV5S0roPa4eSAEyqUQnpcN/A=; b=g8oPQkS4bq7QLH57Zx6LsTwXxh6YU/cONpwL1Q9ZdkfdKoKmJAtCv3nmSCMoBKJK6A VYzm0PMg0RF3oMdhSQhV7/s8i55QA0GepPpp2vK8uDZUQyYovHOSRpeAA+zbezOBKqUt xazc8Cxw2vQs9VrdR1M228SU4JOH+MsTpJ25uRGD/x2ACDzDjYqwLoWwqP+Joivfcbd+ lXj/oZyFMatNvwk6LtwFM3++qtFRmjBuyS7FNJ3LKh9tVaX7FiAH4284HOwOfzqr2B2E L8QlMKtkWQbPwkv7nnAZMYZ2qdH2wi964n2WYoqjIvBwIr0g9kBv4FX7fqp3Hrhq5M4n 5h7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Xbmew7YagdCxqTbWBxXCV5S0roPa4eSAEyqUQnpcN/A=; b=QaoZ7XqcWDIhW09IKIHCwi6Kjlnm6t8tLzMU9RP9gMaY3OgBtQ6wSPAmBW4teOMbMK gGRAOAZ2se+ZUVC3LrTPgr3DJMsAEZ6B8LAF12Jn7IVTnLY6H+IWUTvgY7wuZs7iMu5J OHH+Vpx2TKAzC/rHqMuNnIM6v1TvgJ1LIwk1T73cBY6qsFN+e7spBPMDV7fcVfIXwoh+ qqU19PrZLkYTBxoVRNvnHnWGcgMNkAYCW9d/FMAYrFOM3sxJBj5/q9SHw4WSDSrkQO7N U1MwVWWMIp4WJK4mcban0FdtURoTNmdtXoWyOGGxWM0ZfsQmSqQHrCjlOk5/5YNwU5ua 1laA== X-Received: by 10.152.128.98 with SMTP id nn2mr11603914lab.17.1363036063675; Mon, 11 Mar 2013 14:07:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.7.138 with HTTP; Mon, 11 Mar 2013 14:07:23 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 11 Mar 2013 17:07:23 -0400 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=f46d042c6423644d1e04d7ac90f3 X-Gm-Message-State: ALoCoQkX+jS0Uy0o2M6YJFFSvrGiOI1iO2V9QDTj+JXuQ1/C1DJybAvdAB0k0h0/hG7jT1AW8rF0+DepmO/Qp+j4qUU8q3/IHcvN8KpQ8GD1LM+L2o8mVop47Z7bcSsltwAxYG3kS0jV0GyUmfgOpVY6C91ICpjaTyBxPKil0H43cVLWyP4k+k/2J+qTV6k0xQ3yqoMV7Qvr Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 21:07:46 -0000 --f46d042c6423644d1e04d7ac90f3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 11, 2013 at 4:30 PM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > > * Section 3, "performing TCP fast open" (and other > > places): I recall both some meeting as well as mailing list > > discussion what will happen if draft-ietf-tcpm-fast-open is > > combined with draft-ietf-tcpm-initcwnd. I really wonder why > > there is hardly any text on congestion control implications > > in the draft. Even if the impact may be minor and congestion > > control is not the major focus of this draft, I think that > > implementors and users will wonder like me about that > > question and some explanation would help them. The way the > > draft is written right now seems to imply that an application > > developer may have to decide whether to experiment with IW10 > > or with fast open. If an app developer has to decide this, > > this will be a non-trivial tradeoff for him, in particular at > > design time. > > > > > > What's the problem of experimenting both? whatever issue > > identified in IW10 draft will occur with TFO except it'll > > happen an RTT earlier, except for this case, which is > > addressed in the new draft in 4.2.2 > > > > "" Note that if SYN-ACK is lost, regular TCP reduces the initial > > > > > > congestion window before sending any data. In this case TFO is > > slightly more aggressive in the first data round trip even though > > it does not change the congestion control. > > """ > > This statement is at some rather "random" position in the protocol spec > and (at least to me) hard to parse. Our past discussion > http://www.ietf.org/mail-archive/web/tcpm/current/msg07329.html describes > more verbosely what this issue is, and whether it matters (or not). > > Why don't you add a dedicated subsection "Congestion Control Implications" > to Section 5? > personally I am fine w/ a dedicated subsection but have to consult other co-authors. > > > Maybe you can suggest what exactly to add in the draft > > because I am not sure what to do. > > This statement > > " 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the > server MUST follow the congestion control [RFC5681], in particular > the initial congestion window [RFC3390], to send more data packets." > > seems to imply to me that a stack either uses fast open or IW10, but MUST > not use them both, right? If so, I think that this requires guidance for > the app developer do decide whether to select either IW10 or fast open. > > If this is not your intention, i. e., it should be allowed that IW10 and > fast open are combined, this should be explicitly explained in the > document, imho. IW10 will probably be an RFC when this document gets > published, and their relationship is pretty apparent. As I said, I really > think that people will ask this question. > No I do not imply that. My intention is to say TFO should follow TCP CC, whatever IETF RFC recommends. This is the answer to your or similar questions like can TFO work with any other changes to CC). > > * Section 4.1.3: "Since TFO is enabled on a per-service > > port basis but cookies are independent of service ports, > > clients' cache should include remote port numbers too." Is it > > possible that there are different cookies for different > > service ports on the same server IP? This is probably not > > what the specification intends, but I wonder whether it would > > be a possible > > > > of course, why not? the server applications (on different) > > may prefer to use different secrets, whatever reason they > > think. in our Linux implementation but we'd like to keep the > > option open. > > ... but that question implies interoperability, because the client SW > design depends on what the cookie is about. Not every TCP endpoint is Linux > ;) Please help me understand by an example of how sever applications on port 17483 and port 432 using two masters keys talking to different TFO client implementation may break. A TFO cookie is only meaningful for server applications that permit TFO. > > system design. I also wonder if that could improve > > security (e. g., possibly a shorter cookie)? > > > > * Section 4.2.2: Thanks for adding the text on > > simultaneous open! I think that this scenario can only occur > > if fast open is activated on the corresponding ports on both > > endpoints, i. e., it is really a corner case. But are the > > fast open cookie semantics in that corner case indeed clear? > > In particular, I wonder whether one can savely distinguish > > between a client "Fast Open Cookie Request Option" (Sect. > > 4.1.1) and a server "null cookie" (Section 4.1.2). > > > > > > I am not sure I understand the problem. When a (simul open) > > client sends a SYN w/ FO cookie request option, he gets a > > SYN-ACK that may have the Fast Open cookie option (from the > > other simul-open client) > > If in a simulatenous open both SYNs carry an empty FO cookie option, what > is the correct behavior? > On receiving the empty FO cookie option, aka FO cookie request, the server (also a simul-open client) responds the cookie in SYN-ACK if it supports TFO on that port. details are in Section 4.2.2 " Server: Receiving SYN and responding with SYN-ACK" > > The null cookie is only used by server responding SYN-ACK to > > a (simul open) client sending SYN-data with Fast Open cookie > > option, not FO cookie "request" option. > > I don't understand. In simulateous open, the role of client and server is > fuzzy. And the distinction between client and server is quite inherent to > fast open. This is why I wonder about that corner case.. > If not too much trouble please give a exact case of how simul. fast open won't work. I don't understand your case. sorry. > > Michael --f46d042c6423644d1e04d7ac90f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 11, 2013 at 4:30 PM, Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:
> =A0 =A0 =A0 * Section 3, "perf= orming TCP fast open" (and other
> places): I recall both some meeting as well as mailing list
> discussion what will happen if draft-ietf-tcpm-fast-open is
> combined with draft-ietf-tcpm-initcwnd. I really wonder why
> there is hardly any text on congestion control implications
> in the draft. Even if the impact may be minor and congestion
> control is not the major focus of this draft, I think that
> implementors and users will wonder like me about that
> question and some explanation would help them. The way the
> draft is written right now seems to imply that an application
> developer may have to decide whether to experiment with IW10
> or with fast open. If an app developer has to decide this,
> this will be a non-trivial tradeoff for him, in particular at
> design time.
>
>
> What's the problem of experimenting both? whatever issue
> identified in IW10 draft will occur with TFO except it'll
> happen an RTT earlier, except for this case, which is
> addressed in the new draft in 4.2.2
>
> "" Note that if SYN-ACK is lost, regular TCP reduces the ini= tial
>
>
> =A0 =A0congestion window before sending any data. In this case TFO is<= br> > =A0 =A0slightly more aggressive in the first data round trip even thou= gh
> =A0 =A0it does not change the congestion control.
> """

This statement is at some rather "random" position in the p= rotocol spec and (at least to me) hard to parse. Our past discussion http://www.ietf.org/mail-archive/web/tcpm/current/msg07329.htm= l describes more verbosely what this issue is, and whether it matters (= or not).

Why don't you add a dedicated subsection "Congestion Control Impli= cations" to Section 5?
personally I am fine= w/ a dedicated subsection but have to consult other co-authors.
=A0

> Maybe you can suggest what exactly to add in the draft
> because I am not sure what to do.

This statement

" 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the=
=A0 =A0 server MUST follow the congestion control [RFC5681], in particular<= br> =A0 =A0the initial congestion window [RFC3390], to send more data =A0 packe= ts."

seems to imply to me that a stack either uses fast open or IW10, but MUST n= ot use them both, right? If so, I think that this requires guidance for the= app developer do decide whether to select either IW10 or fast open.

If this is not your intention, i. e., it should be allowed that IW10 and fa= st open are combined, this should be explicitly explained in the document, = imho. IW10 will probably be an RFC when this document gets published, and t= heir relationship is pretty apparent. As I said, I really think that people= will ask this question.
No I do not imply that. My intention is to say= TFO should follow TCP CC, whatever IETF RFC recommends. =A0This is the ans= wer to your or similar questions like can TFO work with any other changes t= o CC).=A0



> =A0 =A0 =A0 * Section 4.1.3: "Since TFO is enabled on a per-servi= ce
> port basis but cookies are independent of service ports,
> clients' cache should include remote port numbers too." Is it=
> possible that there are different cookies for different
> service ports on the same server IP? This is probably not
> what the specification intends, but I wonder whether it would
> be a possible
>
> of course, why not? the server applications (on different)
> may prefer to use different secrets, whatever reason they
> think. in our Linux implementation but we'd like to keep the
> option open.

... but that question implies interoperability, because the client SW= design depends on what the cookie is about. Not every TCP endpoint is Linu= x ;)
Please help me understand by an example of how = sever applications on port 17483 and port 432 using two masters keys talkin= g to different TFO client implementation may break.

A TFO cookie is only meaningful for server applic= ations that permit TFO.


> =A0 =A0 =A0 system design. I also wonder if that could improve
> security (e. g., possibly a shorter cookie)?
>
> =A0 =A0 =A0 * Section 4.2.2: Thanks for adding the text on
> simultaneous open! I think that this scenario can only occur
> if fast open is activated on the corresponding ports on both
> endpoints, i. e., it is really a corner case. But are the
> fast open cookie semantics in that corner case indeed clear?
> In particular, I wonder whether one can savely distinguish
> between a client "Fast Open Cookie Request Option" (Sect. > 4.1.1) and a server "null cookie" (Section 4.1.2).
>
>
> I am not sure I understand the problem. When a (simul open)
> client sends a SYN w/ FO cookie request option, he gets a
> SYN-ACK that may have the Fast Open cookie option (from the
> other simul-open client)

If in a simulatenous open both SYNs carry an empty FO cookie option, = what is the correct behavior?

On receiving the empty FO cookie option, aka FO cookie request, the serv= er (also a simul-open client) responds the cookie in SYN-ACK if it supports= TFO on that port.
details are in =A0Section =A04.2.2 "=A0Server: Receiving SYN and responding with SYN-AC= K"


> The null cookie is only used by server responding SYN-ACK to
> a (simul open) client sending SYN-data with Fast Open cookie
> option, not FO cookie "request" option.

I don't understand. In simulateous open, the role of client and s= erver is fuzzy. And the distinction between client and server is quite inhe= rent to fast open. This is why I wonder about that corner case..
If not too much trouble please give a exact case of how simul. f= ast open won't work. I don't understand your case. sorry.
=A0

Michael

--f46d042c6423644d1e04d7ac90f3-- From pasi.sarolahti@iki.fi Mon Mar 11 14:16:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C47B21F8EB1 for ; Mon, 11 Mar 2013 14:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS-XsVX5rhTI for ; Mon, 11 Mar 2013 14:16:24 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8E07221F8F49 for ; Mon, 11 Mar 2013 14:16:24 -0700 (PDT) Received: from dhcp-54b2.meeting.ietf.org (130.129.84.178) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087139908ECD0E6; Mon, 11 Mar 2013 23:16:21 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Pasi Sarolahti In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24A7F959@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 11 Mar 2013 17:16:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B95A63B-DC65-444E-A2E7-F730096037EE@iki.fi> References: <012C3117EDDB3C4781FD802A8C27DD4F24A7F959@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1283) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 21:16:25 -0000 On Mar 11, 2013, at 4:36 PM, Scheffenegger, Richard wrote: > Hmm... actually, that SHOULD should be a "should", as it's in section = 1 before any normative texts. Thanks for spotting, I had missed that. = Even if that "should" is too strong, I'd rather leave something with = "recommend" in that place... ok, "recommended" sounds better. > The "new TCP" is fixed in the upcoming -07 (after the meeting, also = contains the updated text section sent around earlier), this was a = feedback from Michael too! ok > The last paragraphs of section 3.4 is based on the relevant text = regarding window reduction from RFC1122. That particular text was = donated by Matt Mathis IIRC, to make it clear to any implementer, how to = code what is described in RFC1122/4.2.2.16... How about this: expand/rephrase step 1) a bit: if window has been shrinked due to = reception of small segment, the receiver should accept segments that = would have been in window prior to window retraction (this is not ideal = wording for the document, but trying to rephrase what it says to check = that I understand). Should receiver really accept *any* segment that = would have been in-window for *any* ACK sent by the server? RFC = 1122/4.2.2.16 does not seem to say that (in case some receiver against = recommendations would intentionally shrink the window) step 2) might benefit from explaining more verbosely what exactly is = "actual maximum window sequence number". The edge of the actual current = buffer at TCP receiver? Step 3) is clear Step 4) what sequence number exactly? It might also be useful to have an = additional sentence to explain why it is ok/required to ignore receive = window in this case step 5) explain what are "such ACKs". Difficult to associate with the = preceding text. > Section 4.3 title reads "RTTM Mechanism" not "RTTM Measurement" :) I didn't mean title, but second to last paragraph, where it says "RTTM = measurement" > Regarding Pseudocode: One thing missing there is adding relevant = receiver code to allow "late" TS enablement. That pseudo-code was added = in 2007 in draft-borman-1323bis-00; TSoffset is also not explicitly = included in that section. Ok, so I was looking at diff between RFC1323 and the latest version of = the document. My memory does not cover what has been discussed about = this many years ago. If the WG thinks it is fine to include the code, = then ok. > As acting editor, I don't have any strong feelings regarding that = pseudocode section. If the WG feels that the pseudocode (or event = processing appendix?) aren't necessary, it can be removed easily; if the = consensus is that the optional "TSoffset" and "late TS enablement" = should go into the pseudocode, I can add that too. I'm not concerned about these individual additions. The question was = more about whether the pseudocode is needed at all. Personally I don't = have strong feelings one way or another, either. - Pasi From touch@isi.edu Mon Mar 11 14:39:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF821F8D82 for ; Mon, 11 Mar 2013 14:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.191 X-Spam-Level: X-Spam-Status: No, score=-105.191 tagged_above=-999 required=5 tests=[AWL=1.408, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azAcSdTqLzrT for ; Mon, 11 Mar 2013 14:39:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F012F21F8D2F for ; Mon, 11 Mar 2013 14:39:47 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2BLcFgY011044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 14:38:24 -0700 (PDT) Message-ID: <513E4EC8.1060901@isi.edu> Date: Mon, 11 Mar 2013 14:38:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F24A7F959@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24A7F959@SACEXCMBX02-PRD.hq.netapp.com> 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 21:39:48 -0000 On 3/11/2013 1:36 PM, Scheffenegger, Richard wrote: > Hi Pasi, > > thanks for reading the Doc! > > Hmm... actually, that SHOULD should be a "should", as it's in > section 1 before any normative texts. Thanks for spotting, I had > missed that. Even if that "should" is too strong, I'd rather leave > something with "recommend" in that place... FWIW, these words are sometimes interpreted as meaning the same thing as per RFC 2119. If the lowercase is intended to *not* refer as strongly as RFC 2119, then Sec 2 might need to be updated to add: --- In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. --- Joe From michael.scharf@alcatel-lucent.com Mon Mar 11 16:07:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC7C21F8C69 for ; Mon, 11 Mar 2013 16:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.584 X-Spam-Level: X-Spam-Status: No, score=-9.584 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzdQY-8Ikebx for ; Mon, 11 Mar 2013 16:07:07 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1C11E80EE for ; Mon, 11 Mar 2013 16:07:06 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BN74Ld030650 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 00:07:04 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 12 Mar 2013 00:07:04 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Date: Tue, 12 Mar 2013 00:07:00 +0100 Thread-Topic: [tcpm] draft-ietf-tcpm-fast-open Thread-Index: Ac4enH6Cjtw0rHBLTBSM0D/snSI4UAAAH6ig Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 23:07:08 -0000 > This statement > =09 > " 6. Advance to the SYN-RCVD state. If the FastOpened=20 > flag is set, the > server MUST follow the congestion control=20 > [RFC5681], in particular > the initial congestion window [RFC3390], to send=20 > more data packets." > =09 > seems to imply to me that a stack either uses fast open=20 > or IW10, but MUST not use them both, right? If so, I think=20 > that this requires guidance for the app developer do decide=20 > whether to select either IW10 or fast open. > =09 >=20 >=20 > If this is not your intention, i. e., it should be=20 > allowed that IW10 and fast open are combined, this should be=20 > explicitly explained in the document, imho. IW10 will=20 > probably be an RFC when this document gets published, and=20 > their relationship is pretty apparent. As I said, I really=20 > think that people will ask this question. > =09 >=20 > No I do not imply that. My intention is to say TFO should=20 > follow TCP CC, whatever IETF RFC recommends. This is the=20 > answer to your or similar questions like can TFO work with=20 > any other changes to CC).=20 The text has a MUST for RFC5681 and RFC3390. This prevents IW10, imho. As a= result, I think that your text does not describe what you want. But if you= replace that MUST for IW3 to something less restricitive, you will need to= have to comment on congestion control. > > * Section 4.1.3: "Since TFO is enabled on a per-service > > port basis but cookies are independent of service ports, > > clients' cache should include remote port numbers too." Is it > > possible that there are different cookies for different > > service ports on the same server IP? This is probably not > > what the specification intends, but I wonder whether it would > > be a possible > > > > of course, why not? the server applications (on different) > > may prefer to use different secrets, whatever reason they > > think. in our Linux implementation but we'd like to keep the > > option open. > =09 > =09 > ... but that question implies interoperability, because=20 > the client SW design depends on what the cookie is about. Not=20 > every TCP endpoint is Linux ;) >=20 > Please help me understand by an example of how sever=20 > applications on port 17483 and port 432 using two masters=20 > keys talking to different TFO client implementation may break. >=20 > A TFO cookie is only meaningful for server applications that=20 > permit TFO. I was thinking of one BSD client talking to ports 17483 and 432 on the same= destination IP address. That BSD client has to know whether to query for o= ne or two cookies. And actually I still struggle with understanding which of the two options i= s the better one from a protocol perspective. > > system design. I also wonder if that could improve > > security (e. g., possibly a shorter cookie)? > > > > * Section 4.2.2: Thanks for adding the text on > > simultaneous open! I think that this scenario can only occur > > if fast open is activated on the corresponding ports on both > > endpoints, i. e., it is really a corner case. But are the > > fast open cookie semantics in that corner case indeed clear? > > In particular, I wonder whether one can savely distinguish > > between a client "Fast Open Cookie Request Option" (Sect. > > 4.1.1) and a server "null cookie" (Section 4.1.2). > > > > > > I am not sure I understand the problem. When a (simul open) > > client sends a SYN w/ FO cookie request option, he gets a > > SYN-ACK that may have the Fast Open cookie option (from the > > other simul-open client) > =09 > =09 > If in a simulatenous open both SYNs carry an empty FO=20 > cookie option, what is the correct behavior? > =09 >=20 >=20 > On receiving the empty FO cookie option, aka FO cookie=20 > request, the server (also a simul-open client) responds the=20 > cookie in SYN-ACK if it supports TFO on that port. > details are in Section 4.2.2 " Server: Receiving SYN and=20 > responding with SYN-ACK" With simulatous open, I think speaking of client and server should be avoid= ed. > > The null cookie is only used by server responding SYN-ACK to > > a (simul open) client sending SYN-data with Fast Open cookie > > option, not FO cookie "request" option. > =09 > =09 > I don't understand. In simulateous open, the role of=20 > client and server is fuzzy. And the distinction between=20 > client and server is quite inherent to fast open. This is why=20 > I wonder about that corner case.. > =09 >=20 > If not too much trouble please give a exact case of how=20 > simul. fast open won't work. I don't understand your case. sorry. I don't claim that it does not work. I just want to understand whether more= text is needed or not. And whether the procotol state engines are designed= for that case, or not. Maybe it is trivial. Maybe not.=20 For instance, this pattern seems to result in the situation that both endpo= ints get a valid cookie, i. e., both A and B are client and server at the s= ame time: TCP A TCP B ______________ _____________ CLOSED CLOSED #1 SYN-SENT ----> ........... CLOSED #2 SYN-SENT ..... <---------- SYN-SENT #3 SYN-SENT ..... ----------> SYN-RCVD #4 SYN-RECV <---- ........... SYN-RCVD #5 ESTABLISHED <---- ---------- ESTABLISHED #6 ESTABLISHED ----- ---------> SYN-RCVD At least, the document does not state right now that one TCP endpoint can b= e both fast open client and server for one connection at the same time (eve= n if it is unlikely in practice). This seems also imply that in the next co= nnection, if simultaneous open is used again, there could be bi-directional= fast open with data in SYNs. Furthermore, it is unclear to me what happens if #4 and #5 get reordered. D= oes TCP A process the cookie request from B, or not? Sorry, I haven't thought of more complicated cases so far. I've never studi= ed the simulateous open code in real stacks. As a side note, there seems to be a general inconsistency issue in the draf= t: Section 4.1.1 does apparently not foresee that a client gets an empty co= okie option, while this is allowed in Section 4.1.2, right? Michael= From rs@netapp.com Tue Mar 12 04:45:37 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC9621F86C0 for ; Tue, 12 Mar 2013 04:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqJtUDNZHvbw for ; Tue, 12 Mar 2013 04:45:36 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id D79D921F8623 for ; Tue, 12 Mar 2013 04:45:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,830,1355126400"; d="scan'208";a="246385964" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 12 Mar 2013 04:45:37 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2CBjalD013549; Tue, 12 Mar 2013 04:45:36 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Tue, 12 Mar 2013 04:45:35 -0700 From: "Scheffenegger, Richard" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-00.txt Thread-Index: AQHOCt75lQ6V085w8kOKT7nNulIeaJiiEg8A Date: Tue, 12 Mar 2013 11:45:34 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A814E5@SACEXCMBX02-PRD.hq.netapp.com> References: <20130214181206.22434.33733.idtracker@ietfa.amsl.com> In-Reply-To: <20130214181206.22434.33733.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 11:45:37 -0000 A few nits: Typo: unacknoeledged Missing space: [RFC3517]is References to RFC3517 should be updated to RFC6675 " A TCP sender that enters the non-validated phase will preserve the cwnd (i.e., this neither grows nor reduces while the sender remains in this phase). The phase is concluded after a fixed period of time (the NVP, as explained in section 4.3.2) or when the sender transmits sufficient data so that pipeACK > (1/2)*cwnd (i.e. it is no longer rate-limited)." One still wants to allow cwnd reduction on congestion events, even in the n= on-validated phase, as explained shortly afterwards. So cwnd might shrink -= this is explain in the 2. Bullet point below. Perhaps the initial text bef= ore the bullet points should allude to this behavior described a few senten= ces further in a bullet point? " Where IW is the TCP inital window [RFC5681]" Any point in explicitly mentioning/referencing IW10? I'm mentioning this af= ter the discusson on the list regarding a similar text in FastOpen... This = is also mentioned in the discussion points (section 9) though. I'm proposin= g something like "Where IW is the appropriate TCP initial window, used by the TCP sender (e.= g. [RFC5681])". That leaves it to the implementer to also use IW10 if he chooses to... Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Donnerstag, 14. Februar 2013 19:12 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-00.txt >=20 >=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 : Updating TCP to support Rate-Limited Traffic > Author(s) : Godred Fairhurst > Arjuna Sathiaseelan > Filename : draft-ietf-tcpm-newcwv-00.txt > Pages : 16 > Date : 2013-02-14 >=20 > 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. >=20 > It also evaluates TCP Congestion Window Validation, CWV, an IETF > experimental specification defined in RFC 2861, and concludes that > CWV sought to address important issues, but failed to deliver a > widely used solution. This document therefore proposes an update to > the status of RFC 2861 by recommending it is moved from Experimental > to Historic status, and that it is replaced by the current > specification. >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-00 >=20 >=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 From rs@netapp.com Tue Mar 12 05:46:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA16521F87C3 for ; Tue, 12 Mar 2013 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBljWINqetHj for ; Tue, 12 Mar 2013 05:46:12 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1D80221F8793 for ; Tue, 12 Mar 2013 05:46:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,830,1355126400"; d="scan'208";a="30092145" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 12 Mar 2013 05:46:08 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2CCjvKx028447; Tue, 12 Mar 2013 05:46:08 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Tue, 12 Mar 2013 05:46:05 -0700 From: "Scheffenegger, Richard" To: Nandita Dukkipati , "tcpm@ietf.org" Thread-Topic: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt Thread-Index: Ac4fF61/OifVq+xqSwKE7H+joAcvkw== Date: Tue, 12 Mar 2013 12:46:04 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A82856@SACEXCMBX02-PRD.hq.netapp.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 12:46:12 -0000 Hi, editorial: The enumerated list after "Timeouts can occur in a number of sit= uations, such as the following:" could use "hanging" indentation to make th= e numbering stand out (or use a numbered list with format (%d) ). (As a per= sonal taste, I'd also have an empty line between the one sentence for the b= ullet description, and the more detailed explanation). The numeric data points on page 4 could be put into an ascii art, or a form= atted table, instead of free flowing text. Albeit, I wonder if some of thes= e paragraphs shouldn't be better moved to an appendix, if the draft is adop= ted. Regarding this statement: TLP MUST NOT be used for non-SACK connections. SACK feedback allows senders to use the algorithm described in section 3 to infer whether any segments were lost. When a sender has some way of discriminating between the TLP packet and the= regular packet (ie. use of the TS option, with the TLP carrying a differen= t TS than the original packet; F-RTO like discrimination can work out which= packet triggered the ACK), TLP should be applicable to non-SACK sessions a= s well. Perhaps this working can be relaxed in that way. If so, then sectio= n 3 need some text regarding TS-based (F-RTO like) recovered loss detection= . OTOH: Encouraging the universal adoption of SACK, and not making enhanced f= eatures like this available to non-SACK, might not be that bad an idea anyh= ow. (3) When PTO fires: (a) If a new previously unsent segment exists: Is it deliberate, that this might sent a packet beyond rwin? (If so, that m= ay be stated explicitly in the text beneath) Thanks for adding the FACK recovery section! One minor nit-pick: If (SND.FACK - SND.UNA) > dupack threshold: -> Invoke Fast Retransmit and Fast Recovery. Dupack threshold is usually stated in packets, while Snd.fack/snd.una is (u= sually) in bytes. For byte-oriented stacks, the clause might be better stat= ed as: If (SND.FACK - SND.UNA) > ((dupack threshold - 1)*MSS + 1): -> Invoke Fast Retransmit and Fast Recovery. This will work for most instances, where one (the last) packet is of size s= maller than MSS... (hat tip to Alex Zimmermann). so it should enter fast recovery using the proportional rate reduction algorithm [IMC11PRR]. I think, that sentence can end after "enter fast recovery". The specifics h= ow the sender performs fast recovery should be regarded out of scope of thi= s doc... Nit: an RTO. / a RTO. Nit: insequence ACKs / in-sequence ACKs Overall, I still think this is a very valuable mechanism and the document i= s very well written, giving a lot of relevant references. Best regards, Richard Scheffenegger From rs@netapp.com Tue Mar 12 08:34:41 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7721F87F6 for ; Tue, 12 Mar 2013 08:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ybr5nJzmaJa for ; Tue, 12 Mar 2013 08:34:41 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 422D721F86E6 for ; Tue, 12 Mar 2013 08:34:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,831,1355126400"; d="scan'208";a="30137168" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 12 Mar 2013 08:34:40 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2CFYepC007222; Tue, 12 Mar 2013 08:34:40 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Tue, 12 Mar 2013 08:34:40 -0700 From: "Scheffenegger, Richard" To: Nandita Dukkipati , "tcpm@ietf.org" Thread-Topic: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt Thread-Index: Ac4fF61/OifVq+xqSwKE7H+joAcvkwAHpLPg Date: Tue, 12 Mar 2013 15:34:38 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A84404@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24A82856@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24A82856@SACEXCMBX02-PRD.hq.netapp.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.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:34:42 -0000 To follow up on my comments on the microphone: I think the special case when both PTO and RTO timer fire in the same cycle= need to be documented... And some more text regarding the exact interactio= n with RTOrestart (where setting PTO=3DRTO will not necessarily cause PTO f= ire before RTO, I would expect) would be good. I think I heared Jana to comment that if the cwnd is large but the sender i= s application limited, to proactively resend on the remaining, incoming ACK= s (in order to not lose the ACK clock). But I'd like a more complete statem= ent if that really is what was meant. Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Scheffenegger, Richard > Sent: Dienstag, 12. M=E4rz 2013 13:46 > To: Nandita Dukkipati; tcpm@ietf.org > Subject: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp- > loss-probe-01.txt >=20 >=20 > Hi, >=20 > editorial: The enumerated list after "Timeouts can occur in a number of > situations, such as the following:" could use "hanging" indentation to > make the numbering stand out (or use a numbered list with format (%d) ). > (As a personal taste, I'd also have an empty line between the one sentenc= e > for the bullet description, and the more detailed explanation). >=20 > The numeric data points on page 4 could be put into an ascii art, or a > formatted table, instead of free flowing text. Albeit, I wonder if some o= f > these paragraphs shouldn't be better moved to an appendix, if the draft i= s > adopted. >=20 >=20 >=20 > Regarding this statement: >=20 > TLP MUST NOT be used for non-SACK connections. SACK feedback allows > senders to use the algorithm described in section 3 to infer whether > any segments were lost. >=20 > When a sender has some way of discriminating between the TLP packet and > the regular packet (ie. use of the TS option, with the TLP carrying a > different TS than the original packet; F-RTO like discrimination can work > out which packet triggered the ACK), TLP should be applicable to non-SACK > sessions as well. Perhaps this working can be relaxed in that way. If so, > then section 3 need some text regarding TS-based (F-RTO like) recovered > loss detection. > OTOH: Encouraging the universal adoption of SACK, and not making enhanced > features like this available to non-SACK, might not be that bad an idea > anyhow. >=20 >=20 >=20 > (3) When PTO fires: >=20 > (a) If a new previously unsent segment exists: >=20 > Is it deliberate, that this might sent a packet beyond rwin? (If so, that > may be stated explicitly in the text beneath) >=20 >=20 >=20 > Thanks for adding the FACK recovery section! >=20 >=20 >=20 > One minor nit-pick: >=20 > If (SND.FACK - SND.UNA) > dupack threshold: > -> Invoke Fast Retransmit and Fast Recovery. >=20 > Dupack threshold is usually stated in packets, while Snd.fack/snd.una is > (usually) in bytes. For byte-oriented stacks, the clause might be better > stated as: >=20 > If (SND.FACK - SND.UNA) > ((dupack threshold - 1)*MSS + 1): > -> Invoke Fast Retransmit and Fast Recovery. >=20 > This will work for most instances, where one (the last) packet is of size > smaller than MSS... (hat tip to Alex Zimmermann). >=20 >=20 > so it should enter fast recovery using the > proportional rate reduction algorithm [IMC11PRR]. >=20 > I think, that sentence can end after "enter fast recovery". The specifics > how the sender performs fast recovery should be regarded out of scope of > this doc... >=20 >=20 >=20 > Nit: an RTO. / a RTO. >=20 > Nit: insequence ACKs / in-sequence ACKs >=20 >=20 >=20 > Overall, I still think this is a very valuable mechanism and the document > is very well written, giving a lot of relevant references. >=20 >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Tue Mar 12 15:17:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE5E11E812D for ; Tue, 12 Mar 2013 15:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z0d9t4-rb-W for ; Tue, 12 Mar 2013 15:17:33 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id DBD1311E8110 for ; Tue, 12 Mar 2013 15:17:32 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CMHUV6003488 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 23:17:31 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 12 Mar 2013 23:17:30 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , Nandita Dukkipati , "tcpm@ietf.org" Date: Tue, 12 Mar 2013 23:17:28 +0100 Thread-Topic: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt Thread-Index: Ac4fF61/OifVq+xqSwKE7H+joAcvkwAVhqBg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C24@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24A82856@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24A82856@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 22:17:33 -0000 > editorial: The enumerated list after "Timeouts can occur in a=20 > number of situations, such as the following:" could use=20 > "hanging" indentation to make the numbering stand out (or use=20 > a numbered list with format (%d) ). (As a personal taste, I'd=20 > also have an empty line between the one sentence for the=20 > bullet description, and the more detailed explanation). Some remarks, with chair hat off: I also had difficulties parsing some description in the current draft, in p= articular Section 3.1, page 10. Apparently, two lists intersect without ide= ntion, both using (a)... > One minor nit-pick: >=20 > If (SND.FACK - SND.UNA) > dupack threshold: > -> Invoke Fast Retransmit and Fast Recovery. >=20 > Dupack threshold is usually stated in packets, while=20 > Snd.fack/snd.una is (usually) in bytes. For byte-oriented=20 > stacks, the clause might be better stated as: >=20 > If (SND.FACK - SND.UNA) > ((dupack threshold - 1)*MSS + 1): > -> Invoke Fast Retransmit and Fast Recovery. >=20 > This will work for most instances, where one (the last)=20 > packet is of size smaller than MSS... (hat tip to Alex Zimmermann). I don't think that this is a nit only. When reading this document, I indeed= wondered how a byte-based stack would implement TLP. In addition, I also wondered whether the TLP loss detection algorithm is in= deed robust to packet reordering, in particular "stange" loss/reordering pa= tterns. To be honest, I haven't thought of this in detail. But it would be = certainly important to understand if the loss detection heuristic could fai= l in certain corner cases. Michael= From ycheng@google.com Wed Mar 13 11:09:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D4C21F8E67 for ; Wed, 13 Mar 2013 11:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CjjVu7sztmX for ; Wed, 13 Mar 2013 11:09:08 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A154D21F8E6E for ; Wed, 13 Mar 2013 11:09:06 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so1453469lab.23 for ; Wed, 13 Mar 2013 11:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=7KJ0NX+JkfN6dFeHMjyuW7VE+Dinq3TecokOPrr0YPg=; b=FC92s4sqvA93D1XsCgmMmWcjlqk70DKAzA1FEsjTgWmu5Y43QiC3yKcuLn5bTODeNL 58RPATKMudZu1c2epvGP/TdCZlAXy6j6KvFpdmgE39gArlvLLz/Mxswy7AbggXexkCWm UDmyti3AXjyWcLa0O9w0FZFmAVhqxMkeYWOUT8LBeIVWnOMQNegN+YRBSDWl5+d9RyUX DrupYZYxc6F8ykjukp+I7lLUwLi+JN/eyh5YuWMSJUyXXeEqLkq25n+Vc3GiHyGCKQj0 guH2E0x1Vm4Jye+NpJkyylI0x5aq6L3sGkJ1WXXfr6dAH9fzd0KezwMmAhrhJBPt6/wo j2QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=7KJ0NX+JkfN6dFeHMjyuW7VE+Dinq3TecokOPrr0YPg=; b=dSaYvN4FoOJZ4JatX04bIVyzkuFj8Diu0c+NCgvQorAx9G2+9OpH5iAtGkAhc3FmCc +JV/OC7+8SdPsp3qPHD8fVVS74SJVCAplYGt9FdgqKTMywaO+45EXmeiY3C1FQWLXFdt 44ElNoYmS8b2WdgCN9eXA9286uN8R/QOzO541kwN5g8vPypMnDOYH28WSa78Q4SjZh47 UIpAga9P72jO8O1ZNcbKYCN2K1xDx8HnmmyirwkzH0afdHykiVFbFIjZmr3wo78iLOY/ Nf18kcU90UbCVFYlEHA4uIfXtSw7J+l+rYnKtnThveFCOFMBswad6FjXVFKRXsUq3ZfH XICw== X-Received: by 10.112.88.35 with SMTP id bd3mr8190745lbb.56.1363198145333; Wed, 13 Mar 2013 11:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.52.48 with HTTP; Wed, 13 Mar 2013 11:08:45 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C24@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24A82856@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C24@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Wed, 13 Mar 2013 11:08:45 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkzizhG2y3fBWBpAyrnV1mKQljBO7gOGigfJAyP7kNmI3N/K1Lk5VtbKv/78j69FxC08uL7laXi6QXUF3a3861iVYAg3Y34HKn+WfK6HCYvV4RV5SWx7f9faVKen7P6EDwiKOhr2SQtcwvuzpGVfyJu6a6DUD4Av54BdvM7Debi8qTUtSdjz1AHOw7E5Uu7BbCTBc+/ Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 18:09:08 -0000 On Tue, Mar 12, 2013 at 3:17 PM, Scharf, Michael (Michael) wrote: >> editorial: The enumerated list after "Timeouts can occur in a >> number of situations, such as the following:" could use >> "hanging" indentation to make the numbering stand out (or use >> a numbered list with format (%d) ). (As a personal taste, I'd >> also have an empty line between the one sentence for the >> bullet description, and the more detailed explanation). > > Some remarks, with chair hat off: > > I also had difficulties parsing some description in the current draft, in= particular Section 3.1, page 10. Apparently, two lists intersect without i= dention, both using (a)... > >> One minor nit-pick: >> >> If (SND.FACK - SND.UNA) > dupack threshold: >> -> Invoke Fast Retransmit and Fast Recovery. >> >> Dupack threshold is usually stated in packets, while >> Snd.fack/snd.una is (usually) in bytes. For byte-oriented >> stacks, the clause might be better stated as: >> >> If (SND.FACK - SND.UNA) > ((dupack threshold - 1)*MSS + 1): >> -> Invoke Fast Retransmit and Fast Recovery. >> >> This will work for most instances, where one (the last) >> packet is of size smaller than MSS... (hat tip to Alex Zimmermann). > > I don't think that this is a nit only. When reading this document, I inde= ed wondered how a byte-based stack would implement TLP. > > In addition, I also wondered whether the TLP loss detection algorithm is = indeed robust to packet reordering, in particular "stange" loss/reordering = patterns. To be honest, I haven't thought of this in detail. But it would b= e certainly important to understand if the loss detection heuristic could f= ail in certain corner cases. can you give an example of the reordering problem you have in mind? > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From internet-drafts@ietf.org Wed Mar 13 11:36:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA3D21F8C1A; Wed, 13 Mar 2013 11:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmj0juZGY7nS; Wed, 13 Mar 2013 11:36:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4E21F89CB; Wed, 13 Mar 2013 11:36:34 -0700 (PDT) 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.42 Message-ID: <20130313183634.24197.72852.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2013 11:36:34 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 18:36:35 -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 : Shared Use of Experimental TCP Options Author(s) : Joe Touch Filename : draft-ietf-tcpm-experimental-options-05.txt Pages : 12 Date : 2013-03-13 Abstract: This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection. It uses a new IANA TCP experiment identifier, and is also robust to experiments that are not registered and those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ycheng@google.com Wed Mar 13 12:50:53 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D2721F8E0F for ; Wed, 13 Mar 2013 12:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMn-pJ0TxbL6 for ; Wed, 13 Mar 2013 12:50:51 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0257521F8DC9 for ; Wed, 13 Mar 2013 12:50:50 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id gg13so1272503lbb.16 for ; Wed, 13 Mar 2013 12:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=/qEutrmXbwbhPeZefd2hLbH26/KBpiw0i7cHJU43dYA=; b=MALmiKVDpOOc0ZQ20c3f2PCC92y+GBoT/Vk0skVR8qMATNS19eUClXoex8nuw+gR3T Qbj6h6d4jUqptpDFdYxRaiM84LQqCnEUH9IWhruXd9A9yWQZZ4x6LBbzQE9VE8oY+VJW XbDDQuhW/ojCaLGAJaWss3tVAkhw8jWOrMd3bwQlfQsl7RFpSDiW+dvNWvrhQYzt9qWp YsGXBnIZVKWE1RXPTGxIXU7O+W/N1WqNpWOHuegSOCepbSBeJ78X3BsZeL0w8v2LozCT o6WT0sBrTfV8LhwbISGeESB5uyCg67zB8/w7C/40bco5dDz7hBXE5oXC/aaCcWtF0cRk DaLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=/qEutrmXbwbhPeZefd2hLbH26/KBpiw0i7cHJU43dYA=; b=hQ47pCnSqY3EODvZtjTyIzycC7RBBio+eIBh2eS5OJbNTuUNDO1Xveufjr+L/mr7BP hWGpQgWHYIPzAVo0hBv6GAhGxrWuHhnP/SsmS6Teaxf8kRmO9GHPsToxt7lsbD+3bN+h WLjxmsXFMrJpArlBnj3WgmYsAjw/U7licqZKR28ibyvHpdyiwvZ2A7MVaGTCwycvv9fg G7RA9uuYhWcWfCRZz3is1D46ds6e2knqtfAcGBdm68430UyQlJU+tLmIb8xfeH4lGW6v RComrd+TEkhuO3nyEW7rVzZ4P6TS/qM0sWVuqanXwNzUpZnUcH2sw/cgqropWiwiEENi aEDw== X-Received: by 10.112.27.199 with SMTP id v7mr62862lbg.44.1363204249730; Wed, 13 Mar 2013 12:50:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.52.48 with HTTP; Wed, 13 Mar 2013 12:50:27 -0700 (PDT) In-Reply-To: <20130313183634.24197.72852.idtracker@ietfa.amsl.com> References: <20130313183634.24197.72852.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Wed, 13 Mar 2013 12:50:27 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkCors8FVMJ7Ep8gTts7tEiMxJF+MKikW5cCNV8H6+t0SCd2XlfxDAMoUOfopzbhXjl5hsMuBMgebjRJHW0qONlMtShTcZSE5VGYd23gEOIhr6lkB5M/LHdOdmj99178pDee5O7krHoHwBq5ajqKLDAzqKBWIDrxnMJ0L8yfbU0qp081xSu1CnTUdw/MpXYWU//txVk Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 19:50:53 -0000 I-D looks fine to me except one question: is ExID unique across 254 and 253? i.e., do 254-0xf989 and 253-0xf989 both mean Fast Open (currently uses 253-0xf989)? On Wed, Mar 13, 2013 at 11:36 AM, wrote: > > 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. > > Title : Shared Use of Experimental TCP Options > Author(s) : Joe Touch > Filename : draft-ietf-tcpm-experimental-options-05.txt > Pages : 12 > Date : 2013-03-13 > > Abstract: > This document describes how the experimental TCP option codepoints > can concurrently support multiple TCP extensions, even within the > same connection. It uses a new IANA TCP experiment identifier, and > is also robust to experiments that are not registered and those that > do not use this sharing mechanism. It is recommended for all new TCP > options that use these codepoints. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Wed Mar 13 13:07:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C566F11E8129 for ; Wed, 13 Mar 2013 13:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uBZIn-Wezlf for ; Wed, 13 Mar 2013 13:07:52 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 46EB511E80AD for ; Wed, 13 Mar 2013 13:07:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,838,1355126400"; d="scan'208";a="246682571" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 13 Mar 2013 13:07:51 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2DK7pkd005165; Wed, 13 Mar 2013 13:07:51 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 13:07:50 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] draft-ietf-tcpm-fast-open Thread-Index: Ac4ei2ZE3Ezr/UKdRny6hlzWfklkCgAPgIuAAAIiugAAAUl3gAAELXQAAD5pAqA= Date: Wed, 13 Mar 2013 20:07:49 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A885A6@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.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.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 20:07:52 -0000 A few nits: Section 2.1, 3rd paragraph should be a properly formatted list: a) the receiver host receives data in a duplicate SYN after it has forgotten it received the original SYN (e.g. due to a reboot); b) the duplicate is received after the connection created by the original SYN has been closed and the close was initiated by the sender (so the receiver will not be protected by the 2MSL TIMEWAIT state). Page 5, first paragraph: TFO goes one step further to allow server-side TCP to process and send up data to the application layer before 3WHS is completed. "send data up to the" reads better... Section 3: Line breaks before the list would look better: future TCP connections to exchange data during 3WHS. Requesting a Fast Open Cookie: 1. The client sends a SYN with a Fast Open Cookie Request option. Section 4.1.2: the implementation is often server specific. Remove the "often" (alternatively, an example of a not server specific key = rotation scheme would be needed. But that somehow collides with the text be= fore this). The Null cookie is not defined (last paragraph, same section). As mentioned= earlier, if there exists a special entity (NULL cookie, ie. filled with al= l zeros or something), this should be documented if the client is to do any= thing with it (like purging it's TFO cookie cache for that server). In that= context however, the null cookie can be any arbitrary binary blob that is = just not verified on the server, for debugging purposes. Further, if the nu= ll cookie might look like a regular cookie (all zeros may also be a valid c= ookie, for example), this may require documentation of a special case when = a collision between a valid cookie and the null cookie happens (albeit, the= impact would be minimal, I believe; an impacted client would simply not be= allowed TFO until a key change; so this may not even require any code chan= ge at all. The abbreviation TCB (TCP control block) is not defined in the document (bu= t I think writing it out before first use and not pointing to rfc793 there = should do). Section 4.2.2, Step 1b). Is the text stating 536 bytes clear enough, that t= his does not necessarily mean 536 data bytes (TCP option size must be subtr= acted)? Perhaps a reference to RFC6691 might be good here... Also Section 4.2.2 the formatting (indentation) seem to have gone awry... Section 6.2: 3., 4. Paragraph "But she may be" - while I like the thought that a malicious adversary is a= female (to some extent :), I think that may be s/she/the attacker/g. That'= s still gender neutral. Section 6.3: s/ outweigh/ outweight/ ? Best regards, Richard Scheffenegger From touch@isi.edu Wed Mar 13 13:56:31 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413F411E8103 for ; Wed, 13 Mar 2013 13:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.292 X-Spam-Level: X-Spam-Status: No, score=-103.292 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYkHfUNjSWIU for ; Wed, 13 Mar 2013 13:56:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB2811E80FE for ; Wed, 13 Mar 2013 13:56:30 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2DKtt0V012372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2013 13:56:08 -0700 (PDT) Message-ID: <5140E7DC.8050704@isi.edu> Date: Wed, 13 Mar 2013 13:55:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Yuchung Cheng References: <20130313183634.24197.72852.idtracker@ietfa.amsl.com> 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: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 20:56:31 -0000 Hi, Yuchung, On 3/13/2013 12:50 PM, Yuchung Cheng wrote: > I-D looks fine to me except one question: is ExID unique across 254 > and 253? i.e., do 254-0xf989 and 253-0xf989 both mean Fast Open > (currently uses 253-0xf989)? Yes. The ExID would be for either or both TCP experimental option numbers. Joe > > > On Wed, Mar 13, 2013 at 11:36 AM, wrote: >> >> 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. >> >> Title : Shared Use of Experimental TCP Options >> Author(s) : Joe Touch >> Filename : draft-ietf-tcpm-experimental-options-05.txt >> Pages : 12 >> Date : 2013-03-13 >> >> Abstract: >> This document describes how the experimental TCP option codepoints >> can concurrently support multiple TCP extensions, even within the >> same connection. It uses a new IANA TCP experiment identifier, and >> is also robust to experiments that are not registered and those that >> do not use this sharing mechanism. It is recommended for all new TCP >> options that use these codepoints. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-05 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-05 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 ycheng@google.com Wed Mar 13 15:37:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66C821F8952 for ; Wed, 13 Mar 2013 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfhCVX-wnw1i for ; Wed, 13 Mar 2013 15:37:48 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5630421F8A99 for ; Wed, 13 Mar 2013 15:37:48 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id ge1so1393061lbb.1 for ; Wed, 13 Mar 2013 15:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=5FNeV52z79PBdmOFc5MLyNbYGoMc6bQFL9e9OXC4P48=; b=EfddnMa5A2qU8wAacfzpph/9ICrm/Qs81tsFF9aB5Ly3iL221BAS6NG1S/D6KX4psh WNyH2jX9YNEDjIALOmNXyus8Uv6DL8YuOjygL4aJo+uND5lC9Y1Qe94vJiooV7mhudrs Qp1neTgKVjaRUr//r7agFkt8d7kuxutKLWIukzINs0HO5MBE4cl6omoAVEtjHK7EYVs3 emw4UootL9B9v5q+riPKCwj9XldCjJqVcesbYc56djPVmoTHAgk8QzzNnjOtvwFvA22k LpHZoL10XAz76K/xTVCh9gSU66M6BghFg/ctLy/RnK9fyjpZHN8SUA6pPxtJGvy3F4fb 33Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=5FNeV52z79PBdmOFc5MLyNbYGoMc6bQFL9e9OXC4P48=; b=ZZxedFJGTvoq2zzi4mgeLfdKsA8DzIoZHkN9I021b51aEJKNBa8L/FOUOUWq9FJMLt +spX7hp9OY4JDbFV9urmyyBzQHRcH98eDXkfGjGPxAnokst7ZJssZkD+7QvWoE9bGAum msJpEdEpvLFTh10Po8aT7IUXiMKRRpS2Ysfc201e1X6celW9BfXJkWYgjAvpFWAFAjUl oASw63OItZkHYagYHeDovRtrJbW5tiXiJRW7Od9RyeoSwEVSjyzc3TUpngZc7xOb2ULa eI5Uz/UECMLjlP1tiU4AlKaJjJfN3TEV0P65VyYzAjOtY4kVSQlQ57PJEntRWG/6hIr9 izww== X-Received: by 10.152.104.80 with SMTP id gc16mr22919lab.49.1363214267074; Wed, 13 Mar 2013 15:37:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.52.48 with HTTP; Wed, 13 Mar 2013 15:37:26 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Wed, 13 Mar 2013 15:37:26 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlPRr8SD+0BGCO9j+UsuMvAG5YdeK93TbS93BxU3dKEVLbhafozzVVzJW3HEZz4yVLaQzD28kwVMwz+9pkBbnDTCa9og7fs4jn2K9n5XFknzwGyYBhFsAbH706/jjjAIAm+ZzYkFYdqlshC87m7mhpSpEpQY231T9CxDVs9IXCmj+1sx3mKsceBLtIy0FBBnsK96LsA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 22:37:49 -0000 On Mon, Mar 11, 2013 at 4:07 PM, Scharf, Michael (Michael) wrote: >> This statement >> >> " 6. Advance to the SYN-RCVD state. If the FastOpened >> flag is set, the >> server MUST follow the congestion control >> [RFC5681], in particular >> the initial congestion window [RFC3390], to send >> more data packets." >> >> seems to imply to me that a stack either uses fast open >> or IW10, but MUST not use them both, right? If so, I think >> that this requires guidance for the app developer do decide >> whether to select either IW10 or fast open. >> >> >> >> If this is not your intention, i. e., it should be >> allowed that IW10 and fast open are combined, this should be >> explicitly explained in the document, imho. IW10 will >> probably be an RFC when this document gets published, and >> their relationship is pretty apparent. As I said, I really >> think that people will ask this question. >> >> >> No I do not imply that. My intention is to say TFO should >> follow TCP CC, whatever IETF RFC recommends. This is the >> answer to your or similar questions like can TFO work with >> any other changes to CC). > > The text has a MUST for RFC5681 and RFC3390. This prevents IW10, imho. As= a result, I think that your text does not describe what you want. But if y= ou replace that MUST for IW3 to something less restricitive, you will need = to have to comment on congestion control. could you suggest some text if you agree on my intention? I am not sure why citing the current RFCs in a draft precludes future updates or related experimental RFCs. By that rationale, any draft with text "MUST follow RFCxxx" should change to "MUST follow RFCxxx but also the future updated version but does not preclude using related experimental RFCs". > >> > * Section 4.1.3: "Since TFO is enabled on a per-service >> > port basis but cookies are independent of service ports, >> > clients' cache should include remote port numbers too." Is it >> > possible that there are different cookies for different >> > service ports on the same server IP? This is probably not >> > what the specification intends, but I wonder whether it would >> > be a possible >> > >> > of course, why not? the server applications (on different) >> > may prefer to use different secrets, whatever reason they >> > think. in our Linux implementation but we'd like to keep the >> > option open. >> >> >> ... but that question implies interoperability, because >> the client SW design depends on what the cookie is about. Not >> every TCP endpoint is Linux ;) >> >> Please help me understand by an example of how sever >> applications on port 17483 and port 432 using two masters >> keys talking to different TFO client implementation may break. >> >> A TFO cookie is only meaningful for server applications that >> permit TFO. > > I was thinking of one BSD client talking to ports 17483 and 432 on the sa= me destination IP address. That BSD client has to know whether to query for= one or two cookies. The TFO is per dst-ip-port, so the client TCP stack should request cookies from both port. > > And actually I still struggle with understanding which of the two options= is the better one from a protocol perspective. > >> > system design. I also wonder if that could improve >> > security (e. g., possibly a shorter cookie)? >> > >> > * Section 4.2.2: Thanks for adding the text on >> > simultaneous open! I think that this scenario can only occur >> > if fast open is activated on the corresponding ports on both >> > endpoints, i. e., it is really a corner case. But are the >> > fast open cookie semantics in that corner case indeed clear? >> > In particular, I wonder whether one can savely distinguish >> > between a client "Fast Open Cookie Request Option" (Sect. >> > 4.1.1) and a server "null cookie" (Section 4.1.2). >> > >> > >> > I am not sure I understand the problem. When a (simul open) >> > client sends a SYN w/ FO cookie request option, he gets a >> > SYN-ACK that may have the Fast Open cookie option (from the >> > other simul-open client) >> >> >> If in a simulatenous open both SYNs carry an empty FO >> cookie option, what is the correct behavior? >> >> >> >> On receiving the empty FO cookie option, aka FO cookie >> request, the server (also a simul-open client) responds the >> cookie in SYN-ACK if it supports TFO on that port. >> details are in Section 4.2.2 " Server: Receiving SYN and >> responding with SYN-ACK" > > With simulatous open, I think speaking of client and server should be avo= ided. > >> > The null cookie is only used by server responding SYN-ACK to >> > a (simul open) client sending SYN-data with Fast Open cookie >> > option, not FO cookie "request" option. >> >> >> I don't understand. In simulateous open, the role of >> client and server is fuzzy. And the distinction between >> client and server is quite inherent to fast open. This is why >> I wonder about that corner case.. >> >> >> If not too much trouble please give a exact case of how >> simul. fast open won't work. I don't understand your case. sorry. > > I don't claim that it does not work. I just want to understand whether mo= re text is needed or not. And whether the procotol state engines are design= ed for that case, or not. Maybe it is trivial. Maybe not. > > For instance, this pattern seems to result in the situation that both end= points get a valid cookie, i. e., both A and B are client and server at the= same time: > > TCP A TCP B > ______________ _____________ > CLOSED CLOSED > > #1 SYN-SENT ----> ........... CLOSED > > #2 SYN-SENT ..... <---------- SYN-SENT > > #3 SYN-SENT ..... ----------> SYN-RCVD > > #4 SYN-RECV <---- ........... SYN-RCVD in a simul. open #4 should be #4 SYN-RECV <---- ........... SYN-RCVD It seems you are looking at cookie request during a "regular" TCP simultaneous open? not simultaneous Fast Open? Since cookie request is just passing options, and the receiver of the SYN always respond with SYN-ACK with the cookie (null or non-null), there shouldn't be any problem, just like other option negotiation. > > #5 ESTABLISHED <---- ---------- ESTABLISH= ED > > #6 ESTABLISHED ----- ---------> SYN-RCVD > > At least, the document does not state right now that one TCP endpoint can= be both fast open client and server for one connection at the same time (e= ven if it is unlikely in practice). This seems also imply that in the next = connection, if simultaneous open is used again, there could be bi-direction= al fast open with data in SYNs. > > Furthermore, it is unclear to me what happens if #4 and #5 get reordered.= Does TCP A process the cookie request from B, or not? > > Sorry, I haven't thought of more complicated cases so far. I've never stu= died the simulateous open code in real stacks. > > > As a side note, there seems to be a general inconsistency issue in the dr= aft: Section 4.1.1 does apparently not foresee that a client gets an empty = cookie option, while this is allowed in Section 4.1.2, right? > > Michael From ycheng@google.com Wed Mar 13 23:04:53 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58AB21F8AD8 for ; Wed, 13 Mar 2013 23:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxvZo6cmRYE0 for ; Wed, 13 Mar 2013 23:04:53 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A40C821F8ACE for ; Wed, 13 Mar 2013 23:04:52 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so2038685lab.3 for ; Wed, 13 Mar 2013 23:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=+xW3MPI6mj/VFfXvYDGfH+p2QuJuyv2chCpjILlXpK0=; b=EMpvyesWfs+tsuAS88TxcSwbhL54Z8ZBWwsJZWzzB7ILrkUPVFhdpZ0zo/id4ESZ3f EyFQsMjgSBdwiJVCNKaKuEbIPr8itMId4f/mg0vHZZ+neksVQXkrDW8WyU8DlbLtijc6 tgDUB52t3OYGso+aKMEWu3kDyAwECGueoBko4n9O5qTeDyjph7JCwDaNm9vpAtCTg+eN KD3leRuFnKxCiYMKs48RzDakQspi8BHnP/wv8Y1cb1jDT4fSoWzg6IuvXcnetf9iWwkb bvxopblKLKRiJG7InrESYdt69v78wOVf5t7PznDcLAyYMjEu+b1s+FAIkfTCLPtwvZaR hsCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=+xW3MPI6mj/VFfXvYDGfH+p2QuJuyv2chCpjILlXpK0=; b=OhQo23FHdMFf6ZjA/i2DnwpVHHhY9CO36xGUBdyjQ8LYRePz5KXZiNjSbKt3qnE+2u AljjR6eQVOd12A0vS08//LhKuyJ/xbbeMlFtRN1V588ILd7Pz6A4SfquobMTm2Isrvk6 3PauF+DBmnxhMFO/uwNuwyGSlHSyhKtICOe6tHymNlpnmrKvLV0SypRemT/s/vtto1Cs 1XWjJxhpa74RxrXboBzF4E/ISVGxK2OyffcIkrva+S1SOom2z+sn1ryJpUfrh9Mwc30Q cIDgW07ijP+jueKBTeWSW/64TGkfNY3xdroIe+z/maFYU0EW2fAYbZAmi1AUTx+gerGj aWNg== X-Received: by 10.152.106.5 with SMTP id gq5mr1040493lab.5.1363241091348; Wed, 13 Mar 2013 23:04:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.52.48 with HTTP; Wed, 13 Mar 2013 23:04:31 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24A885A6@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BDF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6BE4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F24A885A6@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Wed, 13 Mar 2013 23:04:31 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn3NbwCJ7Op+4zJ9ANpPzEVZAfEqUuj6w/AMAKq1RV1xK4Cs80U8P31Jr3u+Kuw3srusDggpwfsuJRzirk7ERgnd7GQojCPoDCnva1GFpwcRl9qKK4fy92ThYMP94BR5IBKDAaZ5/3yFTu2s+emgRZ//VCXb3oYGBBX4YuAFUSNLnyXAwhx+ZFfgH0tQyRTLzR/cyiP Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fast-open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2013 06:04:53 -0000 On Wed, Mar 13, 2013 at 1:07 PM, Scheffenegger, Richard wro= te: > A few nits: > > Section 2.1, 3rd paragraph should be a properly formatted list: > > a) the receiver host receives data in a duplicate SYN after it has > forgotten it received the original SYN (e.g. due to a reboot); b) the > duplicate is received after the connection created by the original > SYN has been closed and the close was initiated by the sender (so > the receiver will not be protected by the 2MSL TIMEWAIT state). > > > Page 5, first paragraph: > > TFO goes one step further to allow server-side TCP to process and > send up data to the application layer before 3WHS is completed. > > "send data up to the" reads better... > > > Section 3: > Line breaks before the list would look better: > > future TCP connections to exchange data during 3WHS. > > Requesting a Fast Open Cookie: > > 1. The client sends a SYN with a Fast Open Cookie Request option. > > Section 4.1.2: > the implementation is often server > specific. > > Remove the "often" (alternatively, an example of a not server specific ke= y rotation scheme would be needed. But that somehow collides with the text = before this). > > > The Null cookie is not defined (last paragraph, same section). As mention= ed earlier, if there exists a special entity (NULL cookie, ie. filled with = all zeros or something), this should be documented if the client is to do a= nything with it (like purging it's TFO cookie cache for that server). In th= at context however, the null cookie can be any arbitrary binary blob that i= s just not verified on the server, for debugging purposes. Further, if the = null cookie might look like a regular cookie (all zeros may also be a valid= cookie, for example), this may require documentation of a special case whe= n a collision between a valid cookie and the null cookie happens (albeit, t= he impact would be minimal, I believe; an impacted client would simply not = be allowed TFO until a key change; so this may not even require any code ch= ange at all. null cookie is a cookie option with zero option length. if the active SYN sender sends such an option, it is called a Fast Open Cookie Request. For a SYN-receiver (that sends such an option in SYN-ACK), it's called null-cookie. I will add that to the document and fix other formatting and wording issues mentioned in this email. thx > > > The abbreviation TCB (TCP control block) is not defined in the document (= but I think writing it out before first use and not pointing to rfc793 ther= e should do). > > > Section 4.2.2, Step 1b). Is the text stating 536 bytes clear enough, that= this does not necessarily mean 536 data bytes (TCP option size must be sub= tracted)? Perhaps a reference to RFC6691 might be good here... > > Also Section 4.2.2 the formatting (indentation) seem to have gone awry... > > > Section 6.2: 3., 4. Paragraph > "But she may be" - while I like the thought that a malicious adversary is= a female (to some extent :), I think that may be s/she/the attacker/g. Tha= t's still gender neutral. > > Section 6.3: s/ outweigh/ outweight/ ? > > > > Best regards, > > Richard Scheffenegger > > From michael.scharf@alcatel-lucent.com Thu Mar 14 10:57:11 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4311E80DF for ; Thu, 14 Mar 2013 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAxPVrQpN0TQ for ; Thu, 14 Mar 2013 10:57:08 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF9021F8D03 for ; Thu, 14 Mar 2013 10:57:06 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2EHv4HL005768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 14 Mar 2013 18:57:04 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 14 Mar 2013 18:57:04 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Thu, 14 Mar 2013 18:57:02 +0100 Thread-Topic: Additional feedback on draft-gont-tcpm-tcp-seq-validation-00 Thread-Index: Ac4g3VTnhVJLPBuRQY6ZVMnIV2XTTQ== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C8A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [tcpm] Additional feedback on draft-gont-tcpm-tcp-seq-validation-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2013 17:57:12 -0000 Dear all, In the TCPM meeting, there has been some interest in draft-gont-tcpm-tcp-se= q-validation-00, which documents issues of RFC 793 with TCP simultaneous op= en, TCP self connects, TCP simultaneous close, and Simultaneous Window Prob= es. However, the chairs have the impression that some TCPM contributors left th= e room for the parallel irtfopen session, and therefore the feedback from t= he room might not be representative. We therefore would like to ask for add= itional feedback on this draft on the mailing list. Specifically, we are interested in feedback on the following two questions,= given that at least a subset of the issues is already known for some time: (1) Whether the problems described in the draft are relevant and should be = addressed by a new milestone in the TCPM charter. (2) If the updates to RFC 793 suggested in draft-gont-tcpm-tcp-seq-validati= on-00 are the right way to address the problems, or if there are other know= n solutions (possibly implemented already). Any feedback would be very welcome! Michael From rs@netapp.com Thu Mar 14 13:38:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D2A21F909E for ; Thu, 14 Mar 2013 13:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.695 X-Spam-Level: X-Spam-Status: No, score=-9.695 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySF8nAXwG9E6 for ; Thu, 14 Mar 2013 13:38:47 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 19D0E21F909C for ; Thu, 14 Mar 2013 13:38:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,846,1355126400"; d="scan'208";a="30878370" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 14 Mar 2013 13:38:46 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2EKck0M000021; Thu, 14 Mar 2013 13:38:46 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 14 Mar 2013 13:38:45 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 13:38:45 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Thread-Topic: Additional feedback on draft-gont-tcpm-tcp-seq-validation-00 Thread-Index: Ac4g3VTnhVJLPBuRQY6ZVMnIV2XTTQAE5KvA Date: Thu, 14 Mar 2013 20:38:44 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AAC97A@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C8A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C8A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.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.116] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Additional feedback on draft-gont-tcpm-tcp-seq-validation-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2013 20:38:47 -0000 Hi, As mentioned on the microphone, I think this draft is valuable and basicall= y addresses an documentation bug/errata (Errata ID: 3305, reported in 2012 = by Botong Huang, but preceeded by the IETF73 mentioned in the Acknowledgeme= nts). However, I suggest to remove the verbatim quotation of RFC793; I observe th= at the formatting allows a "swap" of the two relevant pages of RFC793 with = the fixed mechanism. I don't know if a document, that is to stand on its ow= n needs to adhere that strictly to the original wording and structure. Also, as an implementer I would want the "meat" sooner, and the detailed de= scription what the problem is and how the change solves it, later (swap sec= tions 3 and 4, basically). There was some question, if other points that go into TCP window validation= should be mentioned in this document. I think it would be beneficial to ha= ve everything relevant in that area in one complete document, rather than s= pread across a few documents. In general, I like efforts that document the current implemented TCP stack = behavior, fix documentation errata/bugs or speak about deployed and useful = mechanisms, that haven't been documented in the IETF so far. I have a draft sitting around, to describe TCP SACK Lost Retransmission Det= ection (LRD), as performed by Linux TCP since that stack supports SACK. Int= erestingly, there are also some research papers independent from Linux, dis= cussing the properties of an optimal SACK stack that recovers lost retransm= issions, and matches the runtime behavior of Linux. If there are a few revi= ewers for this draft, I would like to share that draft before bringing it t= o the WG for formal processing. Any takers? Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Scharf, Michael (Michael) > Sent: Donnerstag, 14. M=E4rz 2013 18:57 > To: tcpm@ietf.org > Subject: [tcpm] Additional feedback on draft-gont-tcpm-tcp-seq-validation= - > 00 >=20 > Dear all, >=20 > In the TCPM meeting, there has been some interest in draft-gont-tcpm-tcp- > seq-validation-00, which documents issues of RFC 793 with TCP simultaneou= s > open, TCP self connects, TCP simultaneous close, and Simultaneous Window > Probes. >=20 > However, the chairs have the impression that some TCPM contributors left > the room for the parallel irtfopen session, and therefore the feedback > from the room might not be representative. We therefore would like to ask > for additional feedback on this draft on the mailing list. >=20 > Specifically, we are interested in feedback on the following two > questions, given that at least a subset of the issues is already known fo= r > some time: >=20 > (1) Whether the problems described in the draft are relevant and should b= e > addressed by a new milestone in the TCPM charter. >=20 > (2) If the updates to RFC 793 suggested in draft-gont-tcpm-tcp-seq- > validation-00 are the right way to address the problems, or if there are > other known solutions (possibly implemented already). >=20 > Any feedback would be very welcome! >=20 > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Fri Mar 15 09:41:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741CD21F8838 for ; Fri, 15 Mar 2013 09:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.92 X-Spam-Level: X-Spam-Status: No, score=-9.92 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYynvvM2mCuy for ; Fri, 15 Mar 2013 09:41:55 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12E21F84AE for ; Fri, 15 Mar 2013 09:41:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,852,1355126400"; d="scan'208,217";a="31135258" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 15 Mar 2013 09:41:51 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2FGfp9q012901; Fri, 15 Mar 2013 09:41:51 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 15 Mar 2013 09:41:51 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Fri, 15 Mar 2013 09:41:50 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng , "Nandita Dukkipati (nanditad@google.com)" , "Neal Cardwell (ncardwell@google.com)" Thread-Topic: TLP Thread-Index: Ac4hmeB25OSPuIOLT5++7iOSx3bHoA== Date: Fri, 15 Mar 2013 16:41:49 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.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.118] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F24AB1D79SACEXCMBX02PRDh_" MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2013 16:41:59 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F24AB1D79SACEXCMBX02PRDh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nandita, Yuchung, Neal, this might be a stupid idea, but I bring it up anyway... TLP is to elicit an ACK from the receiver at the end of a burst, where some= of the ultimate segments might have been lost... What would happen, if the sender (which knows the size of the burst, and if= the stream actually ends...) would deliberately send the 3 final packets o= f the burst in reverse order, Instead of ... 6 7 8 9, send 6, 9, 8, 7, or 9, 6, 8, 7 (interleaving avoids= exceeding/modifying dupthresh in the no-loss case, and can be extended to = the last N segments). The slides your colleague showed at some point the probability of a packet = loss into a burst, which linearly rises into the length of the .... As one critical issue is to have the receiver "know" how many packets shoul= d come, and to remove the receiver side delACK timer, a deliberate reorderi= ng might achieve this without using timers and blind sending of one (two) p= ackets to the receiver... (Implementing this with HW support is probably more challenging though). Any thoughts on that? Was that route investigated, and if so, what drawback= s did you identify? Best regards, Richard Scheffenegger NetApp rs@netapp.com +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com EURO PLAZA Geb=E4ude G, Stiege 7, 3.OG Am Euro Platz 2 A-1120 Wien --_000_012C3117EDDB3C4781FD802A8C27DD4F24AB1D79SACEXCMBX02PRDh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Nandita, Yuchung, Neal,
 
this might be a stupid idea, but I bring it up anyway...
 
TLP is to elicit an ACK from the receiver at the end of a burst, where= some of the ultimate segments might have been lost…
 
What would happen, if the sender (which knows the size of the burst, a= nd if the stream actually ends…) would deliberately send the 3 final = packets of the burst in reverse order,
 
Instead of … 6 7 8 9, send 6, 9, 8, 7, or 9, 6, 8, 7 (interleavi= ng avoids exceeding/modifying dupthresh in the no-loss case, and can be ext= ended to the last N segments).
 
The slides your colleague showed at some point the probability of a pa= cket loss into a burst, which linearly rises into the length of the …= .
 
As one critical issue is to have the receiver “know” how m= any packets should come, and to remove the receiver side delACK timer, a de= liberate reordering might achieve this without using timers and blind sendi= ng of one (two) packets to the receiver…
 
(Implementing this with HW support is probably more challenging though= ).
 
Any thoughts on that? Was that route investigated, and if so, what dra= wbacks did you identify?
 
Best regards,
 
Richard Scheffenegger

NetApp
rs@netapp.com<= br> +43 1 3676811 3146 Off= ice (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com  

EURO PLAZA
Geb=E4ude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien
 
 
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F24AB1D79SACEXCMBX02PRDh_-- From tsabatini@hotmail.com Fri Mar 15 10:12:43 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4909E21F8788 for ; Fri, 15 Mar 2013 10:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULGq05tlJ6Df for ; Fri, 15 Mar 2013 10:12:40 -0700 (PDT) Received: from bay0-omc4-s2.bay0.hotmail.com (bay0-omc4-s2.bay0.hotmail.com [65.54.190.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2563A21F8548 for ; Fri, 15 Mar 2013 10:12:40 -0700 (PDT) Received: from BAY172-W15 ([65.54.190.200]) by bay0-omc4-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Mar 2013 10:12:39 -0700 X-EIP: [s/ws4UoAhOMCjSH9yvDH3QchCuMeDC2w] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f132ce99-f8cb-4a89-b82e-4dcbf020337b_" From: Anthony Sabatini To: Richard Scheffenegger , Google Yuchung Cheng , Nandita Dukkipati , "Neal Cardwell (ncardwell@google.com)" Date: Fri, 15 Mar 2013 13:12:39 -0400 Importance: Normal In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> MIME-Version: 1.0 X-OriginalArrivalTime: 15 Mar 2013 17:12:39.0328 (UTC) FILETIME=[4BF6EA00:01CE21A0] Cc: tcpm Subject: Re: [tcpm] TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2013 17:12:43 -0000 --_f132ce99-f8cb-4a89-b82e-4dcbf020337b_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All - I agree with RS=2C an important point here is that in a dual network link o= r alternate route scenario you often get just this out of order sequence of= messages. This is why I counseled the use of a "settling time"=2C a perio= d for all relevant packets to arrive in before making a decision so that th= e ordering issues would not affect link retransmission calculations (specif= ically by attaching a timestamp to each incoming packet and not acting on t= he implication of that packet until a set amount of time later). Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 From: rs@netapp.com To: ycheng@google.com=3B nanditad@google.com=3B ncardwell@google.com Date: Fri=2C 15 Mar 2013 16:41:49 +0000 CC: tcpm@ietf.org Subject: [tcpm] TLP =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Hi Nandita=2C Yuchung=2C Neal=2C=0A= =0A= this might be a stupid idea=2C but I bring it up anyway...=0A= =0A= TLP is to elicit an ACK from the receiver at the end of a burst=2C where so= me of the ultimate segments might have been lost=85=0A= =0A= What would happen=2C if the sender (which knows the size of the burst=2C an= d if the stream actually ends=85) would deliberately send the 3 final packe= ts of the burst in reverse order=2C=0A= =0A= Instead of =85 6 7 8 9=2C send 6=2C 9=2C 8=2C 7=2C or 9=2C 6=2C 8=2C 7 (int= erleaving avoids exceeding/modifying dupthresh in the no-loss case=2C and c= an be extended to the last N segments).=0A= =0A= The slides your colleague showed at some point the probability of a packet = loss into a burst=2C which linearly rises into the length of the =85.=0A= =0A= As one critical issue is to have the receiver =93know=94 how many packets s= hould come=2C and to remove the receiver side delACK timer=2C a deliberate = reordering might achieve this without using timers and blind sending of one= (two) packets to the receiver=85=0A= =0A= (Implementing this with HW support is probably more challenging though).=0A= =0A= Any thoughts on that? Was that route investigated=2C and if so=2C what draw= backs did you identify?=0A= =0A= Best regards=2C=0A= =0A= Richard Scheffenegger =0A= =0A= =0A= =0A= NetApp =0A= =0A= rs@netapp.com =0A= =0A= +43 1 3676811 3146 Office (2143 3146 - internal) =0A= =0A= +43 676 654 3146 Mobile =0A= =0A= www.netapp.com =20 =0A= =0A= =0A= =0A= EURO PLAZA =0A= =0A= Geb=E4ude G=2C Stiege 7=2C 3.OG =0A= =0A= Am Euro Platz 2 =0A= =0A= A-1120 Wien =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm = --_f132ce99-f8cb-4a89-b82e-4dcbf020337b_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All -

I agree with RS=2C = an important point here is that in a dual network link or alternate route s= cenario you often get just this out of order sequence of messages. =3B = This is why I counseled the use of a "settling time"=2C a period for all re= levant packets to arrive in before making a decision so that the ordering i= ssues would not affect link retransmission calculations (specifically by at= taching a timestamp to each incoming packet and not acting on the implicati= on of that packet until a set amount of time later).

Tony

Ant= hony Sabatini
200 =3BWest 20th Street
Apt. 1216
New York=2C NY= 10011

Phone: (212) 867-7179
Mobile: (917) 224-8388

 = =3B


From: rs@netapp.com
To: ycheng@google.com=3B nanditad@google.com= =3B ncardwell@google.com
Date: Fri=2C 15 Mar 2013 16:41:49 +0000
CC: = tcpm@ietf.org
Subject: [tcpm] TLP

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Hi Nandita=2C Yuchung=2C Neal=2C
=0A=
 =3B
=0A=
this might be a stupid idea=2C but I bring it up anyway...
=0A=
 =3B
=0A=
TLP is to elicit an ACK from the receiver at the end of a burst=2C whe= re some of the ultimate segments might have been lost=85
=0A=
 =3B
=0A=
What would happen=2C if the sender (which knows the size of the burst= =2C and if the stream actually ends=85) would deliberately send the 3 final= packets of the burst in reverse order=2C
=0A=
 =3B
=0A=
Instead of =85 6 7 8 9=2C send 6=2C 9=2C 8=2C 7=2C or 9=2C 6=2C 8=2C 7= (interleaving avoids exceeding/modifying dupthresh in the no-loss case=2C = and can be extended to the last N segments).
=0A=
 =3B
=0A=
The slides your colleague showed at some point the probability of a pa= cket loss into a burst=2C which linearly rises into the length of the =85.<= /div>=0A=
 =3B
=0A=
As one critical issue is to have the receiver =93know=94 how many pack= ets should come=2C and to remove the receiver side delACK timer=2C a delibe= rate reordering might achieve this without using timers and blind sending o= f one (two) packets to the receiver=85
=0A=
 =3B
=0A=
(Implementing this with HW support is probably more challenging though= ).
=0A=
 =3B
=0A=
Any thoughts on that? Was that route investigated=2C and if so=2C what= drawbacks did you identify?
=0A=
 =3B
=0A=
Best regards=2C
=0A=
 =3B
=0A=
Richard Scheffenegger
=0A= =0A=
=0A= =0A= NetApp
=0A= =0A= rs@netapp.com
=0A= =0A= +43 1 3676811 3146 Offic= e (2143 3146 - internal)
=0A= =0A= +43 676 654 3146 Mobile
=0A= =0A= www.netapp.com<= /u>&nb= sp=3B =3B
=0A= =0A=
=0A= =0A= EURO PLAZA
=0A= =0A= Geb=E4ude G=2C Stiege 7=2C 3.OG
=0A= =0A= Am Euro Platz 2
=0A= =0A= A-1120 Wien
=0A= =0A=
=0A=
 =3B
=0A=
 =3B
=0A=
 =3B
=0A= =0A= =0A= =0A=
_______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm
= --_f132ce99-f8cb-4a89-b82e-4dcbf020337b_-- From jakob.heitz@ericsson.com Fri Mar 15 10:38:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6671521F8691 for ; Fri, 15 Mar 2013 10:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aSzuMVESQ46 for ; Fri, 15 Mar 2013 10:38:51 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C587721F8681 for ; Fri, 15 Mar 2013 10:38:50 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-2e-51435ca92284 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 90.05.02430.AAC53415; Fri, 15 Mar 2013 18:38:50 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 13:38:49 -0400 From: Jakob Heitz To: "Scheffenegger, Richard" , Yuchung Cheng , "Nandita Dukkipati (nanditad@google.com)" , "Neal Cardwell (ncardwell@google.com)" Thread-Topic: TLP Thread-Index: Ac4hmeB25OSPuIOLT5++7iOSx3bHoAACd3pA Date: Fri, 15 Mar 2013 17:38:48 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E1C7E1D@eusaamb109.ericsson.se> References: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E1C7E1Deusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiO6qGOdAg6OLxC32fdjKZNFxZy+L xcp/Z9gttp2cz2Tx5fFVNgdWjwWbSj2WLPnJ5DHj0xe2AOYoLpuU1JzMstQifbsErowXn6cw F0zWr/h7/hZzA2OfRhcjJ4eEgInE4g/T2SFsMYkL99azdTFycQgJHGGUeNa3jxnCWc4o0b69 hxWkik1AR+Lb9S6whIjAVUaJ6zNAHE4OZgEtiTsvF4LZwgICEks2rGIDsUUEBCVWbFvMCmEb Say9/RXI5uBgEVCVaH3uCBLmFfCWOPvuIyOILSQQIvFyyl0WEJtTIFRixq1LYK2MQNd9P7WG CWKVuMStJ/OZIK4GWrXnPDOELSrx8vE/VghbWeL7nEcsEPX5Erden2KE2CUocXLmE5YJjKKz kIyahaRsFpIyiLiexI2pU9ggbG2JZQtfM0PYuhIz/h1iQRZfwMi+ipGjtDi1LDfdyGATIzD6 jkmw6e5g3PPS8hCjNAeLkjhvkOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mnv6JDru+ ax14m3FxwVQRRn9Xo2aenS+28lp9cHKq2BR87yvP+d4666+vtjBullRpPP7afIunOptT5ibe Fdz/X0Y/vRpy65nDniU1bG3v5ealO2Rfs1RWfOm6PKOfg/mK+6Uy18vRn3q19rXIu9QlNuTc yv386visxKUzl9//8n2vFNPFudsDlViKMxINtZiLihMBX5Xli4wCAAA= Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2013 17:38:52 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E1C7E1Deusaamb109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nice! -- Jakob Heitz. ________________________________ From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Sch= effenegger, Richard Sent: Friday, March 15, 2013 9:42 AM To: Yuchung Cheng; Nandita Dukkipati (nanditad@google.com); Neal Cardwell (= ncardwell@google.com) Cc: tcpm (tcpm@ietf.org) Subject: [tcpm] TLP Hi Nandita, Yuchung, Neal, this might be a stupid idea, but I bring it up anyway... TLP is to elicit an ACK from the receiver at the end of a burst, where some= of the ultimate segments might have been lost... What would happen, if the sender (which knows the size of the burst, and if= the stream actually ends...) would deliberately send the 3 final packets o= f the burst in reverse order, Instead of ... 6 7 8 9, send 6, 9, 8, 7, or 9, 6, 8, 7 (interleaving avoids= exceeding/modifying dupthresh in the no-loss case, and can be extended to = the last N segments). The slides your colleague showed at some point the probability of a packet = loss into a burst, which linearly rises into the length of the .... As one critical issue is to have the receiver "know" how many packets shoul= d come, and to remove the receiver side delACK timer, a deliberate reorderi= ng might achieve this without using timers and blind sending of one (two) p= ackets to the receiver... (Implementing this with HW support is probably more challenging though). Any thoughts on that? Was that route investigated, and if so, what drawback= s did you identify? Best regards, Richard Scheffenegger NetApp rs@netapp.com +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com EURO PLAZA Geb=E4ude G, Stiege 7, 3.OG Am Euro Platz 2 A-1120 Wien --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E1C7E1Deusaamb109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nice!

-- Jakob Heitz.

From: tcpm-bounces@ietf.org [mailto= :tcpm-bounces@ietf.org] On Behalf Of Scheffenegger, Richard
Sent: Friday, March 15, 2013 9:42 AM
To: Yuchung Cheng; Nandita Dukkipati (nanditad@google.com); Neal Car= dwell (ncardwell@google.com)
Cc: tcpm (tcpm@ietf.org)
Subject: [tcpm] TLP

Hi Nandita, Yuchung, Neal,
 
this might be a stupid idea, but I bring it up anyway...
 
TLP is to elicit an ACK from the receiver at the end of a burst, where= some of the ultimate segments might have been lost…
 
What would happen, if the sender (which knows the size of the burst, a= nd if the stream actually ends…) would deliberately send the 3 final = packets of the burst in reverse order,
 
Instead of … 6 7 8 9, send 6, 9, 8, 7, or 9, 6, 8, 7 (interleavi= ng avoids exceeding/modifying dupthresh in the no-loss case, and can be ext= ended to the last N segments).
 
The slides your colleague showed at some point the probability of a pa= cket loss into a burst, which linearly rises into the length of the …= .
 
As one critical issue is to have the receiver “know” how m= any packets should come, and to remove the receiver side delACK timer, a de= liberate reordering might achieve this without using timers and blind sendi= ng of one (two) packets to the receiver…
 
(Implementing this with HW support is probably more challenging though= ).
 
Any thoughts on that? Was that route investigated, and if so, what dra= wbacks did you identify?
 
Best regards,
 
Richard Scheffenegger

NetApp
rs@netapp.com<= br> +43 1 3676811 3146 Off= ice (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com<= /a>  

EURO PLAZA
Geb=E4ude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien
 
 
 
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E1C7E1Deusaamb109ericsso_-- From ycheng@google.com Fri Mar 15 11:05:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AF721F899E for ; Fri, 15 Mar 2013 11:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtn--557Pk83 for ; Fri, 15 Mar 2013 11:05:38 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 467EF21F8536 for ; Fri, 15 Mar 2013 11:05:38 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id gg6so3039318lbb.27 for ; Fri, 15 Mar 2013 11:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=H4pxpQ2AF7ImqHRRQaZQmH92wRamo3/5MwmGW8pV1n0=; b=oL15UiRquhPqplPZS/JzuffpBya6Tp0cLElcrIizshdiAT2V0XLxbSsIu0aHKohv2Q PI+F52v6pAPwV+cqtvUMEnlVNok9DNtv2/9XN+3TYXO5RmYXnuMOE1ftRhmorudD7CcR BUpnfG3/3JxSzxjCJzI+WWLKH1ZF6oxfiFWVOvKXwN4z1dy4IPYBX03lr3ODuOwXxBkG U4Z7ym1QrXp5h2X7jeSklgGQlhNwG30o3J37uqO1HyRW9QNig4O7T5NdBHzlrzbK+KLn Q7MQZ1Hr5/j+KJuqWHsdPEqzKFhN3n/daAcI8ruLWenaC07bcfIlwimLjAMy8KFAbwZK /m7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=H4pxpQ2AF7ImqHRRQaZQmH92wRamo3/5MwmGW8pV1n0=; b=eFraj+5aDRWnE6OBCyvIZglQvbwesSgmMirQWv9fMkPZA1G2NMdZyzB4K02V/WpTUo LVgCJGc3eYVAfkAH+aSYgvDX7+f1ZSUMxwgj3vrLSafPqkGcSNK3gi+kJA7T1qFpTGdD 3dqkv9Z2YwjFTT90PXyaBjPHlgrRfaLrMWVMBNyDj/Y2tsnDRLOyj9wsEgWQea803qhR DreL6CjMDpbic5/ySKQViuzv57ogxCjU1O0o+U6viREG56yhIiZdU1KEcmeoKsMfaFg/ svJ7rA9c4OuhQarWyANRMY0/JQuTr/zgWiabXFyTHEkvcYKqnhYTCN99d5VzH5/jWJZf KSNw== X-Received: by 10.112.40.228 with SMTP id a4mr2998935lbl.26.1363370737183; Fri, 15 Mar 2013 11:05:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.52.48 with HTTP; Fri, 15 Mar 2013 11:05:16 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Fri, 15 Mar 2013 11:05:16 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnEQOA/mePgnFzIzOwYK6o5jvi4KKcX+BFZ+GJICKRbGiBmcQWLO8wPGeKGwPkCNhQ7QQG0dMhKfUYP0+LdVJ0ZTT2IXud30KY47P1TFr77isqNuawwaurc66vyHhRkW1JcdfgiM35guS4dP8vCZZEm4nk0B3pXXgJBwemWOO/ELORrvvgOyB099jZ7TnW46cqm0c84 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2013 18:05:39 -0000 On Fri, Mar 15, 2013 at 9:41 AM, Scheffenegger, Richard wro= te: > Hi Nandita, Yuchung, Neal, > > this might be a stupid idea, but I bring it up anyway... > > TLP is to elicit an ACK from the receiver at the end of a burst, where so= me > of the ultimate segments might have been lost=85 > > What would happen, if the sender (which knows the size of the burst, and = if > the stream actually ends=85) would deliberately send the 3 final packets = of > the burst in reverse order, > > Instead of =85 6 7 8 9, send 6, 9, 8, 7, or 9, 6, 8, 7 (interleaving avoi= ds > exceeding/modifying dupthresh in the no-loss case, and can be extended to > the last N segments). I am not sure how this addresses the tail drops. If the sender sends 9,6,8,= 7 then 7 got lost, not only the sender needs to be careful not triggering fas= t recovery on receiving DUPACK of SACK9 or SACK8, the sender ultimately has to wait and retry 7. Similar case if 8,7 got lost. TLP is to quickly resume the sending rate on small tail drops if the ack clocking is not completely lost (within 1-2 RTTs). Tail drop is about packets not sequences. When the last packets, regardless of their TCP sequences, are dropped the sender needs to wait a reasonable time and retry. How much time is reasonab= le is worth discussing, but playing with sequence numbers don't help. The probe packet does not have to be the last packet. The reason we choose that is convenience to trigger FACK-sender's Fast Recovery w/o any changes. Also, without any losses, receiving 9,6,8,7 drives receiver into slow-path processing. > > The slides your colleague showed at some point the probability of a packe= t > loss into a burst, which linearly rises into the length of the =85. > > As one critical issue is to have the receiver =93know=94 how many packets= should > come, and to remove the receiver side delACK timer, a deliberate reorderi= ng > might achieve this without using timers and blind sending of one (two) > packets to the receiver=85 > > (Implementing this with HW support is probably more challenging though). > > Any thoughts on that? Was that route investigated, and if so, what drawba= cks > did you identify? > > Best regards, > > Richard Scheffenegger > > NetApp > rs@netapp.com > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > > EURO PLAZA > Geb=E4ude G, Stiege 7, 3.OG > Am Euro Platz 2 > A-1120 Wien > > > From rs@netapp.com Fri Mar 15 15:45:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF4311E80E1 for ; Fri, 15 Mar 2013 15:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.147 X-Spam-Level: X-Spam-Status: No, score=-10.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gMaz-+p3ptR for ; Fri, 15 Mar 2013 15:45:35 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7F21F86C1 for ; Fri, 15 Mar 2013 15:45:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,854,1355126400"; d="scan'208";a="31224536" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 15 Mar 2013 15:45:27 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2FMjQeO012960; Fri, 15 Mar 2013 15:45:27 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 15 Mar 2013 15:43:17 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Fri, 15 Mar 2013 15:43:16 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: TLP Thread-Index: Ac4hmeB25OSPuIOLT5++7iOSx3bHoAASHFkAAAtRtrA= Date: Fri, 15 Mar 2013 22:43:16 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AB359D@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2013 22:45:36 -0000 Hi Yuchung, True, but you don't need to wait for a (unknown) delAck timeout of the receiver i= n the special case.=20 Also, the last few ACKs will be received by the sender ideally with similar= time delay between them, so assuming the path didn't change you could do a= slightly faster PTO. Further, by the time of the PTO you already know how = many packets to retransmit (if one, two or more packets didn't made it) bec= ause the scoreboard has been populated already. With TLP, only the TLP pack= et populates the scoreboard (thus that ACK is more critical). I assumed TCP SACK (just as in TLP) for this to work, not NewReno... Yes, both sender and receiver would be processing these last packets of a b= urst in slow-path (which might not be the worst idea, actually, to slightly= pace out on the sender side; again, if the cumulative ACK doesn't show by = the PTO time, you then know already (usually) which packets to retransmit. = So with 2 or more packet drops, you save one RTT recovering them, not? Only the case with the very last packet being lost, the regular and TLP rec= overy time would be the same. Of course, I haven't looked in detail in all the scenarios, but the macrosc= opic behavior might be beneficial for your particular use case (saving RTT = on multiple losses), and the microscopic behavior beneficial to the network= (less spurious packets)? Best regards, Richard Scheffenegger > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Freitag, 15. M=E4rz 2013 19:05 > To: Scheffenegger, Richard > Cc: Nandita Dukkipati (nanditad@google.com); Neal Cardwell > (ncardwell@google.com); tcpm (tcpm@ietf.org) > Subject: Re: TLP >=20 > On Fri, Mar 15, 2013 at 9:41 AM, Scheffenegger, Richard > wrote: > > Hi Nandita, Yuchung, Neal, > > > > this might be a stupid idea, but I bring it up anyway... > > > > TLP is to elicit an ACK from the receiver at the end of a burst, where > > some of the ultimate segments might have been lost. > > > > What would happen, if the sender (which knows the size of the burst, > > and if the stream actually ends.) would deliberately send the 3 final > > packets of the burst in reverse order, > > > > Instead of . 6 7 8 9, send 6, 9, 8, 7, or 9, 6, 8, 7 (interleaving > > avoids exceeding/modifying dupthresh in the no-loss case, and can be > > extended to the last N segments). > I am not sure how this addresses the tail drops. If the sender sends > 9,6,8,7 then 7 got lost, not only the sender needs to be careful not > triggering fast recovery on receiving DUPACK of SACK9 or SACK8, the sende= r > ultimately has to wait and retry 7. Similar case if 8,7 got lost. >=20 > TLP is to quickly resume the sending rate on small tail drops if the ack > clocking is not completely lost (within 1-2 RTTs). Tail drop is about > packets not sequences. > When the last packets, regardless of their TCP sequences, are dropped the > sender needs to wait a reasonable time and retry. How much time is > reasonable is worth discussing, but playing with sequence numbers don't > help. >=20 > The probe packet does not have to be the last packet. The reason we choos= e > that is convenience to trigger FACK-sender's Fast Recovery w/o any > changes. >=20 > Also, without any losses, receiving 9,6,8,7 drives receiver into slow-pat= h > processing. >=20 > > > > The slides your colleague showed at some point the probability of a > > packet loss into a burst, which linearly rises into the length of the .= . > > > > As one critical issue is to have the receiver "know" how many packets > > should come, and to remove the receiver side delACK timer, a > > deliberate reordering might achieve this without using timers and > > blind sending of one (two) packets to the receiver. > > > > (Implementing this with HW support is probably more challenging though)= . > > > > Any thoughts on that? Was that route investigated, and if so, what > > drawbacks did you identify? > > > > Best regards, > > > > Richard Scheffenegger > > > > NetApp > > rs@netapp.com > > +43 1 3676811 3146 Office (2143 3146 - internal) > > +43 676 654 3146 Mobile > > www.netapp.com > > > > EURO PLAZA > > Geb=E4ude G, Stiege 7, 3.OG > > Am Euro Platz 2 > > A-1120 Wien > > > > > > From rs@netapp.com Mon Mar 18 04:24:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA24821F8CD6 for ; Mon, 18 Mar 2013 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbM4f6FAFLVJ for ; Mon, 18 Mar 2013 04:24:43 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id D001A21F8CBB for ; Mon, 18 Mar 2013 04:24:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,863,1355126400"; d="scan'208";a="247392998" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 18 Mar 2013 04:24:43 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2IBOg8e007006; Mon, 18 Mar 2013 04:24:42 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Mon, 18 Mar 2013 04:24:41 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: TLP Thread-Index: Ac4hmeB25OSPuIOLT5++7iOSx3bHoAASHFkAAHluKAA= Date: Mon, 18 Mar 2013 11:24:41 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AB737B@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> 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.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 18 Mar 2013 11:24:44 -0000 Hi Yuchung, Here is a short comparison between the TLP draft behavior and the deliberat= e tail reordering I mentioned. A PTO timer will still be necessary, but again, one special case can be avo= ided (unless dealing with very thin streams, which are app limited to <=3D1= segment/RTT), and full recovery is accomplished at least 1 RTT sooner than= with TLP, provided that cwnd is large enough. I hope the ascii art survive= s (use fixed-font); the PTO/delack delay are not to scale with RTT though. =20 draft TLP deliberate reordering =20 TLP =20 =20 5-_ 5-_ =20 ^-_ ^-_ =20 6-_ ^-_ 9-_ ^-_ =20 ^-_ ^-_ ^-_ ^-_ =20 7-_ ^-_ ^-> 6-_ ^-_ ^-> (delayed ACK) = =20 ^-_ ^-_ ^-_ ^-_ =20 8-X ^-_ ^-> 8-X ^-_ ^-> =20 ^-_ _-6 ^-_ _-5(9) =20 9-X _^^> -+ 7-X _^^> =20 _-^ | _-^ _-6(9) =20 _-^ delAck TO _-^ _-^ =20 <-^ | <-^ _-^ =20 _-7 -+ _-^ =20 _-^ +- <-^ =20 _-^ | =20 _-^ P =20 +- <-^ T =20 | O =20 P | =20 T +- 7-_ =20 O ^-_ =20 | 8-_ ^-_ =20 +- 9-_ ^-_ ^-_ =20 ^-_ ^-_ ^-> =20 ^-_ ^-_ _-7(9) =20 ^-_ ^-> =20 ^-> _-9 =20 _-7(9) =20 _-^ =20 _-^ =20 _-^ =20 <-^ =20 8-_ =20 ^-_ =20 ^-_ =20 ^-_ =20 ^-> =20 -9 =20 Also, the graph showing relative loss probability into a tail end burst ind= icates to me, that the later packets of a burst are more likely to really h= ave been dropped... Thus the retransmission sequence might be modified to r= e-send the last packets first (TLP resending the ultimate packet only perfo= rms this). Also note, that with the deliberate reordering, the sender already knows at= the time when PTO fires (after being rescheduled with the arriving ACKs), = which segments are most likely still outstanding. If cwnd permits, more tha= n a single segment may be re-sent when PTO fires. The reordering also causes the sender to send more ACKs (inter-ACK arrival = times at the sender could be used as additional signal). If the cumulative = (last) ACK is lost, the special handling to detect if a PTO retransmission = was necessary, is still necessary. Again, if the PTO retransmission was unn= ecessary, and TS is used, an old TS (since the retransmission doesn't advan= ce the receiver window), or DSACK block would be strong signals... Best regards, Richard Scheffenegger > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Freitag, 15. M=E4rz 2013 19:05 > To: Scheffenegger, Richard > Cc: Nandita Dukkipati (nanditad@google.com); Neal Cardwell > (ncardwell@google.com); tcpm (tcpm@ietf.org) > Subject: Re: TLP >=20 > On Fri, Mar 15, 2013 at 9:41 AM, Scheffenegger, Richard > wrote: > > Hi Nandita, Yuchung, Neal, > > > > this might be a stupid idea, but I bring it up anyway... > > > > TLP is to elicit an ACK from the receiver at the end of a burst, where > > some of the ultimate segments might have been lost. > > > > What would happen, if the sender (which knows the size of the burst, > > and if the stream actually ends.) would deliberately send the 3 final > > packets of the burst in reverse order, > > > > Instead of . 6 7 8 9, send 6, 9, 8, 7, or 9, 6, 8, 7 (interleaving > > avoids exceeding/modifying dupthresh in the no-loss case, and can be > > extended to the last N segments). > I am not sure how this addresses the tail drops. If the sender sends > 9,6,8,7 then 7 got lost, not only the sender needs to be careful not > triggering fast recovery on receiving DUPACK of SACK9 or SACK8, the sende= r > ultimately has to wait and retry 7. Similar case if 8,7 got lost. >=20 > TLP is to quickly resume the sending rate on small tail drops if the ack > clocking is not completely lost (within 1-2 RTTs). Tail drop is about > packets not sequences. > When the last packets, regardless of their TCP sequences, are dropped the > sender needs to wait a reasonable time and retry. How much time is > reasonable is worth discussing, but playing with sequence numbers don't > help. >=20 > The probe packet does not have to be the last packet. The reason we choos= e > that is convenience to trigger FACK-sender's Fast Recovery w/o any > changes. >=20 > Also, without any losses, receiving 9,6,8,7 drives receiver into slow-pat= h > processing. >=20 > > > > The slides your colleague showed at some point the probability of a > > packet loss into a burst, which linearly rises into the length of the .= . > > > > As one critical issue is to have the receiver "know" how many packets > > should come, and to remove the receiver side delACK timer, a > > deliberate reordering might achieve this without using timers and > > blind sending of one (two) packets to the receiver. > > > > (Implementing this with HW support is probably more challenging though)= . > > > > Any thoughts on that? Was that route investigated, and if so, what > > drawbacks did you identify? > > > > Best regards, > > > > Richard Scheffenegger > > > > NetApp > > rs@netapp.com > > +43 1 3676811 3146 Office (2143 3146 - internal) > > +43 676 654 3146 Mobile > > www.netapp.com > > > > EURO PLAZA > > Geb=E4ude G, Stiege 7, 3.OG > > Am Euro Platz 2 > > A-1120 Wien > > > > > > From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 19 01:04:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E28D21F86F7; Tue, 19 Mar 2013 01:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_40=-0.185, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0plgJ38qzZnS; Tue, 19 Mar 2013 01:04:36 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD9321F8A7E; Tue, 19 Mar 2013 01:04:35 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id BA624600F5; Tue, 19 Mar 2013 09:04:33 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 614AE600F4; Tue, 19 Mar 2013 09:04:33 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: iccrg@irtf.org, tcpm@ietf.org, aqm@ietf.org, Brian Trammell Date: Tue, 19 Mar 2013 09:04:32 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> Subject: [tcpm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 08:04:36 -0000 Hi everybody, we just published a paper on the state of ECN support and usage on the=20 Internet. We performed a similar study than Bauer et al., probing webserver= s=20 to get the current status. We found that about 30% of webservers (by Sep'12= )=20 support ECN. Unfortunately, still we saw a failure rate of 9% when checking end-2-end path ECN usability (setting CE). Additionally, we analyzed NetFlo= w=20 data to get a lower bound for the ECN usage which was below 1%. Then we als= o=20 had a look at IPv6 (47,5% ECN support). At the same time we also monitored = an=20 increase in general IPv6 support on webserver over the IPv6 launch day last= =20 year (-> check the paper). K=FChlewind, M.; Neuner, S.; Trammell, B.: On the state of ECN and TCP Opti= ons=20 on the Internet. Proceedings of the 14th Passive and Active Measurement=20 conference (PAM 2013), Hong Kong, March 2013. http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_4016= 0.pdf Do we need to start a campaign to further encourage greater ECN support (al= so=20 of network providers)? Asking the content providers on the list(s): What ar= e=20 the reasons to not enable ECN support? Mirja From swmike@swm.pp.se Tue Mar 19 02:22:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82A21F89D7; Tue, 19 Mar 2013 02:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es4du8m7DByD; Tue, 19 Mar 2013 02:22:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5B02721F89AF; Tue, 19 Mar 2013 02:22:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9711C9C; Tue, 19 Mar 2013 10:22:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8C1049A; Tue, 19 Mar 2013 10:22:52 +0100 (CET) Date: Tue, 19 Mar 2013 10:22:52 +0100 (CET) From: Mikael Abrahamsson To: =?ISO-8859-15?Q?Mirja_K=FChlewind?= In-Reply-To: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> Message-ID: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-27937894-1363684972=:2309" Cc: tcpm@ietf.org, iccrg@irtf.org, aqm@ietf.org Subject: Re: [tcpm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 09:22:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-27937894-1363684972=:2309 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 19 Mar 2013, Mirja Khlewind wrote: > Do we need to start a campaign to further encourage greater ECN support > (also of network providers)? Asking the content providers on the > list(s): What are the reasons to not enable ECN support? Let me speculate: It's not on by default in Windows. There is little reason to turn it on, because "nobody" acts on ECN, and nobody acts on ECN because there is no demand for AQM, and even if there was AQM, it would most likely not be ECN enabled. I tried enabling ECN back in 2001 but saw major breakage. I re-enabled ECN again around 2008 or so and investigated, and at least the vendors I talked to didn't show much interest. I've been running with ECN on ever since and have not experienced any breakage I could trace back to ECN usage. This is hopeful. I believe the Bufferbloat discussions and increased interest in AQM on the customer access link will increase interest in ECN as well, so the important thing is that AQM document includes requirements for AQM, so when I request support for "best practice AQM", I get ECN support as well. I am looking for RFC6204 (Basic Requirements) style document. Then we need to advertise ECN benefit to end users, for instance by advocating its use through tools like . The change log says "Changed ECN Capability optimal recommendation in General tab based on user feedback and issues with some US ISPs" and I fear that the recommendation there is to turn ECN off :P. I don't want to install the utility to test. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-27937894-1363684972=:2309-- From pasi.sarolahti@iki.fi Tue Mar 19 02:24:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5074E21F88F5 for ; Tue, 19 Mar 2013 02:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw42VAU9PT13 for ; Tue, 19 Mar 2013 02:24:26 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9947E21F87DF for ; Tue, 19 Mar 2013 02:24:26 -0700 (PDT) Received: from pc116.netlab.hut.fi (130.233.154.116) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 51292B7F01BB9E51 for tcpm@ietf.org; Tue, 19 Mar 2013 11:24:25 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Mar 2013 11:24:25 +0200 Message-Id: To: "tcpm (tcpm@ietf.org)" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Draft TCPM minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 09:24:27 -0000 Hi, Draft TCPM meeting minutes are available at = http://www.ietf.org/proceedings/86/minutes/minutes-86-tcpm . Please let = us chairs know if something is missing, or if there are corrections to = make. Many thanks to Gorry and Faisal for taking the notes! - Pasi From rick.jones2@hp.com Tue Mar 19 07:46:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A1C21F8CA7; Tue, 19 Mar 2013 07:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEzOgMtXyXp2; Tue, 19 Mar 2013 07:46:16 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D721F8CA3; Tue, 19 Mar 2013 07:46:16 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 161CA38579; Tue, 19 Mar 2013 14:46:09 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 933A33454E; Tue, 19 Mar 2013 14:46:00 +0000 (UTC) Message-ID: <51487A27.7010904@hp.com> Date: Tue, 19 Mar 2013 07:45:59 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mikael Abrahamsson References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: tcpm@ietf.org, aqm@ietf.org, iccrg@irtf.org Subject: Re: [tcpm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 14:46:17 -0000 On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote: > On Tue, 19 Mar 2013, Mirja Kühlewind wrote: > >> Do we need to start a campaign to further encourage greater ECN >> support (also of network providers)? Asking the content providers on >> the list(s): What are the reasons to not enable ECN support? > > Let me speculate: > > It's not on by default in Windows. There is little reason to turn it on, > because "nobody" acts on ECN, and nobody acts on ECN because there is no > demand for AQM, and even if there was AQM, it would most likely not be > ECN enabled. Out of curiosity, which stacks have ECN enabled by default? To my recollection, on netperf.org I had to explicitly enable TCP's use of ECN in the kernel which ships with Ubuntu 12.04. rick jones From gettysjim@gmail.com Tue Mar 19 10:26:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238CE21F8D63; Tue, 19 Mar 2013 10:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTYHfZZwzVTn; Tue, 19 Mar 2013 10:26:24 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5970421F8D34; Tue, 19 Mar 2013 10:26:24 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id x4so699453obh.16 for ; Tue, 19 Mar 2013 10:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mND3ULikwWoEnVcQ+P37Wl9wGfSIEyyi03wC0s8ZhXI=; b=pmxPKfbCsBhDv0rjVutV1HHULppaVv9aFpZ8Vbst+hEnA3mrD9SU8xNoq4QR0BxlvV M2OX7hNxatsq907Z0U+VpwArYu3Oq1G3wObXvedrti4M/a4xpYKO8qW1hBE50oY1qQu9 KsUSwR+Yuz58lZfvZAYm2pw9ypSelycQL6sTC2Yd6zp1IhrZcGk/ooTaXbGe83OEMpiA c3CI41KKH2GaVLKkf+/FdXh8hhKTvetAQYVOXgwmSzlbznZa6ToUW2nSeizwYEg9zmh2 IfW1dvQqdVzVhevpxQ0d4cKlsKEGzaeHgqy7/RKX3DGnHb8nqlVYVj8ojliU0zvqc/rQ RI0w== MIME-Version: 1.0 X-Received: by 10.60.3.103 with SMTP id b7mr1850839oeb.86.1363713983726; Tue, 19 Mar 2013 10:26:23 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Tue, 19 Mar 2013 10:26:23 -0700 (PDT) In-Reply-To: <51487A27.7010904@hp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com> Date: Tue, 19 Mar 2013 13:26:23 -0400 X-Google-Sender-Auth: ZkpC693eg7WCg6tnCpl7_b9NK-o Message-ID: From: Jim Gettys To: Rick Jones Content-Type: multipart/alternative; boundary=e89a8ff2514a934f0104d84a670e Cc: tcpm@ietf.org, aqm@ietf.org, iccrg@irtf.org Subject: Re: [tcpm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 17:26:25 -0000 --e89a8ff2514a934f0104d84a670e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You need to distinguish 1) "Will talk ECN when talked to", from 2) "Will initiate an ECN conversation". Linux, for example, will do 1) by default (and has for some time now), but requires configuration to turn on ECN when initiating a connection. - Jim On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones wrote: > On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote: > >> On Tue, 19 Mar 2013, Mirja K=FChlewind wrote: >> >> Do we need to start a campaign to further encourage greater ECN >>> support (also of network providers)? Asking the content providers on >>> the list(s): What are the reasons to not enable ECN support? >>> >> >> Let me speculate: >> >> It's not on by default in Windows. There is little reason to turn it on, >> because "nobody" acts on ECN, and nobody acts on ECN because there is no >> demand for AQM, and even if there was AQM, it would most likely not be >> ECN enabled. >> > > Out of curiosity, which stacks have ECN enabled by default? To my > recollection, on netperf.org I had to explicitly enable TCP's use of ECN > in the kernel which ships with Ubuntu 12.04. > > rick jones > > ______________________________**_________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/**listinfo/tcpm > --e89a8ff2514a934f0104d84a670e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You need to distinguish 1) "Will talk ECN when talked= to", from 2) "Will initiate an ECN conversation".

<= /div>
Linux, for example, will do 1) by default (and has for some= time now), but requires configuration to turn on ECN when initiating a con= nection.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 - Jim


On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones <= span dir=3D"ltr"><rick.jones2@hp.com> wrote:
On 03/19/2013 02:22 AM, Mi= kael Abrahamsson wrote:
On Tue, 19 Mar 2013, Mirja K=FChlewind wrote:

Do we need to start a campaign to further encourage greater ECN
support (also of network providers)? Asking the content providers on
the list(s): What are the reasons to not enable ECN support?

Let me speculate:

It's not on by default in Windows. There is little reason to turn it on= ,
because "nobody" acts on ECN, and nobody acts on ECN because ther= e is no
demand for AQM, and even if there was AQM, it would most likely not be
ECN enabled.

Out of curiosity, which stacks have ECN enabled by default? =A0To my recoll= ection, on netperf.org= I had to explicitly enable TCP's use of ECN in the kernel which ships = with Ubuntu 12.04.

rick jones

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--e89a8ff2514a934f0104d84a670e-- From ycheng@google.com Tue Mar 19 13:18:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A903B21F8DE3 for ; Tue, 19 Mar 2013 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL5vwPR+IcV9 for ; Tue, 19 Mar 2013 13:18:20 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A7B6821F8DDC for ; Tue, 19 Mar 2013 13:18:19 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gw10so1720933lab.41 for ; Tue, 19 Mar 2013 13:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=i6jaxFlFqeOCJNUT8xMntKYkSDYDu3W39alFwdf0Hrw=; b=aMdp+ik84QE/dH4ZmK9UnRCWquiPXxyM9amQpzvyprYdJE6UFGJXXj7PcPmC52JDNy wR2AO0LdZynUuFyW1DC1toCFMgawLn/AwvYlPg3FP3YaBFXAnkzv8MB6OQudkAbghZQu jTMTgoGvw40dZbx7d3s78MrggUjvK9aee+ecs27TMK27REEbIpOJ+hzIRAyBm0e/W1T5 GfgHxjmJGRehRTyYdVz04XI/vBnE3M8mcykNuxd7XsYiK+vMy+btpgHc5WQc3QQm/AAN d8bpqK86g5vgGQhY/Ya3i97Su2eFPJUN7gbvKWw5qO0cydQ4QXlxmXYKQXjzbQBZIDuy O21Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=i6jaxFlFqeOCJNUT8xMntKYkSDYDu3W39alFwdf0Hrw=; b=cik0k2n+ub7/L1SVpelwmTN+mZ1YfIvAxaFX2bSvl0VQFyjpVSXyR00V10LNSS1LnY oFdrsqJ9BH7ZEhjm+vzxcCe0OUUT0LCnr2ljn5sYDyAFFaLmfjuxX0Yh2WNQMBHPCrPP tQUnOlCb4VmNrOxA546bOof5YTIK9n93Xm0IG2EhYWc8I5pPiIo4zNLu+FgkcLbsg7S5 widAnJ/PttoQYNAMpKp2s2sWLZGCvzSoYbTjsvzfZwWyzNqK2VVXzAQWHQHitF4qpkPT i5e7rH0OU+UjKu6W5vQjZf3CrYtrN8OsZTPVAj66XJ1zOIS4OG0Bq2yskBOjy2aifMs7 fx5A== X-Received: by 10.112.88.35 with SMTP id bd3mr8700119lbb.56.1363724298428; Tue, 19 Mar 2013 13:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.52.48 with HTTP; Tue, 19 Mar 2013 13:17:57 -0700 (PDT) In-Reply-To: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> From: Yuchung Cheng Date: Tue, 19 Mar 2013 13:17:57 -0700 Message-ID: To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlaG/gv6mIw0bz0WpYDevuGHRYNiNwHlZ/39w800Errf3sA7tyABSkCflrInIXBHR3BYrkJX8VVEKSMIeG/OvM0UWCAc3RKJ+1G9yPtK2kveOxVKWugQVI0q4kxO44oTMyumd+w03Y56xvbTfJtZLubSmbJ6AnJFBDQmD8S8PRvV9uRWtBJ4c8rZ0h/lODcsWQAGt32 Cc: "tcpm@ietf.org Extensions" , iccrg@irtf.org, aqm@ietf.org Subject: Re: [tcpm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 20:18:20 -0000 On Tue, Mar 19, 2013 at 1:04 AM, Mirja K=FChlewind wrote: > Hi everybody, > > we just published a paper on the state of ECN support and usage on the > Internet. We performed a similar study than Bauer et al., probing webserv= ers > to get the current status. We found that about 30% of webservers (by Sep'= 12) > support ECN. Unfortunately, still we saw a failure rate of 9% when checki= ng > end-2-end path ECN usability (setting CE). Additionally, we analyzed NetF= low > data to get a lower bound for the ECN usage which was below 1%. Then we a= lso > had a look at IPv6 (47,5% ECN support). At the same time we also monitore= d an > increase in general IPv6 support on webserver over the IPv6 launch day la= st > year (-> check the paper). > > K=FChlewind, M.; Neuner, S.; Trammell, B.: On the state of ECN and TCP Op= tions > on the Internet. Proceedings of the 14th Passive and Active Measurement > conference (PAM 2013), Hong Kong, March 2013. > > http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_40= 160.pdf Do people on the list know any (good) evaluation of performance impact of ECN on real and/or emulated networks. E.g., how much faster will the Web be if ECN is used (correctly). > > Do we need to start a campaign to further encourage greater ECN support (= also > of network providers)? Asking the content providers on the list(s): What = are > the reasons to not enable ECN support? > > Mirja > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fred@cisco.com Tue Mar 19 13:35:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE2C21F8DDB; Tue, 19 Mar 2013 13:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.983 X-Spam-Level: X-Spam-Status: No, score=-109.983 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAvb25TqASzb; Tue, 19 Mar 2013 13:35:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D112521F8CC5; Tue, 19 Mar 2013 13:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=331; q=dns/txt; s=iport; t=1363725328; x=1364934928; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XNMVNWO5Lp5RkLlTmmsAxKTNWN80fB9KJFfGYsZ+O0g=; b=JJX2iytnnT6D/9378RJrPchpb36elKjy/2T0woQzH716TrpUJzH+h9I4 wGK2zT5L2eqowhW9gWRBwCfSW1ALpnrddF/L86J5Q79zlRr6GhaC31i/b eaqhvuZS/gPXfzExUlavXr1EKhR4rKd5HKdZBf/KqObmSmPHq9jmBGF6A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMFAC3LSFGtJV2b/2dsb2JhbABDh169P4FcFnSCJAEBAQMBeQULAgEIIiQyJQIEDgUIiAYGsXqQC45bAjEHgl9hA4g/nyKDCoIo X-IronPort-AV: E=Sophos;i="4.84,873,1355097600"; d="scan'208";a="189218437" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2013 20:35:27 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2JKZRur019494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 20:35:27 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 15:35:27 -0500 From: "Fred Baker (fred)" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [aqm] ECN support and usage on the Internet Thread-Index: AQHOJOFJiFyhVlNPAEK7GgUpyWANoA== Date: Tue, 19 Mar 2013 20:35:26 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7DC251@xmb-rcd-x09.cisco.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.100.174] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9832A55E311E6147AB87E5F5C2F70605@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [tcpm] [aqm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 20:35:28 -0000 On Mar 19, 2013, at 1:04 AM, Mirja K=FChlewind wrote: > Do we need to start a campaign to further encourage greater ECN support (= also=20 > of network providers)? Asking the content providers on the list(s): What = are=20 > the reasons to not enable ECN support? probably.= From gettysjim@gmail.com Tue Mar 19 15:36:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D17D21F8D12; Tue, 19 Mar 2013 15:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.733 X-Spam-Level: *** X-Spam-Status: No, score=3.733 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ8+yv2nSJvd; Tue, 19 Mar 2013 15:36:20 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id ECEDE21F8A98; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id er7so12793obc.0 for ; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nokrkxSBgc7Ypd2Gs9HvTnnYp8GAzuhWZVd+vkD5B4U=; b=PosXCTRJXu2PSDDkR1+OKkMYJPe7gwdCOch2xLNDooHdtBSfbygzMv1SlJHjjMkF2E p5X8PtadxbFOxGX9l9fDS5AT1o8ZhoueyZ52fb4D12NfkrpSGsXs+WZ0XdqTXqtcJrJ0 OGbmgqgmlED9tsmKfMea87ras0a+ajAxlY00PeIg4Wv0sgJz388Z/QvE5br1IQtrbWSM MbUQM8ziogMz5zPfT4lfCIAtrCXE3ZDOU5ZMoPdeATX3z8G3UdYUuH0XRTGgM4u+Qnea FfRSlGv5pM1UpCMhd4fVCg/ldpvZAQa5w3St9Kx+LmJ1MgoyNpUcpm3iTespW1CBvr+q B42Q== MIME-Version: 1.0 X-Received: by 10.60.3.71 with SMTP id a7mr2699262oea.35.1363732579347; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) In-Reply-To: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com> Date: Tue, 19 Mar 2013 18:36:19 -0400 X-Google-Sender-Auth: --9eXhWCqOnC8mjcBV-gR9aVGYg Message-ID: From: Jim Gettys To: =?GB2312?B?zOzAvQ==?= Content-Type: multipart/alternative; boundary=e89a8f839d51f5f8c604d84ebb8b Cc: "tcpm@ietf.org" , "aqm@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] =?gb2312?b?tPC4tDogW2ljY3JnXSAgRUNOIHN1cHBvcnQgYW5kIHVz?= =?gb2312?b?YWdlIG9uIHRoZSBJbnRlcm5ldA==?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 22:36:24 -0000 --e89a8f839d51f5f8c604d84ebb8b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Clearly, having a working AQM is a necessary prerequisite for ECN to be useful; one only overcome in the last year with CoDel/Pie. Variable bandwidth is still a challenge, but with CoDel at least, we think it can be done. And we've certainly implemented ECN support in the codel/fq_codel qdisc's (though would be grateful if ECN experts make sure it's been done correctly). The incentive structure needs to work here. There may be things we can and should do to provide incentive for ECN deployment. For Bell Heads working on wireless cellular transport, the incentive is really pretty clear: they ***hate*** dropping packets with a passion, not understanding that either packet drop or ECN are necessary, and it will probably be easier to convince them to adopt ECN than to drop packets. Given how hard they sweat to get packets over the air, I sort of understand where they come from. I believe some of the cellular carriers are requiring ECN support in handsets going forward, and as they classify VOIP into a separate bearer class anyway, I can see little incentive not to use ECN on their "best effort" bearer class. I believe all current operating systems react correctly to ECN marked packets; the only question is whether they will talk ECN if talked to (pretty common; Linux has done so now for quite a few years), *and* whether they enable ECN when establishing new connections or not (no one does right now by default). At the moment, Windows is vanishingly small fraction of handsets, being dominated by Android (Linux) and Apple as it is. I worry about bufferbloat in the HARQ layer of cellular networks not reflecting ECN marking into packets, but until that analysis has been done in real systems, it's just one more thing to worry about. Our Linux experience is that bufferbloat hides everywhere in current systems: the analogy in WiFi is the error correction layer in 802.11n, which causes large amounts of bloat, and fixing WiFi is very much a work in progress (except that not enough resources are currently available to go do the work, and it's more complicated that wired systems). Dave Taht cheered the first time he got the 802.11 layer to drop a packet, it was so much a problem. Right now, there are still some disincentives for ECN: e.g. some very small fraction of sites that become "black holes", or crashing antique middelboxes. We have no data on how much this is at this date, and the database that used to exist documenting middlebox problems has bit-rotted. These middleboxes are likely in the consumer edge, and unlikely to be in the path of most mobile devices and web sites on 3g/LTE. Mobile devices on home WiFi networks are more likely to have problems. We have ECN enabled in CeroWrt and have not noticed any problems; but 4-5 years ago OpenWrt (with a very much larger user base) still detected problems to the extent they had to disable initiating ECN connections. I know Bauer et. al. examined this a few years ago. But we have no data over the last several years I've seen (though this new paper referenced may: I've not had a chance to read it yet). There is one other issue with ECN: when operating at low bandwidth at the very edge of the net, it can still be advantageous to drop a packet rather than ECN mark it, to get back the transmission time of the packet. Dave Taht's experiments (IIRC) were below 4Mbps for this advantage (when doing VOIP over that bottleneck competing against other traffic in a best effort class). My intuition is to get VOIP reliable over WiFI on a busy network (or when far away from the AP) we'll want to classify the VOIP packets anyway and use the right hardware class in WiFi; this is primarily to get priority access to a transmit opportunity on WiFi rather than the previous reasons we've had. Certainly on other media we've seen little reason to have to do any explicit classification for VOIP anymore once running fq_codel. Things generally "just work" without all that hair for VOIP traffic. - Jim On Tue, Mar 19, 2013 at 5:49 PM, =CC=EC=C0=BD = wrote: > To let ECN be popular used =A3=ACthe most important is let the connection= which > used =A1=B0ECN=A1=B1 is fairness to the other connection; > So we should design new algorithm for ECN connection to "prize" those > people who use ECN; > > > hritian > > ________________________________________ > =B7=A2=BC=FE=C8=CB: Jim Gettys [jg@freedesktop.org] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA3=D4=C220=C8=D5 1:26 > =B5=BD: Rick Jones > Cc: tcpm@ietf.org; aqm@ietf.org; iccrg@irtf.org; Mikael Abrahamsson > =D6=F7=CC=E2: Re: [iccrg] [tcpm] ECN support and usage on the Internet > > You need to distinguish 1) "Will talk ECN when talked to", from 2) "Will > initiate an ECN conversation". > > Linux, for example, will do 1) by default (and has for some time now), bu= t > requires configuration to turn on ECN when initiating a connection. > - Jim > > > > On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones rick.jones2@hp.com>> wrote: > On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote: > On Tue, 19 Mar 2013, Mirja K=A8=B9hlewind wrote: > > Do we need to start a campaign to further encourage greater ECN > support (also of network providers)? Asking the content providers on > the list(s): What are the reasons to not enable ECN support? > > Let me speculate: > > It's not on by default in Windows. There is little reason to turn it on, > because "nobody" acts on ECN, and nobody acts on ECN because there is no > demand for AQM, and even if there was AQM, it would most likely not be > ECN enabled. > > Out of curiosity, which stacks have ECN enabled by default? To my > recollection, on netperf.org I had to explicitly > enable TCP's use of ECN in the kernel which ships with Ubuntu 12.04. > > rick jones > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > ________________________________ > > This email (including any attachments) is confidential and may be legally > privileged. If you received this email in error, please delete it > immediately and do not copy it or use it for any purpose or disclose its > contents to any other person. Thank you. > > > =B1=BE=B5=E7=D3=CA(=B0=FC=C0=A8=C8=CE=BA=CE=B8=BD=BC=FE)=BF=C9=C4=DC=BA= =AC=D3=D0=BB=FA=C3=DC=D7=CA=C1=CF=B2=A2=CA=DC=B7=A8=C2=C9=B1=A3=BB=A4=A1=A3= =C8=E7=C4=FA=B2=BB=CA=C7=D5=FD=C8=B7=B5=C4=CA=D5=BC=FE=C8=CB=A3=AC=C7=EB=C4= =FA=C1=A2=BC=B4=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A1=A3=C7=EB=B2=BB=D2=AA=BD=AB= =B1=BE=B5=E7=D3=CA=BD=F8=D0=D0=B8=B4=D6=C6=B2=A2=D3=C3=D7=F7=C8=CE=BA=CE=C6= =E4=CB=FB=D3=C3=CD=BE=A1=A2=BB=F2=CD=B8=C2=B6=B1=BE=D3=CA=BC=FE=D6=AE=C4=DA= =C8=DD=A1=A3=D0=BB=D0=BB=A1=A3 > --e89a8f839d51f5f8c604d84ebb8b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Clearly, having a working AQM is a necessary prerequisite = for ECN to be useful; one only overcome in the last year with CoDel/Pie. &n= bsp;Variable bandwidth is still a challenge, but with CoDel at least, we th= ink it can be done.  And we've certainly implemented ECN support i= n the codel/fq_codel qdisc's (though would be grateful if ECN experts m= ake sure it's been done correctly).

The incentive structure needs to work here. There may be thi= ngs we can and should do to provide incentive for ECN deployment.

For Bell Heads working on wireless cellular transport, the = incentive is really pretty clear: they ***hate*** dropping packets with a p= assion, not understanding that either packet drop or ECN are necessary, and= it will probably be easier to convince them to adopt ECN than to drop pack= ets.  Given how hard they sweat to get packets over the air, I sort of= understand where they come from.  

I believe some of the cellular carriers are requiring E= CN support in handsets going forward, and as they classify VOIP into a sepa= rate bearer class anyway, I can see little incentive not to use ECN on thei= r "best effort" bearer class.

I believe all current operating systems react cor= rectly to ECN marked packets; the only question is whether they will talk E= CN if talked to (pretty common; Linux has done so now for quite a few years= ), *and* whether they enable ECN when establishing new connections or not (= no one does right now by default).

At the moment, Windows is vanishingly small fract= ion of handsets, being dominated by Android (Linux) and Apple as it is.

I worry about bufferbloat in the HARQ layer of cellul= ar networks not reflecting ECN marking into packets, but until that analysi= s has been done in real systems, it's just one more thing to worry abou= t. Our Linux experience is that bufferbloat hides everywhere in current sys= tems: the analogy in WiFi is the error correction layer in 802.11n, which c= auses large amounts of bloat, and fixing WiFi is very much a work in progre= ss (except that not enough resources are currently available to go do the w= ork, and it's more complicated that wired systems).  Dave Taht che= ered the first time he got the 802.11 layer to drop a packet, it was so muc= h a problem.

Right now, there are still some disincentive= s for ECN: e.g. some very small fraction of sites that become "black h= oles", or crashing antique middelboxes. We have no data on how much th= is is at this date, and the database that used to exist documenting middleb= ox problems has bit-rotted.  These  middleboxes are likely in the= consumer edge, and unlikely to be in the path of most mobile devices and w= eb sites on 3g/LTE.  Mobile devices on home WiFi networks are more lik= ely to have problems.

We have ECN enabled in CeroWrt and have not= noticed any problems; but 4-5 years ago OpenWrt (with a very much larger u= ser base) still detected problems to the extent they had to disable initiat= ing ECN connections.  

I know Bauer et. al. examined this a few ye= ars ago. But we have no data over the last several years I've seen (tho= ugh this new paper referenced may: I've not had a chance to read it yet= ).

There is one other issue with ECN: when ope= rating at low bandwidth at the very edge of the net, it can still be advant= ageous to drop a packet rather than ECN mark it, to get back the transmissi= on time of the packet.  Dave Taht's experiments (IIRC) were below = 4Mbps for this advantage (when doing VOIP over that bottleneck competing ag= ainst other traffic in a best effort class).

My intuition is to get VOIP reliable over W= iFI on a busy network (or when far away from the AP) we'll want to clas= sify the VOIP packets anyway and use the right hardware class in WiFi; this= is primarily to get priority access to a transmit opportunity on WiFi rath= er than the previous reasons we've had.  Certainly on other media = we've seen little reason to have to do any explicit classification for = VOIP anymore once running fq_codel.  Things generally "just work&= quot; without all that hair for VOIP traffic.
                  &= nbsp;                    =           - Jim



<= br>
On Tue, Mar 19, 2013 at 5:49 PM, =CC=EC= =C0=BD <tianlan.lhh@alibaba-inc.com> wrote:
To let ECN be popular used =A3=ACthe most im= portant is let the connection which used “ECN” is fairness to t= he other connection;
So we should design new algorithm for ECN connection to "prize" t= hose people who use ECN;

                     = ;                     &nb= sp;                     &= nbsp;                    =                     &nbs= p;        hritian

________________________________________
=B7=A2=BC=FE=C8=CB: Jim Gettys [jg@fr= eedesktop.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA3=D4=C220=C8=D5 1:26
=B5=BD: Rick Jones
Cc: tcpm@ietf.org; aqm@ietf.org; iccrg@irtf= .org; Mikael Abrahamsson
=D6=F7=CC=E2: Re: [iccrg] [tcpm] ECN support and usage on the Internet

You need to distinguish 1) "Will talk ECN when talked to", from 2= ) "Will initiate an ECN conversation".

Linux, for example, will do 1) by default (and has for some time now), but = requires configuration to turn on ECN when initiating a connection.
                     = ;             - Jim



On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones <rick.jones2@hp.com<mailto:rick.jones2@hp.com>> wrote:
On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote:
On Tue, 19 Mar 2013, Mirja K=A8=B9hlewind wrote:

Do we need to start a campaign to further encourage greater ECN
support (also of network providers)? Asking the content providers on
the list(s): What are the reasons to not enable ECN support?

Let me speculate:

It's not on by default in Windows. There is little reason to turn it on= ,
because "nobody" acts on ECN, and nobody acts on ECN because ther= e is no
demand for AQM, and even if there was AQM, it would most likely not be
ECN enabled.

Out of curiosity, which stacks have ECN enabled by default?  To = my recollection, on netper= f.org<http://netper= f.org> I had to explicitly enable TCP's use of ECN in the kernel= which ships with Ubuntu 12.04.

rick jones

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
ht= tps://www.ietf.org/mailman/listinfo/tcpm


________________________________

This email (including any attachments) is confidential and may be legally p= rivileged. If you received this email in error, please delete it immediatel= y and do not copy it or use it for any purpose or disclose its contents to = any other person. Thank you.

=B1=BE=B5=E7=D3=CA(=B0=FC=C0=A8=C8=CE=BA=CE=B8=BD=BC=FE)=BF=C9=C4=DC=BA=AC= =D3=D0=BB=FA=C3=DC=D7=CA=C1=CF=B2=A2=CA=DC=B7=A8=C2=C9=B1=A3=BB=A4=A1=A3=C8= =E7=C4=FA=B2=BB=CA=C7=D5=FD=C8=B7=B5=C4=CA=D5=BC=FE=C8=CB=A3=AC=C7=EB=C4=FA= =C1=A2=BC=B4=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A1=A3=C7=EB=B2=BB=D2=AA=BD=AB=B1= =BE=B5=E7=D3=CA=BD=F8=D0=D0=B8=B4=D6=C6=B2=A2=D3=C3=D7=F7=C8=CE=BA=CE=C6=E4= =CB=FB=D3=C3=CD=BE=A1=A2=BB=F2=CD=B8=C2=B6=B1=BE=D3=CA=BC=FE=D6=AE=C4=DA=C8= =DD=A1=A3=D0=BB=D0=BB=A1=A3

--e89a8f839d51f5f8c604d84ebb8b-- From swmike@swm.pp.se Tue Mar 19 21:01:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DA421F8EF2; Tue, 19 Mar 2013 21:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-2.155, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa1z3GoIxTxq; Tue, 19 Mar 2013 21:01:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A749921F8F22; Tue, 19 Mar 2013 21:01:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A878A9C; Wed, 20 Mar 2013 05:01:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A37A79A; Wed, 20 Mar 2013 05:01:22 +0100 (CET) Date: Wed, 20 Mar 2013 05:01:22 +0100 (CET) From: Mikael Abrahamsson To: Jim Gettys In-Reply-To: Message-ID: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" , "aqm@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] =?gb2312?b?tPC4tDogW2ljY3JnXSAgRUNOIHN1cHBvcnQgYW5kIHVz?= =?gb2312?b?YWdlIG9uIHRoZSBJbnRlcm5ldA==?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 04:01:25 -0000 On Tue, 19 Mar 2013, Jim Gettys wrote: > I worry about bufferbloat in the HARQ layer of cellular networks not This might be from just one vendor, but the Radio Link Control (RLC) layer on our equipment will buffer up to 400 packets before it does tail-drop. There might be additional buffering in GGSN/SGSN doing rate-shaping before it's even sent to the RNC (which terminates the RLC layer between the RNC and the end user terminal equipment). All this buffering is strict FIFO. I personally belive that AQM at each of these buffering points would be beneficial to the end user equipment. > My intuition is to get VOIP reliable over WiFI on a busy network (or > when far away from the AP) we'll want to classify the VOIP packets > anyway and use the right hardware class in WiFi; this is primarily to > get priority access to a transmit opportunity on WiFi rather than the > previous reasons we've had. Certainly on other media we've seen little > reason to have to do any explicit classification for VOIP anymore once > running fq_codel. Things generally "just work" without all that hair > for VOIP traffic. I agree, fq_codel probably needs some DSCP handling so that VOIP packets (EF marked) would end up in a different hardware queue. For mobile, the bearer model would mean there would be an L4 inspection engine putting the traffic into the correct bearer anyway (that's the 3GPP way), so here codel probably wouldn't need to do anything (because there would be several codel instances running, one per bearer). -- Mikael Abrahamsson email: swmike@swm.pp.se From emmanuel.lochin@isae.fr Wed Mar 20 04:21:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFEE21F8C82; Wed, 20 Mar 2013 04:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkmBbERGp5Gq; Wed, 20 Mar 2013 04:21:51 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with SMTP id 3A44421F8C7D; Wed, 20 Mar 2013 04:21:51 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with SMTP id C491D22E93C; Wed, 20 Mar 2013 12:21:45 +0100 (CET) Received: from [10.33.1.1] (pc-lochin.isae.fr [10.33.1.1]) by catalpa (Postfix) with ESMTP id 80197B7D6C; Wed, 20 Mar 2013 12:21:49 +0100 (CET) Message-ID: <51499BFB.7050202@isae.fr> Date: Wed, 20 Mar 2013 12:22:35 +0100 From: Emmanuel Lochin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Yuchung Cheng References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org Extensions" , aqm@ietf.org, iccrg@irtf.org Subject: Re: [tcpm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 11:21:52 -0000 On 19/03/2013 21:17, Yuchung Cheng wrote: > Do people on the list know any (good) evaluation of performance impact > of ECN on real and/or emulated networks. E.g., how much faster will > the Web be if ECN is used (correctly). There is : http://dl.acm.org/citation.cfm?id=3D1080091.1080100 EL --=20 Emmanuel Lochin Professeur ISAE - OSSI Institut Sup=E9rieur de l'A=E9ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legall= y privileged information or copyright material. You should not read, copy= , use or disclose them without authorisation. If you are not an intended = recipient, please contact us at once by return email and then delete both= messages. We do not accept liability in connection with computer virus, = data corruption, delay, interruption, unauthorised access or unauthorised= amendment. This notice should not be removed" From rs@netapp.com Wed Mar 20 06:35:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5949021F8E32 for ; Wed, 20 Mar 2013 06:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlUOfuSVoQE0 for ; Wed, 20 Mar 2013 06:35:58 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id AF19A21F8D77 for ; Wed, 20 Mar 2013 06:35:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,877,1355126400"; d="scan'208";a="15777229" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Mar 2013 06:35:58 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2KDZwQs026687; Wed, 20 Mar 2013 06:35:58 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 06:35:58 -0700 From: "Scheffenegger, Richard" To: Rick Jones Thread-Topic: [tcpm] TLP Thread-Index: Ac4hmeB25OSPuIOLT5++7iOSx3bHoAASHFkAAHluKAAAIsZNAABGrlxw Date: Wed, 20 Mar 2013 13:35:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ABFE49@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AB1D79@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AB737B@SACEXCMBX02-PRD.hq.netapp.com> <51477B22.5090905@hp.com> In-Reply-To: <51477B22.5090905@hp.com> 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 \(tcpm@ietf.org\)" Subject: Re: [tcpm] TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 13:35:59 -0000 Definitely... But the use case mentioned by the authors of TLP is the timely delivery of = web objects. So, the sender does know the probably end of the burst (the se= nder queue is not fully utilized) and could perform that deliberate reorder= ing. In the degenerate case, that the application "tickles in" data in small chu= nks that fit into a single packet (or Nigle is turned off), the application= probably does some pacing already, so that the tail-loss-after-burst, that= is to be addressed, is most likely less of an issue. In a "burst" size of one packet, there is nothing to reorder, but the chanc= e that this segment is lost, is also reduced (I cann't find the presentatio= n, where the probability of subsequent packet losses, after the first packe= t loss, was given vs. the burst size). In that case, TLP would send the ultimate segment anew, if no cumulative AC= K was seen during the PTO period... But with deliberate reordering of the ultimate (and penultimate) segments, = the deliberate reordering should yield the exact information (except of ACK= losses, of course), which segments to retransmit, and also would deliver a= "better" ACK clock by disabling delayed ACKs... I hope that point came across in my last mail with the ascii tcp diagrams..= . Best regards, Richard Scheffenegger NetApp rs@netapp.com +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=A0=A0 EURO PLAZA Geb=E4ude G, Stiege 7, 3.OG Am Euro Platz 2 A-1120 Wien > -----Original Message----- > From: Rick Jones [mailto:rick.jones2@hp.com] > Sent: Montag, 18. M=E4rz 2013 21:38 > To: Scheffenegger, Richard > Subject: Re: [tcpm] TLP >=20 > I missed the beginning of the discussion, so I'll ask this question > directly lest it be an Emily Litella Moment - doesn't deliberate > reordering rely on having all the data in the first place rather than > having it dribbling-in? >=20 > rick jones From rs@netapp.com Wed Mar 20 07:07:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14711E80A4 for ; Wed, 20 Mar 2013 07:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.742 X-Spam-Level: X-Spam-Status: No, score=-9.742 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrWFao3NN8te for ; Wed, 20 Mar 2013 07:07:21 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FF21F8F9E for ; Wed, 20 Mar 2013 07:07:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,877,1355126400"; d="scan'208,217";a="15784445" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Mar 2013 07:07:20 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2KE7KOc013756 for ; Wed, 20 Mar 2013 07:07:20 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 07:07:20 -0700 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+Nzg== Date: Wed, 20 Mar 2013 14:07:19 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> 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: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F24AC0025SACEXCMBX02PRDh_" MIME-Version: 1.0 Subject: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 14:07:25 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F24AC0025SACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi group, running up to and during the IETF 86, the following points were raised w.r.= t 1323bis. I hope this lengthy email makes it through your tl;dr filter... a) Is it necessary or useful, to have an Appendix D giving a Pseudo Co= de example? This section was added early in the process of creating the draft. As = a couple of years have passed since, it was suggested to poll the WG if thi= s text is valuable, or if the document would be better off without a strict= Pseudocode example. Note that certain points that were added later in the= text of the draft, are not reflected in the Pseudocode (ie. late TS negoti= ation), and the Pseudocode also does NOT touch any of the interactions with= other TCP subsystems (ie. Window Retraction). From an editorial point of view, removing an incomplete example, that = may be misleading, is easier than working out a full-fledged pseudocode cov= ering all the edge cases... (I updated my view of this from neutral to remo= ve; the document is long enough even without an incomplete example). b) Guidance regarding late TS negotiation: This is a technical (semantic) change of timestamps; the upcoming -07 = version of the draft will have this text added; is the WG satisfied with th= is wording, or shall more specific (2119) wording be added: A TCP MAY send the Timestamps option (TSopt) in an initial segment (i.e., a segment containing a SYN bit and no ACK bit). Once a TSopt has been sent or received in a non segment, it MUST be sent in all segments. Once a TSopt has been received in a non segment, then any successive segment that is received without the RST bit and without a TSopt MAY be dropped without further processing, and an ACK of the current SND.UNA generated. Note that it is RECOMMENDED to negotiate the use of the timestamp option during the initial handshake. Although this document is less restrictive regarding the use of the timestamp option when not sent initially, any guidance and discussion of potential issues when timestamp is enabled late in a session is beyond the scope of this document. I have received suggestions, to increase the "MAY" in the first senten= ce to a "SHOULD" (but that might indicate to implementers, that any TCP ses= sion SHOULD have TS enabled, not that TS MAY be used, and if, it SHOULD be = negotiated during SYN). Another suggestion was to add a sentence like "Timestamps MUST be nego= tiated in and unless another mechanism allows enabling them= in during an established session. Such a mechanism is outside the scope = of this document." c) More appropriate introductory text; the following statement will su= persede very old text (that apparently addressed WS, TS and SACK back in RF= C1072); this was already presented at IETF 86 and received no objections. The window scale option negotiates fundamental parameters of the TCP session. Therefore, it is only sent during the initial handshake. Furthermore, the window scale option will be sent in a segment only if the corresponding option was received in the initial segment. The timestamps option may appear in any data or ACK segment, adding 12 bytes to the 20-byte TCP header. It is recommended that this TCP option will be sent on non-SYN segments only after an exchange of options on the SYN segments has indicated that both sides understand the extension. We believe that the bandwidth saved by reducing unnecessary retransmission timeouts will more than pay for the extra header bandwidth. d) Better text in the new section 2.4. describing the corner case when= the Window Scale option results in a Window Retraction during Loss Recove= ry; but no suggestions for better wording have been made so far. Does the W= G agree with these steps, or should there be a different description around= that particular case: 2.4. Addressing Window Retraction When a non-zero scale factor is in use, there are instances when a retracted window can be offered [Mathis08]. The end of the window will be on a boundary based on the granularity of the scale factor being used. If the sequence number is then updated by a number of bytes smaller than that granularity, the TCP will have to either advertise a new window that is beyond what it previously advertised (and perhaps beyond the buffer), or will have to advertise a smaller window, which will cause the TCP window to shrink. Implementations MUST ensure that they handle a shrinking window, as specified in section 4.2.2.16 of [RFC1122]. For the receiver, this implies that: 1) The receiver MUST honor, as in-window, any segment that would have been in-window for any ACK sent by the receiver. 2) When window scaling is in effect, the receiver SHOULD track the actual maximum window sequence number (which is likely to be greater than the window announced by the most recent ACK, if more than one segment has arrived since the application consumed any data in the receive buffer). On the sender side: 3) The initial transmission MUST honor window on most recent ACK. 4) On first retransmission, or if the sequence number is out-of- window by less than (2^Rcv.Wind.Scale) then do normal retransmission(s) without regard to receiver window as long as the original segment was in window when it was sent. 5) On subsequent retransmissions, treat such ACKs as zero window probes. I'm currently in the process of updating the -07 "Changes " Appendix to spl= it it into an technical/editorial part, as mentioned in my IETF 86 talk. On= ce that finishes, -07 will be submitted, together with any changes which th= e WG agrees. Best regards, Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F24AC0025SACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi group,
 
running up to and during the IETF 86, the following points were raised= w.r.t 1323bis. I hope this lengthy email makes it through your tl;dr filte= r…
 
 
  1. Is it necessary or useful, to have an Appendix D giving a Pseudo Code e= xample?
 
This section was added early in the pro= cess of creating the draft. As a couple of years have passed since, it was = suggested to poll the WG if this text is valuable, or if the document would= be better off without a strict Pseudocode example. Note that certain points that were added later  in the text o= f the draft, are not reflected in the Pseudocode (ie. late TS negotiation),= and the Pseudocode also does NOT touch any of the interactions with other = TCP subsystems (ie. Window Retraction).
 
From an editorial point of view, removi= ng an incomplete example, that may be misleading, is easier than working ou= t a full-fledged pseudocode covering all the edge cases… (I updated m= y view of this from neutral to remove; the document is long enough even without an incomplete example).
 
  1. Guidance regarding late TS negotiation:
 
This is a technical (semantic) change o= f timestamps; the upcoming -07 version of the draft will have this text add= ed; is the WG satisfied with this wording, or shall more specific (2119) wo= rding be added:
 
=    A TCP MAY send the Timestamps option (TSopt) in an initial <= ;SYN>
=    segment (i.e., a segment containing a SYN bit and no ACK bit).=   Once
=    a TSopt has been sent or received in a non <SYN> segment= , it MUST be
=    sent in all segments.  Once a TSopt has been received in = a non <SYN>
=    segment, then any successive segment that is received without = the RST
=    bit and without a TSopt MAY be dropped without further process= ing,
=    and an ACK of the current SND.UNA generated.
=  
=    Note that it is RECOMMENDED to negotiate the use of the timest= amp
=    option during the initial handshake.  Although this docum= ent is less
=    restrictive regarding the use of the timestamp option when not= sent
=    initially, any guidance and discussion of potential issues whe= n
=    timestamp is enabled late in a session is beyond the scope of = this
=    document.
 
I have received suggestions, to increas= e the “MAY” in the first sentence to a “SHOULD” (bu= t that might indicate to implementers, that any TCP session SHOULD have TS = enabled, not that TS MAY be used, and if, it SHOULD be negotiated during SYN).
 
Another suggestion was to add a sentenc= e like “Timestamps MUST be negotiated in <SYN> and <SYN,ACK&= gt; unless another mechanism allows enabling them in during an established = session.  Such a  mechanism is outside the scope of this document.”
 
  1. More appropriate introductory text; the following statement will supers= ede very old text (that apparently addressed WS, TS and SACK back in RFC107= 2); this was already presented at IETF 86 and received no objections.
    2. <= /ol>
     
    =    The window scale option negotiates fundamental parameters of t= he TCP
    =    session.  Therefore, it is only sent during the initial h= andshake.
    =    Furthermore, the window scale option will be sent in a <SYN= ,ACK>
    =    segment only if the corresponding option was received in the i= nitial
    =    <SYN> segment.
    =  
    =    The timestamps option may appear in any data or ACK segment, a= dding
    =    12 bytes to the 20-byte TCP header.  It is recommended th= at this TCP
    =    option will be sent on non-SYN segments only after an exchange= of
    =    options on the SYN segments has indicated that both sides unde= rstand
    =    the extension.  We believe that the bandwidth saved by re= ducing
    =    unnecessary retransmission timeouts will more than pay for the= extra
    =    header bandwidth.
     
    1. Better text in the new section 2.4. describing the corner case when the= Window Scale  option results in a Window Retraction during Loss Recov= ery; but no suggestions for better wording have been made so far. Does the = WG agree with these steps, or should there be a different description around that particular case:
     
    = 2.4.  Addressing Window Retraction
    =  
    =    When a non-zero scale factor is in use, there are instances wh= en a
    =    retracted window can be offered [Mathis08].  The end of t= he window
    =    will be on a boundary based on the granularity of the scale fa= ctor
    =    being used.  If the sequence number is then updated by a = number of
    =    bytes smaller than that granularity, the TCP will have to eith= er
    =    advertise a new window that is beyond what it previously adver= tised
    =    (and perhaps beyond the buffer), or will have to advertise a s= maller
    =    window, which will cause the TCP window to shrink.  Imple= mentations
    =    MUST ensure that they handle a shrinking window, as specified = in
    =    section 4.2.2.16 of [RFC1122].
    =  
    =    For the receiver, this implies that:
    =  
    =    1)  The receiver MUST honor, as in-window, any segment th= at would
    =       have been in-window for any ACK sent by the = receiver.
    =  
    =    2)  When window scaling is in effect, the receiver SHOULD= track the
    =       actual maximum window sequence number (which= is likely to be
    =       greater than the window announced by the mos= t recent ACK, if more
    =       than one segment has arrived since the appli= cation consumed any
    =       data in the receive buffer).
    =  
    =    On the sender side:
    =  
    =    3)  The initial transmission MUST honor window on most re= cent ACK.
    =  
    =    4)  On first retransmission, or if the sequence number is= out-of-
    =       window by less than (2^Rcv.Wind.Scale) then = do normal
    =       retransmission(s) without regard to receiver= window as long as the
    =       original segment was in window when it was s= ent.
    =  
    =    5)  On subsequent retransmissions, treat such ACKs as zer= o window
    =       probes.
    =  
    =  
    =  
    I’m currently in the process of updating the -07 “Changes = “ Appendix to split it into an technical/editorial part, as mentioned= in my IETF 86 talk. Once that finishes, -07 will be submitted, together wi= th any changes which the WG agrees.
     
    Best regards,
     
    Richard Scheffenegger
     
     --_000_012C3117EDDB3C4781FD802A8C27DD4F24AC0025SACEXCMBX02PRDh_-- From gdt@gdt.id.au Tue Mar 19 16:09:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C096621F867D; Tue, 19 Mar 2013 16:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+g11tgLWAzB; Tue, 19 Mar 2013 16:09:07 -0700 (PDT) Received: from aix.gdt.id.au (eth6445.sa.adsl.internode.on.net [150.101.30.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0321F84D9; Tue, 19 Mar 2013 16:09:06 -0700 (PDT) Received: from thrace.44ansell.gdt.id.au (thrace.44ansell.gdt.id.au [192.168.253.149]) (authenticated bits=0) by aix.gdt.id.au (8.14.2/8.14.2) with ESMTP id r2JN8baD026631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 09:38:38 +1030 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6" From: Glen Turner In-Reply-To: Date: Wed, 20 Mar 2013 09:38:37 +1030 Message-Id: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com> To: Jim Gettys X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Wed, 20 Mar 2013 08:08:15 -0700 Cc: "iccrg@irtf.org" , "tcpm@ietf.org" , =?utf-8?B?5aSp5r6c?= , "aqm@ietf.org" Subject: Re: [tcpm] [iccrg] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 23:09:07 -0000 --Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On 20/03/2013, at 9:06 AM, Jim Gettys wrote: >=20 > We have ECN enabled in CeroWrt and have not noticed any problems; but = 4-5 years ago OpenWrt (with a very much larger user base) still detected = problems to the extent they had to disable initiating ECN connections. =20= The issues with accessing web sites from ECN-using hosts were primarily = due to one software bug in one popular network vendor's popular = firewall. The software versions with that bug have been end-of-lifed by = the vendor. So you should have a much better experience with ECN = reachability these days. -glen= --Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=GB2312
    On 20/03/2013, at 9:06 AM, Jim Gettys wrote:

    We have ECN enabled in CeroWrt and have not noticed any problems; but 4-5 years ago OpenWrt (with a very much larger user base) still detected problems to the extent they had to disable initiating ECN connections.  

    The issues with accessing web sites from ECN-using hosts were primarily due to one software bug in one popular network vendor's popular firewall. The software versions with that bug have been end-of-lifed by the vendor. So you should have a much better experience with ECN reachability these days.

    -glen
    --Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6-- From simon@superduper.net Tue Mar 19 16:43:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE7B21F8D46; Tue, 19 Mar 2013 16:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVWy6nOSy+zV; Tue, 19 Mar 2013 16:43:26 -0700 (PDT) Received: from masada.superduper.net (masada.superduper.net [85.119.82.91]) by ietfa.amsl.com (Postfix) with ESMTP id D48B721F8C5D; Tue, 19 Mar 2013 16:43:25 -0700 (PDT) Received: from snappy-wlan.parc.xerox.com ([13.1.108.21]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UI6BX-0003Pr-9e; Tue, 19 Mar 2013 23:43:18 +0000 Message-ID: <5148F80F.5000401@superduper.net> Date: Tue, 19 Mar 2013 16:43:11 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jim Gettys References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 20 Mar 2013 08:08:36 -0700 Cc: "iccrg@irtf.org" , "tcpm@ietf.org" , =?UTF-8?B?5aSp5r6c?= , "aqm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?W2FxbV0g562U5aSNOiBbaWNjcmddICBFQ04gc3VwcG9ydCBh?= =?utf-8?q?nd_usage_on_the_Internet?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 23:43:27 -0000 I'm not sure why people are so obsessed with ECN - the little data I've seen about it showed that it's effect on system throughput was in the noise. Sure, wireless guys don't like to waste precious wireless bandwidth, but they're not dropping packets that have used up the precious wireless bandwidth. They get dropped before the wireless link. Simon On 03/19/2013 03:36 PM, Jim Gettys wrote: > Clearly, having a working AQM is a necessary prerequisite for ECN to be > useful; one only overcome in the last year with CoDel/Pie. Variable > bandwidth is still a challenge, but with CoDel at least, we think it can > be done. And we've certainly implemented ECN support in the > codel/fq_codel qdisc's (though would be grateful if ECN experts make > sure it's been done correctly). > > The incentive structure needs to work here. There may be things we can > and should do to provide incentive for ECN deployment. > > For Bell Heads working on wireless cellular transport, the incentive is > really pretty clear: they ***hate*** dropping packets with a passion, > not understanding that either packet drop or ECN are necessary, and it > will probably be easier to convince them to adopt ECN than to drop > packets. Given how hard they sweat to get packets over the air, I sort > of understand where they come from. > > I believe some of the cellular carriers are requiring ECN support in > handsets going forward, and as they classify VOIP into a separate bearer > class anyway, I can see little incentive not to use ECN on their "best > effort" bearer class. > > I believe all current operating systems react correctly to ECN marked > packets; the only question is whether they will talk ECN if talked to > (pretty common; Linux has done so now for quite a few years), *and* > whether they enable ECN when establishing new connections or not (no one > does right now by default). > > At the moment, Windows is vanishingly small fraction of handsets, being > dominated by Android (Linux) and Apple as it is. > > I worry about bufferbloat in the HARQ layer of cellular networks not > reflecting ECN marking into packets, but until that analysis has been > done in real systems, it's just one more thing to worry about. Our Linux > experience is that bufferbloat hides everywhere in current systems: the > analogy in WiFi is the error correction layer in 802.11n, which causes > large amounts of bloat, and fixing WiFi is very much a work in progress > (except that not enough resources are currently available to go do the > work, and it's more complicated that wired systems). Dave Taht cheered > the first time he got the 802.11 layer to drop a packet, it was so much > a problem. > > Right now, there are still some disincentives for ECN: e.g. some very > small fraction of sites that become "black holes", or crashing antique > middelboxes. We have no data on how much this is at this date, and the > database that used to exist documenting middlebox problems has > bit-rotted. These middleboxes are likely in the consumer edge, and > unlikely to be in the path of most mobile devices and web sites on > 3g/LTE. Mobile devices on home WiFi networks are more likely to have > problems. > > We have ECN enabled in CeroWrt and have not noticed any problems; but > 4-5 years ago OpenWrt (with a very much larger user base) still detected > problems to the extent they had to disable initiating ECN connections. > > I know Bauer et. al. examined this a few years ago. But we have no data > over the last several years I've seen (though this new paper referenced > may: I've not had a chance to read it yet). > > There is one other issue with ECN: when operating at low bandwidth at > the very edge of the net, it can still be advantageous to drop a packet > rather than ECN mark it, to get back the transmission time of the > packet. Dave Taht's experiments (IIRC) were below 4Mbps for this > advantage (when doing VOIP over that bottleneck competing against other > traffic in a best effort class). > > My intuition is to get VOIP reliable over WiFI on a busy network (or > when far away from the AP) we'll want to classify the VOIP packets > anyway and use the right hardware class in WiFi; this is primarily to > get priority access to a transmit opportunity on WiFi rather than the > previous reasons we've had. Certainly on other media we've seen little > reason to have to do any explicit classification for VOIP anymore once > running fq_codel. Things generally "just work" without all that hair > for VOIP traffic. > - Jim > > > > > > On Tue, Mar 19, 2013 at 5:49 PM, 天澜 > wrote: > > To let ECN be popular used ，the most important is let the > connection which used “ECN” is fairness to the other connection; > So we should design new algorithm for ECN connection to "prize" > those people who use ECN; > > > hritian > > ________________________________________ > 发件人: Jim Gettys [jg@freedesktop.org ] > 发送时间: 2013年3月20日 1:26 > 到: Rick Jones > Cc: tcpm@ietf.org ; aqm@ietf.org > ; iccrg@irtf.org ; > Mikael Abrahamsson > 主题: Re: [iccrg] [tcpm] ECN support and usage on the Internet > > You need to distinguish 1) "Will talk ECN when talked to", from 2) > "Will initiate an ECN conversation". > > Linux, for example, will do 1) by default (and has for some time > now), but requires configuration to turn on ECN when initiating a > connection. > - Jim > > > > On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones >> wrote: > On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote: > On Tue, 19 Mar 2013, Mirja Kühlewind wrote: > > Do we need to start a campaign to further encourage greater ECN > support (also of network providers)? Asking the content providers on > the list(s): What are the reasons to not enable ECN support? > > Let me speculate: > > It's not on by default in Windows. There is little reason to turn it on, > because "nobody" acts on ECN, and nobody acts on ECN because there is no > demand for AQM, and even if there was AQM, it would most likely not be > ECN enabled. > > Out of curiosity, which stacks have ECN enabled by default? To my > recollection, on netperf.org > I had to explicitly enable > TCP's use of ECN in the kernel which ships with Ubuntu 12.04. > > rick jones > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > ________________________________ > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please > delete it immediately and do not copy it or use it for any purpose > or disclose its contents to any other person. Thank you. > > 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件 > 人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或 > 透露本邮件之内容。谢谢。 > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From rs@netapp.com Wed Mar 20 09:04:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA39821F8573; Wed, 20 Mar 2013 09:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.313 X-Spam-Level: X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TieoXp5OmRN; Wed, 20 Mar 2013 09:04:01 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1A821F8556; Wed, 20 Mar 2013 09:04:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,879,1355126400"; d="scan'208";a="32368327" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 20 Mar 2013 09:04:00 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2KG40d0012922; Wed, 20 Mar 2013 09:04:00 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 20 Mar 2013 09:03:59 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 09:03:59 -0700 From: "Scheffenegger, Richard" To: Emmanuel Lochin , Yuchung Cheng Thread-Topic: [tcpm] ECN support and usage on the Internet Thread-Index: AQHOJN7vLn8i1zQNs0aR6qujDYSanZiu5guA///XOCA= Date: Wed, 20 Mar 2013 16:03:59 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC06C0@SACEXCMBX02-PRD.hq.netapp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51499BFB.7050202@isae.fr> In-Reply-To: <51499BFB.7050202@isae.fr> 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 Extensions" , "aqm@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 16:04:03 -0000 Thanks! Which fortunately is already an experimental http://tools.ietf.org/html/rfc= 5562=20 But too little experience to follow up on that just yet; Last time I looked= , I believe it was the AIX 5.3 TCP stack would default to 5562, when ECN is= enabled - but ECN is off by default in that OS... But the findings in that paper don't compare Tail-Drop non-ECN with AQM/ECN= *, which is probably what you are after Yuchung? Put differently: With a large enough fraction of AQM deployment, a reasonab= le number of RTOs should be avoidable (less probability that the last segme= nt in a session is dropped); with the addition of ECN, even that loss shoul= d go away... Do you know what the CCDF for object load times would look like, if there w= ere virtually no RTOs anymore? Apparently, the incentive to avoid (costly) RTOs is too small to drive ECN = deployment, even though that should be something easy to achieve with ECN o= n TCP. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Emmanuel Lochin > Sent: Mittwoch, 20. M=E4rz 2013 12:23 > To: Yuchung Cheng > Cc: tcpm@ietf.org Extensions; aqm@ietf.org; iccrg@irtf.org > Subject: Re: [tcpm] ECN support and usage on the Internet >=20 > On 19/03/2013 21:17, Yuchung Cheng wrote: > > Do people on the list know any (good) evaluation of performance impact > > of ECN on real and/or emulated networks. E.g., how much faster will > > the Web be if ECN is used (correctly). >=20 > There is : http://dl.acm.org/citation.cfm?id=3D1080091.1080100 >=20 > EL >=20 > -- > Emmanuel Lochin > Professeur ISAE - OSSI > Institut Sup=E9rieur de l'A=E9ronautique et de l'Espace (ISAE) Issu du > rapprochement SUPAERO et ENSICA > 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 3= 3 > 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel- > lochin/ > --- > "This email and any attachments are confidential. They may contain legall= y > privileged information or copyright material. You should not read, copy, > use or disclose them without authorisation. If you are not an intended > recipient, please contact us at once by return email and then delete both > messages. We do not accept liability in connection with computer virus, > data corruption, delay, interruption, unauthorised access or unauthorised > amendment. This notice should not be removed" >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Wed Mar 20 09:14:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7BD21F842A; Wed, 20 Mar 2013 09:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.015 X-Spam-Level: X-Spam-Status: No, score=-10.015 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwoYnAKiDFs6; Wed, 20 Mar 2013 09:14:07 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7821F8415; Wed, 20 Mar 2013 09:14:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,879,1355126400"; d="scan'208";a="32372231" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 20 Mar 2013 09:14:05 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2KGE4l3029309; Wed, 20 Mar 2013 09:14:04 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 09:14:03 -0700 From: "Scheffenegger, Richard" To: Simon Barber , Jim Gettys Thread-Topic: =?utf-8?B?W2FxbV0g562U5aSNOiBbaWNjcmddIFt0Y3BtXSBFQ04gc3VwcG9ydCBhbmQg?= =?utf-8?Q?usage_on_the_Internet?= Thread-Index: AQHOJPuQ4YV4mgvTF0iHLgehV1ZAsZiuv+6Q Date: Wed, 20 Mar 2013 16:14:03 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC06F7@SACEXCMBX02-PRD.hq.netapp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com> <5148F80F.5000401@superduper.net> In-Reply-To: <5148F80F.5000401@superduper.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "iccrg@irtf.org" , =?utf-8?B?5aSp5r6c?= , "aqm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?W2FxbV0g562U5aSNOiBbaWNjcmddICBFQ04gc3VwcG9ydCBh?= =?utf-8?q?nd_usage_on_the_Internet?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 16:14:08 -0000 SGkgU2ltb24sDQoNCg0KRm9yIG9uZSwgdGhyb3VnaHB1dCBpcyB0aGUgb25lIG1ldHJpYywgdGhh dCBzaG91bGQgTk9UIGJlIGluZmx1ZW5jZWQgYnkgRUNOLCBhY3R1YWxseS4gU28gaWYgdGhhdCBp cyAiaW4gdGhlIG5vaXNlIiwgdGhhdCBpcyBhIHZlcnkgZ29vZCBzaWduOyANCg0KVGhlIG1vcmUg aW50ZXJlc3RpbmcgbWV0cmljcywgdGhhdCBhcmUgYWRkcmVzc2VkIHdpdGggRUNOIGFyZSBsYXRl bmN5ICgicGFnZSBsb2FkIHRpbWVzIikgYW5kIG5ldHdvcmsgZWZmaWNpZW5jeSAoZmV3ZXIgcGFj a2V0cyBhcmUgbmVlZGxlc3NseSBwcm9jZXNzZWQgaW4gaW5pdGlhbCBob3BzLCBqdXN0IHRvIGJl IGRyb3BwZWQgYnkgdGhlIHBlbnVsdGltYXRlIGhvcDsgdGhhdCBiYW5kd2lkdGggY2FuIGJlIGFs bG9jYXRlZCB0byBvdGhlciBmbG93cyBldGMpLg0KDQpPdGhlciBzY2hlbWVzIHRoYXQgcmVkdWNl IGxhdGVuY3kgdXN1YWxseSBkbyBzbyBieSB0cmFkaW5nIGEgZ29vZCBzaGFyZSBvZiBiYW5kd2lk dGguLi4gKGNyZWRpdCBhbGxvY2F0aW9uIHNjaGVtZSB1c2VkIGluIEZDLCBhbnlvbmU/KQ0KDQoN CkVDTiBoYXQgYSBodWdlIGlzc3VlIG9mIGRlcGxveWFiaWxpdHkgaXNzdWVzLCB0aGF0IGhhZCBu b3RoaW5nIHRvIGRvIHdpdGggdGhlIG1lY2hhbmlzbSBpdHNlbGYsIGJ1dCB3aXRoIG1pc2JlaGF2 aW5nIGVxdWlwbWVudCBvbiB0aGUgc2lnbmFsaW5nIC0gYW5kIHRoZSBpbnN0aXR1dGlvbmFsIG1l bW9yeSBzdGlsbCByZW1lbWJlcnMgdGhvc2UgYWxiZWl0IGFueSBuZXcgc2lnbmFsaW5nIHNjaGVt ZSBjb3VsZCBydW4gaW50byBzaW1pbGFyIGlzc3VlcyAoaW5kZXBlbmRlbnQgb2YgdGhlIG1lY2hh bmlzbXMpLg0KDQoNCkllLiBzb21lIHBlb3BsZSBzdGlsbCBoYXZlbid0IGdvdCB0aGUgTWVtbyB0 aGF0IElQdjQgVE9TIHdhcyBkZXByZWNhdGVkIHF1aXRlIHNvbWUgdGltZSBhZ28gKG5vdyBEaWZm U2Vydi9FQ04pLA0KDQpSZWdhcmRzLA0KDQpSaWNoYXJkIFNjaGVmZmVuZWdnZXINCg0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXFtLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzphcW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFNpbW9uIEJhcmJl cg0KPiBTZW50OiBNaXR0d29jaCwgMjAuIE3DpHJ6IDIwMTMgMDA6NDMNCj4gVG86IEppbSBHZXR0 eXMNCj4gQ2M6IFJpY2sgSm9uZXM7IGljY3JnQGlydGYub3JnOyB0Y3BtQGlldGYub3JnOyDlpKnm vpw7IGFxbUBpZXRmLm9yZzsgTWlrYWVsDQo+IEFicmFoYW1zc29uDQo+IFN1YmplY3Q6IFJlOiBb YXFtXSDnrZTlpI06IFtpY2NyZ10gW3RjcG1dIEVDTiBzdXBwb3J0IGFuZCB1c2FnZSBvbiB0aGUN Cj4gSW50ZXJuZXQNCj4gDQo+IEknbSBub3Qgc3VyZSB3aHkgcGVvcGxlIGFyZSBzbyBvYnNlc3Nl ZCB3aXRoIEVDTiAtIHRoZSBsaXR0bGUgZGF0YSBJJ3ZlDQo+IHNlZW4gYWJvdXQgaXQgc2hvd2Vk IHRoYXQgaXQncyBlZmZlY3Qgb24gc3lzdGVtIHRocm91Z2hwdXQgd2FzIGluIHRoZQ0KPiBub2lz ZS4gU3VyZSwgd2lyZWxlc3MgZ3V5cyBkb24ndCBsaWtlIHRvIHdhc3RlIHByZWNpb3VzIHdpcmVs ZXNzDQo+IGJhbmR3aWR0aCwgYnV0IHRoZXkncmUgbm90IGRyb3BwaW5nIHBhY2tldHMgdGhhdCBo YXZlIHVzZWQgdXAgdGhlIHByZWNpb3VzDQo+IHdpcmVsZXNzIGJhbmR3aWR0aC4gVGhleSBnZXQg ZHJvcHBlZCBiZWZvcmUgdGhlIHdpcmVsZXNzIGxpbmsuDQo+IA0KPiBTaW1vbg0KPiANCg0K From touch@isi.edu Wed Mar 20 09:26:43 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CFC21F8D6A for ; Wed, 20 Mar 2013 09:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.39 X-Spam-Level: X-Spam-Status: No, score=-104.39 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIMyN8RK9dLM for ; Wed, 20 Mar 2013 09:26:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A68A321F8C9E for ; Wed, 20 Mar 2013 09:26:37 -0700 (PDT) Received: from [192.168.1.89] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2KGPw7q013497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Mar 2013 09:26:10 -0700 (PDT) Message-ID: <5149E317.2080206@isi.edu> Date: Wed, 20 Mar 2013 09:25:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 16:26:44 -0000 Hi, all, On 3/20/2013 7:07 AM, Scheffenegger, Richard wrote: > Hi group, > running up to and during the IETF 86, the following points were raised > w.r.t 1323bis. I hope this lengthy email makes it through your tl;dr filter > ... > 2. Guidance regarding late TS negotiation: > > This is a technical (semantic) change of timestamps; the upcoming -07 > version of the draft will have this text added; is the WG satisfied with > this wording, or shall more specific (2119) wording be added: > > A TCP MAY send the Timestamps option (TSopt) in an initial > segment (i.e., a segment containing a SYN bit and no ACK bit). Once > a TSopt has been sent or received in a non segment, it MUST be > sent in all segments. Once a TSopt has been received in a non > segment, then any successive segment that is received without the RST > bit and without a TSopt MAY be dropped without further processing, > and an ACK of the current SND.UNA generated. > Note that it is RECOMMENDED to negotiate the use of the timestamp > option during the initial handshake. Although this document is less > restrictive regarding the use of the timestamp option when not sent > initially, any guidance and discussion of potential issues when > timestamp is enabled late in a session is beyond the scope of this > document. > > I have received suggestions, to increase the MAY in the first sentence > to a SHOULD (but that might indicate to implementers, that any TCP > session SHOULD have TS enabled, not that TS MAY be used, and if, it > SHOULD be negotiated during SYN). IMO, the first sentence should be a MUST. TCP needs to know about all the options it needs to support during the initial handshake. If you turn on the option later and it isn't supported, there's no way to "handshake" to let the other end know. > Another suggestion was to add a sentence like Timestamps MUST be > negotiated in and unless another mechanism allows > enabling them in during an established session. Such a mechanism is > outside the scope of this document. This is the one I expected, and is fine. It can either be confirmed by the option itself or by some other option; the overall assumption is that "the set of options that MAY be used during a TCP connection MUST be negotiated during the 3WHS". (that text is outside the scope of this doc, though) > 3. More appropriate introductory text; the following statement will > supersede very old text (that apparently addressed WS, TS and SACK > back in RFC1072); this was already presented at IETF 86 and received > no objections. > > The window scale option negotiates fundamental parameters of the TCP > session. Therefore, it is only sent during the initial handshake. > Furthermore, the window scale option will be sent in a > segment only if the corresponding option was received in the initial > segment. > The timestamps option may appear in any data or ACK segment, adding The "*" inserted below is explained further down... > 12 bytes to the 20-byte TCP header. * It is recommended that this TCP Again, IMO recommended should be REQUIRED (in all caps too). > option will be sent on non-SYN segments only after an exchange of > options on the SYN segments has indicated that both sides understand > the extension. The portion below is a bit different: > We believe that the bandwidth saved by reducing > unnecessary retransmission timeouts will more than pay for the extra > header bandwidth. it talks about the bandwidth of the overall connection; it's not specific to the SYN exchange. It might be useful to move this up to the "*" above. Joe From andre@freebsd.org Thu Mar 21 04:36:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D33921F87D9 for ; Thu, 21 Mar 2013 04:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPJ6rYxKVHCh for ; Thu, 21 Mar 2013 04:36:04 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id DA89221F87D0 for ; Thu, 21 Mar 2013 04:36:03 -0700 (PDT) Received: (qmail 46750 invoked from network); 21 Mar 2013 12:46:59 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Mar 2013 12:46:59 -0000 Message-ID: <514AF098.9040108@freebsd.org> Date: Thu, 21 Mar 2013 12:35:52 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joe Touch References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> In-Reply-To: <5149E317.2080206@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 11:36:05 -0000 On 20.03.2013 17:25, Joe Touch wrote: > Hi, all, > > On 3/20/2013 7:07 AM, Scheffenegger, Richard wrote: >> Hi group, >> running up to and during the IETF 86, the following points were raised >> w.r.t 1323bis. I hope this lengthy email makes it through your tl;dr filter >> > ... >> 2. Guidance regarding late TS negotiation: >> >> This is a technical (semantic) change of timestamps; the upcoming -07 >> version of the draft will have this text added; is the WG satisfied with >> this wording, or shall more specific (2119) wording be added: >> >> A TCP MAY send the Timestamps option (TSopt) in an initial >> segment (i.e., a segment containing a SYN bit and no ACK bit). Once >> a TSopt has been sent or received in a non segment, it MUST be >> sent in all segments. Once a TSopt has been received in a non >> segment, then any successive segment that is received without the RST >> bit and without a TSopt MAY be dropped without further processing, >> and an ACK of the current SND.UNA generated. >> Note that it is RECOMMENDED to negotiate the use of the timestamp >> option during the initial handshake. Although this document is less >> restrictive regarding the use of the timestamp option when not sent >> initially, any guidance and discussion of potential issues when >> timestamp is enabled late in a session is beyond the scope of this >> document. > > >> I have received suggestions, to increase the MAY in the first sentence >> to a SHOULD (but that might indicate to implementers, that any TCP >> session SHOULD have TS enabled, not that TS MAY be used, and if, it >> SHOULD be negotiated during SYN). > > IMO, the first sentence should be a MUST. TCP needs to know about all the options it needs to > support during the initial handshake. If you turn on the option later and it isn't supported, > there's no way to "handshake" to let the other end know. Seconded. >> Another suggestion was to add a sentence like Timestamps MUST be >> negotiated in and unless another mechanism allows >> enabling them in during an established session. Such a mechanism is >> outside the scope of this document. > > This is the one I expected, and is fine. It can either be confirmed by the option itself or by some > other option; the overall assumption is that "the set of options that MAY be used during a TCP > connection MUST be negotiated during the 3WHS". (that text is outside the scope of this doc, though) > >> 3. More appropriate introductory text; the following statement will >> supersede very old text (that apparently addressed WS, TS and SACK >> back in RFC1072); this was already presented at IETF 86 and received >> no objections. >> >> The window scale option negotiates fundamental parameters of the TCP >> session. Therefore, it is only sent during the initial handshake. >> Furthermore, the window scale option will be sent in a >> segment only if the corresponding option was received in the initial >> segment. >> The timestamps option may appear in any data or ACK segment, adding > > The "*" inserted below is explained further down... > >> 12 bytes to the 20-byte TCP header. * It is recommended that this TCP > > Again, IMO recommended should be REQUIRED (in all caps too). Is required the correct RFC keyword? Shouldn't the sentence be rewritten to make it use the "MUST" keyword? -- Andre >> option will be sent on non-SYN segments only after an exchange of >> options on the SYN segments has indicated that both sides understand >> the extension. > > The portion below is a bit different: > >> We believe that the bandwidth saved by reducing >> unnecessary retransmission timeouts will more than pay for the extra >> header bandwidth. > > it talks about the bandwidth of the overall connection; it's not specific to the SYN exchange. It > might be useful to move this up to the "*" above. > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From andre@freebsd.org Thu Mar 21 04:42:03 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C8C21F8DE9 for ; Thu, 21 Mar 2013 04:42:03 -0700 (PDT) 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=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv7hOGsJCk65 for ; Thu, 21 Mar 2013 04:42:02 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B03021F8DD2 for ; Thu, 21 Mar 2013 04:42:02 -0700 (PDT) Received: (qmail 46777 invoked from network); 21 Mar 2013 12:52:55 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Mar 2013 12:52:55 -0000 Message-ID: <514AF1FD.4060004@freebsd.org> Date: Thu, 21 Mar 2013 12:41:49 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] Quantitative measurements of the SYN WSCALE factors? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 11:42:03 -0000 All, I'm looking for quantitative measurements and histograms on SYN WSCALE factors on recent representative packet traces. I've found quite a bit on MSS values but unfortunately nothing on WSCALE. Googling didn't turn up anything either. Do you know about some source that has information on WSCALE values or can you extract it from packet traces you have access to? Thanks -- Andre From prvs=1792399a12=david.borman@quantum.com Thu Mar 21 07:07:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F87721F909B for ; Thu, 21 Mar 2013 07:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrPijYfswkhh for ; Thu, 21 Mar 2013 07:07:57 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7EC21F9092 for ; Thu, 21 Mar 2013 07:07:56 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2LE7sJb000343; Thu, 21 Mar 2013 07:07:56 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 1b7fy3hcn1-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 07:07:55 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 21 Mar 2013 08:07:09 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Thu, 21 Mar 2013 08:07:28 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] 1323bis - preparing for WGLC Thread-Index: AQHOJj1rdRfnG5R1r0CvnEcDPb7gqg== Date: Thu, 21 Mar 2013 14:06:57 +0000 Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> In-Reply-To: <5149E317.2080206@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.176.229] Content-ID: <6603FAC69A07524B987E5353C67DA717@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-21_03:2013-03-21, 2013-03-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303210089 Content-Type: text/plain; charset="Windows-1252" Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 14:07:58 -0000 On Mar 20, 2013, at 11:25 AM, Joe Touch wrote: > Hi, all, >=20 > On 3/20/2013 7:07 AM, Scheffenegger, Richard wrote: >> Hi group, >> running up to and during the IETF 86, the following points were raised >> w.r.t 1323bis. I hope this lengthy email makes it through your tl;dr fil= ter=85 >>=20 > ... >> 2. Guidance regarding late TS negotiation: >>=20 >> This is a technical (semantic) change of timestamps; the upcoming -07 >> version of the draft will have this text added; is the WG satisfied with >> this wording, or shall more specific (2119) wording be added: >>=20 >> A TCP MAY send the Timestamps option (TSopt) in an initial >> segment (i.e., a segment containing a SYN bit and no ACK bit). Once >> a TSopt has been sent or received in a non segment, it MUST be >> sent in all segments. Once a TSopt has been received in a non >> segment, then any successive segment that is received without the RST >> bit and without a TSopt MAY be dropped without further processing, >> and an ACK of the current SND.UNA generated. >> Note that it is RECOMMENDED to negotiate the use of the timestamp >> option during the initial handshake. Although this document is less >> restrictive regarding the use of the timestamp option when not sent >> initially, any guidance and discussion of potential issues when >> timestamp is enabled late in a session is beyond the scope of this >> document. > > >> I have received suggestions, to increase the =93MAY=94 in the first sent= ence >> to a =93SHOULD=94 (but that might indicate to implementers, that any TCP >> session SHOULD have TS enabled, not that TS MAY be used, and if, it >> SHOULD be negotiated during SYN). >=20 > IMO, the first sentence should be a MUST. TCP needs to know about all the= options it needs to support during the initial handshake. If you turn on t= he option later and it isn't supported, there's no way to "handshake" to le= t the other end know. That really depends on the TCP option. Turning on timestamps midstream without it being in the initial SYN isn't technically that hard, as long as once you start sending and receiving them, you continue to send/receive them for the rest of the connection. The original reason for negotiating options in the SYN was twofold: 1) SYNs are reliably delivered, hence no additional negotiation mechanism is needed. 2) At the time, all TCP implementations would handle unknown options in the SYN, but some implementations would crash if they received unknown TCP options in non-SYN packets. Hopefully reason #2 is no longer needed. Enabling TS midstream on the receiver is easy: if you receive any packet with TS, then enable TS and use it for the duration of the connection. On the sender, you just start sending TS in every packet, and remember the seq# of the first non-retransmitted packet that was sent with TS. If a TS is received in any packet, then enable TS for the duration of the connection. If no TS has been received when an ACK that covers the initial TS seq# is received, then disable sending TS for the duration of the connection. As long as an unexpected TS mid-stream doesn't crash the other side, then you're good to go, provided you take care of using the TS for PAWS during the transition. Other options, like WS, have to be negotiated in the SYN; trying to change the WS value mid-stream using the current option would require implementing additional negotiating mechanisms, since ACKs are not reliably transmitted. Honestly, the dictum that all TCP options have to be negotiated in the SYN is to avoid sending TCP options mid stream to the other side that the other side doesn't understand and isn't able to properly ignore without crashing. Be conservative in what you send, liberal in what you receive. But maybe it's time to say that any TCP implementation that can't safely ignore unknown options mid-stream is just plain broken and the standards shouldn't continue to try to accommodate them anymore.=20 -David Borman >=20 >> Another suggestion was to add a sentence like =93Timestamps MUST be >> negotiated in and unless another mechanism allows >> enabling them in during an established session. Such a mechanism is >> outside the scope of this document.=94 >=20 > This is the one I expected, and is fine. It can either be confirmed by th= e option itself or by some other option; the overall assumption is that "th= e set of options that MAY be used during a TCP connection MUST be negotiate= d during the 3WHS". (that text is outside the scope of this doc, though) >=20 >> 3. More appropriate introductory text; the following statement will >> supersede very old text (that apparently addressed WS, TS and SACK >> back in RFC1072); this was already presented at IETF 86 and received >> no objections. >>=20 >> The window scale option negotiates fundamental parameters of the TCP >> session. Therefore, it is only sent during the initial handshake. >> Furthermore, the window scale option will be sent in a >> segment only if the corresponding option was received in the initial >> segment. >> The timestamps option may appear in any data or ACK segment, adding >=20 > The "*" inserted below is explained further down... >=20 >> 12 bytes to the 20-byte TCP header. * It is recommended that this TCP >=20 > Again, IMO recommended should be REQUIRED (in all caps too). >=20 >> option will be sent on non-SYN segments only after an exchange of >> options on the SYN segments has indicated that both sides understand >> the extension. >=20 > The portion below is a bit different: >=20 >> We believe that the bandwidth saved by reducing >> unnecessary retransmission timeouts will more than pay for the extra >> header bandwidth. >=20 > it talks about the bandwidth of the overall connection; it's not specific= to the SYN exchange. It might be useful to move this up to the "*" above. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From andre@freebsd.org Thu Mar 21 07:23:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C321F85DF for ; Thu, 21 Mar 2013 07:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYhU+GtozgGw for ; Thu, 21 Mar 2013 07:23:47 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B821F90BC for ; Thu, 21 Mar 2013 07:23:41 -0700 (PDT) Received: (qmail 48369 invoked from network); 21 Mar 2013 15:34:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Mar 2013 15:34:36 -0000 Message-ID: <514B17E2.8040309@freebsd.org> Date: Thu, 21 Mar 2013 15:23:30 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Borman References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 14:23:48 -0000 On 21.03.2013 15:06, David Borman wrote: > > On Mar 20, 2013, at 11:25 AM, Joe Touch wrote: > >> Hi, all, >> >> On 3/20/2013 7:07 AM, Scheffenegger, Richard wrote: >>> Hi group, >>> running up to and during the IETF 86, the following points were raised >>> w.r.t 1323bis. I hope this lengthy email makes it through your tl;dr filter >>> >> ... >>> 2. Guidance regarding late TS negotiation: >>> >>> This is a technical (semantic) change of timestamps; the upcoming -07 >>> version of the draft will have this text added; is the WG satisfied with >>> this wording, or shall more specific (2119) wording be added: >>> >>> A TCP MAY send the Timestamps option (TSopt) in an initial >>> segment (i.e., a segment containing a SYN bit and no ACK bit). Once >>> a TSopt has been sent or received in a non segment, it MUST be >>> sent in all segments. Once a TSopt has been received in a non >>> segment, then any successive segment that is received without the RST >>> bit and without a TSopt MAY be dropped without further processing, >>> and an ACK of the current SND.UNA generated. >>> Note that it is RECOMMENDED to negotiate the use of the timestamp >>> option during the initial handshake. Although this document is less >>> restrictive regarding the use of the timestamp option when not sent >>> initially, any guidance and discussion of potential issues when >>> timestamp is enabled late in a session is beyond the scope of this >>> document. >>> >>> I have received suggestions, to increase the MAY in the first sentence >>> to a SHOULD (but that might indicate to implementers, that any TCP >>> session SHOULD have TS enabled, not that TS MAY be used, and if, it >>> SHOULD be negotiated during SYN). >> >> IMO, the first sentence should be a MUST. TCP needs to know about all the options it needs to support during the initial handshake. If you turn on the option later and it isn't supported, there's no way to "handshake" to let the other end know. > > That really depends on the TCP option. > > Turning on timestamps midstream without it being in the initial SYN isn't > technically that hard, as long as once you start sending and receiving them, > you continue to send/receive them for the rest of the connection. > > The original reason for negotiating options in the SYN was twofold: > 1) SYNs are reliably delivered, hence no additional negotiation > mechanism is needed. 2) At the time, all TCP implementations would > handle unknown options in the SYN, but some implementations would > crash if they received unknown TCP options in non-SYN packets. > > Hopefully reason #2 is no longer needed. Unlikely that any TCP implementation crashes on unknown options. And if they do they get what they deserve. There is a very different problem though. Firewalls again. Those doing stateful inspection may drop packets when well-known but not negotiated options show up. Without empirical studies on the current situation we should not allow this change in behavior of late TS enabling. -- Andre From rs@netapp.com Thu Mar 21 07:30:46 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8EA21F8F53 for ; Thu, 21 Mar 2013 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.065 X-Spam-Level: X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cilw3-si+tjP for ; Thu, 21 Mar 2013 07:30:46 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0CD21F8E1C for ; Thu, 21 Mar 2013 07:30:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,886,1355126400"; d="scan'208";a="32697049" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 21 Mar 2013 07:30:45 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LEUiGW014044; Thu, 21 Mar 2013 07:30:45 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 07:30:45 -0700 From: "Scheffenegger, Richard" To: Andre Oppermann , Joe Touch Thread-Topic: [tcpm] 1323bis - TS nego Thread-Index: Ac4mQE2pizJKahIYQqC1lOJidFaTgw== Date: Thu, 21 Mar 2013 14:30:44 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC5055@SACEXCMBX02-PRD.hq.netapp.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - TS nego X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 14:30:46 -0000 Hi Andre, Joe, Thank you for your feedback. Further comments are still very welcome! > >> I have received suggestions, to increase the "MAY" in the first > >> sentence to a "SHOULD" (but that might indicate to implementers, that > >> any TCP session SHOULD have TS enabled, not that TS MAY be used, and > >> if, it SHOULD be negotiated during SYN). > > > > IMO, the first sentence should be a MUST. TCP needs to know about all > > the options it needs to support during the initial handshake. If you > > turn on the option later and it isn't supported, there's no way to > "handshake" to let the other end know. >=20 > Seconded. That section now reads: A TCP MAY send the Timestamps option (TSopt) in an initial segment. The Timestamp option MUST be negotiated during the initial and unless another mechanism allows to enable it during an established session. However, such a mechanism is outside the scope of this document. When TSopt has been sent or received in a non segment, it MUST be sent in all segments. Once a TSopt has been received in a non segment, then any successive segment that is received without the RST bit and without a TSopt MAY be dropped without further processing, and an ACK of the current SND.UNA generated. I think the "MAY" in the very first sentence is appropriate to underline th= at this really is an optional enhancement to TCP, not a "REQUIRED" one - no= t even in the context of RFC1323bis. One can implement/enable Window Scale = without TS and vice versa.=20 The 2nd Sentence then alludes to the fact, that Joe pointed out, that any T= CP option that may be used later in the session, must^h^h^h^h should be neg= otiated initially. The particular wording here actually still allows a passive (receiver side)= late TS enablement - making the current Linux behavior compliant. Note tha= t this is almost the same wording as in 1323. Also, it describes a very simple mechanism, actually:=20 When a sender eventually starts sending TSopt, it can never go back - even = when the ACKs never contain any TSopt. Which IMHO is the only way to do it,= really, as potentially a middlebox has not removed the TSopt on the forwar= d path, and only "cleans" the TSopt from the ACKs on the return path. Thus = I'm not sure, if "MUST" in the 2nd sentence is the proper 2119 word... However,=20 >> the overall assumption is that=20 >> "the set of options that MAY be used during a TCP connection MUST=20 >> be negotiated during the 3WHS". limits the effective number of useful TCP options to 20 (as at the very lea= st, two bytes, option + len, have to be in the ).=20 Also, such a requirement implicitly rules out potential later suggestions t= o "collapse" certain sets of options to a single TCP option in the . T= hus I'm not fully convinced, that we want to make this an explicit requirem= ent (although I see, that effectively it's already an implicit requirement = with all the middleboxes). Best regards, Richard Scheffenegger From rs@netapp.com Thu Mar 21 07:47:17 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2521F90CE for ; Thu, 21 Mar 2013 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.361 X-Spam-Level: X-Spam-Status: No, score=-10.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4dESASRVwnb for ; Thu, 21 Mar 2013 07:47:16 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7B14821F909E for ; Thu, 21 Mar 2013 07:47:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,886,1355126400"; d="scan'208";a="32701364" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 21 Mar 2013 07:47:16 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LElGup003627; Thu, 21 Mar 2013 07:47:16 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 07:47:16 -0700 From: "Scheffenegger, Richard" To: Andre Oppermann , Joe Touch Thread-Topic: [tcpm] 1323bis - introduction Thread-Index: Ac4mQNsmiLtNQQ8oRUqABTs3iVWTXg== Date: Thu, 21 Mar 2013 14:47:14 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - introduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 14:47:17 -0000 Hi Andre, Joe, New text fragment reads: The timestamp option may appear in any data or ACK segment, adding 12 bytes to the 20-byte TCP header. We believe that the bandwidth saved by reducing unnecessary retransmission timeouts will more than pay for the extra header bandwidth. It is required that this TCP option will be sent on non- segments only after an exchange of options on the segments has indicated that both sides understand this extension. To your remarks: >>> The timestamps option may appear in any data or ACK=20 >>> segment, adding >> >> The "*" inserted below is explained further down... >> >>> 12 bytes to the 20-byte TCP header. * It is recommended that >>> this TCP >> >> Again, IMO recommended should be REQUIRED (in all caps too). >=20 > Is required the correct RFC keyword? Shouldn't the sentence be rewritten > to make it use the "MUST" keyword? >=20 This is still section 1, before the RFC2119 disclaimer. This is introductor= y text, thus I refrained from any ALL CAPS words everywhere in section 1 (e= xcept for the 2119 disclaimer, that is the last subsection of section 1). As mentioned in the comment to the normative section, the actual current 13= 23 text allows the receiver to start reflecting TSopt as soon as it sees it= . Disallowing this would have two effects: a) certain widely deployed stacks would no longer comply with 1323 (as obso= leted by 1323bis) b) it would limit further developments regarding the timestamp option that = could potentially be sender-side only modifications initially. Any comments? Best regards, Richard Scheffenegger >>> option will be sent on non-SYN segments only after an=20 >>> exchange of options on the SYN segments has indicated=20 >>> that both sides understand the extension. >> >> The portion below is a bit different: >> >>> We believe that the bandwidth saved by reducing >>> unnecessary retransmission timeouts will more than=20 >>> pay for the extra header bandwidth. >> >> it talks about the bandwidth of the overall connection; it's not >> specific to the SYN exchange. It might be useful to move this up to the >"*" above. >> > From mallman@icir.org Thu Mar 21 08:01:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCDE21F9092 for ; Thu, 21 Mar 2013 08:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQkn-FIv8yvn for ; Thu, 21 Mar 2013 08:01:59 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id CE32221F875C for ; Thu, 21 Mar 2013 08:01:58 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2LF1m5L014553; Thu, 21 Mar 2013 08:01:48 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A0D76C6C770; Thu, 21 Mar 2013 11:01:48 -0400 (EDT) To: Andre Oppermann From: Mark Allman In-Reply-To: <514B17E2.8040309@freebsd.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Takin' Care of Business X-URL-0: http://www.icir.org/mallman-files/Document3471.doc MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma8410-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Mar 2013 11:01:48 -0400 Sender: mallman@icir.org Message-Id: <20130321150148.A0D76C6C770@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:01:59 -0000 ----------ma8410-1 Content-Type: text/plain Content-Disposition: inline I agree with David. > Unlikely that any TCP implementation crashes on unknown options. > And if they do they get what they deserve. Exactly. > There is a very different problem though. Firewalls again. Those > doing stateful inspection may drop packets when well-known but not > negotiated options show up. > > Without empirical studies on the current situation we should not > allow this change in behavior of late TS enabling. Well, luckily we have some empirical study: Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps We injected a TS and an unknown junk option into the middle of connections (independently) without negotiation in the 3WHS. The connection failure rate in both cases is 3%. If we instead put the options in the SYN the connection failure rate is 0.2%. We cannot of course tell why the connection is failing. It could be middleboxes or it could be receivers. That paper is 8 years old and the data a bit older. Perhaps someone has newer data. But, my guess is that this shows that this is simply not a big problem. My hit here is that timestamps are simply a waste. They take space. They take complexity and processing at the endpoints. And, yet, they provide benefit on only exceedingly rare occasions. In particular, - If you want to use TS for RTTM then you'll just turn it on from the beginning and be done with it. (RTTM doesn't buy you anything, but thats beside the point.) - If you want to use TS for Eifel then you'll turn it on from the beginning and be done with it. - If you want to use TS for PAWS then you can get by without it until you've sent (nearly) 4GB (the sequence space) and you're sending quite fast (such that you might wrap too quickly). Well, go look at flow sizes on the Internet. Without even considering speed this is a Damn Small box. And, once you throw speed in it gets even smaller. And, throw on top of that the failure rate is pretty small (a long time ago) and I can't see where firing up TS as needed is at all problematic. (Plus, we cannot engineer for the corner of the corner case that you found off to the side of the side road. Or, so it seems to me.) allman ----------ma8410-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFLINwACgkQWyrrWs4yIs6dUQCfcBkZYeltob7guejZ+FHxOfHB h+4AoJIziJNmegrMWBucvKVAEYycinNz =IjWE -----END PGP SIGNATURE----- ----------ma8410-1-- From rs@netapp.com Thu Mar 21 08:07:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A28921F9121 for ; Thu, 21 Mar 2013 08:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSVBPYiQu91f for ; Thu, 21 Mar 2013 08:07:18 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5321F90F1 for ; Thu, 21 Mar 2013 08:07:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="248051507" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 21 Mar 2013 08:07:18 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LF7HB3004699; Thu, 21 Mar 2013 08:07:18 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 08:07:17 -0700 From: "Scheffenegger, Richard" To: David Borman , Joe Touch Thread-Topic: [tcpm] 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+NzgAUcmOAAC1vjIAADROhYA== Date: Thu, 21 Mar 2013 15:07:16 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC52A3@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> 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.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 15:07:19 -0000 Thank you David! You made some insightful comments, that I agree with! To this, I want to add some thoughts: > Enabling TS midstream on the receiver is easy: if you receive any > packet with TS, then enable TS and use it for the duration of the > connection. On the sender, you just start sending TS in every > packet, and remember the seq# of the first non-retransmitted packet > that was sent with TS. If a TS is received in any packet, then enable > TS for the duration of the connection. If no TS has been received when > an ACK that covers the initial TS seq# is received, then disable > sending TS for the duration of the connection. It's really the middleboxes that we need to work around in such a scenario.= .. 1) In the forward path, a middlebox might start dropping segments, that con= tain TSopt which wasn't negotiated for. Thus a receiver never sees these da= ta segments... 2) Or a middlebox might scrub the TSopt from the data packets before delive= ry... 3) In the return path, again a middle box might stop forwarding an ACK cont= aining TSopt, if previous segments of that flow didn't have TSopt enabled. 4) Or that middlebox again scrubs the TSopt before delivery. Cases 1+3 and 2+4 are virtually identical to the sender:=20 In 1+3, the sender would not see any ACKs beyond the seq#, where TSopt was = stated; Eventually multiple back-to-back RTOs would happen.=20 In 2+4, the sender would see the ACKs, but without any TSopt. However, the = receiver might have started using TSopt already on the receiver processing,= thus it would be better to keep on sending with TSopt enabled. Only when a RTO (or the 2nd RTO) for the data packet with the Seq# where TS= opt was enabled happens, than it would be save to disable TSopt again... Bu= t once Snd.Fack or Snd.Una goes beyond the Seq# of the first TSopt segment,= there should be no way to disable TSopt again... Does that sound reasonable? Richard Scheffenegger > -----Original Message----- > From: David Borman [mailto:David.Borman@quantum.com] > Sent: Donnerstag, 21. M=E4rz 2013 15:07 > To: Joe Touch > Cc: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] 1323bis - preparing for WGLC >=20 >=20 > On Mar 20, 2013, at 11:25 AM, Joe Touch wrote: >=20 > > Hi, all, > > > > On 3/20/2013 7:07 AM, Scheffenegger, Richard wrote: > >> Hi group, > >> running up to and during the IETF 86, the following points were raised > >> w.r.t 1323bis. I hope this lengthy email makes it through your tl;dr > filter. > >> > > ... > >> 2. Guidance regarding late TS negotiation: > >> > >> This is a technical (semantic) change of timestamps; the upcoming -07 > >> version of the draft will have this text added; is the WG satisfied > with > >> this wording, or shall more specific (2119) wording be added: > >> > >> A TCP MAY send the Timestamps option (TSopt) in an initial > >> segment (i.e., a segment containing a SYN bit and no ACK bit). Onc= e > >> a TSopt has been sent or received in a non segment, it MUST b= e > >> sent in all segments. Once a TSopt has been received in a non > >> segment, then any successive segment that is received without the > RST > >> bit and without a TSopt MAY be dropped without further processing, > >> and an ACK of the current SND.UNA generated. > >> Note that it is RECOMMENDED to negotiate the use of the timestamp > >> option during the initial handshake. Although this document is les= s > >> restrictive regarding the use of the timestamp option when not sent > >> initially, any guidance and discussion of potential issues when > >> timestamp is enabled late in a session is beyond the scope of this > >> document. > > > > >> I have received suggestions, to increase the "MAY" in the first > sentence > >> to a "SHOULD" (but that might indicate to implementers, that any TCP > >> session SHOULD have TS enabled, not that TS MAY be used, and if, it > >> SHOULD be negotiated during SYN). > > > > IMO, the first sentence should be a MUST. TCP needs to know about all > the options it needs to support during the initial handshake. If you turn > on the option later and it isn't supported, there's no way to "handshake" > to let the other end know. >=20 > That really depends on the TCP option. >=20 > Turning on timestamps midstream without it being in the initial SYN isn't > technically that hard, as long as once you start sending and receiving > them, > you continue to send/receive them for the rest of the connection. >=20 > The original reason for negotiating options in the SYN was twofold: > 1) SYNs are reliably delivered, hence no additional negotiation > mechanism is needed. 2) At the time, all TCP implementations would > handle unknown options in the SYN, but some implementations would > crash if they received unknown TCP options in non-SYN packets. >=20 > Hopefully reason #2 is no longer needed. >=20 > Enabling TS midstream on the receiver is easy: if you receive any > packet with TS, then enable TS and use it for the duration of the > connection. On the sender, you just start sending TS in every > packet, and remember the seq# of the first non-retransmitted packet > that was sent with TS. If a TS is received in any packet, then enable > TS for the duration of the connection. If no TS has been received when > an ACK that covers the initial TS seq# is received, then disable > sending TS for the duration of the connection. >=20 > As long as an unexpected TS mid-stream doesn't crash the other > side, then you're good to go, provided you take care of using > the TS for PAWS during the transition. >=20 > Other options, like WS, have to be negotiated in the SYN; trying > to change the WS value mid-stream using the current option would > require implementing additional negotiating mechanisms, since > ACKs are not reliably transmitted. >=20 > Honestly, the dictum that all TCP options have to be negotiated > in the SYN is to avoid sending TCP options mid stream to the other > side that the other side doesn't understand and isn't able to > properly ignore without crashing. Be conservative in what you > send, liberal in what you receive. But maybe it's time to say > that any TCP implementation that can't safely ignore unknown > options mid-stream is just plain broken and the standards shouldn't > continue to try to accommodate them anymore. >=20 > -David Borman >=20 > > > >> Another suggestion was to add a sentence like "Timestamps MUST be > >> negotiated in and unless another mechanism allows > >> enabling them in during an established session. Such a mechanism is > >> outside the scope of this document." > > > > This is the one I expected, and is fine. It can either be confirmed by > the option itself or by some other option; the overall assumption is that > "the set of options that MAY be used during a TCP connection MUST be > negotiated during the 3WHS". (that text is outside the scope of this doc, > though) > > > >> 3. More appropriate introductory text; the following statement will > >> supersede very old text (that apparently addressed WS, TS and SACK > >> back in RFC1072); this was already presented at IETF 86 and receive= d > >> no objections. > >> > >> The window scale option negotiates fundamental parameters of the TC= P > >> session. Therefore, it is only sent during the initial handshake. > >> Furthermore, the window scale option will be sent in a > >> segment only if the corresponding option was received in the initia= l > >> segment. > >> The timestamps option may appear in any data or ACK segment, adding > > > > The "*" inserted below is explained further down... > > > >> 12 bytes to the 20-byte TCP header. * It is recommended that this > TCP > > > > Again, IMO recommended should be REQUIRED (in all caps too). > > > >> option will be sent on non-SYN segments only after an exchange of > >> options on the SYN segments has indicated that both sides understan= d > >> the extension. > > > > The portion below is a bit different: > > > >> We believe that the bandwidth saved by reducing > >> unnecessary retransmission timeouts will more than pay for the extr= a > >> header bandwidth. > > > > it talks about the bandwidth of the overall connection; it's not > specific to the SYN exchange. It might be useful to move this up to the > "*" above. > > > > Joe > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any > disclosure, copying, or further distribution of confidential information > is not permitted unless such privilege is explicitly granted in writing b= y > Quantum. Quantum reserves the right to have electronic communications, > including email and attachments, sent across its networks filtered throug= h > anti virus and spam software programs and retain such messages in order t= o > comply with applicable data security and retention requirements. Quantum > is not responsible for the proper and complete transmission of the > substance of this communication or for any delay in its receipt. From michael.scharf@alcatel-lucent.com Thu Mar 21 08:20:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D119B21F90EC for ; Thu, 21 Mar 2013 08:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.649 X-Spam-Level: X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmGLOHa7tikA for ; Thu, 21 Mar 2013 08:20:34 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7085221F8775 for ; Thu, 21 Mar 2013 08:20:34 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2LFKWYV020860 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Mar 2013 16:20:32 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 21 Mar 2013 16:20:32 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , David Borman , Joe Touch Date: Thu, 21 Mar 2013 16:20:32 +0100 Thread-Topic: [tcpm] 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+NzgAUcmOAAC1vjIAADROhYAAZfKiA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D7E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24AC52A3@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC52A3@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 15:20:36 -0000 To me, this discussion would perfectly fit into a new ID on allowing late T= S enabling. It would be short and straightforward. But a separate ID could = be easier than adding these kinds of thoughts to the 1323bis document, whic= h we want to finish... I think that such a new document would be allowed by "The Timestamp option = MUST be negotiated during the initial and unless another me= chanism allows to enable it during an established session.". Michael (chair hat off) =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Scheffenegger, Richard > Sent: Thursday, March 21, 2013 4:07 PM > To: David Borman; Joe Touch > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] 1323bis - preparing for WGLC >=20 > Thank you David! >=20 >=20 > You made some insightful comments, that I agree with! >=20 > To this, I want to add some thoughts: >=20 >=20 > > Enabling TS midstream on the receiver is easy: if you receive any=20 > > packet with TS, then enable TS and use it for the duration of the=20 > > connection. On the sender, you just start sending TS in=20 > every packet,=20 > > and remember the seq# of the first non-retransmitted packet=20 > that was=20 > > sent with TS. If a TS is received in any packet, then=20 > enable TS for=20 > > the duration of the connection. If no TS has been received when an=20 > > ACK that covers the initial TS seq# is received, then=20 > disable sending=20 > > TS for the duration of the connection. >=20 >=20 > It's really the middleboxes that we need to work around in=20 > such a scenario... >=20 > 1) In the forward path, a middlebox might start dropping=20 > segments, that contain TSopt which wasn't negotiated for.=20 > Thus a receiver never sees these data segments... >=20 > 2) Or a middlebox might scrub the TSopt from the data packets=20 > before delivery... >=20 >=20 > 3) In the return path, again a middle box might stop=20 > forwarding an ACK containing TSopt, if previous segments of=20 > that flow didn't have TSopt enabled. >=20 > 4) Or that middlebox again scrubs the TSopt before delivery. >=20 >=20 > Cases 1+3 and 2+4 are virtually identical to the sender:=20 >=20 > In 1+3, the sender would not see any ACKs beyond the seq#,=20 > where TSopt was stated; Eventually multiple back-to-back RTOs=20 > would happen.=20 >=20 > In 2+4, the sender would see the ACKs, but without any TSopt.=20 > However, the receiver might have started using TSopt already=20 > on the receiver processing, thus it would be better to keep=20 > on sending with TSopt enabled. >=20 > Only when a RTO (or the 2nd RTO) for the data packet with the=20 > Seq# where TSopt was enabled happens, than it would be save=20 > to disable TSopt again... But once Snd.Fack or Snd.Una goes=20 > beyond the Seq# of the first TSopt segment, there should be=20 > no way to disable TSopt again... >=20 >=20 > Does that sound reasonable? >=20 >=20 >=20 > Richard Scheffenegger >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: David Borman [mailto:David.Borman@quantum.com] > > Sent: Donnerstag, 21. M=E4rz 2013 15:07 > > To: Joe Touch > > Cc: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > > Subject: Re: [tcpm] 1323bis - preparing for WGLC > >=20 > >=20 > > On Mar 20, 2013, at 11:25 AM, Joe Touch wrote: > >=20 > > > Hi, all, > > > > > > On 3/20/2013 7:07 AM, Scheffenegger, Richard wrote: > > >> Hi group, > > >> running up to and during the IETF 86, the following points were=20 > > >> raised w.r.t 1323bis. I hope this lengthy email makes it through=20 > > >> your tl;dr > > filter. > > >> > > > ... > > >> 2. Guidance regarding late TS negotiation: > > >> > > >> This is a technical (semantic) change of timestamps; the=20 > upcoming=20 > > >> -07 version of the draft will have this text added; is the WG=20 > > >> satisfied > > with > > >> this wording, or shall more specific (2119) wording be added: > > >> > > >> A TCP MAY send the Timestamps option (TSopt) in an=20 > initial > > >> segment (i.e., a segment containing a SYN bit and no=20 > ACK bit). Once > > >> a TSopt has been sent or received in a non =20 > segment, it MUST be > > >> sent in all segments. Once a TSopt has been received=20 > in a non > > >> segment, then any successive segment that is received without=20 > > >> the > > RST > > >> bit and without a TSopt MAY be dropped without=20 > further processing, > > >> and an ACK of the current SND.UNA generated. > > >> Note that it is RECOMMENDED to negotiate the use of=20 > the timestamp > > >> option during the initial handshake. Although this=20 > document is less > > >> restrictive regarding the use of the timestamp option=20 > when not sent > > >> initially, any guidance and discussion of potential=20 > issues when > > >> timestamp is enabled late in a session is beyond the=20 > scope of this > > >> document. > > > > > > >> I have received suggestions, to increase the "MAY" in the first > > sentence > > >> to a "SHOULD" (but that might indicate to implementers, that any=20 > > >> TCP session SHOULD have TS enabled, not that TS MAY be used, and=20 > > >> if, it SHOULD be negotiated during SYN). > > > > > > IMO, the first sentence should be a MUST. TCP needs to know about=20 > > > all > > the options it needs to support during the initial=20 > handshake. If you=20 > > turn on the option later and it isn't supported, there's no=20 > way to "handshake" > > to let the other end know. > >=20 > > That really depends on the TCP option. > >=20 > > Turning on timestamps midstream without it being in the initial SYN=20 > > isn't technically that hard, as long as once you start sending and=20 > > receiving them, you continue to send/receive them for the=20 > rest of the=20 > > connection. > >=20 > > The original reason for negotiating options in the SYN was twofold: > > 1) SYNs are reliably delivered, hence no additional negotiation=20 > > mechanism is needed. 2) At the time, all TCP implementations would=20 > > handle unknown options in the SYN, but some implementations would=20 > > crash if they received unknown TCP options in non-SYN packets. > >=20 > > Hopefully reason #2 is no longer needed. > >=20 > > Enabling TS midstream on the receiver is easy: if you receive any=20 > > packet with TS, then enable TS and use it for the duration of the=20 > > connection. On the sender, you just start sending TS in=20 > every packet,=20 > > and remember the seq# of the first non-retransmitted packet=20 > that was=20 > > sent with TS. If a TS is received in any packet, then=20 > enable TS for=20 > > the duration of the connection. If no TS has been received when an=20 > > ACK that covers the initial TS seq# is received, then=20 > disable sending=20 > > TS for the duration of the connection. > >=20 > > As long as an unexpected TS mid-stream doesn't crash the=20 > other side,=20 > > then you're good to go, provided you take care of using the TS for=20 > > PAWS during the transition. > >=20 > > Other options, like WS, have to be negotiated in the SYN; trying to=20 > > change the WS value mid-stream using the current option=20 > would require=20 > > implementing additional negotiating mechanisms, since ACKs are not=20 > > reliably transmitted. > >=20 > > Honestly, the dictum that all TCP options have to be=20 > negotiated in the=20 > > SYN is to avoid sending TCP options mid stream to the other=20 > side that=20 > > the other side doesn't understand and isn't able to properly ignore=20 > > without crashing. Be conservative in what you send,=20 > liberal in what=20 > > you receive. But maybe it's time to say that any TCP=20 > implementation=20 > > that can't safely ignore unknown options mid-stream is just plain=20 > > broken and the standards shouldn't continue to try to=20 > accommodate them=20 > > anymore. > >=20 > > -David Borman > >=20 > > > > > >> Another suggestion was to add a sentence like=20 > "Timestamps MUST be=20 > > >> negotiated in and unless another=20 > mechanism allows=20 > > >> enabling them in during an established session. Such a =20 > mechanism=20 > > >> is outside the scope of this document." > > > > > > This is the one I expected, and is fine. It can either be=20 > confirmed=20 > > > by > > the option itself or by some other option; the overall=20 > assumption is=20 > > that "the set of options that MAY be used during a TCP=20 > connection MUST=20 > > be negotiated during the 3WHS". (that text is outside the scope of=20 > > this doc, > > though) > > > > > >> 3. More appropriate introductory text; the following=20 > statement will > > >> supersede very old text (that apparently addressed=20 > WS, TS and SACK > > >> back in RFC1072); this was already presented at IETF=20 > 86 and received > > >> no objections. > > >> > > >> The window scale option negotiates fundamental=20 > parameters of the TCP > > >> session. Therefore, it is only sent during the=20 > initial handshake. > > >> Furthermore, the window scale option will be sent in=20 > a > > >> segment only if the corresponding option was received=20 > in the initial > > >> segment. > > >> The timestamps option may appear in any data or ACK segment,=20 > > >> adding > > > > > > The "*" inserted below is explained further down... > > > > > >> 12 bytes to the 20-byte TCP header. * It is recommended that=20 > > >> this > > TCP > > > > > > Again, IMO recommended should be REQUIRED (in all caps too). > > > > > >> option will be sent on non-SYN segments only after an=20 > exchange of > > >> options on the SYN segments has indicated that both=20 > sides understand > > >> the extension. > > > > > > The portion below is a bit different: > > > > > >> We believe that the bandwidth saved by reducing > > >> unnecessary retransmission timeouts will more than=20 > pay for the extra > > >> header bandwidth. > > > > > > it talks about the bandwidth of the overall connection; it's not > > specific to the SYN exchange. It might be useful to move this up to=20 > > the "*" above. > > > > > > Joe > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > >=20 > >=20 > ---------------------------------------------------------------------- > > The information contained in this transmission may be confidential.=20 > > Any disclosure, copying, or further distribution of confidential=20 > > information is not permitted unless such privilege is explicitly=20 > > granted in writing by Quantum. Quantum reserves the right to have=20 > > electronic communications, including email and attachments, sent=20 > > across its networks filtered through anti virus and spam software=20 > > programs and retain such messages in order to comply with=20 > applicable=20 > > data security and retention requirements. Quantum is not=20 > responsible=20 > > for the proper and complete transmission of the substance=20 > of this communication or for any delay in its receipt. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From rs@netapp.com Thu Mar 21 08:21:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C9321F90AC for ; Thu, 21 Mar 2013 08:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAWNgK0I4lgE for ; Thu, 21 Mar 2013 08:21:20 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 462CB21F8F75 for ; Thu, 21 Mar 2013 08:21:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="16002313" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 21 Mar 2013 08:21:20 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LFLJpX025419; Thu, 21 Mar 2013 08:21:20 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 21 Mar 2013 08:21:19 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 08:21:19 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , Andre Oppermann Thread-Topic: [tcpm] 1323bis - preparing for WGLC Thread-Index: AQHOJkUCjO3olS06RL+dsxE+ZG+NzpiwQOyg Date: Thu, 21 Mar 2013 15:21:18 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC53F2@SACEXCMBX02-PRD.hq.netapp.com> References: <514B17E2.8040309@freebsd.org> <20130321150148.A0D76C6C770@lawyers.icir.org> In-Reply-To: <20130321150148.A0D76C6C770@lawyers.icir.org> 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 \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 15:21:21 -0000 Hi Mark, One point that I would like to mention, which clearly speaks for late TS ne= gotiation, is the severely limited option space, particularly in the .= As mentioned by David, and my previous emails, late enablement would be ea= sy AND useful, and as you pointed out, not impact any of the current mechan= isms tied to TSopt (PAWS, RTTM, Eifel). Returning 12 bytes option space dur= ing SYN (or not painting TS into a corner, where it can never be used in co= njunction with larger SYN options) seems a valid reason to allow that. (I'm still pursuing my semantic change for TS, to allow improvements in los= s recovery; I think that would be a valuable use case for Timestamps). I'm not proposing to have a full fletched mechanism for the late negotiatio= n should be part of 1323bis (apart from a "passive" requirement to support = it). But I'm reluctant to disallow such late enablement categorically in 1323bis= either. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Mark Allman > Sent: Donnerstag, 21. M=E4rz 2013 16:02 > To: Andre Oppermann > Cc: tcpm (tcpm@ietf.org); David Borman; Joe Touch > Subject: Re: [tcpm] 1323bis - preparing for WGLC >=20 >=20 > I agree with David. >=20 > > Unlikely that any TCP implementation crashes on unknown options. > > And if they do they get what they deserve. >=20 > Exactly. >=20 > > There is a very different problem though. Firewalls again. Those > > doing stateful inspection may drop packets when well-known but not > > negotiated options show up. > > > > Without empirical studies on the current situation we should not allow > > this change in behavior of late TS enabling. >=20 > Well, luckily we have some empirical study: >=20 > Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of > Transport Protocols in the Internet. ACM Computer Communication > Review, 35(2), April 2005. > http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps >=20 > We injected a TS and an unknown junk option into the middle of connection= s > (independently) without negotiation in the 3WHS. The connection failure > rate in both cases is 3%. If we instead put the options in the SYN the > connection failure rate is 0.2%. We cannot of course tell why the > connection is failing. It could be middleboxes or it could be receivers. >=20 > That paper is 8 years old and the data a bit older. Perhaps someone has > newer data. But, my guess is that this shows that this is simply not a > big problem. >=20 > My hit here is that timestamps are simply a waste. They take space. > They take complexity and processing at the endpoints. And, yet, they > provide benefit on only exceedingly rare occasions. In particular, >=20 > - If you want to use TS for RTTM then you'll just turn it on from the > beginning and be done with it. (RTTM doesn't buy you anything, but > thats beside the point.) >=20 > - If you want to use TS for Eifel then you'll turn it on from the > beginning and be done with it. >=20 > - If you want to use TS for PAWS then you can get by without it until > you've sent (nearly) 4GB (the sequence space) and you're sending > quite fast (such that you might wrap too quickly). Well, go look at > flow sizes on the Internet. Without even considering speed this is > a Damn Small box. And, once you throw speed in it gets even > smaller. And, throw on top of that the failure rate is pretty small > (a long time ago) and I can't see where firing up TS as needed is at > all problematic. (Plus, we cannot engineer for the corner of the > corner case that you found off to the side of the side road. Or, so > it seems to me.) >=20 > allman >=20 >=20 From rs@netapp.com Thu Mar 21 08:29:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8121F90F5; Thu, 21 Mar 2013 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQU00UssfpT5; Thu, 21 Mar 2013 08:29:18 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE521F9052; Thu, 21 Mar 2013 08:29:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="16004176" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 21 Mar 2013 08:29:18 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LFTHGr006912; Thu, 21 Mar 2013 08:29:17 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 08:29:16 -0700 From: "Scheffenegger, Richard" To: =?utf-8?B?5aSp5r6c?= , Emmanuel Lochin , Yuchung Cheng Thread-Topic: [iccrg] [tcpm] ECN support and usage on the Internet Thread-Index: AQHOJN7vLn8i1zQNs0aR6qujDYSanZiu5guA///XOCCAAW4vAIAAGwOw Date: Thu, 21 Mar 2013 15:29:16 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC54A0@SACEXCMBX02-PRD.hq.netapp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51499BFB.7050202@isae.fr>, <012C3117EDDB3C4781FD802A8C27DD4F24AC06C0@SACEXCMBX02-PRD.hq.netapp.com> 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.106.53.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , "aqm@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] [iccrg] ECN support and usage on the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 15:29:19 -0000 SGksDQoNCkknbSBhZnJhaWQgSSB3YXMgbm90IGFibGUgdG8gcGFyc2UgeW91ciBzdGF0ZW1lbnQu DQoNCk15IGNvbW1lbnQgd2FzIG5vdCBhYm91dCByZWR1Y2luZyB0aGUgUlRPIHRpbWUgKCEpLiBP biB0aGUgY29udHJhcnksIEkgd2FzIHBvaW50aW5nIG91dCwgdGhhdCB3aXRoIEVDTiAoYW5kIHdp dGhvdXQgZ2VudWluZSBsb3NzIGR1ZSB0byBjb3JydXB0aW9uKSwgUlRPcyAtIHJlZ2FyZGxlc3Mg b2YgdGhlIGFjdHVhbCB0aW1lciB2YWx1ZSBhcyBsb25nIGFzIHRoYXQgaXMgcmVhc29uYWJseSBs YXJnZXIgdGhhbiBSVFQgLSBzaG91bGQgYmVjb21lIGV4Y2VlZGluZ2x5IHJhcmUsIG9uY2UgRUNO IGlzIGZ1bGx5IGRlcGxveWVkLg0KDQoNCk9uY2UgUlRPIGlzIG5vIGxvbmdlciBuZWNlc3Nhcnkg dG8gcmVjb3ZlciB+NzAlIG9mIGFsbCBsb3N0IFRDUCBzZWdtZW50cyAoZ29vZ2xlIHdlYnNlcnZl ciBkYXRhKSwgeW91IGNhbiBhY3R1YWxseSAqaW5jcmVhc2UqIHRoZSBtaW5pbXVtIFJUTyB0aW1l b3V0IHZhbHVlIHNpbmNlIGl0IHJlYWxseSBpcyBhIGxhc3QgcmVzb3J0LiAoVXNpbmcgYSAibGFz dCByZXNvcnQiIHJlY292ZXJ5IG1lY2hhbmlzbSBmb3IgNzAlIG9mIHJlY292ZXJpZXMgaXMgcmVh bGx5IE5PVCAibGFzdCByZXNvcnQiKS4NCg0KDQpCZXN0IHJlZ2FyZHMsDQoNClJpY2hhcmQgU2No ZWZmZW5lZ2dlcg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiDl pKnmvpwgW21haWx0bzp0aWFubGFuLmxoaEBhbGliYWJhLWluYy5jb21dDQo+IFNlbnQ6IERvbm5l cnN0YWcsIDIxLiBNw6RyeiAyMDEzIDA3OjQ3DQo+IFRvOiBTY2hlZmZlbmVnZ2VyLCBSaWNoYXJk OyBFbW1hbnVlbCBMb2NoaW47IFl1Y2h1bmcgQ2hlbmcNCj4gQ2M6IHRjcG1AaWV0Zi5vcmcgRXh0 ZW5zaW9uczsgYXFtQGlldGYub3JnOyBpY2NyZ0BpcnRmLm9yZw0KPiBTdWJqZWN0OiDnrZTlpI06 IFtpY2NyZ10gW3RjcG1dIEVDTiBzdXBwb3J0IGFuZCB1c2FnZSBvbiB0aGUgSW50ZXJuZXQNCj4g DQo+IGFib3V0IFJUTyAsYWNjcm9kaW5nIHRvIG91dCBleHBlcmllbmNlICx1c2Ugc21hbGwgcHJv YmUgcGFja2V0IGF0IGxlYXN0DQo+IHJlZHVjZSA5MCUgUlRPIHRpbWXvvIhTaW5jZSAyMDEwLG5v dyBldmVyeSBkYXkgcGVlayBmbG9lIG1vcmUgdGhhbiAxVGJwcyDvvIkNCj4gOyBDb25zaWRlciB0 aGUgbW9iaWxlIG5ldHdvcmsgRXhjZXNzaXZlIHJlZHVjZSBSVE8gdGltZSBpcyB1bnJlYXNvbmFi bGU7DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IOWP keS7tuS6ujogU2NoZWZmZW5lZ2dlciwgUmljaGFyZCBbcnNAbmV0YXBwLmNvbV0NCj4g5Y+R6YCB 5pe26Ze0OiAyMDEz5bm0M+aciDIx5pelIDA6MDMNCj4g5YiwOiBFbW1hbnVlbCBMb2NoaW47IFl1 Y2h1bmcgQ2hlbmcNCj4gQ2M6IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9uczsgYXFtQGlldGYub3Jn OyBpY2NyZ0BpcnRmLm9yZw0KPiDkuLvpopg6IFJlOiBbaWNjcmddIFt0Y3BtXSBFQ04gc3VwcG9y dCBhbmQgdXNhZ2Ugb24gdGhlIEludGVybmV0DQo+IA0KPiBUaGFua3MhDQo+IA0KPiBXaGljaCBm b3J0dW5hdGVseSBpcyBhbHJlYWR5IGFuIGV4cGVyaW1lbnRhbA0KPiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1NTYyDQo+IA0KPiBCdXQgdG9vIGxpdHRsZSBleHBlcmllbmNlIHRvIGZv bGxvdyB1cCBvbiB0aGF0IGp1c3QgeWV0OyBMYXN0IHRpbWUgSQ0KPiBsb29rZWQsIEkgYmVsaWV2 ZSBpdCB3YXMgdGhlIEFJWCA1LjMgVENQIHN0YWNrIHdvdWxkIGRlZmF1bHQgdG8gNTU2Miwgd2hl bg0KPiBFQ04gaXMgZW5hYmxlZCAtIGJ1dCBFQ04gaXMgb2ZmIGJ5IGRlZmF1bHQgaW4gdGhhdCBP Uy4uLg0KPiANCj4gDQo+IEJ1dCB0aGUgZmluZGluZ3MgaW4gdGhhdCBwYXBlciBkb24ndCBjb21w YXJlIFRhaWwtRHJvcCBub24tRUNOIHdpdGgNCj4gQVFNL0VDTiosIHdoaWNoIGlzIHByb2JhYmx5 IHdoYXQgeW91IGFyZSBhZnRlciBZdWNodW5nPw0KPiANCj4gDQo+IFB1dCBkaWZmZXJlbnRseTog V2l0aCBhIGxhcmdlIGVub3VnaCBmcmFjdGlvbiBvZiBBUU0gZGVwbG95bWVudCwgYQ0KPiByZWFz b25hYmxlIG51bWJlciBvZiBSVE9zIHNob3VsZCBiZSBhdm9pZGFibGUgKGxlc3MgcHJvYmFiaWxp dHkgdGhhdCB0aGUNCj4gbGFzdCBzZWdtZW50IGluIGEgc2Vzc2lvbiBpcyBkcm9wcGVkKTsgd2l0 aCB0aGUgYWRkaXRpb24gb2YgRUNOLCBldmVuIHRoYXQNCj4gbG9zcyBzaG91bGQgZ28gYXdheS4u Lg0KPiANCj4gDQo+IERvIHlvdSBrbm93IHdoYXQgdGhlIENDREYgZm9yIG9iamVjdCBsb2FkIHRp bWVzIHdvdWxkIGxvb2sgbGlrZSwgaWYgdGhlcmUNCj4gd2VyZSB2aXJ0dWFsbHkgbm8gUlRPcyBh bnltb3JlPw0KPiANCj4gDQo+IEFwcGFyZW50bHksIHRoZSBpbmNlbnRpdmUgdG8gYXZvaWQgKGNv c3RseSkgUlRPcyBpcyB0b28gc21hbGwgdG8gZHJpdmUgRUNODQo+IGRlcGxveW1lbnQsIGV2ZW4g dGhvdWdoIHRoYXQgc2hvdWxkIGJlIHNvbWV0aGluZyBlYXN5IHRvIGFjaGlldmUgd2l0aCBFQ04N Cj4gb24gVENQLg0KPiANCj4gDQo+IFJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KPiANCj4gDQo+IA0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdGNwbS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBF bW1hbnVlbCBMb2NoaW4NCj4gPiBTZW50OiBNaXR0d29jaCwgMjAuIE3DpHJ6IDIwMTMgMTI6MjMN Cj4gPiBUbzogWXVjaHVuZyBDaGVuZw0KPiA+IENjOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnM7 IGFxbUBpZXRmLm9yZzsgaWNjcmdAaXJ0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3RjcG1dIEVD TiBzdXBwb3J0IGFuZCB1c2FnZSBvbiB0aGUgSW50ZXJuZXQNCj4gPg0KPiA+IE9uIDE5LzAzLzIw MTMgMjE6MTcsIFl1Y2h1bmcgQ2hlbmcgd3JvdGU6DQo+ID4gPiBEbyBwZW9wbGUgb24gdGhlIGxp c3Qga25vdyBhbnkgKGdvb2QpIGV2YWx1YXRpb24gb2YgcGVyZm9ybWFuY2UNCj4gPiA+IGltcGFj dCBvZiBFQ04gb24gcmVhbCBhbmQvb3IgZW11bGF0ZWQgbmV0d29ya3MuIEUuZy4sIGhvdyBtdWNo DQo+ID4gPiBmYXN0ZXIgd2lsbCB0aGUgV2ViIGJlIGlmIEVDTiBpcyB1c2VkIChjb3JyZWN0bHkp Lg0KPiA+DQo+ID4gVGhlcmUgaXMgOiBodHRwOi8vZGwuYWNtLm9yZy9jaXRhdGlvbi5jZm0/aWQ9 MTA4MDA5MS4xMDgwMTAwDQo+ID4NCj4gPiBFTA0KPiA+DQo+ID4gLS0NCj4gPiBFbW1hbnVlbCBM b2NoaW4NCj4gPiBQcm9mZXNzZXVyIElTQUUgLSBPU1NJDQo+ID4gSW5zdGl0dXQgU3Vww6lyaWV1 ciBkZSBsJ0HDqXJvbmF1dGlxdWUgZXQgZGUgbCdFc3BhY2UgKElTQUUpIElzc3UgZHUNCj4gPiBy YXBwcm9jaGVtZW50IFNVUEFFUk8gZXQgRU5TSUNBDQo+ID4gMTAgYXZlbnVlIEVkb3VhcmQgQmVs aW4gLSBCUCA1NDAzMiAtIDMxMDU1IFRvdWxvdXNlIGNlZGV4IDQgVGVsIDogMDUNCj4gPiA2MSAz Mw0KPiA+IDkxIDg1IC0gRmF4IDogMDUgNjEgMzMgOTEgODggV2ViIDogaHR0cDovL3BlcnNvbm5l bC5pc2FlLmZyL2VtbWFudWVsLQ0KPiA+IGxvY2hpbi8NCj4gPiAtLS0NCj4gPiAiVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwuIFRoZXkgbWF5IGNvbnRhaW4N Cj4gPiBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gb3IgY29weXJpZ2h0IG1hdGVyaWFs LiBZb3Ugc2hvdWxkIG5vdA0KPiA+IHJlYWQsIGNvcHksIHVzZSBvciBkaXNjbG9zZSB0aGVtIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4gSWYgeW91IGFyZSBub3QNCj4gPiBhbiBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBjb250YWN0IHVzIGF0IG9uY2UgYnkgcmV0dXJuIGVtYWlsIGFuZA0KPiA+ IHRoZW4gZGVsZXRlIGJvdGggbWVzc2FnZXMuIFdlIGRvIG5vdCBhY2NlcHQgbGlhYmlsaXR5IGlu IGNvbm5lY3Rpb24NCj4gPiB3aXRoIGNvbXB1dGVyIHZpcnVzLCBkYXRhIGNvcnJ1cHRpb24sIGRl bGF5LCBpbnRlcnJ1cHRpb24sDQo+ID4gdW5hdXRob3Jpc2VkIGFjY2VzcyBvciB1bmF1dGhvcmlz ZWQgYW1lbmRtZW50LiBUaGlzIG5vdGljZSBzaG91bGQgbm90IGJlDQo+IHJlbW92ZWQiDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gdGNwbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IA0KPiBUaGlzIGVtYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBiZSBsZWdhbGx5DQo+IHByaXZpbGVnZWQuIElm IHlvdSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0DQo+IGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG9y IGRpc2Nsb3NlIGl0cw0KPiBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLiBUaGFuayB5b3Uu DQo+IA0KPiDmnKznlLXpgq4o5YyF5ous5Lu75L2V6ZmE5Lu2KeWPr+iDveWQq+acieacuuWvhui1 hOaWmeW5tuWPl+azleW+i+S/neaKpOOAguWmguaCqOS4jeaYr+ato+ehrueahOaUtuS7tuS6uu+8 jOivt+aCqOeri+WNs+WIoOmZpA0KPiDmnKzpgq7ku7bjgILor7fkuI3opoHlsIbmnKznlLXpgq7o v5vooYzlpI3liLblubbnlKjkvZzku7vkvZXlhbbku5bnlKjpgJTjgIHmiJbpgI/pnLLmnKzpgq7k u7bkuYvlhoXlrrnjgILosKLosKLjgIINCg== From michael.scharf@alcatel-lucent.com Thu Mar 21 08:48:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A3E21F90F3 for ; Thu, 21 Mar 2013 08:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.02 X-Spam-Level: X-Spam-Status: No, score=-9.02 tagged_above=-999 required=5 tests=[AWL=1.229, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS1yrVNAX52x for ; Thu, 21 Mar 2013 08:48:35 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 612AD21F90BF for ; Thu, 21 Mar 2013 08:48:33 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2LFmOjL020390 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Mar 2013 16:48:24 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 21 Mar 2013 16:48:24 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , Andre Oppermann , Joe Touch Date: Thu, 21 Mar 2013 16:48:24 +0100 Thread-Topic: [tcpm] 1323bis - introduction Thread-Index: Ac4mQNsmiLtNQQ8oRUqABTs3iVWTXgACcpEw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D81@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - introduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 15:48:36 -0000 > -----Original Message----- > New text fragment reads: >=20 > The timestamp option may appear in any data or ACK=20 > segment, adding 12 > bytes to the 20-byte TCP header. We believe that the=20 > bandwidth saved > by reducing unnecessary retransmission timeouts will more than pay > for the extra header bandwidth. It is required that this=20 > TCP option > will be sent on non- segments only after an exchange=20 > of options > on the segments has indicated that both sides understand this > extension. Just a quick thought on one of the other sentences: Could we remove the sen= tence "We believe that the bandwidth saved by reducing unnecessary retransm= ission timeouts will more than pay for the extra header bandwidth"? As individual TCPM contributor I have some doubts on that. I don't have exp= erimental data for that trade-off, though. Michael From pasi.sarolahti@iki.fi Thu Mar 21 09:01:13 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5416E21F9083 for ; Thu, 21 Mar 2013 09:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nipN1F-R5vBk for ; Thu, 21 Mar 2013 09:01:12 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 730C921F9080 for ; Thu, 21 Mar 2013 09:01:12 -0700 (PDT) Received: from pc119.netlab.hut.fi (130.233.154.119) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087139909A3A0D0; Thu, 21 Mar 2013 18:00:43 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Pasi Sarolahti In-Reply-To: <5816_1363879260_514B255C_5816_1783_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D7E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Thu, 21 Mar 2013 18:00:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24AC52A3@SACEXCMBX02-PRD.hq.netapp.com> <5816_1363879260_514B255C_5816_1783_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D7E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1283) Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 16:01:13 -0000 On Mar 21, 2013, at 5:20 PM, Scharf, Michael (Michael) wrote: > I think that such a new document would be allowed by "The Timestamp = option MUST be negotiated during the initial and unless = another mechanism allows to enable it during an established session.". To me this sounds like a proper case of SHOULD, considering the proposed = "unless..." addition. The negotiation either MUST always happen during = initial handshake, or if there can be exceptions, we should not use = MUST. I see that original RFC1323 did not require the option to be = included in SYN. Addition of MUST would turn previously RFC1323 = compliant implementations to be non-compliant. In general, I think MUST should be used sparingly, only when something = is absolutely required for interoperability. RFC 2119 seems to give the = same advice. - Pasi, an individual TCPM follower From rs@netapp.com Thu Mar 21 09:40:06 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955D821F8E5C for ; Thu, 21 Mar 2013 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 263XPHSYsayo for ; Thu, 21 Mar 2013 09:40:06 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5321F8DE9 for ; Thu, 21 Mar 2013 09:40:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="248071598" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 21 Mar 2013 09:40:00 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LGdx0U024131 for ; Thu, 21 Mar 2013 09:40:00 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 09:39:58 -0700 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+NzgA4VuvQ Date: Thu, 21 Mar 2013 16:39:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> 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 Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 16:40:06 -0000 Hi group, While there was quite some feedback regarding the points b and c in my anno= uncement, I'd still like to learn what the WG thinks about these two points= ? a) Appendix D - Pseudo Code (incomplete) I'm leaning to remove that entire section, any objections? d) Window Scale reduction The current text has been proposed by Matt Mathis on the list quite a while= ago=20 http://www.ietf.org/mail-archive/web/tcpm/current/msg03564.html Is the WG in agreement with the specific text, that short summary of the ne= cessary steps an implementer has to take? Or can anyone suggest a better wo= rding for that section? =A0 =A0 Best regards, =A0 Richard Scheffenegger =A0 From touch@isi.edu Thu Mar 21 10:46:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B652C21F9109 for ; Thu, 21 Mar 2013 10:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.413 X-Spam-Level: X-Spam-Status: No, score=-105.413 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmF4Shb0LebV for ; Thu, 21 Mar 2013 10:46:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1268C21F90FC for ; Thu, 21 Mar 2013 10:46:23 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2LHj1xG012891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 10:45:03 -0700 (PDT) Message-ID: <514B4716.2050905@isi.edu> Date: Thu, 21 Mar 2013 10:44:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Borman References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 17:46:27 -0000 Hi, Dave (et al.), On 3/21/2013 7:06 AM, David Borman wrote: ... > Turning on timestamps midstream without it being in the initial SYN isn't > technically that hard, as long as once you start sending and receiving them, > you continue to send/receive them for the rest of the connection. > > The original reason for negotiating options in the SYN was twofold: > 1) SYNs are reliably delivered, hence no additional negotiation > mechanism is needed. 2) At the time, all TCP implementations would > handle unknown options in the SYN, but some implementations would > crash if they received unknown TCP options in non-SYN packets. TCP is always supposed to ignore options it doesn't understand - whether in the SYN or after (RFC1122m Sec 4.2.2.5). > Hopefully reason #2 is no longer needed. It isn't -- we just had a discussion about a TCP that reflects options it doesn't understand. That doesn't mean TCP should be designed to correct for that - we should declare that a serious bug and get it fixed. However... > Enabling TS midstream on the receiver is easy: if you receive any > packet with TS, then enable TS and use it for the duration of the > connection. On the sender, you just start sending TS in every > packet, and remember the seq# of the first non-retransmitted packet > that was sent with TS. If a TS is received in any packet, then enable > TS for the duration of the connection. If no TS has been received when > an ACK that covers the initial TS seq# is received, then disable > sending TS for the duration of the connection. You're describing half a handshake. You need to finish, including things like simultaenous initiation, what to do when if you detect loss and retransmit (do you retry with or without the TS? how many times? what if the loss is *because* of the TS?), etc. And what happens when you set TS? Do you try the above mechanism with the first segment you transmit (including a retransmission)? (you can't because now an ACK without the TS is ambiguous - it can mean no TS support, or that the first segment you thought was lost got there anyway). Even for something as simple as TS, this is a mess, and IMO should be avoided. ... >... But maybe it's time to say > that any TCP implementation that can't safely ignore unknown > options mid-stream is just plain broken and the standards shouldn't > continue to try to accommodate them anymore. I agree with this, but it doesn't affect (and isn't motivating) my view of enabling new capabilities mid-stream. Joe From touch@isi.edu Thu Mar 21 10:49:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EDD21F9148 for ; Thu, 21 Mar 2013 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.492 X-Spam-Level: X-Spam-Status: No, score=-105.492 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlcbDF4YzUZu for ; Thu, 21 Mar 2013 10:49:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8D121F913C for ; Thu, 21 Mar 2013 10:49:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2LHmXOx013658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 10:48:33 -0700 (PDT) Message-ID: <514B47E9.3000200@isi.edu> Date: Thu, 21 Mar 2013 10:48:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <514B17E2.8040309@freebsd.org> <20130321150148.A0D76C6C770@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AC53F2@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC53F2@SACEXCMBX02-PRD.hq.netapp.com> 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: "tcpm \(tcpm@ietf.org\)" , David Borman , "mallman@icir.org" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 17:49:20 -0000 On 3/21/2013 8:21 AM, Scheffenegger, Richard wrote: > > Hi Mark, > > > One point that I would like to mention, which clearly speaks for > late TS negotiation, is the severely limited option space, > particularly in the . As mentioned by David, and my previous > emails, late enablement would be easy AND useful, and as you pointed > out, not impact any of the current mechanisms tied to TSopt (PAWS, > RTTM, Eifel). Returning 12 bytes option space during SYN (or not > painting TS into a corner, where it can never be used in conjunction > with larger SYN options) seems a valid reason to allow that. A better solution than mid-stream enabling is to allow the option to be "vacuous" during the SYN exchange, e.g., to be 2 bytes long (KIND, LEN) -- if the option that is enabled isn't something with values or conditions to be negotiated as part of the handshake. (and NO - I really don't want two KIND values, one for "enable X" and one for "use X"; the LEN field should be sufficient to distinguish between those two cases). Joe From touch@isi.edu Thu Mar 21 10:53:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8598421F85E7 for ; Thu, 21 Mar 2013 10:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.562 X-Spam-Level: X-Spam-Status: No, score=-105.562 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RFTJu9vyY7s for ; Thu, 21 Mar 2013 10:53:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1628C21F85B4 for ; Thu, 21 Mar 2013 10:53:47 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2LHoKvp013968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 10:50:21 -0700 (PDT) Message-ID: <514B4855.9050504@isi.edu> Date: Thu, 21 Mar 2013 10:50:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <5149E317.2080206@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24AC52A3@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D7E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D7E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 17:53:47 -0000 On 3/21/2013 8:20 AM, Scharf, Michael (Michael) wrote: > To me, this discussion would perfectly fit into a new ID on allowing > late TS enabling. It would be short and straightforward. But a > separate ID could be easier than adding these kinds of thoughts to > the 1323bis document, which we want to finish... I agree. > I think that such a new document would be allowed by "The Timestamp > option MUST be negotiated during the initial and > unless another mechanism allows to enable it during an established > session.". The current doc should say *only* "MUST be negotiated during the initial 3WHS". The new doc can try to update that doc when - and if - it passes WG approval. We shouldn't be leaving doors open until we have the full debate on them. Joe From touch@isi.edu Thu Mar 21 11:00:23 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786E821F906A for ; Thu, 21 Mar 2013 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.623 X-Spam-Level: X-Spam-Status: No, score=-105.623 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL5h0LDiMWxU for ; Thu, 21 Mar 2013 11:00:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B118021F9099 for ; Thu, 21 Mar 2013 11:00:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2LHwLYE015712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 10:58:21 -0700 (PDT) Message-ID: <514B4A35.4050104@isi.edu> Date: Thu, 21 Mar 2013 10:58:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - introduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 18:00:23 -0000 Hi, Richard, On 3/21/2013 7:47 AM, Scheffenegger, Richard wrote: > > Hi Andre, Joe, > > > > New text fragment reads: > > > The timestamp option may appear in any data or ACK segment, adding 12 > bytes to the 20-byte TCP header. We believe that the bandwidth saved > by reducing unnecessary retransmission timeouts will more than pay > for the extra header bandwidth. It is required that this TCP option > will be sent on non- segments only after an exchange of options > on the segments has indicated that both sides understand this > extension. Reads better, and I agree with its contents. > > To your remarks: > >>>> The timestamps option may appear in any data or ACK >>>> segment, adding >>> >>> The "*" inserted below is explained further down... >>> >>>> 12 bytes to the 20-byte TCP header. * It is recommended that >>>> this TCP >>> >>> Again, IMO recommended should be REQUIRED (in all caps too). >> >> Is required the correct RFC keyword? Shouldn't the sentence be rewritten >> to make it use the "MUST" keyword? >> > > This is still section 1, before the RFC2119 disclaimer. This is > introductory text, thus I refrained from any ALL CAPS words everywhere > in section 1 (except for the 2119 disclaimer, that is the last > subsection of section 1). You might then include the following text which I've been including for a while in the 2119 disclaimer: When used in lower case, these words have their conventional meaning and do not convey the interpretations in RFC-2119. > As mentioned in the comment to the normative section, the actual > current 1323 text allows the receiver to start reflecting TSopt as soon > as it sees it. Disallowing this would have two effects: > > a) certain widely deployed stacks would no longer comply with 1323 (as obsoleted by 1323bis) I'm OK with that ;-) > b) it would limit further developments regarding the timestamp > optionthat could potentially be sender-side only modifications initially. This is yet another reason why this is the correct decision, IMO. TCP isn't a protocol where surprises should keep popping up - the whole point of the 2WHS is to establish a common understanding of the parameters of the protocol for a given connection. Joe From touch@isi.edu Thu Mar 21 11:01:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5D321F90A1 for ; Thu, 21 Mar 2013 11:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=0.922, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+yjQZjJrScX for ; Thu, 21 Mar 2013 11:01:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DBDDE21F8E62 for ; Thu, 21 Mar 2013 11:01:57 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2LI0Bqj015976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 11:00:11 -0700 (PDT) Message-ID: <514B4AA4.2030008@isi.edu> Date: Thu, 21 Mar 2013 11:00:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D81@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D81@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - introduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 18:01:58 -0000 On 3/21/2013 8:48 AM, Scharf, Michael (Michael) wrote: >> -----Original Message----- >> New text fragment reads: >> >> The timestamp option may appear in any data or ACK >> segment, adding 12 >> bytes to the 20-byte TCP header. We believe that the >> bandwidth saved >> by reducing unnecessary retransmission timeouts will more than pay >> for the extra header bandwidth. It is required that this >> TCP option >> will be sent on non- segments only after an exchange >> of options >> on the segments has indicated that both sides understand this >> extension. > > Just a quick thought on one of the other sentences: Could we remove the sentence "We believe that the bandwidth saved by reducing unnecessary retransmission timeouts will more than pay for the extra header bandwidth"? > > As individual TCPM contributor I have some doubts on that. I don't have experimental data for that trade-off, though. > > Michael +1, but the trade-off is worth noting, IMO. Maybe: --- There is a trade-off between the bandwidth saved by reducing unnecessary retransmission timeouts vs. the extra header bandwidth of this option. --- Joe From mallman@icir.org Thu Mar 21 11:02:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B157821F9104 for ; Thu, 21 Mar 2013 11:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCRCD60330sE for ; Thu, 21 Mar 2013 11:02:06 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 56BA021F90ED for ; Thu, 21 Mar 2013 11:02:06 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2LI23fT005406; Thu, 21 Mar 2013 11:02:04 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C9384C80EAE; Thu, 21 Mar 2013 14:02:03 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <514B4716.2050905@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Takin' Care of Business X-URL-0: http://www.icir.org/mallman-files/Document76673.jpg MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma19226-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Mar 2013 14:02:03 -0400 Sender: mallman@icir.org Message-Id: <20130321180203.C9384C80EAE@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:02:08 -0000 ----------ma19226-1 Content-Type: text/plain Content-Disposition: inline > And what happens when you set TS? Do you try the above mechanism with > the first segment you transmit (including a retransmission)? (you > can't because now an ACK without the TS is ambiguous - it can mean no > TS support, or that the first segment you thought was lost got there > anyway). > > Even for something as simple as TS, this is a mess, and IMO should be > avoided. How is this a mess? I don't get it. Say we have TCP endpoints A and B. A wants to turn on timestamps. So, on some non-retransmit data packet it turns them on and then just keeps using them on every subsequent packet. Now, - If the ACKs for those data packets come back with timestamps, great. We have just figured out we can use timestamps. - If the ACKs for those data packets come back without timestamps, great. We have just figured out either the path or the end host doesn't support timestamps (or doesn't support them when turned on in the middle). We stop sending timestamps. Big deal. - If no ACKs for the window of data come back then we retransmit without TS. We can't tell why these packets were dropped, but perhaps because they had TS. So, be conservative in what you send. This may then hamper the rate you can send at because you won't have PAWS. We have three easy cases: we get back TS, we get back ACKs but no TS and we get back nothing. We ride on top of TCP's data reliability and it all works pretty straightforwardly, it seems to me. It isn't a mess. The simultaneous start of TS usage is a no-op. Both ends will figure out they us TS and then they'll use it. allman ----------ma19226-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFLSxsACgkQWyrrWs4yIs4tnACfQIQBZNz/Nc34+2VUq3AxRp6Y p5IAmwTO5uUvSQ8Btabyd3SeP8aqsyXS =Avxg -----END PGP SIGNATURE----- ----------ma19226-1-- From michael.scharf@alcatel-lucent.com Thu Mar 21 11:10:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81021F8DEA for ; Thu, 21 Mar 2013 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68980MqlJh9e for ; Thu, 21 Mar 2013 11:10:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0F53821F8CF0 for ; Thu, 21 Mar 2013 11:10:14 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2LIA3rx004645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Mar 2013 19:10:06 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 21 Mar 2013 19:10:04 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch Date: Thu, 21 Mar 2013 19:10:03 +0100 Thread-Topic: [tcpm] 1323bis - introduction Thread-Index: Ac4mXi6IVT9JLk4GQmK9Ah8+qknfYgAAQ8WA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D84@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6D81@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <514B4AA4.2030008@isi.edu> In-Reply-To: <514B4AA4.2030008@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - introduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 18:10:16 -0000 > >> -----Original Message----- > >> New text fragment reads: > >> > >> The timestamp option may appear in any data or ACK segment,=20 > >> adding 12 > >> bytes to the 20-byte TCP header. We believe that the=20 > bandwidth=20 > >> saved > >> by reducing unnecessary retransmission timeouts will=20 > more than pay > >> for the extra header bandwidth. It is required that this TCP=20 > >> option > >> will be sent on non- segments only after an exchange of=20 > >> options > >> on the segments has indicated that both sides=20 > understand this > >> extension. > > > > Just a quick thought on one of the other sentences: Could=20 > we remove the sentence "We believe that the bandwidth saved=20 > by reducing unnecessary retransmission timeouts will more=20 > than pay for the extra header bandwidth"? > > > > As individual TCPM contributor I have some doubts on that.=20 > I don't have experimental data for that trade-off, though. > > > > Michael >=20 > +1, but the trade-off is worth noting, IMO. Maybe: >=20 > --- > There is a trade-off between the bandwidth saved by reducing=20 > unnecessary retransmission timeouts vs. the extra header=20 > bandwidth of this option. > --- Good point. I agree. Michael= From touch@isi.edu Thu Mar 21 11:16:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8C21F90F5 for ; Thu, 21 Mar 2013 11:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.725 X-Spam-Level: X-Spam-Status: No, score=-105.725 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w0yXtLQRkhz for ; Thu, 21 Mar 2013 11:16:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E1A8321F9111 for ; Thu, 21 Mar 2013 11:16:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2LIFlfv019666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 11:15:47 -0700 (PDT) Message-ID: <514B4E4C.7030703@isi.edu> Date: Thu, 21 Mar 2013 11:15:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mallman@icir.org References: <20130321180203.C9384C80EAE@lawyers.icir.org> In-Reply-To: <20130321180203.C9384C80EAE@lawyers.icir.org> 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: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 18:16:47 -0000 Hi, Mark, On 3/21/2013 11:02 AM, Mark Allman wrote: > >> And what happens when you set TS? Do you try the above mechanism with >> the first segment you transmit (including a retransmission)? (you >> can't because now an ACK without the TS is ambiguous - it can mean no >> TS support, or that the first segment you thought was lost got there >> anyway). >> >> Even for something as simple as TS, this is a mess, and IMO should be >> avoided. > > How is this a mess? I don't get it. I gave the details in my earlier response, but here are some others: > > Say we have TCP endpoints A and B. A wants to turn on timestamps. So, > on some non-retransmit data packet it turns them on and then just keeps > using them on every subsequent packet. How long? when does it give up? > Now, > > - If the ACKs for those data packets come back with timestamps, > great. We have just figured out we can use timestamps. "for those packets" means you need to keep track of that state. And, as Dave already noted, you need to check whether the ACK is covered *within* a range that is ACKd - including SACK, etc. > - If the ACKs for those data packets come back without timestamps, > great. We have just figured out either the path or the end host > doesn't support timestamps (or doesn't support them when turned on > in the middle). We stop sending timestamps. Big deal. Yes. > - If no ACKs for the window of data come back then we retransmit > without TS. We can't tell why these packets were dropped, but > perhaps because they had TS. So, be conservative in what you send. That makes mid-stream TS enable more fragile than it would be if it were confirmed during the SYN. > This may then hamper the rate you can send at because you won't have > PAWS. > > We have three easy cases: we get back TS, we get back ACKs but no TS and > we get back nothing. We ride on top of TCP's data reliability and it > all works pretty straightforwardly, it seems to me. It isn't a mess. > > The simultaneous start of TS usage is a no-op. Both ends will figure > out they us TS and then they'll use it. At the very least, you have to specify it. My point is that the TS option needs to define a handshake mechanism in detail - including what doesn't need special handling, like simultaneous open. AND you need to define how or whether this interacts with any other pending mid-stream handshakes. The only reason is to avoid what should be 2 bytes (at most) in the SYN. If it's part of an aggregate option ("enable 1323"), then it'd be even less (effectively). I don't think that's a good trade-off. Joe From mallman@icir.org Thu Mar 21 11:35:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9457021F9081 for ; Thu, 21 Mar 2013 11:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTshB5kgdkib for ; Thu, 21 Mar 2013 11:35:00 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8BA21F906F for ; Thu, 21 Mar 2013 11:35:00 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2LIYtUD009655; Thu, 21 Mar 2013 11:34:56 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1E7A5C8185C; Thu, 21 Mar 2013 14:34:56 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <514B4E4C.7030703@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Takin' Care of Business X-URL-0: http://www.icir.org/mallman-files/Document92525.doc X-URL-1: http://www.icir.org/mallman-files/Document58703.html X-URL-2: http://www.icir.org/mallman-files/Document58460.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma21200-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Mar 2013 14:34:56 -0400 Sender: mallman@icir.org Message-Id: <20130321183456.1E7A5C8185C@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:35:00 -0000 ----------ma21200-1 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Say we have TCP endpoints A and B. A wants to turn on timestamps. > > So, on some non-retransmit data packet it turns them on and then > > just keeps using them on every subsequent packet. >=20 > How long? when does it give up? Oh come on ... this isn't rocket science, Joe. If A turns on TS at sequence number S1 it keeps sending them until the ACKs for the window starting at S1 roll in. So, when you get the first ACK (or SACK) for something > S1 you note the largest sequence number you have sent S2. There is your window S1--S2. Now, look at the ACKs that roll in for that window. And, you might as well keep sending TS speculatively until S2 is ACKed---at which point you can make your final decision. Yeah- a little state. Point taken. > > - If no ACKs for the window of data come back then we retransmit > > without TS. We can't tell why these packets were dropped, but > > perhaps because they had TS. So, be conservative in what you send. >=20 > That makes mid-stream TS enable more fragile than it would be if it > were confirmed during the SYN. OK, fine. Point taken. But, it isn't like there isn't a path that adds a little fragility over the current method. See below ... > AND you need to define how or whether this interacts with any other > pending mid-stream handshakes. I don't think it does. I mean, it just rides on packets being delivered reliably and only needs to deal with its own option. So, it seems pretty self-contained to me. And, what are those options? > The only reason is to avoid what should be 2 bytes (at most) in the > SYN. If it's part of an aggregate option ("enable 1323"), then it'd be > even less (effectively). You make it sound that is some sort of panacea. Its not. Its at least as fragile as just starting to use TS in the middle: - Send me one of those new fangled options on the day after the RFC is published. You get no timestamps! - So, to make sure you get timestamps you're going to have to send the full 10 bytes in the packet just like we do now. At that point why send this new option, too? It says the same thing and it further squeezes the option space in the SYN. There is a *disincentive* to move to this new option ... it isn't getting you what you want *and* it takes more room. So, how is this going to help us? If we had a flux and could do this From=20the start I might buy your argument. But, I don't think its a great path at this point. allman ----------ma21200-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFLUtAACgkQWyrrWs4yIs5glgCfS2GCxyMSuOsyuXRm2vJahwqG hIsAnRmKuTR11yzFWStzrFw4N8JUYhOs =JsvJ -----END PGP SIGNATURE----- ----------ma21200-1-- From touch@isi.edu Thu Mar 21 11:43:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D4121F8E16 for ; Thu, 21 Mar 2013 11:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.809 X-Spam-Level: X-Spam-Status: No, score=-103.809 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV-QUruFshbu for ; Thu, 21 Mar 2013 11:43:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D029121F85E0 for ; Thu, 21 Mar 2013 11:43:13 -0700 (PDT) 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 r2LIgqLZ006286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 11:42:52 -0700 (PDT) Message-ID: <514B54A5.4060107@isi.edu> Date: Thu, 21 Mar 2013 11:42:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mallman@icir.org References: <20130321183456.1E7A5C8185C@lawyers.icir.org> In-Reply-To: <20130321183456.1E7A5C8185C@lawyers.icir.org> 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: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 18:43:16 -0000 On 3/21/2013 11:34 AM, Mark Allman wrote: > >>> Say we have TCP endpoints A and B. A wants to turn on timestamps. >>> So, on some non-retransmit data packet it turns them on and then >>> just keeps using them on every subsequent packet. >> >> How long? when does it give up? > > Oh come on ... this isn't rocket science, Joe. No, but it took you a paragraph to answer. And it's just the tip of what needs to be covered. Corner cases are why 3WHS isn't described in a single sentence. ... >> The only reason is to avoid what should be 2 bytes (at most) in the >> SYN. If it's part of an aggregate option ("enable 1323"), then it'd be >> even less (effectively). > > You make it sound that is some sort of panacea. Its not. Its at least > as fragile as just starting to use TS in the middle: > > - Send me one of those new fangled options on the day after the RFC is > published. You get no timestamps! I was talking about how to handle this in the future, to transition to a solution that is more efficient in its use of SYN space (and to design protocols that are more SYN-efficient now). > - So, to make sure you get timestamps you're going to have to send the > full 10 bytes in the packet just like we do now. At that point why > send this new option, too? It says the same thing and it further > squeezes the option space in the SYN. There is a *disincentive* to > move to this new option ... it isn't getting you what you want *and* > it takes more room. > > So, how is this going to help us? If we had a flux and could do this > From the start I might buy your argument. But, I don't think its a > great path at this point. Well, the current TS mid-stream version isn't documented, and has a lot of corner cases that aren't addressed yet, so there are places where things won't work in current implementations even if you figure them out now. Joe From touch@isi.edu Thu Mar 21 13:42:57 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE99621F8617 for ; Thu, 21 Mar 2013 13:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.754 X-Spam-Level: X-Spam-Status: No, score=-103.754 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QeWsiY4fXEc for ; Thu, 21 Mar 2013 13:42:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3ED21F8613 for ; Thu, 21 Mar 2013 13:42:57 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2LKge6C006949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 13:42:40 -0700 (PDT) Message-ID: <514B70B8.8060301@isi.edu> Date: Thu, 21 Mar 2013 13:42:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F24AC5055@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC5055@SACEXCMBX02-PRD.hq.netapp.com> 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - TS nego X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 20:42:58 -0000 Hi, Richard, One additional point: On 3/21/2013 7:30 AM, Scheffenegger, Richard wrote: > However, > >>> the overall assumption is that >>> "the set of options that MAY be used during a TCP connection MUST >>> be negotiated during the 3WHS". > > limits the effective number of useful TCP options to 20 (as at the > very least, two bytes, option + len, have to be in the ). > > Also, such a requirement implicitly rules out potential later > suggestions to "collapse" certain sets of options to a single TCP option > in the . I wasn't assuming this, so the limit isn't 20 options. Further, one trivial solution is to collapse a set of known options to a mechanism that doesn't requiring parsing, e.g., to a define a new "AGGREGATE OPTION" KIND that consists of a list of the single-byte options to be negotiated; that could even allow up to 39 individual options ;-) Yes, that's complex, and yes, it's new, but just poking around the solution space for now... Joe From rs@netapp.com Thu Mar 21 14:40:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B158221F8DF2 for ; Thu, 21 Mar 2013 14:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9TrLq33SQrr for ; Thu, 21 Mar 2013 14:40:12 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3308F21F8DEA for ; Thu, 21 Mar 2013 14:40:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,888,1355126400"; d="scan'208";a="16061507" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 21 Mar 2013 14:40:11 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LLeBSW006808; Thu, 21 Mar 2013 14:40:11 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 14:40:11 -0700 From: "Scheffenegger, Richard" To: Joe Touch Thread-Topic: [tcpm] 1323bis - introduction Thread-Index: Ac4mQNsmiLtNQQ8oRUqABTs3iVWTXgAV3kOAAAoVLnA= Date: Thu, 21 Mar 2013 21:40:11 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC76DC@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC511C@SACEXCMBX02-PRD.hq.netapp.com> <514B4A35.4050104@isi.edu> In-Reply-To: <514B4A35.4050104@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - introduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 21:40:12 -0000 Hello Joe, > >> > > > > This is still section 1, before the RFC2119 disclaimer. This is > > introductory text, thus I refrained from any ALL CAPS words everywhere > > in section 1 (except for the 2119 disclaimer, that is the last > > subsection of section 1). >=20 > You might then include the following text which I've been including for a > while in the 2119 disclaimer: >=20 > When used in lower case, these words have their conventional meaning > and do not convey the interpretations in RFC-2119. >=20 I added In this document, these words will appear with that interpretation only when in UPPER CASE. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. > > As mentioned in the comment to the normative section, the actual > > current 1323 text allows the receiver to start reflecting TSopt as > > soon as it sees it. Disallowing this would have two effects: > > > > a) certain widely deployed stacks would no longer comply with 1323 (as > > obsoleted by 1323bis) >=20 > I'm OK with that ;-) I knew you would be... :) Best regards, =20 Richard Scheffenegger From internet-drafts@ietf.org Thu Mar 21 15:08:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7786321F8FAC; Thu, 21 Mar 2013 15:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRVasLfxTZ4D; Thu, 21 Mar 2013 15:08:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E41EA21F8F4A; Thu, 21 Mar 2013 15:08:54 -0700 (PDT) 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.43 Message-ID: <20130321220854.8516.53737.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2013 15:08:54 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 22:08:55 -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-07.txt Pages : 42 Date : 2013-03-21 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 TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Thu Mar 21 15:15:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408A621F8F81 for ; Thu, 21 Mar 2013 15:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.391 X-Spam-Level: X-Spam-Status: No, score=-10.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay0XaBiUAida for ; Thu, 21 Mar 2013 15:15:07 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD2C21F8E69 for ; Thu, 21 Mar 2013 15:15:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,888,1355126400"; d="scan'208";a="32823025" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 21 Mar 2013 15:15:07 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LMF3cF016122 for ; Thu, 21 Mar 2013 15:15:07 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 15:15:03 -0700 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOJoCv2oEUvXpB+U6xROEmYd/GQpiwtJJg Date: Thu, 21 Mar 2013 22:15:02 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC78F6@SACEXCMBX02-PRD.hq.netapp.com> References: <20130321220854.8516.53737.idtracker@ietfa.amsl.com> In-Reply-To: <20130321220854.8516.53737.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.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 22:15:08 -0000 Group, After the valuable feedback today regarding the sections of text, and updat= ing the document with a minor number of other editorial changes such as swa= pping Packets for segments, and adding < > brackts to signify specific type= s of segments in the text, and doing minor layout work - after a final upda= te of the changes section - here is the promised -07 version of the draft. Please review those sections you think are critical, and please also scan o= ver the other parts of the documents for missed nits. Probably not everyone will be happy, but I think this document reflects the= concensus of the WG so far. Feedback is still very welcome, but if no one objects, I call on the chairs= to formally start a WGLC in a couple days time on this document! Best regards, Richard -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Donnerstag, 21. M=E4rz 2013 23:09 To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt 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-07.txt Pages : 42 Date : 2013-03-21 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 TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Mar 21 16:47:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D121F85ED for ; Thu, 21 Mar 2013 16:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.357 X-Spam-Level: X-Spam-Status: No, score=-103.357 tagged_above=-999 required=5 tests=[AWL=-1.358, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5SJ9JlSrJo1 for ; Thu, 21 Mar 2013 16:47:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 87D5221F88BD for ; Thu, 21 Mar 2013 16:47:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2LNlH3K015411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 16:47:17 -0700 (PDT) Message-ID: <514B9BFE.9060307@isi.edu> Date: Thu, 21 Mar 2013 16:47:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20130321220854.8516.53737.idtracker@ietfa.amsl.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC78F6@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC78F6@SACEXCMBX02-PRD.hq.netapp.com> 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 23:47:33 -0000 Hi, Richard, I'm a bit concerned about the text here; I know I raised the issue before, but I want to be specific about the concern: A TCP MAY send the Timestamps option (TSopt) in an initial segment. When used, the Timestamp option SHOULD be negotiated during the initial and unless another mechanism allows to enable it during an established session. However, such a mechanism is outside the scope of this document. First, I don't like SHOULD unless there is a specific example of an exception. The exception noted is vague and defined as out of scope of this doc, so IMO this should be "MUST" *until* overridden by some potential future document that has WG consensus. I don't think it's appropriate to have consensus on "some future but unspecified mechanism" in this way. *** (note the stars, I'll refer to them later) However, the rest of the paragraph is confusing: When TSopt has been sent or received in a non- segment, it MUST be sent in all segments. Does the above refer to: a) mid-stream enabling when TS was not negotiated during the SYN? b) the idea that TS is negotiated during a SYN and yet the endpoints can decide to hold-off using it, but at some point "turn it on"? Either way, there's a lot of detail here that's missing. Do you mean: When TSopt has been sent or received in a non- segment with a sequence number X, it must be sent on all subsequent segments from X forward including retransmissions that overlap with X or higher. Is that what you mean? or does this refer to ANY segments once the first one with TSopt? Once a TSopt has been received in a non- segment, then any successive segment that is received without the RST bit and without a TSopt MAY be dropped without further processing, and an of the current SND.UNA generated. The above paragraph appears to need the same treatment, referring to specific sequence numbers. However, I would much prefer a cleaner: A TCP MAY send the Timestamps option (TSopt) in an initial segment. When used, the Timestamp option MUST be negotiated during the initial and . The potential for mid-stream enabling of this option was discussed, but no current mechanism is yet specified. Once a TSopt has been received in a non- segment of a connection that has TS enabled, all subsequent segments MUST include TSopt. Any successive segment that is received without the RST bit and without a TSopt MAY be dropped without further processing, and an of the current SND.UNA generated. Any successive segment received with the RST bit can ignore the absence of TSopt; this allows an connection that does not support TSopt to cleanup TCP state associated with a previous TSopt-enabled connection. Joe From shep@xplot.org Thu Mar 21 18:43:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA4421F8B5E for ; Thu, 21 Mar 2013 18:43:13 -0700 (PDT) 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=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIFDFjTGWXrn for ; Thu, 21 Mar 2013 18:43:13 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id 159BA21F8B51 for ; Thu, 21 Mar 2013 18:43:13 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1UIr0g-0006fd-00; Thu, 21 Mar 2013 21:43:10 -0400 From: Tim Shepard To: "Scheffenegger, Richard" In-reply-to: Your message of Thu, 21 Mar 2013 22:15:02 -0000. <012C3117EDDB3C4781FD802A8C27DD4F24AC78F6@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 21 Mar 2013 21:43:10 -0400 Message-Id: Sender: Tim Shepard Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2013 01:43:14 -0000 > Please review those sections you think are critical, and please also scan over the other parts of the documents for missed nits. > OK, I took a look at the paragraph mentioning mid-stream negotiation of the timestamp option: A TCP MAY send the Timestamps option (TSopt) in an initial segment. When used, the Timestamp option SHOULD be negotiated during the initial and unless another mechanism allows to enable it during an established session. However, such a mechanism is outside the scope of this document. When TSopt has been sent or received in a non- segment, it MUST be sent in all segments. Once a TSopt has been received in a non- segment, then any successive segment that is received without the RST bit and without a TSopt MAY be dropped without further processing, and an of the current SND.UNA generated. You say it is outside scope of this document, but then the rest of the paragraph talks about receipt of the TSopt on a non-SYN segment being what determines whether you've got it on or off. That is a change from rfc1323 which says simply: A TCP may send the Timestamps option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it re- ceived a TSopt in the initial segment for the connection. It seems to me that there may indeed something approaching WG consensus that it sure would be nice if timestamps could be negotiated on sometime later even if they weren't negotiated on in the initial exchange of SYN bits. But I think we are no where near having something written down that explains how this might be accomplished safely and effectively. Mark Allman's recent e-mail exchanges with Joe makes me think that maybe it would be possible. But I'd like to see a draft that explains it in full detail. But even so, if you're going to potentially need time stamps on for PAWS today, next year, or 5 years from now, or 10 years from now, you are going to have to include the timestamp option in the SYN otherwise the other end of the TCP connection will not allow the timestamp option to be turned on mid stream. Does that matter? Seems to me it would, and there are a number of things to think about. Unless you can somehow know out-of-band before you send the SYN to initiate the connection that the other end happens to be a host which can turn on the timestamp option midstream, you have to include it with the SYN to get it turned on reliably. And with 1 Gbps symmetric internet connections to the home becoming routine in some communities (e.g. Chattanooga, Lafayette, Kansas City) enabling things like routine overnight cross-town copying (of a 3 TB disk) it seems to me that getting TCP timestamps turned on reliably for PAWS protection sorta matters these days. And it's not just protection from old packets from a TCP connection that has itself wrapped the sequence space, but also protection from packets from previous TCP connections that used the same port numbers and sent bytes at a rate faster than the initial sequence number clock ticked. (There is no mechanism in the net that provides any sort of MSL-like guarantee. And with the proliferation of dodgy cheap devices with network interfaces capable of 1 Gbps that can have cables plugged into them that can be tripped over, the range of crazy undead packet possibilities are only going to get more and more interesting.) I think mechanisms for turning on TCP timestamp option after it was not turned on in the SYN packets belongs (for now) in a seperate draft targeted at experimental status (at best). -Tim Shepard shep@alum.mit.edu From touch@isi.edu Thu Mar 21 20:53:50 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC0C21F8A27 for ; Thu, 21 Mar 2013 20:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.157 X-Spam-Level: X-Spam-Status: No, score=-105.157 tagged_above=-999 required=5 tests=[AWL=1.442, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veiHW8lnMSkO for ; Thu, 21 Mar 2013 20:53:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83CAC21F8A18 for ; Thu, 21 Mar 2013 20:53:50 -0700 (PDT) Received: from [192.168.1.89] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2M3rP0k029196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 20:53:35 -0700 (PDT) Message-ID: <514BD5B7.9070305@isi.edu> Date: Thu, 21 Mar 2013 20:53:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Tim Shepard 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2013 03:53:51 -0000 FWIW... On 3/21/2013 6:43 PM, Tim Shepard wrote: (the original 1323 text:) > > A TCP may send the Timestamps option (TSopt) in an initial > segment (i.e., segment containing a SYN bit and no ACK > bit), and may send a TSopt in other segments only if it re- > ceived a TSopt in the initial segment for the connection. I like this one even better because it is more clear about: a) the use of TSopt is optional b) TSopt must be enabled in the SYN c) TSopt, once enabled, may (or may not) be in a given segment There's no rule about how to respond if an endpoint simply decides not to use it on a given segment, which makes more sense to me. Joe From ilpo.jarvinen@helsinki.fi Fri Mar 22 03:44:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACD421F90DD for ; Fri, 22 Mar 2013 03:44:33 -0700 (PDT) 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=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrI5DWJNQ6h2 for ; Fri, 22 Mar 2013 03:44:33 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334AC21F90ED for ; Fri, 22 Mar 2013 03:44:31 -0700 (PDT) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 22 Mar 2013 12:44:30 +0200 id 0008C5BA.514C360E.00005EDC Date: Fri, 22 Mar 2013 12:44:30 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: "Scheffenegger, Richard" In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2013 10:44:34 -0000 On Thu, 21 Mar 2013, Scheffenegger, Richard wrote: > While there was quite some feedback regarding the points b and c in my > announcement, I'd still like to learn what the WG thinks about these two > points? > > a) Appendix D - Pseudo Code (incomplete) > > I'm leaning to remove that entire section, any objections? While I don't exactly object the removal (it seems you did it already). There's one serious shortcoming in the document. That is, I was once looking for guidance on how to implement RFC793 acceptability check (3.3) together with RFC1323 PAWS, but the precedence was not specified anywhere. I then found that there's the pseudocode in the 1323bis (which was then kind of dead, before you took over it), but even that failed to address the precendence, ie., no RFC793 checks were included to the pseudocode. I'd have suggested that RFC793 checks should be added to the pseudocode but somewhere else in the document is just as fine as long as it is specified. RFC793 checks are relevant in the case when there's 100% ACK loss for a window, the sender RTOs and retransmits to that out-of-synch condition. The interesting question is what timestamp should be echoed. It depends on which runs first, RFC1323 checks or RFC793 checks. I think it's important enough case to warrant consistent implementations, and therefore should be specified in 1323bis. In addition, those ACKs that are triggered after the event should come with DSACK (assuming it's enabled, not detectable otherwise by the sender). They're similarly unreliable like those with SACK (although it actually depends on which of the checks take precedence). I'd amend 3.3, case b), to say explicitly that those with DSACK should also be excluded. -- i. From rs@netapp.com Fri Mar 22 04:51:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C8221F84D3 for ; Fri, 22 Mar 2013 04:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.048 X-Spam-Level: X-Spam-Status: No, score=-9.048 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6wVt3JXMCAh for ; Fri, 22 Mar 2013 04:51:35 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C263621F84C9 for ; Fri, 22 Mar 2013 04:51:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,891,1355126400"; d="scan'208";a="32981423" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 22 Mar 2013 04:51:34 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2MBpU2A021361; Fri, 22 Mar 2013 04:51:33 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Fri, 22 Mar 2013 04:51:30 -0700 From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Ilpo_J=E4rvinen?= Thread-Topic: [tcpm] 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+NzgA4VuvQADTDkwAADTNwoA== Date: Fri, 22 Mar 2013 11:51:30 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC9727@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> 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.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "Fernando Gont \(fernando@gont.com.ar\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2013 11:51:39 -0000 Hi Ilpo, let me tackle the 2nd issue first: > In addition, those ACKs that are triggered after the event should come > with DSACK (assuming it's enabled, not detectable otherwise by the > sender). They're similarly unreliable like those with SACK (although it > actually depends on which of the checks take precedence). I'd amend 3.3, > case b), to say explicitly that those with DSACK should also be excluded. Well, the receiver should reflect the highest timestamp in that case: (2) If: SEG.TSval >=3D TS.recent and SEG.SEQ <=3D Last.ACK.sent then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. Unless there was reordering between the RTO segment and the original segmen= t, the DSACK should carry a current measurement of the network RTT. If the entire flight of s before that DSACK was lost, that = will advance SND.UNA and could be processed for RTTM (delivering a valid m= easurement, unless the reordering + flight of acks lost event). However, DS= ACK is just a special case of SACK, and I would read=20 b) the segment does not indicate any loss or reordering, i.e. contains SACK options to exclude DSACKs (as the DSACK itself is an indication of either loss or r= eordering (or spurious RTO), and DSACK is just a special case of regular SA= CK). So, that particular case appears to me to be covered, but even if DSACKs wo= uld be processed (as they are in current stacks), there is little harm as t= he RTTM should mostly be up-to-date. To the RFC0793 3.3 acceptability check: That is the area of Fernando's rece= nt draft, I would like to hear his view of this issue. Your scenario looks like this: A(0) --> X- ack(A,0) B(1) --> X- ack(B,1) C(2) --> X- ack(C,2) : RTO : A(10) --> Ack(C,2)? Or ack(C,10)? Correct? When 793/3.3 runs first, the A(10) segment will be dropped, and TS.recent n= ot updated, thus Ack(C,2) would be sent. My view is, that this is not the correct behavior, as the TSecr in the ACK = for that duplicate segment A would not reflect the most recent measurement = of RTT. Therefore, PAWS processing takes precedence. I think the steps in section 4= .3 of 1323bis-07 allude to this implicit assumption. Having a short statement at the beginning of section 4.3 (PAWS processing M= UST take precedence over 793/3.3 acceptability checks) should make that cle= ar, right? Best regards, Richard Scheffenegger > -----Original Message----- > From: Ilpo J=E4rvinen [mailto:ilpo.jarvinen@helsinki.fi] > Sent: Freitag, 22. M=E4rz 2013 11:45 > To: Scheffenegger, Richard > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] 1323bis - preparing for WGLC >=20 > On Thu, 21 Mar 2013, Scheffenegger, Richard wrote: >=20 > > While there was quite some feedback regarding the points b and c in my > > announcement, I'd still like to learn what the WG thinks about these > > two points? > > > > a) Appendix D - Pseudo Code (incomplete) > > > > I'm leaning to remove that entire section, any objections? >=20 > While I don't exactly object the removal (it seems you did it already). > There's one serious shortcoming in the document. That is, I was once > looking for guidance on how to implement RFC793 acceptability check (3.3) > together with RFC1323 PAWS, but the precedence was not specified anywhere= . >=20 > I then found that there's the pseudocode in the 1323bis (which was then > kind of dead, before you took over it), but even that failed to address > the precendence, ie., no RFC793 checks were included to the pseudocode. > I'd have suggested that RFC793 checks should be added to the pseudocode > but somewhere else in the document is just as fine as long as it is > specified. >=20 > RFC793 checks are relevant in the case when there's 100% ACK loss for a > window, the sender RTOs and retransmits to that out-of-synch condition. > The interesting question is what timestamp should be echoed. It depends o= n > which runs first, RFC1323 checks or RFC793 checks. I think it's important > enough case to warrant consistent implementations, and therefore should b= e > specified in 1323bis. >=20 > In addition, those ACKs that are triggered after the event should come > with DSACK (assuming it's enabled, not detectable otherwise by the > sender). They're similarly unreliable like those with SACK (although it > actually depends on which of the checks take precedence). I'd amend 3.3, > case b), to say explicitly that those with DSACK should also be excluded. >=20 >=20 > -- > i. From dab@weston.borman.com Fri Mar 22 07:39:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6833921F8B9C for ; Fri, 22 Mar 2013 07:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 289lCv3ONgQ6 for ; Fri, 22 Mar 2013 07:39:58 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBFC21F8A85 for ; Fri, 22 Mar 2013 07:39:58 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r2MEdl7F008910; Fri, 22 Mar 2013 08:39:47 -0600 (CST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Borman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC9727@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 22 Mar 2013 09:39:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC9727@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" , "Fernando Gont \(fernando@gont.com.ar\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2013 14:39:59 -0000 On Mar 22, 2013, at 6:51 AM, "Scheffenegger, Richard" = wrote: > Hi Ilpo, >=20 > let me tackle the 2nd issue first: >=20 >> In addition, those ACKs that are triggered after the event should = come >> with DSACK (assuming it's enabled, not detectable otherwise by the >> sender). They're similarly unreliable like those with SACK (although = it >> actually depends on which of the checks take precedence). I'd amend = 3.3, >> case b), to say explicitly that those with DSACK should also be = excluded. >=20 > Well, the receiver should reflect the highest timestamp in that case: >=20 > (2) If: >=20 > SEG.TSval >=3D TS.recent and SEG.SEQ <=3D Last.ACK.sent >=20 > then SEG.TSval is copied to TS.Recent; otherwise, it is = ignored. >=20 > Unless there was reordering between the RTO segment and the original = segment, the DSACK should carry a current measurement of the = network RTT. >=20 > If the entire flight of s before that DSACK was lost, that = will advance SND.UNA and could be processed for RTTM (delivering a = valid measurement, unless the reordering + flight of acks lost event). = However, DSACK is just a special case of SACK, and I would read=20 >=20 >=20 > b) the segment does not indicate any loss or reordering, i.e. > contains SACK options >=20 > to exclude DSACKs (as the DSACK itself is an indication of either loss = or reordering (or spurious RTO), and DSACK is just a special case of = regular SACK). >=20 > So, that particular case appears to me to be covered, but even if = DSACKs would be processed (as they are in current stacks), there is = little harm as the RTTM should mostly be up-to-date. >=20 >=20 > To the RFC0793 3.3 acceptability check: That is the area of Fernando's = recent draft, I would like to hear his view of this issue. >=20 > Your scenario looks like this: >=20 > A(0) --> > X- ack(A,0) >=20 > B(1) --> > X- ack(B,1) >=20 > C(2) --> > X- ack(C,2) > : > RTO > : > A(10) --> > Ack(C,2)? Or ack(C,10)? >=20 > Correct? >=20 > When 793/3.3 runs first, the A(10) segment will be dropped, and = TS.recent not updated, thus Ack(C,2) would be sent. >=20 > My view is, that this is not the correct behavior, as the TSecr in the = ACK for that duplicate segment A would not reflect the most recent = measurement of RTT. >=20 > Therefore, PAWS processing takes precedence. I think the steps in = section 4.3 of 1323bis-07 allude to this implicit assumption. >=20 > Having a short statement at the beginning of section 4.3 (PAWS = processing MUST take precedence over 793/3.3 acceptability checks) = should make that clear, right? This is a good point. The intention is that TS.recent should be the = largest value received, and in this case receipt of A(10) will cause an ACK to = be generated; TS.recent should be updated and Ack(C,10) should be sent. = This is important because when the sender receives the Ack(C,10), it will acknowledge new data since all the previous ACKs were lost, and if = Ack(C,2) was sent, the TS information would not be accurate, defeating the whole purpose of TS. In addition, the retransmission of A(10) could have updated ACK = information in it for the reverse direction, and we'd want to get that. Hence, for = the TCP Sequence draft, this is an argument for accepting ACK information as = well as updating TS.recent when receiving duplicate packets that are more = than one byte to the left of the window. The TCP Sequence draft should be = updated to include updating TS.recent as well as the ACK information. -David Borman >=20 >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >=20 >=20 >> -----Original Message----- >> From: Ilpo J=E4rvinen [mailto:ilpo.jarvinen@helsinki.fi] >> Sent: Freitag, 22. M=E4rz 2013 11:45 >> To: Scheffenegger, Richard >> Cc: tcpm (tcpm@ietf.org) >> Subject: Re: [tcpm] 1323bis - preparing for WGLC >>=20 >> On Thu, 21 Mar 2013, Scheffenegger, Richard wrote: >>=20 >>> While there was quite some feedback regarding the points b and c in = my >>> announcement, I'd still like to learn what the WG thinks about these >>> two points? >>>=20 >>> a) Appendix D - Pseudo Code (incomplete) >>>=20 >>> I'm leaning to remove that entire section, any objections? >>=20 >> While I don't exactly object the removal (it seems you did it = already). >> There's one serious shortcoming in the document. That is, I was once >> looking for guidance on how to implement RFC793 acceptability check = (3.3) >> together with RFC1323 PAWS, but the precedence was not specified = anywhere. >>=20 >> I then found that there's the pseudocode in the 1323bis (which was = then >> kind of dead, before you took over it), but even that failed to = address >> the precendence, ie., no RFC793 checks were included to the = pseudocode. >> I'd have suggested that RFC793 checks should be added to the = pseudocode >> but somewhere else in the document is just as fine as long as it is >> specified. >>=20 >> RFC793 checks are relevant in the case when there's 100% ACK loss for = a >> window, the sender RTOs and retransmits to that out-of-synch = condition. >> The interesting question is what timestamp should be echoed. It = depends on >> which runs first, RFC1323 checks or RFC793 checks. I think it's = important >> enough case to warrant consistent implementations, and therefore = should be >> specified in 1323bis. >>=20 >> In addition, those ACKs that are triggered after the event should = come >> with DSACK (assuming it's enabled, not detectable otherwise by the >> sender). They're similarly unreliable like those with SACK (although = it >> actually depends on which of the checks take precedence). I'd amend = 3.3, >> case b), to say explicitly that those with DSACK should also be = excluded. >>=20 >>=20 >> -- >> i. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ilpo.jarvinen@helsinki.fi Fri Mar 22 09:39:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39A421F8AAC for ; Fri, 22 Mar 2013 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqXY7y6uAHj1 for ; Fri, 22 Mar 2013 09:39:16 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id A435621F8A6F for ; Fri, 22 Mar 2013 09:39:14 -0700 (PDT) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 22 Mar 2013 18:39:13 +0200 id 0008C5BD.514C8931.00001E7D Date: Fri, 22 Mar 2013 18:39:13 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: David Borman , "Scheffenegger, Richard" In-Reply-To: Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC9727@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm \\\\\\\\\(tcpm@ietf.org\\\\\\\\\)" , "Fernando Gont \\\\\\\\\(fernando@gont.com.ar\\\\\\\\\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2013 16:39:16 -0000 Hi Richard and David, On Fri, 22 Mar 2013, David Borman wrote: > On Mar 22, 2013, at 6:51 AM, "Scheffenegger, Richard" wrote: > > > > let me tackle the 2nd issue first: > > > >> In addition, those ACKs that are triggered after the event should come > >> with DSACK (assuming it's enabled, not detectable otherwise by the > >> sender). They're similarly unreliable like those with SACK (although it > >> actually depends on which of the checks take precedence). I'd amend 3.3, > >> case b), to say explicitly that those with DSACK should also be excluded. > > > > Well, the receiver should reflect the highest timestamp in that case: > > > > (2) If: > > > > SEG.TSval >= TS.recent and SEG.SEQ <= Last.ACK.sent > > > > then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. > > > > Unless there was reordering between the RTO segment and the original segment, the DSACK should carry a current measurement of the network RTT. > > > > If the entire flight of s before that DSACK was lost, that will advance SND.UNA and could be processed for RTTM (delivering a valid measurement, unless the reordering + flight of acks lost event). However, DSACK is just a special case of SACK, and I would read > > > > > > b) the segment does not indicate any loss or reordering, i.e. > > contains SACK options > > > > to exclude DSACKs (as the DSACK itself is an indication of either loss > > or reordering (or spurious RTO), and DSACK is just a special case of > > regular SACK). > > > > So, that particular case appears to me to be covered, but even if > > DSACKs would be processed (as they are in current stacks), there is > > little harm as the RTTM should mostly be up-to-date. I agree that there's improvement over RFC1323 alone thanks to the recent 1323bis work. I discovered this long time ago when even that SACK wording did not exists (when 1323bis was rather dormant), and therefore I might have been "spoiled" by the previous docs to judge the present wording clear enough. However, I'd say I'd still interpret the "does not indicate any loss or reordering" to mean data direction only (DSACK doesn't exactly "indicate" ACK loss even if that occurred in a particular scenario, IMHO it only "indicates" that a segment was received more than once). Thus it excludes ACK loss, which makes SACK option present vs DSACK ambiguous because there were no data dir losses nor reordering. IMHO, one of the most challenging thing from implementer POV is getting interaction between RFCs right because lack of exact and precise spec for the combos, and I think here's one good example of such (combination of SACK option, DSACK and TS, not exactly trivial combo of three). But adding something because of this is not as important as it used to be before the recent 1323bis changes. Also note that the current Linux implementation does reply with the older timestamp, which is how I discovered this issue in the first place (I set large ACK loss % while I tried to reproduce some totally different issue and saw RTT drifting occassionally to max during testing). So no matter what is done/decided now, we'll have the legacy around for quite long time still. I don't know what other OSes do in this case but it would be interesting to know. > > To the RFC0793 3.3 acceptability check: That is the area of Fernando's > > recent draft, I would like to hear his view of this issue. > > > > Your scenario looks like this: > > > > A(0) --> > > X- ack(A,0) > > > > B(1) --> > > X- ack(B,1) > > > > C(2) --> > > X- ack(C,2) > > : > > RTO > > : > > A(10) --> > > Ack(C,2)? Or ack(C,10)? > > > > Correct? Yes, this is the scenario. > > When 793/3.3 runs first, the A(10) segment will be dropped, and > > TS.recent not updated, thus Ack(C,2) would be sent. > > > > My view is, that this is not the correct behavior, as the TSecr in the > > ACK for that duplicate segment A would not reflect the most recent > > measurement of RTT. > > > > Therefore, PAWS processing takes precedence. I think the steps in > > section 4.3 of 1323bis-07 allude to this implicit assumption. > > > > Having a short statement at the beginning of section 4.3 (PAWS > > processing MUST take precedence over 793/3.3 acceptability checks) > > should make that clear, right? > > This is a good point. The intention is that TS.recent should be the largest > value received, and in this case receipt of A(10) will cause an ACK to be > generated; TS.recent should be updated and Ack(C,10) should be sent. This > is important because when the sender receives the Ack(C,10), it will > acknowledge new data since all the previous ACKs were lost, and if Ack(C,2) > was sent, the TS information would not be accurate, defeating the whole > purpose of TS. I realized this myself when I discovered the issue, but sadly I think both options have downsides: - With Ack(C,10) no window check is done for the PAWS update? It would remove ambiguity that otherwise remains even with TS (like you put it, it's the purpose of TS). But it's against the basic PAWS algo, if it is thought as steps in-order. But the key problem is that it opens a can of security worms (TSRecent-in-future attack)!? (I failed to state this in the 1st email as I misremembered the issue details slightly, and I had completely forgotten the existance of that basic PAWS algo :-)). - With Ack(C,2): the sender mis-measures RTT. Could be mitigated by the sender with a check for DSACK. Due to security, I'd err to the Ack(C,2) option which makes discarding DSACKed ACKs necessary. But I'd definately like to see Ack(C,10) though to remove ambiguity, however, only if security is not jeopardized. Third option I was then thinking was to echo the TSVal from the discarded segment (Ack(C,10)), but to not update TSRecent because of the RFC793 check failure. It would remove the ambiguity successfully but protect against TSRecent-in-future attacks? But there might be other cans of worms with this approach, I'm not fully sure of its impact. > In addition, the retransmission of A(10) could have updated ACK information > in it for the reverse direction, and we'd want to get that. Hence, for the > TCP Sequence draft, this is an argument for accepting ACK information as well > as updating TS.recent when receiving duplicate packets that are more than one > byte to the left of the window. The TCP Sequence draft should be updated to > include updating TS.recent as well as the ACK information. -- i. From michael.scharf@alcatel-lucent.com Fri Mar 22 10:59:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56E021F8CF9 for ; Fri, 22 Mar 2013 10:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.071 X-Spam-Level: X-Spam-Status: No, score=-9.071 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ4ew4bTY-3h for ; Fri, 22 Mar 2013 10:59:07 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9A21F8C71 for ; Fri, 22 Mar 2013 10:59:06 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2MHx24p001844 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Mar 2013 18:59:03 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 22 Mar 2013 18:59:02 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "tcpm (tcpm@ietf.org)" Date: Fri, 22 Mar 2013 18:59:01 +0100 Thread-Topic: 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+NzgA4VuvQADTA+yA= Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6E09@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2013 17:59:08 -0000 > While there was quite some feedback regarding the points b=20 > and c in my announcement, I'd still like to learn what the WG=20 > thinks about these two points? >=20 [...] > d) Window Scale reduction >=20 > The current text has been proposed by Matt Mathis on the list=20 > quite a while ago=20 >=20 > http://www.ietf.org/mail-archive/web/tcpm/current/msg03564.html >=20 > Is the WG in agreement with the specific text, that short=20 > summary of the necessary steps an implementer has to take? Or=20 > can anyone suggest a better wording for that section? I am not sure if I can provide a better wording. But indeed in particular t= he sender side part is hard to parse: - I think the meaning of "honor" is unclear in "The initial transmission MU= ST honor window on most recent ACK.". Does it imply "The initial transmissi= on MUST be within the window announced by the most recent ACK"? - I am not sure if the meaning of "such ACKs" is clear in "On subsequent re= transmissions, treat such ACKs as zero window probes.". Probably, "such ACK= s" refers to "ACKs shrinking the window". But even then it is unclear to me= how this relates to the question whether retransmissions must be in-window= . Given that this is an entire new section in a -bis document, I could also i= magine adding an example such as http://www.ietf.org/mail-archive/web/tcpm/= current/msg03564.html in a new appendix, to better motivate and explain tha= t change compared to 1323. Michael From rs@netapp.com Sun Mar 24 03:48:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81621F8AD8 for ; Sun, 24 Mar 2013 03:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.307 X-Spam-Level: X-Spam-Status: No, score=-9.307 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1quYyzqczU1U for ; Sun, 24 Mar 2013 03:48:25 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id CE82121F8A06 for ; Sun, 24 Mar 2013 03:48:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,900,1355126400"; d="scan'208";a="33494071" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 24 Mar 2013 03:48:24 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2OAmMFF005837; Sun, 24 Mar 2013 03:48:23 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Sun, 24 Mar 2013 03:48:22 -0700 From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , David Borman Thread-Topic: [tcpm] 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+NzgA4VuvQADTDkwAADTNwoP//2COAgAAhXID//bp7YA== Date: Sun, 24 Mar 2013 10:48:20 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ACC4BC@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC9727@SACEXCMBX02-PRD.hq.netapp.com> 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.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \\\\\\\\\(tcpm@ietf.org\\\\\\\\\)" , "Fernando Gont \\\\\\\\\(fernando@gont.com.ar\\\\\\\\\)" Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 24 Mar 2013 10:48:28 -0000 Hi Ilpo, >> This is a good point. The intention is that TS.recent should be the >> largest value received, and in this case receipt of A(10) will cause >> an ACK to be generated; TS.recent should be updated and Ack(C,10) >> should be sent. This is important because when the sender receives >> the Ack(C,10), it will acknowledge new data since all the previous >> ACKs were lost, and if Ack(C,2) was sent, the TS information would not >> be accurate, defeating the whole purpose of TS. >=20 > I realized this myself when I discovered the issue, but sadly I think bot= h > options have downsides: >=20 > - With Ack(C,10) no window check is done for the PAWS update? It would > remove ambiguity that otherwise remains even with TS (like you put it, > it's the purpose of TS). But it's against the basic PAWS algo, if it is > thought as steps in-order. But the key problem is that it opens a can of > security worms (TSRecent-in-future attack)!? (I failed to state this in > the 1st email as I misremembered the issue details slightly, and I had > completely forgotten the existance of that basic PAWS algo :-)). Can you explain this a little more? In the scenario, the A,10 packet has the TS processed first (and TSrecent i= s updated), as by step (2) in section 3.4 (1323bis). As the SEG.SEQ is old,= only an ACK is triggered without any further processing. Someone observing= the session could mount a DOS attack by resending an old packet, with a hi= gher TSval, true... What do you suggest?=20 Swapping points R2/R3 around, and adding (to the current R3): (RCV.NXT - RCV.WND [- 1]) <=3D SEG.SEQ <=3D Last.ACK.sent >=20 > - With Ack(C,2): the sender mis-measures RTT. Could be mitigated by the > sender with a check for DSACK. Expanded the RTTM rules to state:=20 b) the segment does not indicate any potential loss or reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC2883] options >=20 > Due to security, I'd err to the Ack(C,2) option which makes discarding > DSACKed ACKs necessary. But I'd definately like to see Ack(C,10) though t= o > remove ambiguity, however, only if security is not jeopardized. >=20 > Third option I was then thinking was to echo the TSVal from the discarded > segment (Ack(C,10)), but to not update TSRecent because of the RFC793 > check failure. It would remove the ambiguity successfully but protect > against TSRecent-in-future attacks? But there might be other cans of worm= s > with this approach, I'm not fully sure of its impact. That would be in-line with my proposed TS nego draft, which actually change= s the semantics of TSopt when SACK is also negotiated... Keeping 1323bis in= line with the use of TSrecent and the semantics imposed by that would be p= referable. I would suggest an extension to the TSrecent update test as mentioned above= . Any downsides with that? Best regards, Richard Scheffenegger From rs@netapp.com Sun Mar 24 04:29:46 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3312321F8C53 for ; Sun, 24 Mar 2013 04:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.029 X-Spam-Level: X-Spam-Status: No, score=-10.029 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYatLYYrDAjO for ; Sun, 24 Mar 2013 04:29:45 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8822021F89EE for ; Sun, 24 Mar 2013 04:29:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,900,1355126400"; d="scan'208";a="33499196" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 24 Mar 2013 04:29:45 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2OBTiAk004683; Sun, 24 Mar 2013 04:29:45 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Sun, 24 Mar 2013 04:29:43 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm (tcpm@ietf.org)" , "Matthew Mathis (mattmathis@google.com)" Thread-Topic: 1323bis - preparing for WGLC Thread-Index: Ac4lcH25jO3olS06RL+dsxE+ZG+NzgA4VuvQADTA+yAAVttV8A== Date: Sun, 24 Mar 2013 11:29:43 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ACC4D6@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AC0025@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AC5A2D@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6E09@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6E09@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.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.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] 1323bis - preparing for WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 24 Mar 2013 11:29:46 -0000 Hi Michael, >> d) Window Scale reduction I reworded that section using your suggestion: On the sender side: 3) The initial transmission MUST be within the window announced by the most recent . 4) On first retransmission, or if the sequence number is out-of- window by less than (2^Rcv.Wind.Scale) then do normal retransmission(s) without regard to receiver window as long as the original segment was in window when it was sent. 5) Subsequent retransmissions MAY only be sent, if they are within the window announced by the most recent . The zero window probe reference I removed, as regular new transmissions, wh= ich would fall beyond the most recent announced window, should not be perfo= rmed anyway. Also, I added an appendix, quoting Matt's email near verbatim (fixing typos= ): Appendix F. Window Retraction Example Consider a established TCP connection with WSCALE=3D7 (128 byte receiver window quantization), that is running with a very small windows because the receiver is bottlenecked and both ends are doing small reads and writes. Consider the ACKs coming back: SEG.ACK SEG.WIN computed SND.WIN receiver's actual window 1000 2 1256 1300 The sender writes 40 bytes and receiver ACKs: 1040 2 1296 1300 The sender writes 5 additional bytes and the receiver has a problem. Two choices: 1045 2 1301 1300 - BEYOND BUFFER 1045 1 1173 1300 - RETRACTED WINDOW This problems is completely general and can in principle happen any time the sender does a write which is smaller than the window scale quanta. In most stacks it is at least partially obscured when the window size is larger than some small number of segments because the stacks prefer to announce windows that are integral numbers of segments (rounded up to the next window quanta). This plus silly window suppression tends to cause less frequent, larger window updates. If the window was rounded down to a segment size there is more opportunity to advance it ("beyond buffer" case above) rather than retracting it. Richard Scheffenegger > -----Original Message----- > From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com= ] > Sent: Freitag, 22. M=E4rz 2013 18:59 > To: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > Subject: RE: 1323bis - preparing for WGLC >=20 > > While there was quite some feedback regarding the points b and c in my > > announcement, I'd still like to learn what the WG thinks about these > > two points? > > >=20 > [...] >=20 > > d) Window Scale reduction > > > > The current text has been proposed by Matt Mathis on the list quite a > > while ago > > > > http://www.ietf.org/mail-archive/web/tcpm/current/msg03564.html > > > > Is the WG in agreement with the specific text, that short summary of > > the necessary steps an implementer has to take? Or can anyone suggest > > a better wording for that section? >=20 > I am not sure if I can provide a better wording. But indeed in particular > the sender side part is hard to parse: >=20 > - I think the meaning of "honor" is unclear in "The initial transmission > MUST honor window on most recent ACK.". Does it imply "The initial > transmission MUST be within the window announced by the most recent ACK"? >=20 > - I am not sure if the meaning of "such ACKs" is clear in "On subsequent > retransmissions, treat such ACKs as zero window probes.". Probably, "such > ACKs" refers to "ACKs shrinking the window". But even then it is unclear > to me how this relates to the question whether retransmissions must be in= - > window. >=20 > Given that this is an entire new section in a -bis document, I could also > imagine adding an example such as http://www.ietf.org/mail- > archive/web/tcpm/current/msg03564.html in a new appendix, to better > motivate and explain that change compared to 1323. >=20 > Michael From rs@netapp.com Sun Mar 24 04:34:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F3121F8C7A for ; Sun, 24 Mar 2013 04:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.028 X-Spam-Level: X-Spam-Status: No, score=-10.028 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL5nfmbK-7a4 for ; Sun, 24 Mar 2013 04:34:04 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id B8CDB21F8C5D for ; Sun, 24 Mar 2013 04:34:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,900,1355126400"; d="scan'208";a="33499833" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 24 Mar 2013 04:34:04 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2OBY4nc007446; Sun, 24 Mar 2013 04:34:04 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Sun, 24 Mar 2013 04:34:04 -0700 From: "Scheffenegger, Richard" To: Joe Touch , Tim Shepard Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOJrDdscFonFA9vEavV3WDHbIX35i0uJcA Date: Sun, 24 Mar 2013 11:34:02 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> References: <514BD5B7.9070305@isi.edu> In-Reply-To: <514BD5B7.9070305@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 24 Mar 2013 11:34:05 -0000 I restored the original text of draft -00: A TCP MAY send the Timestamp option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in other segments only if it received a TSopt in the initial or segment for the connection. When TSopt has been sent or received in a non- segment, it MUST be sent in all segments. Once a TSopt has been received in a non- segment, then any successive segment that is received without the RST bit and without a TSopt MAY be dropped without further processing, and an of the current SND.UNA generated. Keeping the additional text to stipulate exactly, that TSopt MUST NOT be re= moved later in the session, and also the text specific to , as that is= one area of major technical change to RFC1323.=20 Richard Scheffenegger > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Freitag, 22. M=E4rz 2013 04:53 > To: Tim Shepard > Cc: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >=20 > FWIW... >=20 > On 3/21/2013 6:43 PM, Tim Shepard wrote: > (the original 1323 text:) > > > > A TCP may send the Timestamps option (TSopt) in an initial > > segment (i.e., segment containing a SYN bit and no ACK > > bit), and may send a TSopt in other segments only if it re- > > ceived a TSopt in the initial segment for the > connection. >=20 > I like this one even better because it is more clear about: >=20 > a) the use of TSopt is optional > b) TSopt must be enabled in the SYN > c) TSopt, once enabled, may (or may not) be in a given segment >=20 > There's no rule about how to respond if an endpoint simply decides not to > use it on a given segment, which makes more sense to me. >=20 > Joe From touch@isi.edu Mon Mar 25 10:12:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DF221F9081 for ; Mon, 25 Mar 2013 10:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tijJaCxkJjGL for ; Mon, 25 Mar 2013 10:12:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A76C221F8DF7 for ; Mon, 25 Mar 2013 10:12:00 -0700 (PDT) Received: from [192.168.1.89] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2PHAavP017151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 10:10:45 -0700 (PDT) Message-ID: <5150850E.1040405@isi.edu> Date: Mon, 25 Mar 2013 10:10:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> 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: "tcpm \(tcpm@ietf.org\)" , Tim Shepard Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Mar 2013 17:12:04 -0000 Hi, Richard, On 3/24/2013 4:34 AM, Scheffenegger, Richard wrote: > > I restored the original text of draft -00: > > A TCP MAY send the Timestamp option (TSopt) in an initial > segment (i.e., segment containing a SYN bit and no ACK bit), and MAY > send a TSopt in other segments only if it received a TSopt in the > initial or segment for the connection. When TSopt > has been sent or received in a non- segment, it MUST be sent in > all segments. Once a TSopt has been received in a non- segment, > then any successive segment that is received without the RST bit and > without a TSopt MAY be dropped without further processing, and an > of the current SND.UNA generated. > > Keeping the additional text to stipulate exactly, that TSopt MUST > NOTbe removed later in the session, and also the text specific to , as > that is one area of major technical change to RFC1323. I don't recall the rationale for either change; can you explain in the doc? Joe From rs@netapp.com Mon Mar 25 10:31:17 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9AE21F9509 for ; Mon, 25 Mar 2013 10:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbojYZOi1CsT for ; Mon, 25 Mar 2013 10:31:17 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5220C21F9500 for ; Mon, 25 Mar 2013 10:31:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,905,1355126400"; d="scan'208";a="16624289" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 25 Mar 2013 10:31:16 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2PHVGpK010993; Mon, 25 Mar 2013 10:31:16 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Mon, 25 Mar 2013 10:31:16 -0700 From: "Scheffenegger, Richard" To: Joe Touch Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOJrDdscFonFA9vEavV3WDHbIX35i0uJcAgAJmtwD//47skA== Date: Mon, 25 Mar 2013 17:31:15 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> In-Reply-To: <5150850E.1040405@isi.edu> 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 \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Mar 2013 17:31:18 -0000 Hi Joe, at the end of 4.2, there is this paragraph; doesn't that contain the ration= ale? (Albeit, the "most recently" is ~2007 or so...) [RFC1323] recommended that segments NOT carry timestamps, and that they be acceptable regardless of their timestamp. At that time, the thinking was that old duplicate segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. More recently, discussions about various blind attacks on TCP connections have raised the suggestion that if the timestamp option is present, SEG.TSecr could be used to provide stricter acceptance tests for segments. While still under discussion, to enable research into this area it is now RECOMMENDED that when generating a , that if the segment causing the to be generated contained a timestamp option, that the also contain a timestamp option. In the segment, SEG.TSecr SHOULD be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be set to zero. If a is being generated because of a user abort, and Snd.TS.OK is set, then a timestamp option SHOULD be included in the . When a segment is received, it MUST NOT be subjected to PAWS checks, and information from the timestamp option MUST NOT be used to update connection state information. SEG.TSecr MAY be used to provide stricter acceptance checks. This was added before my time as editor, though.... Disallowing the state machine from later opting out from sending TSopt (eve= n when the other end stops sending it) sounds like a reasonable approach? Richard Scheffenegger > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Montag, 25. M=E4rz 2013 18:11 > To: Scheffenegger, Richard > Cc: Tim Shepard; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >=20 > Hi, Richard, >=20 > On 3/24/2013 4:34 AM, Scheffenegger, Richard wrote: > > > > I restored the original text of draft -00: > > > > A TCP MAY send the Timestamp option (TSopt) in an initial > > segment (i.e., segment containing a SYN bit and no ACK bit), and MA= Y > > send a TSopt in other segments only if it received a TSopt in the > > initial or segment for the connection. When TSopt > > has been sent or received in a non- segment, it MUST be sent i= n > > all segments. Once a TSopt has been received in a non- > segment, > > then any successive segment that is received without the RST bit an= d > > without a TSopt MAY be dropped without further processing, and an > > of the current SND.UNA generated. > > > > Keeping the additional text to stipulate exactly, that TSopt MUST > > NOTbe removed later in the session, and also the text specific to > > , as that is one area of major technical change to RFC1323. >=20 > I don't recall the rationale for either change; can you explain in the > doc? >=20 > Joe From touch@isi.edu Mon Mar 25 11:35:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E4921F90C7 for ; Mon, 25 Mar 2013 11:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISbtuUU2JsHP for ; Mon, 25 Mar 2013 11:35:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 73DA521F90B1 for ; Mon, 25 Mar 2013 11:35:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2PIZHAw003413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 11:35:17 -0700 (PDT) Message-ID: <515098E2.6060703@isi.edu> Date: Mon, 25 Mar 2013 11:35:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Mar 2013 18:35:47 -0000 Hi, Richard, There are two separate issues: 1) whether non-RST segments should be required to include TSopt once it is negotiated for a connection and 2) whether RSTs should be required to include TSopt once it is negotiated for a connection I disagree with either one. TSopt is not a security mechanism, so I'm not buying arguments based on that at all. I am more concerned with TCP's stability. Joe On 3/25/2013 10:31 AM, Scheffenegger, Richard wrote: > Hi Joe, > > at the end of 4.2, there is this paragraph; doesn't that contain the rationale? (Albeit, the "most recently" is ~2007 or so...) > > > [RFC1323] recommended that segments NOT carry timestamps, and > that they be acceptable regardless of their timestamp. At that time, > the thinking was that old duplicate segments should be > exceedingly unlikely, and their cleanup function should take > precedence over timestamps. More recently, discussions about various > blind attacks on TCP connections have raised the suggestion that if > the timestamp option is present, SEG.TSecr could be used to provide > stricter acceptance tests for segments. While still under > discussion, to enable research into this area it is now RECOMMENDED > that when generating a , that if the segment causing the > to be generated contained a timestamp option, that the also > contain a timestamp option. In the segment, SEG.TSecr SHOULD > be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be > set to zero. If a is being generated because of a user abort, > and Snd.TS.OK is set, then a timestamp option SHOULD be included in > the . When a segment is received, it MUST NOT be > subjected to PAWS checks, and information from the timestamp option > MUST NOT be used to update connection state information. SEG.TSecr > MAY be used to provide stricter acceptance checks. > > This was added before my time as editor, though.... > > > Disallowing the state machine from later opting out from sending TSopt (even when the other end stops sending it) sounds like a reasonable approach? > > > Richard Scheffenegger >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Montag, 25. Mrz 2013 18:11 >> To: Scheffenegger, Richard >> Cc: Tim Shepard; tcpm (tcpm@ietf.org) >> Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >> >> Hi, Richard, >> >> On 3/24/2013 4:34 AM, Scheffenegger, Richard wrote: >>> >>> I restored the original text of draft -00: >>> >>> A TCP MAY send the Timestamp option (TSopt) in an initial >>> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY >>> send a TSopt in other segments only if it received a TSopt in the >>> initial or segment for the connection. When TSopt >>> has been sent or received in a non- segment, it MUST be sent in >>> all segments. Once a TSopt has been received in a non- >> segment, >>> then any successive segment that is received without the RST bit and >>> without a TSopt MAY be dropped without further processing, and an >>> of the current SND.UNA generated. >>> >>> Keeping the additional text to stipulate exactly, that TSopt MUST >>> NOTbe removed later in the session, and also the text specific to >>> , as that is one area of major technical change to RFC1323. >> >> I don't recall the rationale for either change; can you explain in the >> doc? >> >> Joe From prvs=17963f7db4=david.borman@quantum.com Mon Mar 25 12:07:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941E621F9571 for ; Mon, 25 Mar 2013 12:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrXuOjo1QJRO for ; Mon, 25 Mar 2013 12:07:34 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0288821F9576 for ; Mon, 25 Mar 2013 12:07:33 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2PJ4Sbw009922; Mon, 25 Mar 2013 12:07:30 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1ba56euecv-9 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Mar 2013 12:07:29 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 25 Mar 2013 13:07:10 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Mon, 25 Mar 2013 13:07:16 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKYv2ehkUjAjsyE+NwCGyU9etWQ== Date: Mon, 25 Mar 2013 19:06:34 +0000 Message-ID: References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> In-Reply-To: <515098E2.6060703@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.176.229] Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-25_04:2013-03-25, 2013-03-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303250173 Content-Type: text/plain; charset="iso-8859-1" Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Mar 2013 19:07:34 -0000 On Mar 25, 2013, at 1:35 PM, Joe Touch wrote: > Hi, Richard, >=20 > There are two separate issues: >=20 > 1) whether non-RST segments should be required to include TSopt once it i= s negotiated for a connection Whether or not you send TSopt on the first non-SYN packet, once you start s= ending TSopt, you need to keep sending TSopt for the duration of the connec= tion or it messes up both PAWS and making RTT measurements based on TSopt. = If you can't use it for PAWS and you can't trust the RTT measurements, the= n TSopt is worthless. Hence, once you start sending/receiving it, you send= it for the rest of the connection. That's the point of the original 1323bis wording that Richard has restored,= that text goes back to at least 1996. -David Borman >=20 > and >=20 > 2) whether RSTs should be required to include TSopt once it is negotiated= for a connection >=20 > I disagree with either one. TSopt is not a security mechanism, so I'm not= buying arguments based on that at all. >=20 > I am more concerned with TCP's stability. >=20 > Joe >=20 > On 3/25/2013 10:31 AM, Scheffenegger, Richard wrote: >> Hi Joe, >>=20 >> at the end of 4.2, there is this paragraph; doesn't that contain the rat= ionale? (Albeit, the "most recently" is ~2007 or so...) >>=20 >>=20 >> [RFC1323] recommended that segments NOT carry timestamps, and >> that they be acceptable regardless of their timestamp. At that time, >> the thinking was that old duplicate segments should be >> exceedingly unlikely, and their cleanup function should take >> precedence over timestamps. More recently, discussions about various >> blind attacks on TCP connections have raised the suggestion that if >> the timestamp option is present, SEG.TSecr could be used to provide >> stricter acceptance tests for segments. While still under >> discussion, to enable research into this area it is now RECOMMENDED >> that when generating a , that if the segment causing the >> to be generated contained a timestamp option, that the also >> contain a timestamp option. In the segment, SEG.TSecr SHOULD >> be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be >> set to zero. If a is being generated because of a user abort, >> and Snd.TS.OK is set, then a timestamp option SHOULD be included in >> the . When a segment is received, it MUST NOT be >> subjected to PAWS checks, and information from the timestamp option >> MUST NOT be used to update connection state information. SEG.TSecr >> MAY be used to provide stricter acceptance checks. >>=20 >> This was added before my time as editor, though.... >>=20 >>=20 >> Disallowing the state machine from later opting out from sending TSopt (= even when the other end stops sending it) sounds like a reasonable approach? >>=20 >>=20 >> Richard Scheffenegger >>> -----Original Message----- >>> From: Joe Touch [mailto:touch@isi.edu] >>> Sent: Montag, 25. M=E4rz 2013 18:11 >>> To: Scheffenegger, Richard >>> Cc: Tim Shepard; tcpm (tcpm@ietf.org) >>> Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >>>=20 >>> Hi, Richard, >>>=20 >>> On 3/24/2013 4:34 AM, Scheffenegger, Richard wrote: >>>>=20 >>>> I restored the original text of draft -00: >>>>=20 >>>> A TCP MAY send the Timestamp option (TSopt) in an initial >>>> segment (i.e., segment containing a SYN bit and no ACK bit), and M= AY >>>> send a TSopt in other segments only if it received a TSopt in the >>>> initial or segment for the connection. When TSopt >>>> has been sent or received in a non- segment, it MUST be sent = in >>>> all segments. Once a TSopt has been received in a non- >>> segment, >>>> then any successive segment that is received without the RST bit a= nd >>>> without a TSopt MAY be dropped without further processing, and an >>>> of the current SND.UNA generated. >>>>=20 >>>> Keeping the additional text to stipulate exactly, that TSopt MUST >>>> NOTbe removed later in the session, and also the text specific to >>>> , as that is one area of major technical change to RFC1323. >>>=20 >>> I don't recall the rationale for either change; can you explain in the >>> doc? >>>=20 >>> Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From touch@isi.edu Mon Mar 25 13:11:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D62D21F9581 for ; Mon, 25 Mar 2013 13:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-MTZT2jAI1w for ; Mon, 25 Mar 2013 13:11:07 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9491B21F8DFD for ; Mon, 25 Mar 2013 13:11:07 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2PKAZb6025138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 13:10:35 -0700 (PDT) Message-ID: <5150AF37.7060302@isi.edu> Date: Mon, 25 Mar 2013 13:10:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Borman References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Mar 2013 20:11:08 -0000 Hi, David, I don't disagree, but none of this is in the doc. IMO, the doc needs to be very clear about how it modifies RFC1323, and highlight not only how it differs but also why. The reason you point out, FWIW, is valid for all segments except RST. For RST, there are valid robustness reasons that IMO trump security concerns exactly because this is NOT a security mechanism. So my conclusion would be: - include the requirement for non-RST segments, but NOT for RSTs - add a paragraph explaining how things changed - include in that paragraph both why non-RST segments need TSopt and why RSTs should be allowed to omit them. Joe On 3/25/2013 12:06 PM, David Borman wrote: > > On Mar 25, 2013, at 1:35 PM, Joe Touch wrote: > >> Hi, Richard, >> >> There are two separate issues: >> >> 1) whether non-RST segments should be required to include TSopt once it is negotiated for a connection > > Whether or not you send TSopt on the first non-SYN packet, once you start sending TSopt, you need to keep sending TSopt for the duration of the connection or it messes up both PAWS and making RTT measurements based on TSopt. If you can't use it for PAWS and you can't trust the RTT measurements, then TSopt is worthless. Hence, once you start sending/receiving it, you send it for the rest of the connection. > > That's the point of the original 1323bis wording that Richard has restored, that text goes back to at least 1996. > > -David Borman > >> >> and >> >> 2) whether RSTs should be required to include TSopt once it is negotiated for a connection >> >> I disagree with either one. TSopt is not a security mechanism, so I'm not buying arguments based on that at all. >> >> I am more concerned with TCP's stability. >> >> Joe >> >> On 3/25/2013 10:31 AM, Scheffenegger, Richard wrote: >>> Hi Joe, >>> >>> at the end of 4.2, there is this paragraph; doesn't that contain the rationale? (Albeit, the "most recently" is ~2007 or so...) >>> >>> >>> [RFC1323] recommended that segments NOT carry timestamps, and >>> that they be acceptable regardless of their timestamp. At that time, >>> the thinking was that old duplicate segments should be >>> exceedingly unlikely, and their cleanup function should take >>> precedence over timestamps. More recently, discussions about various >>> blind attacks on TCP connections have raised the suggestion that if >>> the timestamp option is present, SEG.TSecr could be used to provide >>> stricter acceptance tests for segments. While still under >>> discussion, to enable research into this area it is now RECOMMENDED >>> that when generating a , that if the segment causing the >>> to be generated contained a timestamp option, that the also >>> contain a timestamp option. In the segment, SEG.TSecr SHOULD >>> be set to SEG.TSval from the incoming segment and SEG.TSval SHOULD be >>> set to zero. If a is being generated because of a user abort, >>> and Snd.TS.OK is set, then a timestamp option SHOULD be included in >>> the . When a segment is received, it MUST NOT be >>> subjected to PAWS checks, and information from the timestamp option >>> MUST NOT be used to update connection state information. SEG.TSecr >>> MAY be used to provide stricter acceptance checks. >>> >>> This was added before my time as editor, though.... >>> >>> >>> Disallowing the state machine from later opting out from sending TSopt (even when the other end stops sending it) sounds like a reasonable approach? >>> >>> >>> Richard Scheffenegger >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Montag, 25. Mrz 2013 18:11 >>>> To: Scheffenegger, Richard >>>> Cc: Tim Shepard; tcpm (tcpm@ietf.org) >>>> Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >>>> >>>> Hi, Richard, >>>> >>>> On 3/24/2013 4:34 AM, Scheffenegger, Richard wrote: >>>>> >>>>> I restored the original text of draft -00: >>>>> >>>>> A TCP MAY send the Timestamp option (TSopt) in an initial >>>>> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY >>>>> send a TSopt in other segments only if it received a TSopt in the >>>>> initial or segment for the connection. When TSopt >>>>> has been sent or received in a non- segment, it MUST be sent in >>>>> all segments. Once a TSopt has been received in a non- >>>> segment, >>>>> then any successive segment that is received without the RST bit and >>>>> without a TSopt MAY be dropped without further processing, and an >>>>> of the current SND.UNA generated. >>>>> >>>>> Keeping the additional text to stipulate exactly, that TSopt MUST >>>>> NOTbe removed later in the session, and also the text specific to >>>>> , as that is one area of major technical change to RFC1323. >>>> >>>> I don't recall the rationale for either change; can you explain in the >>>> doc? >>>> >>>> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. > From rs@netapp.com Tue Mar 26 04:39:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62FF21F8A5E for ; Tue, 26 Mar 2013 04:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtM12eytVf80 for ; Tue, 26 Mar 2013 04:39:46 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED5821F8A55 for ; Tue, 26 Mar 2013 04:39:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,911,1355126400"; d="scan'208";a="34100938" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 26 Mar 2013 04:39:46 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2QBdj70002254; Tue, 26 Mar 2013 04:39:45 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 04:39:44 -0700 From: "Scheffenegger, Richard" To: Joe Touch , David Borman Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOJrDdscFonFA9vEavV3WDHbIX35i0uJcAgAJmtwD//47skIAAiLcAgAAIwQCAABHegIAAhmDQ Date: Tue, 26 Mar 2013 11:39:44 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> In-Reply-To: <5150AF37.7060302@isi.edu> 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 \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2013 11:39:47 -0000 Hi Joe, > I don't disagree, but none of this is in the doc. >> Whether or not you send TSopt on the first non-SYN packet, once you >> start sending TSopt, you need to keep sending TSopt for the duration of >> the connection=20 I believe, the (restored) wording covers that part... >> or it messes up both PAWS and making RTT measurements based >> on TSopt. If you can't use it for PAWS and you can't trust the RTT >> measurements, then TSopt is worthless. Hence, once you start >> sending/receiving it, you send it for the rest of the connection. Only this more explicit explanation, why a TCP MUST NOT stop sending TSopt = once started is missing. But the current text IMHO described that technical= ly. I will try to reword the above statement and add it to 1323bis. Again, this is NOT a deviation from 1323, just a clarification for implemen= ters. How about this paragraph following the TSopt text: As TSopt is required for the two mechanisms described in sections 3.3 and 4.2, once established, every segment of a session - with the exception of (for a detailed discussion see Section 4.2) - is REQUIRED to have TSopt sent. If a TCP stopped sending TSopt at any later time, it would interfere with both PAWS and RTTM mechanism, that are both based on TSopt. This update to [RFC1323] makes it explicit, that segments missing the TSopt MAY be dropped by either end of the session, to alert implementers of the serious repercussions of not adhering to the timestamp mechanism. The detailed text explaining the is at the end of section 4.2, with t= he PAWS check. Do you suggest to move that paragraph forward to the end of section 3.2, wh= ere TSopt is defined? Richard Scheffenegger > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Montag, 25. M=E4rz 2013 21:11 > To: David Borman > Cc: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >=20 > Hi, David, >=20 > I don't disagree, but none of this is in the doc. >=20 > IMO, the doc needs to be very clear about how it modifies RFC1323, and > highlight not only how it differs but also why. >=20 > The reason you point out, FWIW, is valid for all segments except RST. > For RST, there are valid robustness reasons that IMO trump security > concerns exactly because this is NOT a security mechanism. >=20 > So my conclusion would be: >=20 > - include the requirement for non-RST segments, but NOT for RSTs >=20 > - add a paragraph explaining how things changed >=20 > - include in that paragraph both why non-RST segments need TSopt > and why RSTs should be allowed to omit them. >=20 > Joe >=20 > On 3/25/2013 12:06 PM, David Borman wrote: > > > > On Mar 25, 2013, at 1:35 PM, Joe Touch wrote: > > > >> Hi, Richard, > >> > >> There are two separate issues: =09 > >> > >> 1) whether non-RST segments should be required to include TSopt once > >> it is negotiated for a connection > > > > Whether or not you send TSopt on the first non-SYN packet, once you > start sending TSopt, you need to keep sending TSopt for the duration of > the connection or it messes up both PAWS and making RTT measurements base= d > on TSopt. If you can't use it for PAWS and you can't trust the RTT > measurements, then TSopt is worthless. Hence, once you start > sending/receiving it, you send it for the rest of the connection. > > > > That's the point of the original 1323bis wording that Richard has > restored, that text goes back to at least 1996. > > > > -David Borman > > > >> > >> and > >> > >> 2) whether RSTs should be required to include TSopt once it is > >> negotiated for a connection > >> > >> I disagree with either one. TSopt is not a security mechanism, so I'm > not buying arguments based on that at all. > >> > >> I am more concerned with TCP's stability. > >> > >> Joe > >> > >> On 3/25/2013 10:31 AM, Scheffenegger, Richard wrote: > >>> Hi Joe, > >>> > >>> at the end of 4.2, there is this paragraph; doesn't that contain the > >>> rationale? (Albeit, the "most recently" is ~2007 or so...) > >>> > >>> > >>> [RFC1323] recommended that segments NOT carry timestamps, > and > >>> that they be acceptable regardless of their timestamp. At that > time, > >>> the thinking was that old duplicate segments should be > >>> exceedingly unlikely, and their cleanup function should take > >>> precedence over timestamps. More recently, discussions about > various > >>> blind attacks on TCP connections have raised the suggestion that > if > >>> the timestamp option is present, SEG.TSecr could be used to > provide > >>> stricter acceptance tests for segments. While still under > >>> discussion, to enable research into this area it is now > RECOMMENDED > >>> that when generating a , that if the segment causing the > > >>> to be generated contained a timestamp option, that the also > >>> contain a timestamp option. In the segment, SEG.TSecr > SHOULD > >>> be set to SEG.TSval from the incoming segment and SEG.TSval SHOUL= D > be > >>> set to zero. If a is being generated because of a user > abort, > >>> and Snd.TS.OK is set, then a timestamp option SHOULD be included > in > >>> the . When a segment is received, it MUST NOT be > >>> subjected to PAWS checks, and information from the timestamp > option > >>> MUST NOT be used to update connection state information. > SEG.TSecr > >>> MAY be used to provide stricter acceptance checks. > >>> > >>> This was added before my time as editor, though.... > >>> > >>> > >>> Disallowing the state machine from later opting out from sending TSop= t > (even when the other end stops sending it) sounds like a reasonable > approach? > >>> > >>> > >>> Richard Scheffenegger > >>>> -----Original Message----- > >>>> From: Joe Touch [mailto:touch@isi.edu] > >>>> Sent: Montag, 25. M=E4rz 2013 18:11 > >>>> To: Scheffenegger, Richard > >>>> Cc: Tim Shepard; tcpm (tcpm@ietf.org) > >>>> Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt > >>>> > >>>> Hi, Richard, > >>>> > >>>> On 3/24/2013 4:34 AM, Scheffenegger, Richard wrote: > >>>>> > >>>>> I restored the original text of draft -00: > >>>>> > >>>>> A TCP MAY send the Timestamp option (TSopt) in an initial > >>>>> segment (i.e., segment containing a SYN bit and no ACK bit), > and MAY > >>>>> send a TSopt in other segments only if it received a TSopt in > the > >>>>> initial or segment for the connection. When > TSopt > >>>>> has been sent or received in a non- segment, it MUST be > sent in > >>>>> all segments. Once a TSopt has been received in a non- > >>>> segment, > >>>>> then any successive segment that is received without the RST > bit and > >>>>> without a TSopt MAY be dropped without further processing, and > an > >>>>> of the current SND.UNA generated. > >>>>> > >>>>> Keeping the additional text to stipulate exactly, that TSopt MUST > >>>>> NOTbe removed later in the session, and also the text specific to > >>>>> , as that is one area of major technical change to RFC1323. > >>>> > >>>> I don't recall the rationale for either change; can you explain in > >>>> the doc? > >>>> > >>>> Joe > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > ---------------------------------------------------------------------- > > The information contained in this transmission may be confidential. Any > disclosure, copying, or further distribution of confidential information > is not permitted unless such privilege is explicitly granted in writing b= y > Quantum. Quantum reserves the right to have electronic communications, > including email and attachments, sent across its networks filtered throug= h > anti virus and spam software programs and retain such messages in order t= o > comply with applicable data security and retention requirements. Quantum > is not responsible for the proper and complete transmission of the > substance of this communication or for any delay in its receipt. > > From touch@isi.edu Tue Mar 26 11:17:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BB621F87D1 for ; Tue, 26 Mar 2013 11:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.161 X-Spam-Level: X-Spam-Status: No, score=-104.161 tagged_above=-999 required=5 tests=[AWL=2.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAMYnTY-PszH for ; Tue, 26 Mar 2013 11:17:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8219221F8C48 for ; Tue, 26 Mar 2013 11:17:06 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2QIFhaS000593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Mar 2013 11:15:46 -0700 (PDT) Message-ID: <5151E5CB.6070003@isi.edu> Date: Tue, 26 Mar 2013 11:15:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> 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: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2013 18:17:08 -0000 Hi, Richard, On 3/26/2013 4:39 AM, Scheffenegger, Richard wrote: ... > How about this paragraph following the TSopt text: > > > As TSopt is required for the two mechanisms described in sections 3.3 > and 4.2, once established, every segment of a session - with the > exception of (for a detailed discussion see Section 4.2) - is > REQUIRED to have TSopt sent. If a TCP stopped sending TSopt at any > later time, it would interfere with both PAWS and RTTM mechanism, > that are both based on TSopt. This update to [RFC1323] makes it > explicit, that segments missing the TSopt MAY be dropped by either > end of the session, to alert implementers of the serious > repercussions of not adhering to the timestamp mechanism. If you say that something is REQUIRED, you have to explain what happens when it's absent. So far, you say a segment missing TSopt MAY be dropped "to alert". I don't consider a "drop" an "alert". IMO, this should say: - if missing, MAY drop and MAY be logged - if missing and not dropped, what happens? > The detailed text explaining the is at the end of section 4.2, with the PAWS check. OK. > Do you suggest to move that paragraph forward to the end of section 3.2, where TSopt is defined? I think so; backward references make more sense than opaque forward ones. I think you also need a paragraph to highlight how this changes what was in RFC1323, i.e., "what changed". Joe From prvs=1797e0cfb8=david.borman@quantum.com Tue Mar 26 13:36:21 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF74021F8D7F for ; Tue, 26 Mar 2013 13:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-NlkpYBhRSI for ; Tue, 26 Mar 2013 13:36:16 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 242AC21F8D32 for ; Tue, 26 Mar 2013 13:36:14 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2QKXT0p016087; Tue, 26 Mar 2013 13:36:14 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1bb43u2axg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Mar 2013 13:36:13 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 26 Mar 2013 14:36:07 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Tue, 26 Mar 2013 14:36:11 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKYv2ehkUjAjsyE+NwCGyU9etWZi3OxeAgAEDngCAAG6fgIAAJ0OA Date: Tue, 26 Mar 2013 20:35:27 +0000 Message-ID: References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> <5151E5CB.6070003@isi.edu> In-Reply-To: <5151E5CB.6070003@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.176.229] Content-ID: <05497B505AB6CF40A122F368E0F7A516@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-26_04:2013-03-26, 2013-03-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303260215 Content-Type: text/plain; charset="iso-8859-1" Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2013 20:36:21 -0000 On Mar 26, 2013, at 1:15 PM, Joe Touch wrote: > Hi, Richard, >=20 > On 3/26/2013 4:39 AM, Scheffenegger, Richard wrote: > ... >> How about this paragraph following the TSopt text: >>=20 >>=20 >> As TSopt is required for the two mechanisms described in sections 3.3 >> and 4.2, once established, every segment of a session - with the >> exception of (for a detailed discussion see Section 4.2) - is >> REQUIRED to have TSopt sent. If a TCP stopped sending TSopt at any >> later time, it would interfere with both PAWS and RTTM mechanism, >> that are both based on TSopt. This update to [RFC1323] makes it >> explicit, that segments missing the TSopt MAY be dropped by either >> end of the session, to alert implementers of the serious >> repercussions of not adhering to the timestamp mechanism. >=20 > If you say that something is REQUIRED, you have to explain what happens w= hen it's absent. >=20 > So far, you say a segment missing TSopt MAY be dropped "to alert". I don'= t consider a "drop" an "alert". >=20 > IMO, this should say: > - if missing, MAY drop and MAY be logged > - if missing and not dropped, what happens? How about something like: Once TSopt has been sent or received on a non-SYN packet, TSopt MUST be sent in every non-RST packet for the duration of the connection. If a non-RST packet is received without a TSopt, a TCP MAY drop the packet and send an ACK. A TCP MUST NOT abort a TCP connection if a non-RST packet is received without a TSopt. If a TSopt is received on a connection where TSopt was not negotiated in the initial SYN exchange, the TSopt SHOULD be ignored and the packet processed normally. A bit of history: RFC 1072 had ECHO and ECHO-REPLY, and only talks about sending the ECHO on data packets. RFC 1185 introduced PAWS, though not explicitly by that name, and the described algorithm has the explicit assumption that the ECHO is in every packet. RFC 1323 has that same explicit assumption in section 4.2, which is carried forward to 1323.bis. The coupling of ECHO and ECHO-REPLY into a single TSopt option was done because both options were being sent in every packet, and combining them made processing easier and allowed both TS values to be 32 bit aligned without inserting additional padding. Despite the simplistic statement in the TSopt description in 1323: A TCP may send the Timestamps option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it re- ceived a TSopt in the initial segment for the connection. the assumption was that once enabled, TSopt would be sent in every packet,as stated in in section 4.2 for PAWS. >=20 >> The detailed text explaining the is at the end of section 4.2, wit= h the PAWS check. >=20 > OK. >=20 >> Do you suggest to move that paragraph forward to the end of section 3.2,= where TSopt is defined? >=20 > I think so; backward references make more sense than opaque forward ones. >=20 > I think you also need a paragraph to highlight how this changes what was = in RFC1323, i.e., "what changed". That's what appendix F is for, a detailed list of technical and editorial changes from RFC 1323. This a *replacement* for 1323, not just an update to it. It clutters up the document putting in explanations throughout it on why things changed from 1323. The main body should just have the current state of things, with any necessary explanations for someone reading the document for the first time, having never read 1323. Just highlighting that something is a change from 1323 belongs in Appendix F. -David Borman >=20 > Joe ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From rs@netapp.com Wed Mar 27 03:57:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21EB21F90A6 for ; Wed, 27 Mar 2013 03:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.942 X-Spam-Level: X-Spam-Status: No, score=-9.942 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTsnJYEVh4Ka for ; Wed, 27 Mar 2013 03:57:54 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1F33621F909F for ; Wed, 27 Mar 2013 03:57:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,917,1355126400"; d="scan'208";a="34478945" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 27 Mar 2013 03:57:53 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2RAvqhO024827; Wed, 27 Mar 2013 03:57:53 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Wed, 27 Mar 2013 03:57:52 -0700 From: "Scheffenegger, Richard" To: David Borman , Joe Touch Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOJrDdscFonFA9vEavV3WDHbIX35i0uJcAgAJmtwD//47skIAAiLcAgAAIwQCAABHegIAAhmDQgADr3YCAACcQgIAAen9A Date: Wed, 27 Mar 2013 10:57:51 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AD147B@SACEXCMBX02-PRD.hq.netapp.com> References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> <5151E5CB.6070003@isi.edu> 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.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 10:57:55 -0000 Hi David, Joe, I added the text suggested by David, and updated the mentioned paragraphs t= o this text: A TCP MAY send the Timestamp option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in other segments only if it received a TSopt in the initial or segment for the connection. Once TSopt has been sent or received on a non- packet, TSopt MUST be sent in every non- packet for the duration of the connection. If a non- packet is received without a TSopt, a TCP MAY drop the packet and send an . A TCP MUST NOT abort a TCP connection if a non- packet is received without a TSopt. If a TSopt is received on a connection where TSopt was not negotiated in the initial three-way handshake, the TSopt SHOULD be ignored and the packet processed normally. In the case of crossing segments where one contains a TSopt and the other doesn't, both sides SHOULD put a TSopt in the segment. TSopt is required for the two mechanisms described in sections 3.3 and 4.2. If a TCP stopped sending TSopt at any time during an established session, it interferes with both the PAWS and RTTM mechanisms. This update to [RFC1323] describes explicitly the previous implicit assumption. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > David Borman > Sent: Dienstag, 26. M=E4rz 2013 21:35 > To: Joe Touch > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >=20 >=20 > On Mar 26, 2013, at 1:15 PM, Joe Touch > wrote: >=20 > > Hi, Richard, > > > > On 3/26/2013 4:39 AM, Scheffenegger, Richard wrote: > > ... > >> How about this paragraph following the TSopt text: > >> > >> > >> As TSopt is required for the two mechanisms described in sections > 3.3 > >> and 4.2, once established, every segment of a session - with the > >> exception of (for a detailed discussion see Section 4.2) - i= s > >> REQUIRED to have TSopt sent. If a TCP stopped sending TSopt at any > >> later time, it would interfere with both PAWS and RTTM mechanism, > >> that are both based on TSopt. This update to [RFC1323] makes it > >> explicit, that segments missing the TSopt MAY be dropped by either > >> end of the session, to alert implementers of the serious > >> repercussions of not adhering to the timestamp mechanism. >=20 > > > > If you say that something is REQUIRED, you have to explain what happens > when it's absent. >=20 > > > > So far, you say a segment missing TSopt MAY be dropped "to alert". I > don't consider a "drop" an "alert". > > > > IMO, this should say: > > - if missing, MAY drop and MAY be logged > > - if missing and not dropped, what happens? >=20 > How about something like: > Once TSopt has been sent or received on a non-SYN packet, TSopt > MUST be sent in every non-RST packet for the duration of the > connection. If a non-RST packet is received without a TSopt, a > TCP MAY drop the packet and send an ACK. A TCP MUST NOT abort a > TCP connection if a non-RST packet is received without a TSopt. >=20 > If a TSopt is received on a connection where TSopt was not > negotiated in the initial SYN exchange, the TSopt SHOULD > be ignored and the packet processed normally. >=20 > A bit of history: RFC 1072 had ECHO and ECHO-REPLY, and only talks about > sending the ECHO on data packets. RFC 1185 introduced PAWS, though not > explicitly by that name, and the described algorithm has the explicit > assumption that the ECHO is in every packet. RFC > 1323 has that same explicit assumption in section 4.2, which is carried > forward to 1323.bis. The coupling of ECHO and ECHO-REPLY into a single > TSopt option was done because both options were being sent in every > packet, and combining them made processing easier and allowed both TS > values to be 32 bit aligned without inserting additional padding. >=20 > Despite the simplistic statement in the TSopt description in 1323: >=20 > A TCP may send the Timestamps option (TSopt) in an initial > segment (i.e., segment containing a SYN bit and no ACK > bit), and may send a TSopt in other segments only if it re- > ceived a TSopt in the initial segment for the connection. >=20 > the assumption was that once enabled, TSopt would be sent in every > packet,as stated in in section 4.2 for PAWS. >=20 >=20 > > > >> The detailed text explaining the is at the end of section 4.2, > with the PAWS check. > > > > OK. > > > >> Do you suggest to move that paragraph forward to the end of section > 3.2, where TSopt is defined? > > > > I think so; backward references make more sense than opaque forward > ones. > > > > I think you also need a paragraph to highlight how this changes what wa= s > in RFC1323, i.e., "what changed". >=20 > That's what appendix F is for, a detailed list of technical and editorial > changes from RFC 1323. This a *replacement* for 1323, not just an update > to it. It clutters up the document putting in explanations throughout it > on why things changed from 1323. > The main body should just have the current state of things, with any > necessary explanations for someone reading the document for the first > time, having never read 1323. Just highlighting that something is a > change from 1323 belongs in Appendix F. >=20 > -David Borman > > > > Joe >=20 > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any > disclosure, copying, or further distribution of confidential information > is not permitted unless such privilege is explicitly granted in writing b= y > Quantum. Quantum reserves the right to have electronic communications, > including email and attachments, sent across its networks filtered throug= h > anti virus and spam software programs and retain such messages in order t= o > comply with applicable data security and retention requirements. Quantum > is not responsible for the proper and complete transmission of the > substance of this communication or for any delay in its receipt. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From shep@xplot.org Wed Mar 27 05:47:17 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA621F8B0A for ; Wed, 27 Mar 2013 05:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlFCMeusik2F for ; Wed, 27 Mar 2013 05:47:17 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id 105A721F8AE8 for ; Wed, 27 Mar 2013 05:47:16 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1UKpkX-0000g5-00; Wed, 27 Mar 2013 08:46:41 -0400 From: Tim Shepard To: "Scheffenegger, Richard" In-reply-to: Your message of Wed, 27 Mar 2013 10:57:51 -0000. <012C3117EDDB3C4781FD802A8C27DD4F24AD147B@SACEXCMBX02-PRD.hq.netapp.com> Date: Wed, 27 Mar 2013 08:46:41 -0400 Message-Id: Sender: Tim Shepard Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 12:47:17 -0000 > A TCP MAY send the Timestamp option (TSopt) in an initial > segment (i.e., segment containing a SYN bit and no ACK bit), and MAY > send a TSopt in other segments only if it received a TSopt in the > initial or segment for the connection. > > Once TSopt has been sent or received on a non- packet, TSopt > MUST be sent in every non- packet for the duration of the > connection. [...] I still find that confusing. It sounds like it is suggesting to an implementor that in addition to the normal sort of negotiation of the TSopt on the SYN and SYN ACK exchange, they need to also watch for whether a TSopt has been received on the first non-SYN packet. It makes it sound like it is OK to negotiate use of TSopt on the first two packets, but then never send the option again on any of the normal packets. Is that really what we want here? -Tim Shepard shep@alum.mit.edu From rs@netapp.com Wed Mar 27 06:16:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ABF21F910A for ; Wed, 27 Mar 2013 06:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLGT3i5K8WCq for ; Wed, 27 Mar 2013 06:16:50 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1F20F21F90CE for ; Wed, 27 Mar 2013 06:16:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,919,1355126400"; d="scan'208";a="34508507" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 27 Mar 2013 06:16:49 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2RDGmjg024603; Wed, 27 Mar 2013 06:16:48 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Wed, 27 Mar 2013 06:16:47 -0700 From: "Scheffenegger, Richard" To: Tim Shepard Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKukwzu0MSRIY4kOsCK2RdOWG6Ji5gMxA Date: Wed, 27 Mar 2013 13:16:47 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AD1D9B@SACEXCMBX02-PRD.hq.netapp.com> References: Your message of Wed, 27 Mar 2013 10:57:51 -0000. <012C3117EDDB3C4781FD802A8C27DD4F24AD147B@SACEXCMBX02-PRD.hq.netapp.com> 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.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 13:16:55 -0000 Hi Tim, Well, I don't know how to improve this wording so that it is still optional= for any TCP implementing 1323bis, to not use TS, but use WS... The two MAYs in the first paragraph seem to accomplish that. Perhaps the first sentence in the 2nd paragraph should be something like: Once TSopt has been successfully negotiated in the initial three-way handsh= ake (all of the , and first contained a TSopt), TSopt = MUST be send in every non- segment for the duration of the connection. ? However, that wording might cause an implementer to use much more state tha= t currently to track this. Note that TSopt may be successfully delivered on the forward path, but some= middlebox might be stripping it from the return path. So the receiver shou= ld really only start sending TSopt after the 3WHS was received with T= Sopt.=20 Richard Scheffenegger > -----Original Message----- > From: Tim Shepard [mailto:shep@xplot.org] On Behalf Of Tim Shepard > Sent: Mittwoch, 27. M=E4rz 2013 13:47 > To: Scheffenegger, Richard > Cc: David Borman; Joe Touch; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt >=20 >=20 >=20 > > A TCP MAY send the Timestamp option (TSopt) in an initial > > segment (i.e., segment containing a SYN bit and no ACK bit), and MAY > > send a TSopt in other segments only if it received a TSopt in the > > initial or segment for the connection. > > > > Once TSopt has been sent or received on a non- packet, TSopt > > MUST be sent in every non- packet for the duration of the > > connection. [...] >=20 >=20 > I still find that confusing. It sounds like it is suggesting to an > implementor that in addition to the normal sort of negotiation of the > TSopt on the SYN and SYN ACK exchange, they need to also watch for whethe= r > a TSopt has been received on the first non-SYN packet. It makes it sound > like it is OK to negotiate use of TSopt on the first two packets, but the= n > never send the option again on any of the normal packets. >=20 > Is that really what we want here? >=20 > -Tim Shepard > shep@alum.mit.edu From mallman@icir.org Wed Mar 27 06:39:06 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B08C21F8EED for ; Wed, 27 Mar 2013 06:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zugu3E0Bd4UX for ; Wed, 27 Mar 2013 06:39:05 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id B360321F8ED3 for ; Wed, 27 Mar 2013 06:39:05 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RDcuQ3019858; Wed, 27 Mar 2013 06:38:56 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E245BD34239; Wed, 27 Mar 2013 09:38:57 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <514B54A5.4060107@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Takin' Care of Business X-URL-0: http://www.icir.org/mallman-files/Document2002.html X-URL-1: http://www.icir.org/mallman-files/Document23828.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma63089-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 09:38:57 -0400 Sender: mallman@icir.org Message-Id: <20130327133857.E245BD34239@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 13:39:06 -0000 ----------ma63089-1 Content-Type: text/plain Content-Disposition: inline [This message has been sitting here mostly written for a long time now. I have lost track of the discussion. The generic subject lines don't really help me tease all this apart. I am hoping a new draft will be forthcoming so I can re-sync.] I want to pop up a level here. I think the important thing in all of this 1323bis business is to downplay the need for TS. - First, there is no evidence that RTTM buys you any better RTO estimator (and there is evidence that it does not) so there is no reason to use TS to grab more RTT samples per RTT. (My druthers would be to relegate RTTM to an appendix. I.e., "here is something we thought would help, but it doesn't really change much and while you're free to still use it as it doesn't much hurt the RTO, we're no longer recommending it".) - Second, in the absence of RTTM that leaves PAWS as the sole user of timestamps. But, just because we use WS does not mean we need PAWS and so we should divorce the use of TS from the use of WS. Obviously, at some point there is a need for PAWS and so we have to engineer a mechanism to enable TS when needed. That might mean negotiating in the SYN. It might not. There are tradeoffs. But, ultimately this need will arise quite rarely and so probably the specifics are not crucial. Its easy to focus on the nitty-gritty of mechanism (I do all the time!), but lets also keep the big picture in mind, too. allman ----------ma63089-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFS9nEACgkQWyrrWs4yIs7vswCfVq2W9BZxVERdebW62nMO/Org 5wMAmgOe7MYHfnlksqlkfoEMRL/tmsvM =0sa7 -----END PGP SIGNATURE----- ----------ma63089-1-- From shep@xplot.org Wed Mar 27 06:51:26 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7CF21F907C for ; Wed, 27 Mar 2013 06:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLtC4oLkGFwk for ; Wed, 27 Mar 2013 06:51:22 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id 187A421F9057 for ; Wed, 27 Mar 2013 06:51:21 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1UKqkf-0001On-00; Wed, 27 Mar 2013 09:50:53 -0400 From: Tim Shepard To: mallman@icir.org In-reply-to: Your message of Wed, 27 Mar 2013 09:38:57 -0400. <20130327133857.E245BD34239@lawyers.icir.org> Date: Wed, 27 Mar 2013 09:50:53 -0400 Message-Id: Sender: Tim Shepard Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 13:51:26 -0000 > Obviously, at some point there is a need for PAWS and so we have to > engineer a mechanism to enable TS when needed. That might mean Do you think that such a mechanism would need to work with the existing installed base? Or do you think the existing installed base will soon be irrelevant and we can engineer such a mechanism which does not achieve PAWS when interoperating with the existing installed base? -Tim Shepard shep@alum.mit.edu From john@jlc.net Wed Mar 27 07:07:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EC221F9131 for ; Wed, 27 Mar 2013 07:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVtawOtNFFcq for ; Wed, 27 Mar 2013 07:07:06 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9977921F9130 for ; Wed, 27 Mar 2013 07:07:06 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8435A33C20; Wed, 27 Mar 2013 10:07:06 -0400 (EDT) Date: Wed, 27 Mar 2013 10:07:06 -0400 From: John Leslie To: Mark Allman Message-ID: <20130327140706.GH29513@verdi> References: <514B54A5.4060107@isi.edu> <20130327133857.E245BD34239@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20130327133857.E245BD34239@lawyers.icir.org> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 14:07:07 -0000 Mark Allman wrote: >=20 > I want to pop up a level here. I think the important thing in all of > this 1323bis business is to downplay the need for TS. =20 I'd be willing to "deprecate" it entirely... > - First, there is no evidence that RTTM buys you any better RTO > estimator (and there is evidence that it does not) so there is no > reason to use TS to grab more RTT samples per RTT. =20 That's the way I see it too. > (My druthers would be to relegate RTTM to an appendix. I.e., "here > is something we thought would help, but it doesn't really change > much and while you're free to still use it as it doesn't much hurt > the RTO, we're no longer recommending it".) If we do that, I think we need to note some of the problems we've found since RFC 1323 was published. > - Second, in the absence of RTTM that leaves PAWS as the sole user of > timestamps. But, just because we use WS does not mean we need PAWS > and so we should divorce the use of TS from the use of WS. > Obviously, at some point there is a need for PAWS and so we have to > engineer a mechanism to enable TS when needed. That might mean > negotiating in the SYN. It might not. There are tradeoffs. But, > ultimately this need will arise quite rarely and so probably the > specifics are not crucial. IMHO, PAWS use of TS must remain possible (in the absence of middlebox damage, that is) -- but I agree it may not be the best way to protect against wrapped sequence numbers. > Its easy to focus on the nitty-gritty of mechanism (I do all the time!), > but lets also keep the big picture in mind, too. I'm pretty sure that the TS option can't be "fixed" enough to be problem-free -- if we believe there is a need for something it does, we're probably better off designing a (new) replacement option. (YMMV, obviously...) -- John Leslie From prvs=1798b84bb6=david.borman@quantum.com Wed Mar 27 07:40:13 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733BB21F91A1 for ; Wed, 27 Mar 2013 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxkuDmyJO5w9 for ; Wed, 27 Mar 2013 07:40:12 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id D6BCF21F9172 for ; Wed, 27 Mar 2013 07:40:11 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2REcPfb008528; Wed, 27 Mar 2013 07:40:08 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1bc1png509-19 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 07:40:07 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 27 Mar 2013 08:39:19 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 27 Mar 2013 08:39:27 -0600 From: David Borman To: "" Thread-Topic: timestamps usage (was Re: [tcpm] 1323bis - preparing for WGLC) Thread-Index: AQHOKvCe4S+Ys3HphU6Y5iCHHx+5mpi6AHeA Date: Wed, 27 Mar 2013 14:38:41 +0000 Message-ID: References: <20130327133857.E245BD34239@lawyers.icir.org> In-Reply-To: <20130327133857.E245BD34239@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <60FABCD639C6694E9F363F66756C7588@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_04:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=5 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270113 Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 14:40:13 -0000 On Mar 27, 2013, at 8:38 AM, Mark Allman wrote: >=20 > [This message has been sitting here mostly written for a long time now. > I have lost track of the discussion. The generic subject lines don't > really help me tease all this apart. I am hoping a new draft will be > forthcoming so I can re-sync.] >=20 > I want to pop up a level here. I think the important thing in all of > this 1323bis business is to downplay the need for TS.=20=20 >=20 > - First, there is no evidence that RTTM buys you any better RTO > estimator (and there is evidence that it does not) so there is no > reason to use TS to grab more RTT samples per RTT.=20 I've said it before, and I'll say it again: The worst case scenario using TS is equivalent to the best case scenario for the Karn algorithm; that's that TS buys you. As long as you are making forward progress, with TS you are guaranteed to be able to get at least one valid RTT sample per RTT, whenever new data is acknowledged, even in the face of packet loss. With the Karn algorithm over a lossy connection, in the worst case scenario you never get any valid RTT samples, if they keep getting invalidated due to retransmissions. For lossy connections, that distinction is probably important. -David Borman >=20 > (My druthers would be to relegate RTTM to an appendix. I.e., "here > is something we thought would help, but it doesn't really change > much and while you're free to still use it as it doesn't much hurt > the RTO, we're no longer recommending it".) >=20 > - Second, in the absence of RTTM that leaves PAWS as the sole user of > timestamps. But, just because we use WS does not mean we need PAWS > and so we should divorce the use of TS from the use of WS. > Obviously, at some point there is a need for PAWS and so we have to > engineer a mechanism to enable TS when needed. That might mean > negotiating in the SYN. It might not. There are tradeoffs. But, > ultimately this need will arise quite rarely and so probably the > specifics are not crucial. >=20 > Its easy to focus on the nitty-gritty of mechanism (I do all the time!), > but lets also keep the big picture in mind, too. >=20 > allman >=20 >=20 >=20 ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From prvs=1798b84bb6=david.borman@quantum.com Wed Mar 27 07:45:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A8B21F914B for ; Wed, 27 Mar 2013 07:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaUZuvH-M2fc for ; Wed, 27 Mar 2013 07:44:58 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4F921F912B for ; Wed, 27 Mar 2013 07:44:58 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2REimdW014401; Wed, 27 Mar 2013 07:44:55 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0b-000ceb01.pphosted.com with ESMTP id 1bay3q2tjc-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 07:44:54 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 27 Mar 2013 08:44:42 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 27 Mar 2013 08:44:20 -0600 From: David Borman To: Tim Shepard Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKvmQsGvW8DgEG0q0fmqosL0RBg== Date: Wed, 27 Mar 2013 14:43:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A190D0EC313A441AFD6E69BB5A9613D@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_04:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270114 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 14:45:10 -0000 On Mar 27, 2013, at 7:46 AM, Tim Shepard wrote: >=20 >=20 >> A TCP MAY send the Timestamp option (TSopt) in an initial >> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY >> send a TSopt in other segments only if it received a TSopt in the >> initial or segment for the connection. >>=20 >> Once TSopt has been sent or received on a non- packet, TSopt >> MUST be sent in every non- packet for the duration of the >> connection. [...] >=20 >=20 > I still find that confusing. It sounds like it is suggesting to an > implementor that in addition to the normal sort of negotiation of the > TSopt on the SYN and SYN ACK exchange, they need to also watch for > whether a TSopt has been received on the first non-SYN packet. It > makes it sound like it is OK to negotiate use of TSopt on the first > two packets, but then never send the option again on any of the normal > packets. >=20 > Is that really what we want here? Yes, that is late enablement of TSopt, i.e., negotiate it on the SYNs, and then not use TSopt until later in the connection. But once a TSopt has been sent in either direction, it must be enabled for the duration of the connection. What we don't want is TSopt being turned off later in the connection. The intention is that this is compatible with implementations that don't support late enablement, i.e. either side can send TSopt in all their packets, and then the other side must also send TSopt. So, an implementor doesn't need to "watch for whether a TSopt has been received on the first non-SYN packet," unless they are putting in support for late enablement of TSopt. >=20 > -Tim Shepard > shep@alum.mit.edu > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From jakob.heitz@ericsson.com Wed Mar 27 08:01:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CE121F91CA for ; Wed, 27 Mar 2013 08:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOtS2UkZLJeG for ; Wed, 27 Mar 2013 08:01:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C071D21F91C9 for ; Wed, 27 Mar 2013 08:01:25 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-89-515309c5374f Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A2.CB.02411.5C903515; Wed, 27 Mar 2013 16:01:25 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Wed, 27 Mar 2013 11:01:24 -0400 From: Jakob Heitz To: "" Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKvB8gQZWAuIB6Ue9UTV+nEIaapi5ogRG Date: Wed, 27 Mar 2013 15:01:23 +0000 Message-ID: <48FA04E3-1666-49E9-9AD7-CDD75915F19E@ericsson.com> References: <514B54A5.4060107@isi.edu> ,<20130327133857.E245BD34239@lawyers.icir.org> In-Reply-To: <20130327133857.E245BD34239@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXSPn+5RzuBAg+aLIhavfm9gtZi2ZhqT xbaT85ks1v2Zy+LA4vHv0E1mjyVLfjJ57H6/lcWj9/la9gCWKC6blNSczLLUIn27BK6MxoO3 mAse81U0b9vN1MC4nLuLkZNDQsBE4vrVm+wQtpjEhXvr2boYuTiEBI4wStw5tZkJwlnOKLH+ 0ScmkCo2AR2Jb9e7mEFsEQFtidWft7OC2MwCRRKf7z0Bs4UFfCS2rPjHDlHjK7H91AMmCNtI 4suaq2A1LAKqEu+v9YPFeQXsJdbvbWUBsYUEwiVmbl/LCGJzClhJrH65D2wOI9B130+tYYLY JS5x68l8JoirBSSW7DnPDGGLSrx8/A/qHh2JBbs/sUHY2hLLFr5mhtglKHFy5hOWCYyis5CM moWkZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQIjJtjEmyOOxgXfLI8xCjNwaIkzhvqeiFASCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2O71sQ1qpzzHirZz1Zd6hoQI65cHnxyUb7KYoki9tmP Hm4SM3/7pvNA9B6HKq2vlisYHYoEk9e3zdH4fUt35udj2auehj3Puip2PZHj18xX13rD/E6Y pJj4HvJ2T/GOEb6yQY03jnX/I3WJJJYAwRWHU6+V6u0RtGN/+eDTt9nGSy73nCvp11RiKc5I NNRiLipOBABdVl/8aQIAAA== Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 15:01:27 -0000 RTO is 1 second. RTT doesn't matter, because it's always much less. -- Jakob Heitz. On Mar 27, 2013, at 6:39 AM, "Mark Allman" wrote: >=20 > [This message has been sitting here mostly written for a long time now. > I have lost track of the discussion. The generic subject lines don't > really help me tease all this apart. I am hoping a new draft will be > forthcoming so I can re-sync.] >=20 > I want to pop up a level here. I think the important thing in all of > this 1323bis business is to downplay the need for TS. =20 >=20 > - First, there is no evidence that RTTM buys you any better RTO > estimator (and there is evidence that it does not) so there is no > reason to use TS to grab more RTT samples per RTT. =20 >=20 > (My druthers would be to relegate RTTM to an appendix. I.e., "here > is something we thought would help, but it doesn't really change > much and while you're free to still use it as it doesn't much hurt > the RTO, we're no longer recommending it".) >=20 > - Second, in the absence of RTTM that leaves PAWS as the sole user of > timestamps. But, just because we use WS does not mean we need PAWS > and so we should divorce the use of TS from the use of WS. > Obviously, at some point there is a need for PAWS and so we have to > engineer a mechanism to enable TS when needed. That might mean > negotiating in the SYN. It might not. There are tradeoffs. But, > ultimately this need will arise quite rarely and so probably the > specifics are not crucial. >=20 > Its easy to focus on the nitty-gritty of mechanism (I do all the time!), > but lets also keep the big picture in mind, too. >=20 > allman >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Wed Mar 27 08:04:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B3321F907C for ; Wed, 27 Mar 2013 08:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbSRHH8ynHc7 for ; Wed, 27 Mar 2013 08:04:14 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id F20EF21F905C for ; Wed, 27 Mar 2013 08:04:13 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RF48TS029236; Wed, 27 Mar 2013 08:04:08 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B9F1ED352FA; Wed, 27 Mar 2013 11:03:54 -0400 (EDT) To: Jakob Heitz From: Mark Allman In-Reply-To: <48FA04E3-1666-49E9-9AD7-CDD75915F19E@ericsson.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document95028.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2650-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 11:03:54 -0400 Sender: mallman@icir.org Message-Id: <20130327150354.B9F1ED352FA@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:04:14 -0000 ----------ma2650-1 Content-Type: text/plain Content-Disposition: inline > RTO is 1 second. (not in practice) ----------ma2650-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTCloACgkQWyrrWs4yIs6PmACcDd2LaWPtfUVb8bxfexg78/SH 6+cAnA4vMx/N6QFAouUbV1BYlGSH7x2P =dTb4 -----END PGP SIGNATURE----- ----------ma2650-1-- From mallman@icir.org Wed Mar 27 08:04:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3AA21F905C for ; Wed, 27 Mar 2013 08:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U30+wRLNsodb for ; Wed, 27 Mar 2013 08:04:14 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id F13AB21F8C09 for ; Wed, 27 Mar 2013 08:04:13 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RF48If029237; Wed, 27 Mar 2013 08:04:08 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id DA73CD352CD; Wed, 27 Mar 2013 11:03:20 -0400 (EDT) To: David Borman From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2616-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 11:03:20 -0400 Sender: mallman@icir.org Message-Id: <20130327150320.DA73CD352CD@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:04:14 -0000 ----------ma2616-1 Content-Type: text/plain Content-Disposition: inline > I've said it before, and I'll say it again: > > The worst case scenario using TS is equivalent to the best case > scenario for the Karn algorithm; that's that TS buys you. > > As long as you are making forward progress, with TS you are guaranteed > to be able to get at least one valid RTT sample per RTT, whenever new > data is acknowledged, even in the face of packet loss. With the Karn > algorithm over a lossy connection, in the worst case scenario you > never get any valid RTT samples, if they keep getting invalidated due > to retransmissions. > > For lossy connections, that distinction is probably important. Let me say two things ... (1) Requiring 10 bytes of every TCP packet ever transmitted to guard against a pathology seems pretty dubious to me. The 'net worked and works without timestamps. (2) This: "in the worst case scenario you never get any valid RTT samples, if they keep getting invalidated due to retransmissions" is either wrong or a red herring. I.e., recall that you backoff the RTO until you can get a new segment and its ACK through---at which point you have an RTT sample and you can get rid of the backoff. So, there is a mechanism to hack the RTO in the absence of RTT samples. I.e., that leaves a case like where every segment is dropped on its first transmission and makes it through on retransmission. And, that doesn't change with backing off the RTO. In this case it just isn't at all that this RTT sample is at all important in getting us to a better RTO. allman ----------ma2616-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTCjgACgkQWyrrWs4yIs6y+gCeJR2ClD2RM5NgJdXwRwC0UwgH 7CYAn3rVXSwM19aFMZuptJeXBpmO9F1y =AQgX -----END PGP SIGNATURE----- ----------ma2616-1-- From mallman@icir.org Wed Mar 27 08:04:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9021F8C09 for ; Wed, 27 Mar 2013 08:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA5MBdO7tMZf for ; Wed, 27 Mar 2013 08:04:14 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id F145C21F8C45 for ; Wed, 27 Mar 2013 08:04:13 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RF48L5029235; Wed, 27 Mar 2013 08:04:08 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 63D77D35055; Wed, 27 Mar 2013 10:50:07 -0400 (EDT) To: Tim Shepard From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document44012.docx X-URL-1: http://www.icir.org/mallman-files/Document89340.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma1823-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 10:50:07 -0400 Sender: mallman@icir.org Message-Id: <20130327145007.63D77D35055@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:04:15 -0000 ----------ma1823-1 Content-Type: text/plain Content-Disposition: inline > > Obviously, at some point there is a need for PAWS and so we have to > > engineer a mechanism to enable TS when needed. That might mean > > Do you think that such a mechanism would need to work with the > existing installed base? Or do you think the existing installed base > will soon be irrelevant and we can engineer such a mechanism which > does not achieve PAWS when interoperating with the existing installed > base? I think you could do either. I think you get some skid greasing by leveraging the current scheme with some tweaks to allow for the TS to be used without requiring it to be used for the entire connection. allman ----------ma1823-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTBx8ACgkQWyrrWs4yIs7kKACfXGee4FXI2JcPamdDFN71oobG ovgAn2dnDjs5bhNyymBaUAYEtHN6lWnM =SOAl -----END PGP SIGNATURE----- ----------ma1823-1-- From mallman@icir.org Wed Mar 27 08:04:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AA221F8C09 for ; Wed, 27 Mar 2013 08:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-F6BWt4hMgT for ; Wed, 27 Mar 2013 08:04:14 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id F142A21F8C35 for ; Wed, 27 Mar 2013 08:04:13 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RF480U029234; Wed, 27 Mar 2013 08:04:08 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4D080D3500C; Wed, 27 Mar 2013 10:48:43 -0400 (EDT) To: John Leslie From: Mark Allman In-Reply-To: <20130327140706.GH29513@verdi> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document43765.doc X-URL-1: http://www.icir.org/mallman-files/Document73856.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma1737-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 10:48:43 -0400 Sender: mallman@icir.org Message-Id: <20130327144843.4D080D3500C@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:04:15 -0000 ----------ma1737-1 Content-Type: text/plain Content-Disposition: inline > > (My druthers would be to relegate RTTM to an appendix. I.e., "here > > is something we thought would help, but it doesn't really change > > much and while you're free to still use it as it doesn't much hurt > > the RTO, we're no longer recommending it".) > > If we do that, I think we need to note some of the problems we've > found since RFC 1323 was published. We can simply say RTTM does not help. Evidence: Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. Proceedings of the ACM SIGCOMM Technical Symposium, Cambridge, MA, September 1999. http://www.icir.org/mallman/papers/estimation.ps We learned that since the publication of 1323. And, bis documents are supposed to reflect what we have learned (either in terms of specification looseness or ambiguity or in terms of technical lessons). > > - Second, in the absence of RTTM that leaves PAWS as the sole user of > > timestamps. But, just because we use WS does not mean we need PAWS > > and so we should divorce the use of TS from the use of WS. > > Obviously, at some point there is a need for PAWS and so we have to > > engineer a mechanism to enable TS when needed. That might mean > > negotiating in the SYN. It might not. There are tradeoffs. But, > > ultimately this need will arise quite rarely and so probably the > > specifics are not crucial. > > IMHO, PAWS use of TS must remain possible (in the absence of middlebox > damage, that is) -- but I agree it may not be the best way to protect > against wrapped sequence numbers. My hit is that the sequence space isn't big enough for the windows afforded by large WS factors. So, we need some additional protection against wrapped sequence space when we (a) actually wrap and (b) are transmitting quite fast. The current mechanism we have is PAWS and that in turn is based on the timestamp option. So, it seems to me the path of least resistance is to tweak when the timestamp option is used. Now, > > Its easy to focus on the nitty-gritty of mechanism (I do all the time!), > > but lets also keep the big picture in mind, too. > > I'm pretty sure that the TS option can't be "fixed" enough to be > problem-free -- if we believe there is a need for something it does, > we're probably better off designing a (new) replacement option. ... this is also a possibility. I am sure a 4 or 6 byte option would get us the same thing as PAWS in less space. But, by doing this we lose the greasing of the skids TS gives us. And, in the infrequent cases we really need PAWS the bytes might not matter. Also, note, that the TS option has been used for other things. And, that seems fine to me. If you want to use Eifel or if more RTT samples helps some delay-based CC scheme or whatnot then great, use timestamps. But, turning on TS without an actual tangible reason (i.e., just because you want to scale the window) is highly dubious. allman ----------ma1737-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTBssACgkQWyrrWs4yIs6tIwCfZqC819m1SOCUmWq9dky/IDQQ CrsAn1/E+BFoynxc1WUJhQLy9vCxKqRs =cdwl -----END PGP SIGNATURE----- ----------ma1737-1-- From jakob.heitz@ericsson.com Wed Mar 27 08:05:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943ED21F91CD for ; Wed, 27 Mar 2013 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzZrlzkZmLcv for ; Wed, 27 Mar 2013 08:05:54 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0668521F91C6 for ; Wed, 27 Mar 2013 08:05:53 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-ee-51530ad1ac42 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 58.0C.02411.1DA03515; Wed, 27 Mar 2013 16:05:53 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Wed, 27 Mar 2013 11:05:53 -0400 From: Jakob Heitz To: "" Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKvxYlRUvAW4us0uDz+fZRFiSKZi5oy3K Date: Wed, 27 Mar 2013 15:05:52 +0000 Message-ID: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> References: <48FA04E3-1666-49E9-9AD7-CDD75915F19E@ericsson.com> ,<20130327150354.B9F1ED352FA@lawyers.icir.org> In-Reply-To: <20130327150354.B9F1ED352FA@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXRPiO5FruBAg9+X9Cxe/d7AajFtzTQm i20n5zNZrPszl8WBxePfoZvMHkuW/GTy2P1+K4tH7/O17AEsUVw2Kak5mWWpRfp2CVwZJ38f ZCw4yFjx/Xo/UwNjL2MXIyeHhICJxMJtU9ghbDGJC/fWs3UxcnEICRxhlHj2+j87hLOcUWLB +xY2kCo2AR2Jb9e7mEFsEQFtidWft7OC2MwCRRKf7z0Bs4UFfCQed91kh6jxlXi6+i9UvZHE tQkrmEBsFgFViZ43N8DivAL2EvMO7wCrFxIokPh2YSILiM0pYCVx+P02sBpGoOu+n1rDBLFL XOLWk/lMEFcLSCzZc54ZwhaVePn4H9Q9OhILdn9ig7C1JZYtfA21S1Di5MwnLBMYRWchGTUL ScssJC2zkLQsYGRZxchRWpxalptuZLiJERg3xyTYHHcwLvhkeYhRmoNFSZw31PVCgJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbG6Fn8EYJ7eM6lOwo59L5raWj7FeD05Krl6Ug54U5JxfWL hNKU7KSsBLwczGsmZPItmh+479Oy9n95VzVmr1ny8sQSpdI/l6ecsTjP1jBte0U8g5l2Fs8P fQa+qc7GB2ZO/7ogjuntVntBxia1a4dDl7zOXZ0cGbT88bqj7G8q3+sYP88uP82pxFKckWio xVxUnAgA+toIe2kCAAA= Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 15:05:54 -0000 What is it in practice? -- Jakob Heitz. On Mar 27, 2013, at 8:04 AM, "Mark Allman" wrote: >=20 >> RTO is 1 second. >=20 > (not in practice) >=20 >=20 >=20 From mallman@icir.org Wed Mar 27 08:17:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDB621F9230 for ; Wed, 27 Mar 2013 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2olI3divkRyk for ; Wed, 27 Mar 2013 08:17:39 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 881BB21F919A for ; Wed, 27 Mar 2013 08:17:39 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RFHZ81000524; Wed, 27 Mar 2013 08:17:35 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7F3FDD35AE3; Wed, 27 Mar 2013 11:17:35 -0400 (EDT) To: Jakob Heitz From: Mark Allman In-Reply-To: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document88109.doc X-URL-1: http://www.icir.org/mallman-files/Document78603.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma3471-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 11:17:35 -0400 Sender: mallman@icir.org Message-Id: <20130327151735.7F3FDD35AE3@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:17:40 -0000 ----------ma3471-1 Content-Type: text/plain Content-Disposition: inline > What is it in practice? I don't have good data at my finger tips, but I think it is pretty well known that the 1sec min is violated routinely and the min is often a couple hundred msec. (What we don't know is the implications of this change. We found that there is a pretty fundamental tradeoff between making the RTO aggressive and taking more spurious RTOs. Many times when I have talked with folks who advocate dropping the min they are solely focused on needed RTOs taking less time. Well, for needed RTOs you can be as aggressive as you want and show improvement. However, that neglects the impact of unneeded RTOs which drop the cwnd to one segment. I have never seen anyone do a nice study of both sides of this equation.) allman ----------ma3471-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTDY8ACgkQWyrrWs4yIs65TACfZBnYeoauHJ7FrxegAc5gsVFP puMAn3E+0aIacNm/bqSvhbCvHch+x77y =OAJ5 -----END PGP SIGNATURE----- ----------ma3471-1-- From touch@isi.edu Wed Mar 27 08:39:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7411B21F91C5 for ; Wed, 27 Mar 2013 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgsdLS7hbNe7 for ; Wed, 27 Mar 2013 08:39:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFBE21F91D4 for ; Wed, 27 Mar 2013 08:39:07 -0700 (PDT) Received: from [192.168.1.92] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2RFc8Du000598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 08:38:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <20130327150320.DA73CD352CD@lawyers.icir.org> Date: Wed, 27 Mar 2013 08:38:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5CF2A4A8-044F-497E-9ADB-744BFD5897DB@isi.edu> References: <20130327150320.DA73CD352CD@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1503) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 15:39:08 -0000 On Mar 27, 2013, at 8:03 AM, Mark Allman wrote: > Let me say two things ... > > (1) Requiring 10 bytes of every TCP packet ever transmitted to guard > against a pathology seems pretty dubious to me. The 'net worked and > works without timestamps. +1 More to the point, 10 bytes of option space, i.e., 25%. Joe From touch@isi.edu Wed Mar 27 08:47:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F65521F91A5 for ; Wed, 27 Mar 2013 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrJIq-iiRiYl for ; Wed, 27 Mar 2013 08:47:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF9C21F91B9 for ; Wed, 27 Mar 2013 08:47:51 -0700 (PDT) Received: from [192.168.1.92] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2RFkwB6010834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 08:47:07 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: Date: Wed, 27 Mar 2013 08:47:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> <5151E5CB.6070003@isi.edu> To: David Borman X-Mailer: Apple Mail (2.1503) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 15:47:52 -0000 On Mar 26, 2013, at 1:35 PM, David Borman = wrote: >> If you say that something is REQUIRED, you have to explain what = happens when it's absent. >=20 >>=20 >> So far, you say a segment missing TSopt MAY be dropped "to alert". I = don't consider a "drop" an "alert". >>=20 >> IMO, this should say: >> - if missing, MAY drop and MAY be logged >> - if missing and not dropped, what happens? >=20 > How about something like: > Once TSopt has been sent or received on a non-SYN packet, TSopt I don't understand this idea - that TSopt can be "activated" for a = connection during the SYN exchange, but not used until sent in a non-SYN = packet? I thought we had converged that - for now - we would assume = that TSopt needed to be in every non-SYN once it was negotiated. So I would suggest: Once TSopt has been successfully negotiated during the SYN exchange, TSopt (continuing below) > MUST be sent in every non-RST packet for the duration of the > connection. If a non-RST packet is received without a TSopt, a > TCP MAY drop the packet and send an ACK. what's being ACK'd? i.e., ACK the last segment successfully received? = could this then be used to 'trick' TCP into sending dup-acks? why send = anything, if you consider this an error? > A TCP MUST NOT abort a > TCP connection if a non-RST packet is received without a TSopt. >=20 > If a TSopt is received on a connection where TSopt was not > negotiated in the initial SYN exchange, the TSopt SHOULD > be ignored and the packet processed normally. The SHOULD should be MUST AFAICT. Same as for any unrecognized option. >> I think you also need a paragraph to highlight how this changes what = was in RFC1323, i.e., "what changed". >=20 > That's what appendix F is for, a detailed list of technical and > editorial changes from RFC 1323. This a *replacement* for 1323, > not just an update to it. It clutters up the document putting > in explanations throughout it on why things changed from 1323. > The main body should just have the current state of things, with > any necessary explanations for someone reading the document for > the first time, having never read 1323. Just highlighting that > something is a change from 1323 belongs in Appendix F. OK. But you should mention that in the intro and perhaps reiterate it in = each section. Right now, it is referenced first in the PAWS intro, but = that's after TSopt. Joe= From touch@isi.edu Wed Mar 27 08:51:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1684F21F91FE for ; Wed, 27 Mar 2013 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMWqFHzTxlgA for ; Wed, 27 Mar 2013 08:50:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7E21F91FD for ; Wed, 27 Mar 2013 08:50:47 -0700 (PDT) Received: from [192.168.1.92] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2RFnbrD019545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 08:49:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: Date: Wed, 27 Mar 2013 08:49:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D7ADA77-0F51-47D3-9847-764CD99A5969@isi.edu> References: To: David Borman X-Mailer: Apple Mail (2.1503) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 15:51:00 -0000 On Mar 27, 2013, at 7:43 AM, David Borman = wrote: >=20 > On Mar 27, 2013, at 7:46 AM, Tim Shepard wrote: >=20 >>=20 >>=20 >>> A TCP MAY send the Timestamp option (TSopt) in an initial >>> segment (i.e., segment containing a SYN bit and no ACK bit), and = MAY >>> send a TSopt in other segments only if it received a TSopt in the >>> initial or segment for the connection. >>>=20 >>> Once TSopt has been sent or received on a non- packet, TSopt >>> MUST be sent in every non- packet for the duration of the >>> connection. [...] >>=20 >>=20 >> I still find that confusing. It sounds like it is suggesting to an >> implementor that in addition to the normal sort of negotiation of the >> TSopt on the SYN and SYN ACK exchange, they need to also watch for >> whether a TSopt has been received on the first non-SYN packet. It >> makes it sound like it is OK to negotiate use of TSopt on the first >> two packets, but then never send the option again on any of the = normal >> packets. >>=20 >> Is that really what we want here? >=20 > Yes, that is late enablement of TSopt, i.e., negotiate it on the SYNs, > and then not use TSopt until later in the connection. Why would that make sense? ... > The intention is that this is compatible with implementations that > don't support late enablement, i.e. either side can send TSopt in all > their packets, and then the other side must also send TSopt. Let's figure out what the protocol ought to do first, then decide = whether it impacts existing implementations. Joe From ycheng@google.com Wed Mar 27 09:23:06 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6721F8FF2 for ; Wed, 27 Mar 2013 09:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCSRCbdU2RfG for ; Wed, 27 Mar 2013 09:23:00 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFD721F8C1A for ; Wed, 27 Mar 2013 09:22:58 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fo12so16044700lab.14 for ; Wed, 27 Mar 2013 09:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=4APs0/+7+htKqPS6XhKdT+wT74hLsYb/9xg6xMdF/Pk=; b=VpNXYn0f/f4TtsXEXXrY+B8VE/75hW5/Gmpi7ePOcaWhcKd8nOQwbekYQ/DSYbCq4d 7MGg4IK6qE5yBP6kFbRB104awzrNCUrN50a2K7gP8BtCQmMNviESHFCdbZYVWMDUjn5S KNIN3H2a81YFPaTQmavSRa9Nfi0vCI/f2N2u0OrNsm+I7Uffv7O8oRJhnN5w/3SK751q q8yGvgzGVWB9oP6zSguHoktjizwQJTeZNUY9y34NoM6YMvr/FUa+tcW13TlfDY7+p0HX 8T5A01OxEUuIL/xaV/gbp/v9DoCNDaKfWlORsmVJMZBc/QGw6oLovl2g31Ahubyfek3Y hNaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=4APs0/+7+htKqPS6XhKdT+wT74hLsYb/9xg6xMdF/Pk=; b=MwxkSJMqCfpddh9OV7gbV1HXQ9E5kBFOsAHlVzX8GmTJxkbUEbbsfbKTy5l41sHBSZ JyLk+ZJ0JhItz3UnWR9PhVPTU1mt6Eh9mPvXmHE/ENW650uXa84mvKEyPCKSG2fmMwbC LMcAGmlo3bIdaoi5TChlGzbV/JEdHNNELnv8AVCfoSYTDal+goqPREOAu92/U9rHn/40 FN/iy4sJCpSNHY7qPuZhozavUtp/eKLdIzHNIg3ZZVKmlr/nw8IRxM8zh//jzAWbjSRs ZDCbOyWiomUzs9GeN6Ys0N6ITtY4XHvcwJpf520frpfpGb/HlsakuyJCW+XAB3DjYFB0 lWjw== X-Received: by 10.112.173.169 with SMTP id bl9mr5745134lbc.37.1364401373852; Wed, 27 Mar 2013 09:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.25.234 with HTTP; Wed, 27 Mar 2013 09:22:33 -0700 (PDT) In-Reply-To: <20130327151735.7F3FDD35AE3@lawyers.icir.org> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> From: Yuchung Cheng Date: Wed, 27 Mar 2013 09:22:33 -0700 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlbA7anW7gyT7rpfigh4KGuInEQQvymVUjwhHhPpUyQB21fvYt8/uFjgWc0+COeZ9VinGavXJpHR1enicDZ2KXLEUn11Khf6/UZ6guzA7DWDcXl/bM15T86aBQKIXDz4a/iBViPYFt8Qd5258oRTxkECe0lY0Pahr5qVlARgR6ULXLwqd9bhSi6bXrxRMetyReHVAYw Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 16:23:06 -0000 On Wed, Mar 27, 2013 at 8:17 AM, Mark Allman wrote: > > > > What is it in practice? > > I don't have good data at my finger tips, but I think it is pretty well > known that the 1sec min is violated routinely and the min is often a > couple hundred msec. For Linux the 4*RTTVAR is lower-bounded at 200ms (due to the common setting of delayed ACK). RTO =3D SRTT + 4*RTTVAR and does not cap RTO at 1sec. Linux samples RTT for every ACK. http://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf Also =93A Performance Study of Loss Detection/Recovery in Real-world TCP Implementations=94, ICNP 2007 > > (What we don't know is the implications of this change. We found that > there is a pretty fundamental tradeoff between making the RTO aggressive > and taking more spurious RTOs. Many times when I have talked with folks > who advocate dropping the min they are solely focused on needed RTOs > taking less time. Well, for needed RTOs you can be as aggressive as you > want and show improvement. However, that neglects the impact of > unneeded RTOs which drop the cwnd to one segment. I have never seen Worse in fact. The acks of original packets after a spurious RTO can trigger a false slow-start storm of inflight packets. with deep buffers this pours way more than BDP into the jammed highway. With timestamp and Eifel this can be detected and stopped early. Without TS this is terrible. Sorry it's rude to not read the entire thread and the document and chime in now. but TS is helpful for RTT samples during loss recovery where RTT varies the most due to congestion. It also key to identify spurious retransmission and is more robust and useful than F-RTO. The former does not require new data available to send at timeout, a luxury that interactive request-response application does not have. I also agree 12 bytes (not 10 b/c of option alignment) is not negligible so a lazy trigger on dubious network condition sounds a great solution to me. > anyone do a nice study of both sides of this equation.) Why don't you do that :) > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mallman@icir.org Wed Mar 27 09:40:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A60021F9133 for ; Wed, 27 Mar 2013 09:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82BkSj0XaXc6 for ; Wed, 27 Mar 2013 09:40:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 81BC921F8C6F for ; Wed, 27 Mar 2013 09:40:35 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RGeSpG011036; Wed, 27 Mar 2013 09:40:28 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0AAF8D37C52; Wed, 27 Mar 2013 12:40:28 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document18754.doc X-URL-1: http://www.icir.org/mallman-files/Document55646.docx X-URL-2: http://www.icir.org/mallman-files/Document90683.pdf X-URL-3: http://www.icir.org/mallman-files/Document12608.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma8442-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 12:40:28 -0400 Sender: mallman@icir.org Message-Id: <20130327164028.0AAF8D37C52@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:40:36 -0000 ----------ma8442-1 Content-Type: text/plain Content-Disposition: inline > Sorry it's rude to not read the entire thread and the document and > chime in now. but TS is helpful for RTT samples during loss recovery > where RTT varies the most due to congestion. Certainly RTTM can get you samples during this period when the Usual Mechanism cannot (although it isn't like without TS it is impossible; it costs more state at the sender, but you can do it). However, our results are that in the aggregate this doesn't impact the efficacy of the estimator. (In fact, if you look back at our path estimation paper you'll see that taking only a *single* RTT sample *per connection* actually isn't too shabby. It isn't the best estimator, but it isn't the worst either. I am not advocating doing this, but it shows that a reasonable estimator does not require fine-grained updating.) > It also key to identify spurious retransmission Sure. If you are using timestamps for something tangible and they are helping you then *fine*. I am not at all suggesting the option go away. I am saying the RTTM scheme is all cost and little-to-no benefit. And, I am saying that PAWS is simply not needed in the vast majority of cases and so it makes more sense to me to be able to turn the TS option when it becomes necessary and not presume it will be needed simply because we scale the window. > I also agree 12 bytes (not 10 b/c of option alignment) (Right- I was being generous in that in theory one could use those bytes for something else.) > > anyone do a nice study of both sides of this equation.) > > Why don't you do that :) If Google has figured out cloning let me know, as I have many, many things that are rattling around my head, but too few cycles to pursue. :-) allman ----------ma8442-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTIPsACgkQWyrrWs4yIs6qaQCgiPGUwuxcyGOW/gSqyYscbxG2 GVwAn2Ktn+mtisHfz2D+zXDZsN7ivC2P =5dSk -----END PGP SIGNATURE----- ----------ma8442-1-- From prvs=1798b84bb6=david.borman@quantum.com Wed Mar 27 10:07:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92B21F9212 for ; Wed, 27 Mar 2013 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpZNo1uGaYVl for ; Wed, 27 Mar 2013 10:07:18 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id A496421F9227 for ; Wed, 27 Mar 2013 10:07:15 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2RH2gig020369; Wed, 27 Mar 2013 10:07:11 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1bc1pngjfb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 10:07:10 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 27 Mar 2013 11:07:01 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 27 Mar 2013 11:07:09 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKw2EgRnnFcmMyU2cO4zDlDw6YQ== Date: Wed, 27 Mar 2013 17:06:21 +0000 Message-ID: References: <3D7ADA77-0F51-47D3-9847-764CD99A5969@isi.edu> In-Reply-To: <3D7ADA77-0F51-47D3-9847-764CD99A5969@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <7CC4EF7FAE740048AB28B0C58C605F70@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_07:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270156 Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard , David Borman Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 17:07:24 -0000 On Mar 27, 2013, at 10:49 AM, Joe Touch wrote: >=20 > On Mar 27, 2013, at 7:43 AM, David Borman wrot= e: >=20 >>=20 >> On Mar 27, 2013, at 7:46 AM, Tim Shepard wrote: >>=20 >>>=20 >>>=20 >>>> A TCP MAY send the Timestamp option (TSopt) in an initial >>>> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY >>>> send a TSopt in other segments only if it received a TSopt in the >>>> initial or segment for the connection. >>>>=20 >>>> Once TSopt has been sent or received on a non- packet, TSopt >>>> MUST be sent in every non- packet for the duration of the >>>> connection. [...] >>>=20 >>>=20 >>> I still find that confusing. It sounds like it is suggesting to an >>> implementor that in addition to the normal sort of negotiation of the >>> TSopt on the SYN and SYN ACK exchange, they need to also watch for >>> whether a TSopt has been received on the first non-SYN packet. It >>> makes it sound like it is OK to negotiate use of TSopt on the first >>> two packets, but then never send the option again on any of the normal >>> packets. >>>=20 >>> Is that really what we want here? >>=20 >> Yes, that is late enablement of TSopt, i.e., negotiate it on the SYNs, >> and then not use TSopt until later in the connection. >=20 > Why would that make sense? See the other discussion about the usefulness of TS. If you are just using TS for PAWS, don't use TS until you're in danger of wrapping the sequence space. -David >=20 > ... >> The intention is that this is compatible with implementations that >> don't support late enablement, i.e. either side can send TSopt in all >> their packets, and then the other side must also send TSopt. >=20 > Let's figure out what the protocol ought to do first, then decide whether= it impacts existing implementations. >=20 > Joe >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From rs@netapp.com Wed Mar 27 10:25:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0411421F8488 for ; Wed, 27 Mar 2013 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3Ob+qXPRKnO for ; Wed, 27 Mar 2013 10:25:39 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id D653021F87D5 for ; Wed, 27 Mar 2013 10:25:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,920,1355126400"; d="scan'208";a="34584485" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 27 Mar 2013 10:25:10 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2RHP8L0016287; Wed, 27 Mar 2013 10:25:09 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Wed, 27 Mar 2013 10:25:08 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng , "mallman@icir.org" Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxA= Date: Wed, 27 Mar 2013 17:25:07 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> 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.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 17:25:40 -0000 Well, I found the following mechanisms (at least partially) relying on the = presence of TSopt: Eifel (RFC3522/4015) NewReno (RFC3782) ACK congestion control (RFC3449, RFC5690) Plus some of the passive measurement people use it... Did I miss any? (Besides, I still think that TS can be put to better use during loss recove= ry by changing the semantics when used in conjunction with SACK. But let's = finish 1323bis first.) BTW: Latest iteration of the disputed section: =20 A TCP MAY send the Timestamp option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in other segments only if it received a TSopt in the initial or segment for the connection. Once TSopt has been successfully negotiated during the , exchange, TSopt MUST be sent in every non- segment for the duration of the connection. If a non- segment is received without a TSopt, a TCP MAY drop the segment and MAY send an for the last in-sequence segment. A TCP MUST NOT abort a TCP connection if a non- segment is received without a TSopt. If a TSopt is received on a connection where TSopt was not negotiated in the initial three-way handshake, the TSopt MUST be ignored and the packet processed normally. In the case of crossing segments where one contains a TSopt and the other doesn't, both sides SHOULD put a TSopt in the segment. TSopt is required for the two mechanisms described in sections 3.3 and 4.2. There are also other mechanisms that rely on the presence of the TSopt, e.g. [RFC3522]. If a TCP stopped sending TSopt at any time during an established session, it interferes with these mechanisms. This update to [RFC1323] describes explicitly the previous implicit assumption, that each TCP segment must have TSopt, once negotiated. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Yuchung Cheng > Sent: Mittwoch, 27. M=E4rz 2013 17:23 > To: mallman@icir.org > Cc: tcpm (tcpm@ietf.org); David Borman; Joe Touch > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > WGLC) >=20 > On Wed, Mar 27, 2013 at 8:17 AM, Mark Allman wrote: > > > > > > > What is it in practice? > > > > I don't have good data at my finger tips, but I think it is pretty > > well known that the 1sec min is violated routinely and the min is > > often a couple hundred msec. >=20 > For Linux the 4*RTTVAR is lower-bounded at 200ms (due to the common > setting of delayed ACK). RTO =3D SRTT + 4*RTTVAR and does not cap RTO at > 1sec. Linux samples RTT for every ACK. > http://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf >=20 > Also "A Performance Study of Loss Detection/Recovery in Real-world TCP > Implementations", ICNP 2007 >=20 > > > > (What we don't know is the implications of this change. We found that > > there is a pretty fundamental tradeoff between making the RTO > > aggressive and taking more spurious RTOs. Many times when I have > > talked with folks who advocate dropping the min they are solely > > focused on needed RTOs taking less time. Well, for needed RTOs you > > can be as aggressive as you want and show improvement. However, that > > neglects the impact of unneeded RTOs which drop the cwnd to one > > segment. I have never seen > Worse in fact. The acks of original packets after a spurious RTO can > trigger a false slow-start storm of inflight packets. with deep buffers > this pours way more than BDP into the jammed highway. With timestamp and > Eifel this can be detected and stopped early. Without TS this is terrible= . >=20 > Sorry it's rude to not read the entire thread and the document and chime > in now. but TS is helpful for RTT samples during loss recovery where RTT > varies the most due to congestion. It also key to identify spurious > retransmission and is more robust and useful than F-RTO. The former does > not require new data available to send at timeout, a luxury that > interactive request-response application does not have. >=20 > I also agree 12 bytes (not 10 b/c of option alignment) is not negligible > so a lazy trigger on dubious network condition sounds a great solution to > me. >=20 > > anyone do a nice study of both sides of this equation.) > Why don't you do that :) > > > > allman > > > > > > > > > > _______________________________________________ > > 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=1798b84bb6=david.borman@quantum.com Wed Mar 27 10:30:13 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40FC21F91FF for ; Wed, 27 Mar 2013 10:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.085 X-Spam-Level: X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-0X2BiWzdUY for ; Wed, 27 Mar 2013 10:30:12 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id D8DA121F91F9 for ; Wed, 27 Mar 2013 10:30:12 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2RHRkJs012443; Wed, 27 Mar 2013 10:30:10 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1bc1pngmn1-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 10:30:09 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 27 Mar 2013 11:29:57 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 27 Mar 2013 11:30:05 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKxC4o8eqabN/6kObAfC5dtJKvg== Date: Wed, 27 Mar 2013 17:29:17 +0000 Message-ID: References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> <5151E5CB.6070003@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <89A385CA61929149BB249E55266E2414@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_07:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270163 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 17:30:13 -0000 On Mar 27, 2013, at 10:47 AM, Joe Touch wrote: >=20 > On Mar 26, 2013, at 1:35 PM, David Borman wrot= e: >=20 >>> If you say that something is REQUIRED, you have to explain what happens= when it's absent. >>=20 >>>=20 >>> So far, you say a segment missing TSopt MAY be dropped "to alert". I do= n't consider a "drop" an "alert". >>>=20 >>> IMO, this should say: >>> - if missing, MAY drop and MAY be logged >>> - if missing and not dropped, what happens? >>=20 >> How about something like: >> Once TSopt has been sent or received on a non-SYN packet, TSopt >=20 > I don't understand this idea - that TSopt can be "activated" for a connec= tion during the SYN exchange, but not used until sent in a non-SYN packet? = I thought we had converged that - for now - we would assume that TSopt nee= ded to be in every non-SYN once it was negotiated. See the discussion about the usefulness of TSopt and using it only for PAWS. >=20 > So I would suggest: >=20 > Once TSopt has been successfully negotiated during the SYN exchange, > TSopt (continuing below) >=20 >> MUST be sent in every non-RST packet for the duration of the >> connection. If a non-RST packet is received without a TSopt, a >> TCP MAY drop the packet and send an ACK. >=20 > what's being ACK'd? i.e., ACK the last segment successfully received? cou= ld this then be used to 'trick' TCP into sending dup-acks? why send anythin= g, if you consider this an error? You generate an ACK based on the TCP state, just like every place else in 793 where it says you drop the packet and send an ACK. So: "... MAY drop the packet and send an ACK of the form: " >=20 >> A TCP MUST NOT abort a >> TCP connection if a non-RST packet is received without a TSopt. >>=20 >> If a TSopt is received on a connection where TSopt was not >> negotiated in the initial SYN exchange, the TSopt SHOULD >> be ignored and the packet processed normally. >=20 > The SHOULD should be MUST AFAICT. Same as for any unrecognized option. Fine, it doesn't matter much, make it a MUST. The only difference is that if it is a MUST, then an implementation that does something besides ignoring the TSopt does not conform to 1323bis. If it's a SHOULD then if they do something else they can still claim conformance to 1323bis, and future documents that specify how to use TSopt in this case don't have to change 1323bis to do so. Not that that matters much since that future document will also have to say you can send TSopt without having negotiated it in the SYNs. >=20 >>> I think you also need a paragraph to highlight how this changes what wa= s in RFC1323, i.e., "what changed". >>=20 >> That's what appendix F is for, a detailed list of technical and >> editorial changes from RFC 1323. This a *replacement* for 1323, >> not just an update to it. It clutters up the document putting >> in explanations throughout it on why things changed from 1323. >> The main body should just have the current state of things, with >> any necessary explanations for someone reading the document for >> the first time, having never read 1323. Just highlighting that >> something is a change from 1323 belongs in Appendix F. >=20 > OK. But you should mention that in the intro and perhaps reiterate it in = each section. Right now, it is referenced first in the PAWS intro, but that= 's after TSopt. Put what in each section? That there's an Appendix F that lists the changes from 1323? Ugh. The table of contents already lists "Appendix F. Changes from RFC 1323". At most, the second paragraph of the Introduction section can have one sentence added: "Changes between RFC 1323 and this document are detailed in Appendix F." And that should be sufficient, no need to mention it again. -David >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From mallman@icir.org Wed Mar 27 10:31:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD1E21F9202 for ; Wed, 27 Mar 2013 10:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Tym+0qH0BZ8 for ; Wed, 27 Mar 2013 10:31:38 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id B081621F91DE for ; Wed, 27 Mar 2013 10:31:38 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RHVYQ9018982; Wed, 27 Mar 2013 10:31:34 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 99501D39340; Wed, 27 Mar 2013 13:31:34 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document15781.doc X-URL-1: http://www.icir.org/mallman-files/Document88999.html X-URL-2: http://www.icir.org/mallman-files/Document99783.pdf X-URL-3: http://www.icir.org/mallman-files/Document87057.xls X-URL-4: http://www.icir.org/mallman-files/Document416.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma11510-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 13:31:34 -0400 Sender: mallman@icir.org Message-Id: <20130327173134.99501D39340@lawyers.icir.org> Cc: Joe Touch , "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:31:39 -0000 ----------ma11510-1 Content-Type: text/plain Content-Disposition: inline > Well, I found the following mechanisms (at least partially) relying on > the presence of TSopt: > > Eifel (RFC3522/4015) > NewReno (RFC3782) > ACK congestion control (RFC3449, RFC5690) > > Plus some of the passive measurement people use it... > > Did I miss any? What is your point? I just don't follow this because it isn't like I have seen anyone saying we should get rid of the timestamp option. So, what are you trying to say? allman ----------ma11510-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTLPYACgkQWyrrWs4yIs6iqACeOVHSv2sQT82i+nFsk/H0bKd1 hkIAn38B3JHVJJ9U58Ndm5IJxRhjnYIR =Rjrs -----END PGP SIGNATURE----- ----------ma11510-1-- From touch@isi.edu Wed Mar 27 10:34:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2898F21F9208 for ; Wed, 27 Mar 2013 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.771 X-Spam-Level: X-Spam-Status: No, score=-102.771 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfH6SU5Goryq for ; Wed, 27 Mar 2013 10:34:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9C01D21F9205 for ; Wed, 27 Mar 2013 10:34:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2RHXIBB021673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Mar 2013 10:33:19 -0700 (PDT) Message-ID: <51532D59.3070001@isi.edu> Date: Wed, 27 Mar 2013 10:33:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Borman References: <3D7ADA77-0F51-47D3-9847-764CD99A5969@isi.edu> 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: "tcpm \(tcpm@ietf.org\)" , Tim Shepard Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 17:34:05 -0000 On 3/27/2013 10:06 AM, David Borman wrote: > > On Mar 27, 2013, at 10:49 AM, Joe Touch wrote: > >> >> On Mar 27, 2013, at 7:43 AM, David Borman wrote: >> >>> >>> On Mar 27, 2013, at 7:46 AM, Tim Shepard wrote: >>> >>>> >>>> >>>>> A TCP MAY send the Timestamp option (TSopt) in an initial >>>>> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY >>>>> send a TSopt in other segments only if it received a TSopt in the >>>>> initial or segment for the connection. >>>>> >>>>> Once TSopt has been sent or received on a non- packet, TSopt >>>>> MUST be sent in every non- packet for the duration of the >>>>> connection. [...] >>>> >>>> >>>> I still find that confusing. It sounds like it is suggesting to an >>>> implementor that in addition to the normal sort of negotiation of the >>>> TSopt on the SYN and SYN ACK exchange, they need to also watch for >>>> whether a TSopt has been received on the first non-SYN packet. It >>>> makes it sound like it is OK to negotiate use of TSopt on the first >>>> two packets, but then never send the option again on any of the normal >>>> packets. >>>> >>>> Is that really what we want here? >>> >>> Yes, that is late enablement of TSopt, i.e., negotiate it on the SYNs, >>> and then not use TSopt until later in the connection. >> >> Why would that make sense? > > See the other discussion about the usefulness of TS. If you are just > using TS for PAWS, don't use TS until you're in danger of wrapping > the sequence space. I still find this confusing. The benefit is either worth using 10 bytes all the time or not at all. I can't see the justification for a complex mechanism to enable TS only when the seq wrap is imminent. I don't know of any other sort of "on demand" protection in TCP, and introducing this as such needs a bit of discussion on complexity vs. necessity. IMO, this doc should stay closer to the minimum required to correct 1323, not to introduce every corner case that implementers have considered. Joe From touch@isi.edu Wed Mar 27 10:36:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5B21F9227 for ; Wed, 27 Mar 2013 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj4PqI6hFZu4 for ; Wed, 27 Mar 2013 10:36:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1858021F9205 for ; Wed, 27 Mar 2013 10:36:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2RHZkwu022720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Mar 2013 10:35:46 -0700 (PDT) Message-ID: <51532DED.7020109@isi.edu> Date: Wed, 27 Mar 2013 10:35:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Borman References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> <5151E5CB.6070003@isi.edu> 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 17:36:48 -0000 On 3/27/2013 10:29 AM, David Borman wrote: ... >>> MUST be sent in every non-RST packet for the duration of the >>> connection. If a non-RST packet is received without a TSopt, a >>> TCP MAY drop the packet and send an ACK. >> >> what's being ACK'd? i.e., ACK the last segment successfully received? could this then be used to 'trick' TCP into sending dup-acks? why send anything, if you consider this an error? > > You generate an ACK based on the TCP state, just like every place > else in 793 where it says you drop the packet and send an ACK. So: > "... MAY drop the packet and send an ACK of the form: > > " Can you also address the issue of dup-acks? >>> A TCP MUST NOT abort a >>> TCP connection if a non-RST packet is received without a TSopt. >>> >>> If a TSopt is received on a connection where TSopt was not >>> negotiated in the initial SYN exchange, the TSopt SHOULD >>> be ignored and the packet processed normally. >> >> The SHOULD should be MUST AFAICT. Same as for any unrecognized option. > > Fine, it doesn't matter much, make it a MUST. The only difference is > that if it is a MUST, then an implementation that does something > besides ignoring the TSopt does not conform to 1323bis. If it's a SHOULD > then if they do something else they can still claim conformance to > 1323bis, and future documents that specify how to use TSopt in this > case don't have to change 1323bis to do so. Not that that matters > much since that future document will also have to say you can send > TSopt without having negotiated it in the SYNs. My view is that future docs that want to extend this mechanism will need to UPDATE this doc anyway, so we shouldn't be leaving the door open to "future, unspecified" extensions in this one. >>>> I think you also need a paragraph to highlight how this changes what was in RFC1323, i.e., "what changed". >>> >>> That's what appendix F is for, a detailed list of technical and >>> editorial changes from RFC 1323. This a *replacement* for 1323, >>> not just an update to it. It clutters up the document putting >>> in explanations throughout it on why things changed from 1323. >>> The main body should just have the current state of things, with >>> any necessary explanations for someone reading the document for >>> the first time, having never read 1323. Just highlighting that >>> something is a change from 1323 belongs in Appendix F. >> >> OK. But you should mention that in the intro and perhaps reiterate it in each section. Right now, it is referenced first in the PAWS intro, but that's after TSopt. > > Put what in each section? That there's an Appendix F that lists > the changes from 1323? Ugh. The table of contents already > lists "Appendix F. Changes from RFC 1323". At most, the > second paragraph of the Introduction section can have one > sentence added: > > "Changes between RFC 1323 and this document > are detailed in Appendix F." > > And that should be sufficient, no need to mention it again. OK. Joe From rs@netapp.com Wed Mar 27 10:36:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E721F9245 for ; Wed, 27 Mar 2013 10:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7TmR161ALES for ; Wed, 27 Mar 2013 10:36:58 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id AF72021F9242 for ; Wed, 27 Mar 2013 10:36:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,920,1355126400"; d="scan'208";a="34587890" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 27 Mar 2013 10:36:50 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2RHanKW000747; Wed, 27 Mar 2013 10:36:49 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 27 Mar 2013 10:36:49 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Wed, 27 Mar 2013 10:36:49 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAHzlAP//i2eQ Date: Wed, 27 Mar 2013 17:36:48 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AD2938@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> <20130327173134.99501D39340@lawyers.icir.org> In-Reply-To: <20130327173134.99501D39340@lawyers.icir.org> 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 \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 17:36:59 -0000 Hi Mark, Then I must have misinterpreted your statements; I knew you question the RTTM mechanism (for yielding better estimates of RT= O; there are other uses for RTTM though), and PAWS isn't always required (p= articularly in short flows). Thus I got the impression that you'd rather than 1323 obsoleted and replace= d with entirely different mechanisms... Sorry. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Mark Allman > Sent: Mittwoch, 27. M=E4rz 2013 18:32 > To: Scheffenegger, Richard > Cc: Joe Touch; tcpm (tcpm@ietf.org); David Borman > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > WGLC) >=20 >=20 > > Well, I found the following mechanisms (at least partially) relying on > > the presence of TSopt: > > > > Eifel (RFC3522/4015) > > NewReno (RFC3782) > > ACK congestion control (RFC3449, RFC5690) > > > > Plus some of the passive measurement people use it... > > > > Did I miss any? >=20 > What is your point? I just don't follow this because it isn't like I hav= e > seen anyone saying we should get rid of the timestamp option. So, what > are you trying to say? >=20 > allman >=20 >=20 From mallman@icir.org Wed Mar 27 10:55:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BF821F9291 for ; Wed, 27 Mar 2013 10:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B4MOERJAoqN for ; Wed, 27 Mar 2013 10:55:03 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98421F9290 for ; Wed, 27 Mar 2013 10:55:02 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2RHsxKX021932; Wed, 27 Mar 2013 10:55:00 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EE3A1D39D1E; Wed, 27 Mar 2013 13:54:59 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AD2938@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document74783.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma12915-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 13:54:59 -0400 Sender: mallman@icir.org Message-Id: <20130327175459.EE3A1D39D1E@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:55:04 -0000 ----------ma12915-1 Content-Type: text/plain Content-Disposition: inline > I knew you question the RTTM mechanism (for yielding better estimates > of RTO; there are other uses for RTTM though), and PAWS isn't always > required (particularly in short flows). > > Thus I got the impression that you'd rather than 1323 obsoleted and > replaced with entirely different mechanisms... I have said this at least twice today. Maybe the third time is a charm. Within 1323 and 1323bis there are three things we have been talking about: (1) The timestamp option. This option conveys information. We send our current timestamp and we echo a timestamp back to our peer. It is nothing more than exchange of information. (2) The RTTM algorithm. This specifies how one takes information conveyed via the timestamp option and uses that to calculate an RTO estimator. (3) The PAWS algorithm. This specifies how one takes information conveyed via the timestamp option and uses that to protect against the sequence space wrapping too quickly and segments getting injected into the data stream in the wrong place. That is just what we have. I am suggesting: - That we simply deprecate (2). - When we thought we needed RTTM we just rode on its back to get PAWS. Without RTTM we can be more judicious and divorce the use of the timestamp option from the use of the window scaling option. We can decide that for PAWS it is fine to start using timestamps when we actually need PAWS. Neither of these things say anything about (1). If TCP needs timestamps for some reason that is outside the scope of 1323(bis) then the timestamp option is still there and its still available. If you want to pay a per-packet price to use Eifel, great. Go for it. If you think its worth it to pay a per-packet cost to maybe get some fast retransmit benefit immediately after an RTO with NewReno, great. Go for it. If you need more RTT samples for your new whiz-bang delay-based congestion controller, great. Go for it. If you want to invent some new scheme for loss recovery that leverages the information in the timestamp option, great. Go for it. But, none of that has anything to do with the algorithms in 1323bis (RTTM & PAWS). allman ----------ma12915-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTMnMACgkQWyrrWs4yIs6j9ACgj4rxDcUA5wCGl4iJqujfktm3 T0QAn0y/kTNQy2hwt73Wb6ibxdDHzXtn =mJZm -----END PGP SIGNATURE----- ----------ma12915-1-- From prvs=1798b84bb6=david.borman@quantum.com Wed Mar 27 11:03:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC18221F9122 for ; Wed, 27 Mar 2013 11:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRkxFSCOdDlW for ; Wed, 27 Mar 2013 11:03:11 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 1499021F9114 for ; Wed, 27 Mar 2013 11:03:10 -0700 (PDT) Received: from pps.filterd (m0001158 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2RI2CRi024141; Wed, 27 Mar 2013 11:03:09 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0b-000ceb01.pphosted.com with ESMTP id 1bbrc9h2ph-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 11:03:08 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 27 Mar 2013 12:02:48 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 27 Mar 2013 12:02:48 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKw2EgRnnFcmMyU2cO4zDlDw6YZi6MMqAgAAIQ4A= Date: Wed, 27 Mar 2013 18:02:01 +0000 Message-ID: References: <3D7ADA77-0F51-47D3-9847-764CD99A5969@isi.edu> <51532D59.3070001@isi.edu> In-Reply-To: <51532D59.3070001@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_07:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270174 Content-Type: text/plain; charset="iso-8859-1" Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 18:03:12 -0000 On Mar 27, 2013, at 12:33 PM, Joe Touch wrote: >=20 >=20 > On 3/27/2013 10:06 AM, David Borman wrote: >>=20 >> On Mar 27, 2013, at 10:49 AM, Joe Touch wrote: >>=20 >>>=20 >>> On Mar 27, 2013, at 7:43 AM, David Borman wr= ote: >>>=20 >>>>=20 >>>> On Mar 27, 2013, at 7:46 AM, Tim Shepard wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>> A TCP MAY send the Timestamp option (TSopt) in an initial >>>>>> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY >>>>>> send a TSopt in other segments only if it received a TSopt in the >>>>>> initial or segment for the connection. >>>>>>=20 >>>>>> Once TSopt has been sent or received on a non- packet, TSopt >>>>>> MUST be sent in every non- packet for the duration of the >>>>>> connection. [...] >>>>>=20 >>>>>=20 >>>>> I still find that confusing. It sounds like it is suggesting to an >>>>> implementor that in addition to the normal sort of negotiation of the >>>>> TSopt on the SYN and SYN ACK exchange, they need to also watch for >>>>> whether a TSopt has been received on the first non-SYN packet. It >>>>> makes it sound like it is OK to negotiate use of TSopt on the first >>>>> two packets, but then never send the option again on any of the normal >>>>> packets. >>>>>=20 >>>>> Is that really what we want here? >>>>=20 >>>> Yes, that is late enablement of TSopt, i.e., negotiate it on the SYNs, >>>> and then not use TSopt until later in the connection. >>>=20 >>> Why would that make sense? >>=20 >> See the other discussion about the usefulness of TS. If you are just >> using TS for PAWS, don't use TS until you're in danger of wrapping >> the sequence space. >=20 > I still find this confusing. The benefit is either worth using 10 bytes a= ll the time or not at all. I can't see the justification for a complex mech= anism to enable TS only when the seq wrap is imminent. I don't know of any = other sort of "on demand" protection in TCP, and introducing this as such n= eeds a bit of discussion on complexity vs. necessity. You can't have both: requiring TSopt in every packet and not using 10/12 by= tes of option space in every packet. Delayed enablement of TSopt for PAWS is how you avoid using TSopt until PAWS needs it. And why do you think it is a complex mechanism? Just remember ISS in your TCP state, and when sending, if SEG.SEQ < ISS, you're half way to wrapping the sequence space, so turn on TSopt. >=20 > IMO, this doc should stay closer to the minimum required to correct 1323,= not to introduce every corner case that implementers have considered. It's pretty clear that the value of TSopt for calculating RTO is pretty low. and the value of TSopt for PAWS only matters when you might wrap the sequence space. The minimum requirements are that once you start sending TSopt on a connection, you need to continue sending it for the duration of the connection, and you don't send TSopt on a connection unless you negotiated it in the SYN exchange. I don't see a good argument for excluding the late usage of TSopt, especially in the PAWS only case. -David >=20 > Joe ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From john@jlc.net Wed Mar 27 11:05:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98921F91B9 for ; Wed, 27 Mar 2013 11:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UftTVHJR2VFH for ; Wed, 27 Mar 2013 11:05:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C550521F91B6 for ; Wed, 27 Mar 2013 11:05:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 047C133C23; Wed, 27 Mar 2013 14:05:25 -0400 (EDT) Date: Wed, 27 Mar 2013 14:05:24 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20130327180524.GA12940@verdi> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 18:05:25 -0000 Scheffenegger, Richard wrote: > > A TCP MAY send the Timestamp option (TSopt) in an initial > segment (i.e., segment containing a SYN bit and no ACK bit), and MAY > send a TSopt in other segments only if it received a TSopt in the > initial or segment for the connection. That much is the original RFC 1323 text, right? > Once TSopt has been successfully negotiated during the , > exchange, TSopt MUST be sent in every non- segment for > the duration of the connection. I didn't find this MUST anywhere in RFC 1323. Did I miss something? > If a non- segment is received without a TSopt, a TCP MAY drop > the segment and MAY send an for the last in-sequence segment. This text confuses me. I don't particularly want to argue it, but I'm at a loss to understand how it helps. (There are four cases, right? And there seem to be a couple of unnamed variables as well.) > A TCP MUST NOT abort a TCP connection if a non- segment is > received without a TSopt. This sounds reasonable at first blush, but I don't see how anyone could depend on it. > If a TSopt is received on a connection where TSopt was not negotiated > in the initial three-way handshake, the TSopt MUST be ignored and the > packet processed normally. This would have been good to include in RFC 1323, but I wonder what it accomplishes to add it now. > In the case of crossing segments where one contains a > TSopt and the other doesn't, both sides SHOULD put a TSopt in the > segment. This sounds funny: very likely the one that didn't send TSopt doesn't want to dedicate N bytes of option space in every packet. > TSopt is required for the two mechanisms described in sections 3.3 > and 4.2. There are also other mechanisms that rely on the presence > of the TSopt, e.g. [RFC3522]. If a TCP stopped sending TSopt at any > time during an established session, it interferes with these > mechanisms. This update to [RFC1323] describes explicitly the > previous implicit assumption, that each TCP segment must have TSopt, > once negotiated. No doubt some of us believe such an assumption was "implicit"; and quite possibly there are implementations which won't interoperate without that assumption being valid. Nonetheless, I find it hard to believe that any implementations break horribly if the assumption fails. Writing a 1323-bis, the question isn't simply, "What should we have said the first time?" We must include, "How do we get here from there?" This is hard, IMHO: which is why I suggested a new aption instead. -- John Leslie From prvs=1798b84bb6=david.borman@quantum.com Wed Mar 27 11:13:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C354421F9299 for ; Wed, 27 Mar 2013 11:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmlBDaiuWnyf for ; Wed, 27 Mar 2013 11:13:25 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2121F9291 for ; Wed, 27 Mar 2013 11:13:24 -0700 (PDT) Received: from pps.filterd (m0001158 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2RIC40v003096; Wed, 27 Mar 2013 11:13:24 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 1bbrc9h3ad-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 11:13:24 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 27 Mar 2013 12:12:56 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 27 Mar 2013 12:13:02 -0600 From: David Borman To: Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOKxC4o8eqabN/6kObAfC5dtJKvpi6MXSAgAAKawA= Date: Wed, 27 Mar 2013 18:12:14 +0000 Message-ID: References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> <5151E5CB.6070003@isi.edu> <51532DED.7020109@isi.edu> In-Reply-To: <51532DED.7020109@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: <7EBD14155C25B149B8810DEDDB5C2979@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_07:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270177 Content-Type: text/plain; charset="iso-8859-1" Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 18:13:25 -0000 On Mar 27, 2013, at 12:35 PM, Joe Touch wrote: >=20 >=20 > On 3/27/2013 10:29 AM, David Borman wrote: > ... >>>> MUST be sent in every non-RST packet for the duration of the >>>> connection. If a non-RST packet is received without a TSopt, a >>>> TCP MAY drop the packet and send an ACK. >>>=20 >>> what's being ACK'd? i.e., ACK the last segment successfully received? c= ould this then be used to 'trick' TCP into sending dup-acks? why send anyth= ing, if you consider this an error? >>=20 >> You generate an ACK based on the TCP state, just like every place >> else in 793 where it says you drop the packet and send an ACK. So: >> "... MAY drop the packet and send an ACK of the form: >>=20 >> " >=20 > Can you also address the issue of dup-acks? Why? I don't agree with the supposition. It's not hard to get TCP to generate a dup-ack today, e.g., that's what keep-alives do, so what's special about this situation that would warrant it being called out and discussed? -David ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From prvs=1798b84bb6=david.borman@quantum.com Wed Mar 27 11:43:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCD921F906A for ; Wed, 27 Mar 2013 11:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWnfp8oQQ97Z for ; Wed, 27 Mar 2013 11:43:06 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 9A92321F8EAE for ; Wed, 27 Mar 2013 11:43:06 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2RIXSOk023763; Wed, 27 Mar 2013 11:43:00 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 1bc2u3rcjt-20 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 11:42:59 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 27 Mar 2013 12:42:37 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 27 Mar 2013 12:42:53 -0600 From: David Borman To: John Leslie Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKwd0ZqDoudLg402oKIxOVxufYA== Date: Wed, 27 Mar 2013 18:42:04 +0000 Message-ID: References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> <20130327180524.GA12940@verdi> In-Reply-To: <20130327180524.GA12940@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B4066463DC21E46AC31ED4A3CCF9F64@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_07:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270183 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 18:43:08 -0000 On Mar 27, 2013, at 1:05 PM, John Leslie wrote: > Scheffenegger, Richard wrote: >>=20 >> A TCP MAY send the Timestamp option (TSopt) in an initial >> segment (i.e., segment containing a SYN bit and no ACK bit), and MAY >> send a TSopt in other segments only if it received a TSopt in the >> initial or segment for the connection. >=20 > That much is the original RFC 1323 text, right? >=20 >> Once TSopt has been successfully negotiated during the , >> exchange, TSopt MUST be sent in every non- segment for >> the duration of the connection. >=20 > I didn't find this MUST anywhere in RFC 1323. Did I miss something? PAWS assumes it, see section 4.2. >=20 >> If a non- segment is received without a TSopt, a TCP MAY drop >> the segment and MAY send an for the last in-sequence segment. >=20 > This text confuses me. I don't particularly want to argue it, but I'm > at a loss to understand how it helps. (There are four cases, right? And > there seem to be a couple of unnamed variables as well.) Maybe it should be just "a TCP MAY drop the segment and send an ..." The point is that if you are doing PAWS and a packet arrives without TSopt, you can't reliably determine whether or not the packet came from a previous wrap of the sequence space, so without any other knowledge it's best to just drop the packet and generate an ack, just as you do for any other unacceptable packet. >=20 >> A TCP MUST NOT abort a TCP connection if a non- segment is >> received without a TSopt. >=20 > This sounds reasonable at first blush, but I don't see how anyone > could depend on it. Depend on it? No, there is little if anything that you can depend on. This is telling implementors that they can't abort a TCP connection just because a packet arrives without TSopt. And no, I am not aware of this being a real-world issue. >=20 >> If a TSopt is received on a connection where TSopt was not negotiated >> in the initial three-way handshake, the TSopt MUST be ignored and the >> packet processed normally. >=20 > This would have been good to include in RFC 1323, but I wonder what > it accomplishes to add it now. Just covering the bases. TCPs are already supposed to ignore unknown TCP options, and this is just saying treat it as an unknown option, even if you do know what it is. :-) There are two general cases: A) TSopt is sent in SYN, SYN/ACK, and every non-RST packet B) TSopt is never sent, or sent in only the initial SYN. that are the normal, current usages. The previous 3 statements are addressing cases that don't fall into those two cases. I have no problem with just dropping all three of them, but in trying to clarify 1323, folks on this discussion seem to want all the different scenarios spelled out in detail. >=20 >> In the case of crossing segments where one contains a >> TSopt and the other doesn't, both sides SHOULD put a TSopt in the >> segment. >=20 > This sounds funny: very likely the one that didn't send TSopt doesn't > want to dedicate N bytes of option space in every packet. It's the case of an implementation that only enables TSopt if it receives it in the SYN. It doesn't ask the other side to turn on TSopt when initiating a connection, but agrees to use it if the other side asks. -David Borman >=20 >> TSopt is required for the two mechanisms described in sections 3.3 >> and 4.2. There are also other mechanisms that rely on the presence >> of the TSopt, e.g. [RFC3522]. If a TCP stopped sending TSopt at any >> time during an established session, it interferes with these >> mechanisms. This update to [RFC1323] describes explicitly the >> previous implicit assumption, that each TCP segment must have TSopt, >> once negotiated. >=20 > No doubt some of us believe such an assumption was "implicit"; and > quite possibly there are implementations which won't interoperate without > that assumption being valid. >=20 > Nonetheless, I find it hard to believe that any implementations break > horribly if the assumption fails. >=20 > Writing a 1323-bis, the question isn't simply, "What should we have > said the first time?" We must include, "How do we get here from there?" > This is hard, IMHO: which is why I suggested a new aption instead. >=20 > -- > John Leslie > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From touch@isi.edu Wed Mar 27 15:33:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45BE21F8F9F for ; Wed, 27 Mar 2013 15:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIkmurW620sX for ; Wed, 27 Mar 2013 15:33:03 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFEE21F8F86 for ; Wed, 27 Mar 2013 15:33:03 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2RMWReh011450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Mar 2013 15:32:27 -0700 (PDT) Message-ID: <51537375.2050004@isi.edu> Date: Wed, 27 Mar 2013 15:32:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Borman References: <3D7ADA77-0F51-47D3-9847-764CD99A5969@isi.edu> <51532D59.3070001@isi.edu> 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: "tcpm \(tcpm@ietf.org\)" , Tim Shepard Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 22:33:04 -0000 On 3/27/2013 11:02 AM, David Borman wrote: ... >> I still find this confusing. The benefit is either worth using 10 bytes all the time or not at all. I can't see the justification for a complex mechanism to enable TS only when the seq wrap is imminent. I don't know of any other sort of "on demand" protection in TCP, and introducing this as such needs a bit of discussion on complexity vs. necessity. > > You can't have both: requiring TSopt in every packet and not using 10/12 bytes > of option space in every packet. Delayed enablement of TSopt for PAWS is > how you avoid using TSopt until PAWS needs it. And why do you think it is > a complex mechanism? Just remember ISS in your TCP state, and when sending, > if SEG.SEQ < ISS, you're half way to wrapping the sequence space, so turn > on TSopt. Is that what's being proposed? Then *maybe*. But what I've seen so far is "you can turn it on when you want, and here's what happens" in a very vague way. IMO, turning it on mid-stream requires the description of handling a bunch of corner cases - retransmission, SACK, etc. The doc either needs to go down that path - which requires a bunch more text *and* WG consensus, or should leave this out. >> IMO, this doc should stay closer to the minimum required to correct 1323, not to introduce every corner case that implementers have considered. > > It's pretty clear that the value of TSopt for calculating RTO is pretty > low. and the value of TSopt for PAWS only matters when you might wrap > the sequence space. The minimum requirements are that once you start > sending TSopt on a connection, you need to continue sending it for the > duration of the connection, and you don't send TSopt on a connection > unless you negotiated it in the SYN exchange. I don't see a good > argument for excluding the late usage of TSopt, especially in the > PAWS only case. I described it - the complexity of the spec and the implementation vs. the extra overhead. IMO, if you're willing to eat 10 bytes if PAWS might happen, and you ate it during the SYN, then I don't understand wanting or trying to save it the rest of the time. Joe From touch@isi.edu Wed Mar 27 15:35:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129BB21F86B2 for ; Wed, 27 Mar 2013 15:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaIaVkDJaovp for ; Wed, 27 Mar 2013 15:35:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBC721F86A6 for ; Wed, 27 Mar 2013 15:35:58 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2RMZO4t012220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Mar 2013 15:35:24 -0700 (PDT) Message-ID: <51537426.1050703@isi.edu> Date: Wed, 27 Mar 2013 15:35:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Borman References: <514BD5B7.9070305@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACC4EC@SACEXCMBX02-PRD.hq.netapp.com> <5150850E.1040405@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACCC64@SACEXCMBX02-PRD.hq.netapp.com> <515098E2.6060703@isi.edu> <5150AF37.7060302@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24ACDB68@SACEXCMBX02-PRD.hq.netapp.com> <5151E5CB.6070003@isi.edu> <51532DED.7020109@isi.edu> 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: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2013 22:35:59 -0000 On 3/27/2013 11:12 AM, David Borman wrote: > > On Mar 27, 2013, at 12:35 PM, Joe Touch > wrote: > >> >> >> On 3/27/2013 10:29 AM, David Borman wrote: >> ... >>>>> MUST be sent in every non-RST packet for the duration of the >>>>> connection. If a non-RST packet is received without a TSopt, a >>>>> TCP MAY drop the packet and send an ACK. >>>> >>>> what's being ACK'd? i.e., ACK the last segment successfully received? could this then be used to 'trick' TCP into sending dup-acks? why send anything, if you consider this an error? >>> >>> You generate an ACK based on the TCP state, just like every place >>> else in 793 where it says you drop the packet and send an ACK. So: >>> "... MAY drop the packet and send an ACK of the form: >>> >>> " >> >> Can you also address the issue of dup-acks? > > Why? I don't agree with the supposition. It's not hard to get TCP > to generate a dup-ack today, e.g., that's what keep-alives do, so > what's special about this situation that would warrant it being called > out and discussed? The first time you get a segment that you want to drop (because it lacks TSopt), this is fine. The second or third time it's happening because a corner case isn't being handled, and it could prevent the TCP connection from progressing. E.g., what if the sender thinks that TSopt "starts at SEQNO=NNNN" (and thus retransmits segments X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA221F93B7 for ; Wed, 27 Mar 2013 20:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00HctG37Q1mV for ; Wed, 27 Mar 2013 20:25:46 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8215421F93AF for ; Wed, 27 Mar 2013 20:25:46 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2S3PeRP021385; Wed, 27 Mar 2013 20:25:40 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 602F2D42A02; Wed, 27 Mar 2013 23:25:40 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <51532D59.3070001@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Fly By Night X-URL-0: http://www.icir.org/mallman-files/Document81532.doc X-URL-1: http://www.icir.org/mallman-files/Document64121.html X-URL-2: http://www.icir.org/mallman-files/Document65612.pdf X-URL-3: http://www.icir.org/mallman-files/Document83508.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma47156-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Mar 2013 23:25:40 -0400 Sender: mallman@icir.org Message-Id: <20130328032540.602F2D42A02@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard , David Borman Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 03:25:47 -0000 ----------ma47156-1 Content-Type: text/plain Content-Disposition: inline > The benefit is either worth using 10 bytes all the time or not at > all. I think this is just absurd. This is about PAWS. If the sequence space never wraps then how could it be worth using 10 bytes? As far as I can tell the only reason one could even remotely come up with would be simplicity of implementation. But, even that seems dubious to me given that turning on TS mid-way through is a simple conditional---hardly a complex mechanism (and that is even more true if we negotiate in the 3WHS as you like). Just to be clear, if this is all or nothing then ... - We could turn on timestamps for every TCP segment we send so we can ensure if we need PAWS that we can use PAWS. This is of course massively wasteful given that the vast, vast majority of connections will never wrap the sequence space (go look at a flow size distribution). (I do not like this approach.) - We could just decide PAWS isn't a big concern and we can just live with the slight probability that we'll end up with corrupted data on one of the slight number of connections that both sends enough volume and at a great enough speed to wrap too quickly. This is of course gaming things. But, hey, maybe you punt to the app and say there should be an app layer checksum anyway, so Oh Well. (I do not like this approach.) - We let the app indicate whether the TCP should use TS or not. It may have an idea how much data will be sent and hence be able to make a good decision. - Now, what happens when the app says "don't use TS" and we end up in a situation where PAWS is necessary? Well, that just sucks. Now we have to either just forget PAWS and hope for the best or we have to limit the speed of the connection so it can't wrap too fast. Either of these may be OK since the app chose not to use TS and so I guess we could just use the Live With The Consequences notion. - However, limiting the speed of the connection isn't getting us away from complexity TCP. - Also, now you're making the app designer grok TCP's sequence space and wrapping and window size and understanding how all this fits together. That seems lousy. - And, its especially lousy when a little tweak (add a conditional) could fix this within TCP and leave the app out of it. (I do not like this approach.) In other words, the first two add no complexity but either game reliability or are grossly wasteful. The third still adds complexity and may also game reliability or be grossly wasteful. To me it is simply common sense that you should turn the TS option on when you need it. And, for PAWS that isn't until you wrap (or get near wrapping). And, if you need an exemplar of an option we use only when necessary: SACK. allman ----------ma47156-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFTuDQACgkQWyrrWs4yIs4nfwCfS/8eJctEtjYs0cd/ciDhpf4t foIAn2vpjXQ3K6u+UyV2gvhTdWnAkvad =3CHE -----END PGP SIGNATURE----- ----------ma47156-1-- From touch@isi.edu Wed Mar 27 23:12:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C491D21F92A7 for ; Wed, 27 Mar 2013 23:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.524 X-Spam-Level: X-Spam-Status: No, score=-105.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vadz7c6JQFA8 for ; Wed, 27 Mar 2013 23:12:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F24D221F925A for ; Wed, 27 Mar 2013 23:12:21 -0700 (PDT) Received: from [192.168.1.92] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2S6BC64009287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 23:11:24 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <20130328032540.602F2D42A02@lawyers.icir.org> Date: Wed, 27 Mar 2013 23:11:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22EBDF24-9FD3-41AD-816B-2782B0AC2EF5@isi.edu> References: <20130328032540.602F2D42A02@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1503) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard , David Borman Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 06:12:23 -0000 On Mar 27, 2013, at 8:25 PM, Mark Allman wrote: >=20 >> The benefit is either worth using 10 bytes all the time or not at >> all.=20 >=20 > I think this is just absurd. This is about PAWS. If you want absurd, see PAWS. That mechanism can be accomplished with a = very short option that encodes the top byte(s) of an extended sequence = number space - in much fewer than 10 bytes. > If the sequence space > never wraps then how could it be worth using 10 bytes? If you don't "turn it on" during the connection, then you get no = protection across connections or reboots as well, though. I'm OK with = that, but that's another aspect that needs to be described, FWIW. > As far as I can > tell the only reason one could even remotely come up with would be > simplicity of implementation. But, even that seems dubious to me = given > that turning on TS mid-way through is a simple conditional---hardly a > complex mechanism (and that is even more true if we negotiate in the > 3WHS as you like). I've listed a fairly large handful of corner cases for = midway-commencement of TSopt even if negotiated during 3WHS that need to = be clearly and completely documented before we should consider that = reasonable. > Just to be clear, if this is all or nothing then ... >=20 > - We could turn on timestamps for every TCP segment we send so we can > ensure if we need PAWS that we can use PAWS. >=20 > This is of course massively wasteful given that the vast, vast > majority of connections will never wrap the sequence space (go look > at a flow size distribution). >=20 > (I do not like this approach.) >=20 > - We could just decide PAWS isn't a big concern and we can just live > with the slight probability that we'll end up with corrupted data = on > one of the slight number of connections that both sends enough > volume and at a great enough speed to wrap too quickly. >=20 > This is of course gaming things. >=20 > But, hey, maybe you punt to the app and say there should be an app > layer checksum anyway, so Oh Well. >=20 > (I do not like this approach.) >=20 > - We let the app indicate whether the TCP should use TS or not. It > may have an idea how much data will be sent and hence be able to > make a good decision. >=20 > - Now, what happens when the app says "don't use TS" and we end up > in a situation where PAWS is necessary? Well, that just sucks. > Now we have to either just forget PAWS and hope for the best or = we > have to limit the speed of the connection so it can't wrap too > fast. Either of these may be OK since the app chose not to use = TS > and so I guess we could just use the Live With The Consequences > notion.=20 >=20 > - However, limiting the speed of the connection isn't getting us > away from complexity TCP. >=20 > - Also, now you're making the app designer grok TCP's sequence = space > and wrapping and window size and understanding how all this fits > together. That seems lousy. >=20 > - And, its especially lousy when a little tweak (add a conditional) > could fix this within TCP and leave the app out of it. >=20 > (I do not like this approach.) We could create a simple 3-4 byte version that can be defined as = "implicitly encoding a 0 high-order value if absent", which then would = take only 2 bytes during the SYN (vs 10 for TSopt), zero bytes during = most connections, and 3-4 (depending on how far the wrap is expected) to = protect against PAWS. And it would be a lot simpler to spec than this, IMO. Joe From rs@netapp.com Thu Mar 28 04:13:17 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F356221F90BF for ; Thu, 28 Mar 2013 04:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.083 X-Spam-Level: X-Spam-Status: No, score=-10.083 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3yH8fhEAHBX for ; Thu, 28 Mar 2013 04:13:16 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4D15C21F9079 for ; Thu, 28 Mar 2013 04:13:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,925,1355126400"; d="scan'208";a="17152774" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 28 Mar 2013 04:13:15 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2SBDD8t011634; Thu, 28 Mar 2013 04:13:15 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Thu, 28 Mar 2013 04:13:13 -0700 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQ Date: Thu, 28 Mar 2013 11:13:12 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> <20130327180524.GA12940@verdi> In-Reply-To: <20130327180524.GA12940@verdi> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 11:13:17 -0000 Hi John, > From: John Leslie [mailto:john@jlc.net] > > A TCP MAY send the Timestamp option (TSopt) in an initial > > segment (i.e., segment containing a SYN bit and no ACK bit), and MAY > > send a TSopt in other segments only if it received a TSopt in the > > initial or segment for the connection. >=20 > That much is the original RFC 1323 text, right? With minor editorial changes and an update to RFC2119 wording, yes. > > Once TSopt has been successfully negotiated during the , > > exchange, TSopt MUST be sent in every non- segment fo= r > > the duration of the connection. >=20 > I didn't find this MUST anywhere in RFC 1323. Did I miss something? No; as mentioned on this list, certain mechanisms assume the permanent use = of Tsopt right after the successful negotiation. This text was added by Dav= id in 2007 ( http://tools.ietf.org/html/draft-borman-1323bis-00 ): Once a TSopt has been sent or received in a non segment, it must be sent in all segments. Once a TSopt has been received in a non segment, then any successive segment that is received without the RST bit and without a TSopt may be ACKed and dropped without further processing. After the discussions on this list, it seemed to be better to not leave any= potential gap between the 3WHS negotiation, and the actual use of the TS o= ption. All the implementations that I know of effectively work that way. > > If a non- segment is received without a TSopt, a TCP MAY drop > > the segment and MAY send an for the last in-sequence segment. >=20 > This text confuses me. I don't particularly want to argue it, but I'm > at a loss to understand how it helps. (There are four cases, right? And > there seem to be a couple of unnamed variables as well.) Well, the 2nd MAY is superfluous, I guess at this reading. But I'm open for= better wording suggestions. > > A TCP MUST NOT abort a TCP connection if a non- segment is > > received without a TSopt. >=20 > This sounds reasonable at first blush, but I don't see how anyone coul= d > depend on it. >=20 > > If a TSopt is received on a connection where TSopt was not negotiate= d > > in the initial three-way handshake, the TSopt MUST be ignored and th= e > > packet processed normally. >=20 > This would have been good to include in RFC 1323, but I wonder what it > accomplishes to add it now. Just to make this behavior explicit. There is another example in the dreded= RTTM mechanism. 1323 just stated that any ACK that indicates loss/reorderi= ng should be excluded. Most ACKs that contain SACK do indicate some loss/re= ordering, but when I investigated, these ACKs are still used to update RTO = under certain circumstances. Thus the added text there to explicitly exclud= e ACK+SACK for the RTTM mechanism. > > In the case of crossing segments where one contains a > > TSopt and the other doesn't, both sides SHOULD put a TSopt in the > > segment. >=20 > This sounds funny: very likely the one that didn't send TSopt doesn't > want to dedicate N bytes of option space in every packet. This is new text; it was added in 2009 in http://tools.ietf.org/html/draft-= ietf-tcpm-1323bis-01=20 We could leave that case undefined, as in 1323...=20 > > TSopt is required for the two mechanisms described in sections 3.3 > > and 4.2. There are also other mechanisms that rely on the presence > > of the TSopt, e.g. [RFC3522]. If a TCP stopped sending TSopt at an= y > > time during an established session, it interferes with these > > mechanisms. This update to [RFC1323] describes explicitly the > > previous implicit assumption, that each TCP segment must have TSopt, > > once negotiated. >=20 > No doubt some of us believe such an assumption was "implicit"; and > quite possibly there are implementations which won't interoperate without > that assumption being valid. >=20 > Nonetheless, I find it hard to believe that any implementations break > horribly if the assumption fails. >=20 > Writing a 1323-bis, the question isn't simply, "What should we have > said the first time?" We must include, "How do we get here from there?" > This is hard, IMHO: which is why I suggested a new aption instead. I agree, things will usually not go terribly wrong if the assumptions don't= hold, but the implementations seen behave as described in the latest text.= I think it would be save to clearly state, that this is how to actually us= e TSopt... Richard From mallman@icir.org Thu Mar 28 06:12:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BF221F8FBE for ; Thu, 28 Mar 2013 06:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH-85w6-ZV8N for ; Thu, 28 Mar 2013 06:12:00 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF821F8EFD for ; Thu, 28 Mar 2013 06:12:00 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2SDBspt002818; Thu, 28 Mar 2013 06:11:54 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 58DE9D43B30; Thu, 28 Mar 2013 09:11:55 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <22EBDF24-9FD3-41AD-816B-2782B0AC2EF5@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Thunderstruck X-URL-0: http://www.icir.org/mallman-files/Document1480.jpg X-URL-1: http://www.icir.org/mallman-files/Document3740.doc X-URL-2: http://www.icir.org/mallman-files/Document32199.docx X-URL-3: http://www.icir.org/mallman-files/Document93137.pdf X-URL-4: http://www.icir.org/mallman-files/Document51140.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma16795-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 28 Mar 2013 09:11:55 -0400 Sender: mallman@icir.org Message-Id: <20130328131155.58DE9D43B30@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard , David Borman Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 13:12:00 -0000 ----------ma16795-1 Content-Type: text/plain Content-Disposition: inline > If you want absurd, see PAWS. That mechanism can be accomplished with > a very short option that encodes the top byte(s) of an extended > sequence number space - in much fewer than 10 bytes. Absolutely. And, if could turn back the clock and know that RTTM wasn't useful when 1323 was standardized that is no doubt exactly what we'd do. (As an aside, perhaps there is a lesson here in not entangling things up too much. If we had not piggybacked PAWS on the timestamps we presumed we needed anyway then it'd be a bit easier to deprecate one without impact on the other. Well, OK. That doesn't exactly help the current situation, but perhaps a point to remember.) However, while this sort of start-from-scratch approach might be conceptually nice it ignores that the logic for the current PAWS is all there in most TCP implementations and what we're talking about here are a few modest tweaks. The path to get to a PAWS 2.0 is easier through tweaking the current scheme than through inventing a new option. > > If the sequence space never wraps then how could it be worth using > > 10 bytes? > > If you don't "turn it on" during the connection, then you get no > protection across connections or reboots as well, though. I'm OK with > that, but that's another aspect that needs to be described, FWIW. PAWS doesn't necessarily give you protection across connections. You may get some protection. Or, you may not. But, you sure can't count on it. In fact, RFC 1323 explicitly says: We may still ask whether the PAWS mechanism can provide additional security against old duplicates from earlier connections, allowing us to relax the enforcement of MSL by the IP layer. Appendix B explores this question, showing that further assumptions and/or mechanisms are required, beyond those of PAWS. This is not part of the current extension. So, unless you are proposing that 1323bis in fact should tackle this issue further, I think that this is a red herring. allman ----------ma16795-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFUQZsACgkQWyrrWs4yIs6RWgCfeLylfgO6ovwxSj5H8DZ8xlwr hs4An2ZoigMLhJXt4G8832D/mMh4pKi6 =VSec -----END PGP SIGNATURE----- ----------ma16795-1-- From prvs=279985f66c=david.borman@quantum.com Thu Mar 28 07:27:01 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8242E21F8E6E for ; Thu, 28 Mar 2013 07:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meCPT9ueBIR6 for ; Thu, 28 Mar 2013 07:27:00 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id C597A21F8D2E for ; Thu, 28 Mar 2013 07:26:59 -0700 (PDT) Received: from pps.filterd (m0001158 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2SEIoxT015012; Thu, 28 Mar 2013 07:26:54 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0b-000ceb01.pphosted.com with ESMTP id 1bbrc9jkfv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Mar 2013 07:26:54 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 28 Mar 2013 08:26:41 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Thu, 28 Mar 2013 08:26:51 -0600 From: David Borman To: "tcpm (tcpm@ietf.org)" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOK8BJ7KgAmBXci0q5J4oOrDSUnw== Date: Thu, 28 Mar 2013 14:26:01 +0000 Message-ID: References: <20130328131155.58DE9D43B30@lawyers.icir.org> In-Reply-To: <20130328131155.58DE9D43B30@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.176.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <26B6D08E3B305C48916819C1CBEE68EC@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=10 spamscore=10 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303280115 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-28_05:2013-03-28, 2013-03-28, 1970-01-01 signatures=0 Cc: "mallman@icir.org" , Tim Shepard , David Borman , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 14:27:01 -0000 I'm getting pretty frustrated of this whole discussion. I'm to the point where even though I personally think it's the wrong way to go, make the text simply: A TCP MAY send the Timestamp option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in a only if it received a TSopt in an initial . In the case of crossing segments where one contains a TSopt and the other doesn't, the side that sent the without the TSopt MAY send a TSopt in the segment. Once TSopt has been sent and received, TSopt MUST be sent in every non- packet for the duration of the connection. TSopt is required for the two mechanisms described in sections 3.3 and 4.2. If a TCP stopped sending TSopt at any time during an established session, it interferes with both the PAWS and RTTM mechanisms. This update to [RFC1323] describes explicitly the previous implicit assumption. This explicitly disallows late enablement of TSopt in 1323bis, despite the fact that it's been desired for years. Once you send and receive TSopt, it's on for the whole connection. Is this what *other* people on the list want? Otherwise, if the majority of people are fine with Richards text: > A TCP MAY send the Timestamp option (TSopt) in an initial > segment (i.e., segment containing a SYN bit and no ACK bit), and MAY > send a TSopt in other segments only if it received a TSopt in the > initial or segment for the connection. >=20 > Once TSopt has been sent or received on a non- packet, TSopt > MUST be sent in every non- packet for the duration of the > connection. If a non- packet is received without a TSopt, a TCP > MAY drop the packet and send an . A TCP MUST NOT abort a TCP > connection if a non- packet is received without a TSopt. >=20 > If a TSopt is received on a connection where TSopt was not negotiated > in the initial three-way handshake, the TSopt SHOULD be ignored and > the packet processed normally. >=20 > In the case of crossing segments where one contains a > TSopt and the other doesn't, both sides SHOULD put a TSopt in the > segment. >=20 > TSopt is required for the two mechanisms described in sections 3.3 > and 4.2. If a TCP stopped sending TSopt at any time during an > established session, it interferes with both the PAWS and RTTM > mechanisms. This update to [RFC1323] describes explicitly the > previous implicit assumption. we can just take it as is, which leaves the door open for late enablement without spelling out in black and white every last detail of how that would work. Consensus doesn't mean we have 100% agreement, it means that everyone has been able to express their opinion and that opinion has been heard and understood, but the majority decision might still go a different way. So it'd be really good to get some other comments from a larger pool of people on where this should go so we can resolve this: 1) No late enablement of TSopt: once it's negotiated, it's on for the rest of the connection. 2) Allow for late enablement of TSopt, i.e., Richard's text. 3) Allow late enablement of TSopt, and we hash out all the explicit details of every corner case we can think of. -David ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From pasi.sarolahti@iki.fi Thu Mar 28 11:44:29 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7826E21F8EBC for ; Thu, 28 Mar 2013 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJc+6Jfmbb-g for ; Thu, 28 Mar 2013 11:44:29 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id A3DCB21F8E99 for ; Thu, 28 Mar 2013 11:44:28 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508712A00A280828; Thu, 28 Mar 2013 20:44:05 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <31506_1364480834_51545342_31506_15_1_AD01EFBA971A0A4EBB41E1AF7D81F00026B420E6@ppomsg1> Date: Thu, 28 Mar 2013 20:44:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <714C2A4D-B15E-4D1C-84DA-8F0FD3ACC37A@iki.fi> References: <20130328131155.58DE9D43B30@lawyers.icir.org> <31506_1364480834_51545342_31506_15_1_AD01EFBA971A0A4EBB41E1AF7D81F00026B420E6@ppomsg1> To: David Borman X-Mailer: Apple Mail (2.1283) Cc: Joe Touch , "tcpm \(tcpm@ietf.org\)" , Tim Shepard , "mallman@icir.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 18:44:29 -0000 On Mar 28, 2013, at 4:26 PM, David Borman wrote: > Consensus doesn't mean we have 100% agreement, it means that everyone > has been able to express their opinion and that opinion has been heard > and understood, but the majority decision might still go a different = way. Right. We need to decide about how to proceed with the TSopt negotiation = issue, and I think the list you present below are a good and concrete = set of options we have on the table. Thanks for moving us forward. So, I'd like to second David's request: additional input would be much = appreciated, based on the options below. > So it'd be really good to get some other comments from a larger pool > of people on where this should go so we can resolve this: >=20 > 1) No late enablement of TSopt: once it's negotiated, it's on for > the rest of the connection. >=20 > 2) Allow for late enablement of TSopt, i.e., Richard's text. >=20 > 3) Allow late enablement of TSopt, and we hash out all the explicit > details of every corner case we can think of. As Michael said in an earlier Email, option 3) could be a separate I-D, = but in that case it would (in my opinion) imply 2) for rfc1323bis. In my = opinion, it would be good to try to keep rfc1323bis reasonably close to = the original, otherwise we might still need to keep on working on it for = quite a while... - Pasi From michael.scharf@alcatel-lucent.com Thu Mar 28 12:20:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCC421F905F for ; Thu, 28 Mar 2013 12:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.646 X-Spam-Level: X-Spam-Status: No, score=-9.646 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL4qlmcK2ymk for ; Thu, 28 Mar 2013 12:19:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6905F21F905A for ; Thu, 28 Mar 2013 12:19:59 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2SJJlRE026932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Mar 2013 20:19:47 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 28 Mar 2013 20:19:47 +0100 From: "Scharf, Michael (Michael)" To: Pasi Sarolahti , David Borman Date: Thu, 28 Mar 2013 20:19:46 +0100 Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: Ac4r5E2Q6b4X4vYwR5mOndIyPVCVRAAAU3vw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6F0E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20130328131155.58DE9D43B30@lawyers.icir.org> <31506_1364480834_51545342_31506_15_1_AD01EFBA971A0A4EBB41E1AF7D81F00026B420E6@ppomsg1> <714C2A4D-B15E-4D1C-84DA-8F0FD3ACC37A@iki.fi> In-Reply-To: <714C2A4D-B15E-4D1C-84DA-8F0FD3ACC37A@iki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard , "mallman@icir.org" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 19:20:00 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Pasi Sarolahti > Sent: Thursday, March 28, 2013 7:44 PM > To: David Borman > Cc: Joe Touch; tcpm (tcpm@ietf.org); Tim Shepard; mallman@icir.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt >=20 > On Mar 28, 2013, at 4:26 PM, David Borman wrote: >=20 > > Consensus doesn't mean we have 100% agreement, it means=20 > that everyone=20 > > has been able to express their opinion and that opinion has=20 > been heard=20 > > and understood, but the majority decision might still go a=20 > different way. >=20 > Right. We need to decide about how to proceed with the TSopt=20 > negotiation issue, and I think the list you present below are=20 > a good and concrete set of options we have on the table.=20 > Thanks for moving us forward. >=20 > So, I'd like to second David's request: additional input=20 > would be much appreciated, based on the options below. >=20 > > So it'd be really good to get some other comments from a=20 > larger pool=20 > > of people on where this should go so we can resolve this: > >=20 > > 1) No late enablement of TSopt: once it's negotiated, it's on for > > the rest of the connection. > >=20 > > 2) Allow for late enablement of TSopt, i.e., Richard's text. > >=20 > > 3) Allow late enablement of TSopt, and we hash out all the explicit > > details of every corner case we can think of. >=20 > As Michael said in an earlier Email, option 3) could be a=20 > separate I-D, but in that case it would (in my opinion) imply=20 > 2) for rfc1323bis. In my opinion, it would be good to try to=20 > keep rfc1323bis reasonably close to the original, otherwise=20 > we might still need to keep on working on it for quite a while... Indeed, I believe that 3) should be a separate document. For several reason= s: - 1323 is very widely deployed, while we talk here about a new feature that= differs to how TCP works today - 1323bis should really be finalized *now* - It would be good to have a dedicated document for how to realize late ena= blement, in case that it could be applied to options other than TS in futur= e - even if I am not sure if this will ever happen - A new ID gives us the chance to discuss PS vs. EXP separately - I persona= lly think it could be PS and thus update 1323bis, but I guess that some of = you will disagree with that Regarding 1) or 2), I think that a relevant criteria for 1323bis is what is= indeed deployed today. According to what has been said (I don't have own d= ata), this seems to be mostly 1) rather than 2). But, as already said, I'd = also support a follow-up PS draft that would update 1323bis to fix a known = bug therein ;) Michael (random community member) From mallman@icir.org Thu Mar 28 12:46:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E46621F8F86 for ; Thu, 28 Mar 2013 12:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxy+29--CvKm for ; Thu, 28 Mar 2013 12:46:34 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id CE3CD21F8E8F for ; Thu, 28 Mar 2013 12:46:34 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2SJkSWq019523; Thu, 28 Mar 2013 12:46:29 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EA480D4B412; Thu, 28 Mar 2013 15:46:28 -0400 (EDT) To: "Scharf, Michael (Michael)" From: Mark Allman In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6F0E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Thunderstruck X-URL-0: http://www.icir.org/mallman-files/Document81522.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma40468-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 28 Mar 2013 15:46:28 -0400 Sender: mallman@icir.org Message-Id: <20130328194628.EA480D4B412@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard , David Borman , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 19:46:35 -0000 ----------ma40468-1 Content-Type: text/plain Content-Disposition: inline > - 1323bis should really be finalized *now* Why? This just seems bogus to me. We've been waiting for a 1323bis for 10+ years. Why the sudden rush? Why are we pushing a 1323bis? Because of ... what? It seems to me that if we're going to bis anything it isn't to just get an updated date stamp on the same document, but we should incorporate what we have learned about the technology into the new document. It doesn't matter if that is difficult. It doesn't matter if that takes a little time. Yes, at some point we need to decide that a change is big enough that perhaps it isn't bis-worthy given the widespread use of this technology and punt to another document. But, I don't think we do that because we all the sudden after a zillion years need to push something to the IESG. I.e., calm down! :-) allman ----------ma40468-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFUnhQACgkQWyrrWs4yIs686QCfd2G6xQ4+OJ4Sw4gM7Ou43joR 01sAnR7BxjzaPNK7/uqMtG4YBXxAOfs4 =5xQP -----END PGP SIGNATURE----- ----------ma40468-1-- From prvs=279985f66c=david.borman@quantum.com Thu Mar 28 13:13:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6271C21F8F7A for ; Thu, 28 Mar 2013 13:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KudgxP+dNf6C for ; Thu, 28 Mar 2013 13:13:29 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 49EFD21F8F29 for ; Thu, 28 Mar 2013 13:13:29 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r2SKCkHs015091; Thu, 28 Mar 2013 13:13:12 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0a-000ceb01.pphosted.com with ESMTP id 1bc1pnmbe5-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Mar 2013 13:13:12 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 28 Mar 2013 14:12:42 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Thu, 28 Mar 2013 14:13:00 -0600 From: David Borman To: "mallman@icir.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOK/CkXKFwP0mgsEul/hgCNgCgYA== Date: Thu, 28 Mar 2013 20:12:09 +0000 Message-ID: References: <20130328194628.EA480D4B412@lawyers.icir.org> In-Reply-To: <20130328194628.EA480D4B412@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.176.229] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-28_07:2013-03-28, 2013-03-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303280204 Cc: Tim Shepard , "tcpm \(tcpm@ietf.org\)" , David Borman , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 20:13:30 -0000 On Mar 28, 2013, at 2:46 PM, Mark Allman wrote: >=20 >> - 1323bis should really be finalized *now* >=20 > Why? This just seems bogus to me. We've been waiting for a 1323bis for > 10+ years. Why the sudden rush? >=20 > Why are we pushing a 1323bis? Because of ... what? It seems to me that > if we're going to bis anything it isn't to just get an updated date > stamp on the same document, but we should incorporate what we have > learned about the technology into the new document. It doesn't matter > if that is difficult. It doesn't matter if that takes a little time. >=20 > Yes, at some point we need to decide that a change is big enough that > perhaps it isn't bis-worthy given the widespread use of this technology > and punt to another document. But, I don't think we do that because we > all the sudden after a zillion years need to push something to the > IESG. >=20 > I.e., calm down! :-) I hear you, Mark. But as you know we've been down the 1323bis path multiple times, and none of the previous attempts succeeded. With Richard doing a great job of editing the document, I think we are better poised then ever to get this done. My #1 reason for getting 1323bis published is to document and fix the known bugs in 1323, i.e. things in Appendix F, specifically item (b): (b) In RFC1323, section 3.4, step (2) of the algorithm to control which timestamp is echoed was incorrect in two regards: (1) It failed to update TS.recent for a retransmitted segment that resulted from a lost . (2) It failed if SEG.LEN =3D 0. In the new algorithm, the case of SEG.TSval >=3D TS.recent is included for consistency with the PAWS test. People only know things in Appendix F because of tribal knowledge, or looking at draft copies of 1323bis. That's why I'm willing to punt on late TS enablement in 1323bis in favor of getting something published, just like when 1323 was published we pulled out SACK so that 1323 could get published while the discussion continued about SACK. -David=20 =20 >=20 > allman >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From prvs=079904b879=anna.brunstrom@kau.se Thu Mar 28 15:32:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0559C21F8EFD for ; Thu, 28 Mar 2013 15:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbU7E+iWCUkS for ; Thu, 28 Mar 2013 15:32:13 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7821F8ED6 for ; Thu, 28 Mar 2013 15:32:08 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 28 Mar 2013 23:31:53 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 85.231.110.148 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <5154C4D4.2090801@kau.se> Date: Thu, 28 Mar 2013 23:31:48 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: rs@netapp.com References: <012C3117EDDB3C4781FD802A8C27DD4F24A7CD3E@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24A7CD3E@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: multipart/alternative; boundary="------------090808090906010509000605" Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 22:32:14 -0000 This is a multi-part message in MIME format. --------------090808090906010509000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Richard, Thanks for your comment. Given the limited gain of not having to store up to 3 additional values, it seems to us that discussing Timestamp usage with the potential issues it could bring about may not be worth the added document complexity. If there are strong opinions in favor of adding text related to the Timestamp option, we can of course incorporate that though. Best Regards, Anna On 2013-03-11 12:52, Scheffenegger, Richard wrote: > > Hi, > > In Section 3, wouldn't it make sense to add a comment, that tracking > the send times of the last packet that advanced Snd.Una could also be > accomplished using the Timestamp option? (With the potential issue > that a receiver could manipulate a nave implementation to RTO early, > by tweaking TSecr)... > > Richard Scheffenegger > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------090808090906010509000605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Richard,

    Thanks for your comment.

    Given the limited gain of not having to store up to 3 additional  values, it seems to us that discussing Timestamp usage with the potential issues it could bring about may not be worth the added document complexity. If there are strong opinions in favor of adding text related to the Timestamp option, we can of course incorporate that though.

    Best Regards,
    Anna

    On 2013-03-11 12:52, Scheffenegger, Richard wrote:

    Hi,

     

    In Section 3, wouldn’t it make sense to add a comment, that tracking the send times of the last packet that advanced Snd.Una could also be accomplished using the Timestamp option?  (With the potential issue that a receiver could manipulate a naïve implementation to RTO early, by tweaking TSecr)…

     

    Richard Scheffenegger




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

    --------------090808090906010509000605-- From john@jlc.net Fri Mar 29 06:32:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B092421F93FC for ; Fri, 29 Mar 2013 06:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.836 X-Spam-Level: X-Spam-Status: No, score=-105.836 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K+dwgK8hHUs for ; Fri, 29 Mar 2013 06:32:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 171C121F9409 for ; Fri, 29 Mar 2013 06:32:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F052A33C29; Fri, 29 Mar 2013 09:32:24 -0400 (EDT) Date: Fri, 29 Mar 2013 09:32:24 -0400 From: John Leslie To: Joe Touch Message-ID: <20130329133224.GD12940@verdi> References: <20130328032540.602F2D42A02@lawyers.icir.org> <22EBDF24-9FD3-41AD-816B-2782B0AC2EF5@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22EBDF24-9FD3-41AD-816B-2782B0AC2EF5@isi.edu> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 13:32:25 -0000 Joe Touch wrote: > > On Mar 27, 2013, at 8:25 PM, Mark Allman wrote: >> >> I think this is just absurd. This is about PAWS. > > If you want absurd, see PAWS. That mechanism can be accomplished > with a very short option that encodes the top byte(s) of an extended > sequence number space - in much fewer than 10 bytes. I've got to agree with Joe here. PAWS is complicated, non-intutitive, and drains entirely too much TCP option space. If the function is important, we should design a better way to do it. If, OTOH, the funtion isn't worth designing a better way, I'd let the sleeping dogs lie until we can deprecate it. RFC 1323 seems to deserve a path to Historic... -- John Leslie From rs@netapp.com Fri Mar 29 06:53:37 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E116621F9304 for ; Fri, 29 Mar 2013 06:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lroIO6wRml3e for ; Fri, 29 Mar 2013 06:53:36 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE9D21F93A9 for ; Fri, 29 Mar 2013 06:53:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,373,1363158000"; d="scan'208";a="35187415" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 29 Mar 2013 06:53:30 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2TDrUGf003701; Fri, 29 Mar 2013 06:53:30 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Fri, 29 Mar 2013 06:53:30 -0700 From: "Scheffenegger, Richard" To: John Leslie , Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOK2PrEQ5O4ow3akyRO3tyovxcH5i7FKeAgAINmwD//41AQA== Date: Fri, 29 Mar 2013 13:53:29 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ADA8A8@SACEXCMBX02-PRD.hq.netapp.com> References: <20130328032540.602F2D42A02@lawyers.icir.org> <22EBDF24-9FD3-41AD-816B-2782B0AC2EF5@isi.edu> <20130329133224.GD12940@verdi> In-Reply-To: <20130329133224.GD12940@verdi> 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] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 13:53:38 -0000 > RFC 1323 seems to deserve a path to Historic... You sure? That's make WindowScale historic too.... (and yes, the mingling of WS, TS a= nd SACK in one RFC1072 two decades ago was not the wisest approach). I think 1323bis should finally be published, simply to fix the omissions an= d bugs of the original text in 1323. And for the time being, PLEASE let us not discuss the merits of using RTTM/= PAWS/TSopt;=20 Most stacks leave that as a global option, and from what I can tell, many d= isable this by default. And that is fine. But if one chooses to use TS, the= mechanisms should be described properly, without any significant issues in= the RFC for someone how is not into hunting down bug fixes to an RFC in ru= nning code.=20 And WS, as described in 1323, does have its share of issues (implementers n= ot considering window retractions properly).=20 I'll post a -08 shortly, for a consolidated text. I would urge anyone who h= as a major bone to pick with the TSopt, to come up with improved text (than= ks Joe for suggesting improvements). So far, the existing text describes th= e typical TSopt use case / state machine.=20 Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > John Leslie > Sent: Freitag, 29. M=E4rz 2013 14:32 > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt >=20 > Joe Touch wrote: > > > > On Mar 27, 2013, at 8:25 PM, Mark Allman wrote: > >> > >> I think this is just absurd. This is about PAWS. > > > > If you want absurd, see PAWS. That mechanism can be accomplished with > > a very short option that encodes the top byte(s) of an extended > > sequence number space - in much fewer than 10 bytes. >=20 > I've got to agree with Joe here. PAWS is complicated, non-intutitive, > and drains entirely too much TCP option space. If the function is > important, we should design a better way to do it. >=20 > If, OTOH, the funtion isn't worth designing a better way, I'd let the > sleeping dogs lie until we can deprecate it. >=20 > RFC 1323 seems to deserve a path to Historic... >=20 > -- > John Leslie > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From john@jlc.net Fri Mar 29 07:02:57 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D6E21F9414 for ; Fri, 29 Mar 2013 07:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.689 X-Spam-Level: X-Spam-Status: No, score=-105.689 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03gl-0EI4Bga for ; Fri, 29 Mar 2013 07:02:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3772A21F9410 for ; Fri, 29 Mar 2013 07:02:56 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3CC9533C21; Fri, 29 Mar 2013 10:02:56 -0400 (EDT) Date: Fri, 29 Mar 2013 10:02:56 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20130329140256.GE12940@verdi> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> <20130327180524.GA12940@verdi> <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 14:02:57 -0000 Scheffenegger, Richard wrote: > From: John Leslie [mailto:john@jlc.net] > >>> Once TSopt has been successfully negotiated during the , >>> exchange, TSopt MUST be sent in every non- segment for >>> the duration of the connection. >> >> I didn't find this MUST anywhere in RFC 1323. Did I miss something? > > No; as mentioned on this list, certain mechanisms assume the permanent > use of Tsopt right after the successful negotiation. Hmm... there's that "assume" word... > This text was added by David in 2007 > ( http://tools.ietf.org/html/draft-borman-1323bis-00 ): > > Once a TSopt has been sent or received in a > non segment, it must be sent in all segments. Once a > TSopt has been received in a non segment, then any > successive segment that is received without the RST bit and > without a TSopt may be ACKed and dropped without further > processing. It's a definite problem that IETF process sometimes leaves things in limbo for six years. (That draft perhaps predates datatracker.ietf?) No doubt there are implementations out there that haven't waited for a 1323bis to become an RFC. :^( Sorry to say: they proceeded at their own risk, and deserve to suffer the consequences. This does not mean I wish to punish them. They presumably _can_ interoperate with enough other nodes to be worth the trouble. We can quite reasonably describe their situation, whether or not it happens in a 1323-bis. What we should NOT do is publish a 1323-bis that ONLY caters to them. David Borman's 2007 text, IMHO, has been overcome by events. > After the discussions on this list, it seemed to be better to not > leave any potential gap between the 3WHS negotiation, and the actual > use of the TS option. All the implementations that I know of > effectively work that way. The phrase "rearranging the deck chairs on the Titanic" comes to mind... We can legitimately say, "All the implementations we know..." -- but there _will_ be others we don't know. I strongly advise against changing any behavior of TSopt from the original 1323 language. I'm sure that I'm regarded as a Johnny-come-lately here; and I won't deny the name. But, alas!, it's _very_ hard to get enough review of Internet Drafts before LastCall happens. >>> If a TSopt is received on a connection where TSopt was not negotiated >>> in the initial three-way handshake, the TSopt MUST be ignored and the >>> packet processed normally. >> >> This would have been good to include in RFC 1323, but I wonder what it >> accomplishes to add it now. > > Just to make this behavior explicit. I'm not arguing the language -- I'm thinking we have no way of knowing whether the other end is speaking 1323 or 1323-bis. Thus the value of a MUST to ensure interoperability seems dubious. > There is another example in the dreded RTTM mechanism. 1323 just > stated that any ACK that indicates loss/reordering should be > excluded. Most ACKs that contain SACK do indicate some loss/reordering, > but when I investigated, these ACKs are still used to update RTO > under certain circumstances. "In certain circumstances" this could possibly be quite correct. I wouldn't assign 1323 a particularly high precedence here -- but it's probably worth noting the corner case. Measuring Round Trip Time is somewhat of a black art. No doubt many in-the-field measurements are just plain wrong. I've given up any hope of fixing them. :^( > Thus the added text there to explicitly exclude ACK+SACK for the > RTTM mechanism. If that's the desire, it should be explained. Adding one more MUST won't do the trick. -- John Leslie From internet-drafts@ietf.org Fri Mar 29 07:18:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C61721F9434; Fri, 29 Mar 2013 07:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrZiXnL01JJG; Fri, 29 Mar 2013 07:18:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC4321F8632; Fri, 29 Mar 2013 07:18:51 -0700 (PDT) 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.43 Message-ID: <20130329141851.23853.29732.idtracker@ietfa.amsl.com> Date: Fri, 29 Mar 2013 07:18:51 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 14:18: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-08.txt Pages : 44 Date : 2013-03-29 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 TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Fri Mar 29 07:55:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B84521F86A6 for ; Fri, 29 Mar 2013 07:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnJcvAeu5aT6 for ; Fri, 29 Mar 2013 07:55:32 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 33FCE21F8691 for ; Fri, 29 Mar 2013 07:55:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,373,1363158000"; d="scan'208";a="35205054" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 29 Mar 2013 07:55:31 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2TEtVtR019506; Fri, 29 Mar 2013 07:55:31 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Fri, 29 Mar 2013 07:55:31 -0700 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAI9wwD//5A/4A== Date: Fri, 29 Mar 2013 14:55:30 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ADA90A@SACEXCMBX02-PRD.hq.netapp.com> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> <20130327180524.GA12940@verdi> <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> <20130329140256.GE12940@verdi> In-Reply-To: <20130329140256.GE12940@verdi> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 14:55:33 -0000 Hi John, > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] >>> >>> I didn't find this MUST anywhere in RFC 1323. Did I miss something? >> >> No; as mentioned on this list, certain mechanisms assume the permanent >> use of Tsopt right after the successful negotiation. >=20 > Hmm... there's that "assume" word... Well, Section 4.2 in RFC1323 already states: 4.2 The PAWS Mechanism PAWS uses the same TCP Timestamps option as the RTTM mechanism described earlier, and assumes that every received TCP segment (including data and ACK segments) contains a timestamp SEG.TSval whose values are monotone non-decreasing in time. Joe pointed out, that dubious forward references (and 1323 didn't even have= a forward reference in 3.2 when talking about the TSopt signal) in a docum= ent should be avoided.=20 The new text in -bis-08 now clearly states, that TSopt MUST be present, aft= er successful negotiation. Omitting TSopt would - at best (ie. Linux) - lea= ve PAWS in an undefined state; But then, apparently, Linux doesn't implemen= t PAWS as intended (see Ilpo's comment) anyway. =20 >> This text was added by David in 2007 >> ( http://tools.ietf.org/html/draft-borman-1323bis-00 ): >> >> Once a TSopt has been sent or received in a non segment, it >> must be sent in all segments. Once a TSopt has been received in a >> non segment, then any successive segment that is received >> without the RST bit and without a TSopt may be ACKed and dropped >> without further processing. >=20 > It's a definite problem that IETF process sometimes leaves things in > limbo for six years. (That draft perhaps predates datatracker.ietf?) >=20 > No doubt there are implementations out there that haven't waited for a > 1323bis to become an RFC. :^( Sorry to say: they proceeded at their own > risk, and deserve to suffer the consequences. >=20 > This does not mean I wish to punish them. They presumably _can_ > interoperate with enough other nodes to be worth the trouble. We can quit= e > reasonably describe their situation, whether or not it happens in a 1323- > bis. What we should NOT do is publish a 1323-bis that ONLY caters to them= . 1323 already had that in it; just not explicitly worded in section 3.2 (onl= y mentioned in passing in section 4.2). I don't see how this is really chan= ges the mechanisms in 1323. True, it closes the door on certain potential t= hings that 1323 left unspecified (like late TS enablement).=20 =20 > David Borman's 2007 text, IMHO, has been overcome by events. Such as? Do you know of an example where late enablement of Tsopt is done? = Judging the comments, I think David's 2007 text is more relevant (the -08 m= akes it even more restrictive, disallowing any data/ACK without TSopt, whic= h seems to be less controversial). >> After the discussions on this list, it seemed to be better to not >> leave any potential gap between the 3WHS negotiation, and the actual >> use of the TS option. All the implementations that I know of >> effectively work that way. > > The phrase "rearranging the deck chairs on the Titanic" comes to > mind... As long as it contributes to a peace of mind in the end... :) > We can legitimately say, "All the implementations we know..." -- but > there _will_ be others we don't know. I strongly advise against changing > any behavior of TSopt from the original 1323 language. What is then the point of a -bis, if not giving guidance to implementers to= NOT interpret too limited text in a problematic way, and fixing issues wit= h the (internal) mechanisms described? > I'm sure that I'm regarded as a Johnny-come-lately here; and I won't > deny the name. But, alas!, it's _very_ hard to get enough review of > Internet Drafts before LastCall happens. Better late than never; But I need to understand your concerns, and what yo= u propose for the -bis, in more detail. I like the feedback, but I cann't m= ake out what you are suggesting (as text in the -bis). >>>> If a TSopt is received on a connection where TSopt was not >>>> negotiated in the initial three-way handshake, the TSopt MUST be >>>> ignored and the packet processed normally. >>> >>> This would have been good to include in RFC 1323, but I wonder what >>> it accomplishes to add it now. >> >> Just to make this behavior explicit. >=20 > I'm not arguing the language -- I'm thinking we have no way of knowing > whether the other end is speaking 1323 or 1323-bis. Thus the value of a > MUST to ensure interoperability seems dubious. The (bug-fixed) mechanisms stay the same; 1323bis fixes the wording to avoi= d buggy implementations. If there was a stack that does late negotiation (a= s 1323 does allow this), a 1323bis stack would simply continue running all = the regular (non-TSopt) mechanisms, rather than starting to use PAWS on the= receiver side.=20 Am I missing something here? >> There is another example in the dreded RTTM mechanism. 1323 just >> stated that any ACK that indicates loss/reordering should be excluded. >> Most ACKs that contain SACK do indicate some loss/reordering, but when >> I investigated, these ACKs are still used to update RTO under certain >> circumstances. >=20 > "In certain circumstances" this could possibly be quite correct. Highly doubtful. That "certain circumstance" involves one dropped packet on= the forward path, and at least the last in-sequence ACK dropped on the ret= urn path; A sender taking a RTT measurement from the next ACK(SACK) will in= flate the RTO, and suffer from a longer retransmission timeout... The new wording doesn't change the spirit of the RTTM mechanism one bit, bu= t clearly points out, that the presence of a SACK option indicates somethin= g, where the RTT measurement should better not be taken. But this is a very= common implementation issue I noticed. > I wouldn't assign 1323 a particularly high precedence here -- but it's > probably worth noting the corner case. >=20 > Measuring Round Trip Time is somewhat of a black art. No doubt many in= - > the-field measurements are just plain wrong. I've given up any hope of > fixing them. :^( RTTM and OWDV (one way delay variance) don't do that well with the TS seman= tics from 1323(-bis) either. But I won't return to this topic as long as 13= 23bis is lingering. >> Thus the added text there to explicitly exclude ACK+SACK for the RTTM >> mechanism. >=20 > If that's the desire, it should be explained. Adding one more MUST > won't do the trick. The explanation is already in 1323: However, the following rule prevents a resulting inflation of the measured RTT: A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window. The omission in 1323 was to not call out the case, where the returning ACKs= are partially lost too, which inflates the next measurement. Without SACK,= there is not much to do about this; with SACK, that one "MUST" should suff= ice. I could also come up with some text describing the corner case above, if th= at helps, or add a TSG... Best regards, Richard From rs@netapp.com Fri Mar 29 08:10:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCB421F9456 for ; Fri, 29 Mar 2013 08:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.36 X-Spam-Level: X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3CVBrBvQTnL for ; Fri, 29 Mar 2013 08:10:21 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4CA21F9451 for ; Fri, 29 Mar 2013 08:10:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,373,1363158000"; d="scan'208";a="35210325" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 29 Mar 2013 08:10:21 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2TFAJcG012119; Fri, 29 Mar 2013 08:10:20 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Fri, 29 Mar 2013 08:10:19 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti , David Borman Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt Thread-Index: AQHOK+Q2EQ5O4ow3akyRO3tyovxcH5i8w/IA Date: Fri, 29 Mar 2013 15:10:19 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ADA942@SACEXCMBX02-PRD.hq.netapp.com> References: <20130328131155.58DE9D43B30@lawyers.icir.org> <31506_1364480834_51545342_31506_15_1_AD01EFBA971A0A4EBB41E1AF7D81F00026B420E6@ppomsg1> <714C2A4D-B15E-4D1C-84DA-8F0FD3ACC37A@iki.fi> In-Reply-To: <714C2A4D-B15E-4D1C-84DA-8F0FD3ACC37A@iki.fi> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , Tim Shepard , "mallman@icir.org" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 15:10:22 -0000 Hi, > -----Original Message----- > From: Pasi Sarolahti >=20 >=20 > So, I'd like to second David's request: additional input would be much > appreciated, based on the options below. >=20 >> So it'd be really good to get some other comments from a larger pool >> of people on where this should go so we can resolve this: >> >> 1) No late enablement of TSopt: once it's negotiated, it's on for >> the rest of the connection. Note, that text in 1323bis-08 now aligns with option 1) - explicitly disall= ow late TSopt enablement. >> 2) Allow for late enablement of TSopt, i.e., Richard's text. >> >> 3) Allow late enablement of TSopt, and we hash out all the explicit >> details of every corner case we can think of. As Joe pointed out, late enablement with a 10 (12) -byte option in the SYN = is kind of pointless. Also, such a mechanism warrants a full draft in it's = own right (and there are three authors working on that, see=20 http://tools.ietf.org/html/draft-trammell-tcpm-timestamp-interval-00 and=20 http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-0= 5=20 which really is mostly a problem statement / requirements draft, but leavin= g out the late negotiation part in the published draft. I hope that going with option 1 meets more the consensus of the WG. Regards, Richard From mallman@icir.org Fri Mar 29 09:22:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA77C21F92B2 for ; Fri, 29 Mar 2013 09:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DisbaskTS8QU for ; Fri, 29 Mar 2013 09:22:18 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2011E21F91F3 for ; Fri, 29 Mar 2013 09:22:18 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r2TGM7jh008693; Fri, 29 Mar 2013 09:22:07 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 811FBD516E4; Fri, 29 Mar 2013 12:22:06 -0400 (EDT) To: David Borman From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Street Fighting Man X-URL-0: http://www.icir.org/mallman-files/Document29661.jpg X-URL-1: http://www.icir.org/mallman-files/Document49515.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49070-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 29 Mar 2013 12:22:06 -0400 Sender: mallman@icir.org Message-Id: <20130329162206.811FBD516E4@lawyers.icir.org> Cc: Tim Shepard , "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:22:20 -0000 ----------ma49070-1 Content-Type: text/plain Content-Disposition: inline > I hear you, Mark. But as you know we've been down the 1323bis path > multiple times, and none of the previous attempts succeeded. With > Richard doing a great job of editing the document, I think we are better > poised then ever to get this done. Well, I guess we view this differently. I'd say if we have energy then lets do what needs to be done. If you want to play small ball and fix only the small and minor things then I think that'd be disappointing, but at least I think it'd be good to catalog the bigger issues that have been raised. allman ----------ma49070-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlFVv64ACgkQWyrrWs4yIs5HkwCdHjg4xGA6OemynHxmABAWoRqb RLUAoIY20o6e33SVwhGWdEzcmK1adkNk =DLgT -----END PGP SIGNATURE----- ----------ma49070-1-- From ycheng@google.com Fri Mar 29 12:48:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED0D21F883A for ; Fri, 29 Mar 2013 12:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS3z1qSVdeYy for ; Fri, 29 Mar 2013 12:48:14 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id E174D21F8837 for ; Fri, 29 Mar 2013 12:48:13 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so158360wib.10 for ; Fri, 29 Mar 2013 12:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=+WBLxGXAF0f+Z2S29J1cjHit2MPHCN6Ptc5WFulHgz0=; b=CN14eTBl6n0u8M7WjGtPZuhnBy8/XYqeKdic/xcPzcOCb73TS/l5LytOcCmy7JRl4t /lxDfSpOXp5TQtUd6eSfR3uFyBK1J/gsmr6KEZgN3CAvNbHdyahCeVo5py+l0s2hY6cj sDElJqUiArcuUP9TOIAVGjGA3Akr9tslM8iAG7UzYXNlq5b9W1pG/5hr79f/YpLJp95K 2M8E4Mno0U8Ssoz3VFr0yHqQfBJV1NWzup553gUl2V9I5sjZRPsyACjEYC9G8VPHl8/x 8ynrfj+IBwVxgWYNgwesceHgzm+XGNfBMlSYjYUAaNopDn6z69MX4Dy4j9QC56UXvd5T +9/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=+WBLxGXAF0f+Z2S29J1cjHit2MPHCN6Ptc5WFulHgz0=; b=USKS8DZzcC/8TPxBluVVPQwHt8vqRAxRiWzuJ8oL9HuZNW0S2a9U5ASSajpMjf5+sB dU/kf1nfT1d466Rs8s5MhAE0lTuGNk9e6wp9N4/n3hjHzkvBKZ989qKwYfTDLoFb6fZ6 ZPevQ4FHamNmuA+84OqrIcqck051/nmsawfnjQxaNNdj38VsI6pTtquxRZnWCsV7qHFP 3ANHe1Dvv+kijT3dIDfFi307sUSG8kgc8WOlUywp2UD8Uc5mbTPPE6xb+77B0ezZBmqZ 80RMdqKfkzZXbM1FozjHpQU8cfiY9tNbUcNoOaDfVYDnGlDdYTNiQ0gT6b0hhjuuPJWv CcHg== X-Received: by 10.194.220.70 with SMTP id pu6mr5299942wjc.27.1364586492982; Fri, 29 Mar 2013 12:48:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.19.68 with HTTP; Fri, 29 Mar 2013 12:47:52 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> <20130327180524.GA12940@verdi> <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Fri, 29 Mar 2013 12:47:52 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnAMUPx/aM7ZPh78J2DzG/DWf93Of9W36w34QAQrYzp1eWKMJgnQo1UzCPcydqFUiEcQL0fVtWFcZx+mRED9VTzOlaJJn79RDtbDp1kZjDBJb2ZaPbwCzdnWA54J/RmgtjIAazDqzUOXq3RvAPD0xRZq3APqxN0kAPRlnY21MiQghgcxeFDnSj+gfaMWHyewUleHIfO Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 19:48:15 -0000 On Thu, Mar 28, 2013 at 4:13 AM, Scheffenegger, Richard wro= te: > Hi John, > >> From: John Leslie [mailto:john@jlc.net] >> > A TCP MAY send the Timestamp option (TSopt) in an initial >> > segment (i.e., segment containing a SYN bit and no ACK bit), and MA= Y >> > send a TSopt in other segments only if it received a TSopt in the >> > initial or segment for the connection. >> >> That much is the original RFC 1323 text, right? > > With minor editorial changes and an update to RFC2119 wording, yes. > > >> > Once TSopt has been successfully negotiated during the , >> > exchange, TSopt MUST be sent in every non- segment f= or >> > the duration of the connection. >> >> I didn't find this MUST anywhere in RFC 1323. Did I miss something? > > No; as mentioned on this list, certain mechanisms assume the permanent us= e of Tsopt right after the successful negotiation. This text was added by D= avid in 2007 ( http://tools.ietf.org/html/draft-borman-1323bis-00 ): > > Once a TSopt has been sent or received in a > non segment, it must be sent in all segments. Once a > TSopt has been received in a non segment, then any > successive segment that is received without the RST bit and > without a TSopt may be ACKed and dropped without further > processing. > > After the discussions on this list, it seemed to be better to not leave a= ny potential gap between the 3WHS negotiation, and the actual use of the TS= option. All the implementations that I know of effectively work that way. > > >> > If a non- segment is received without a TSopt, a TCP MAY drop >> > the segment and MAY send an for the last in-sequence segment. >> >> This text confuses me. I don't particularly want to argue it, but I'm >> at a loss to understand how it helps. (There are four cases, right? And >> there seem to be a couple of unnamed variables as well.) > > Well, the 2nd MAY is superfluous, I guess at this reading. But I'm open f= or better wording suggestions. > > >> > A TCP MUST NOT abort a TCP connection if a non- segment is >> > received without a TSopt. >> >> This sounds reasonable at first blush, but I don't see how anyone cou= ld >> depend on it. >> >> > If a TSopt is received on a connection where TSopt was not negotiat= ed >> > in the initial three-way handshake, the TSopt MUST be ignored and t= he >> > packet processed normally. >> >> This would have been good to include in RFC 1323, but I wonder what i= t >> accomplishes to add it now. > > Just to make this behavior explicit. There is another example in the dred= ed RTTM mechanism. 1323 just stated that any ACK that indicates loss/reorde= ring should be excluded. Most ACKs that contain SACK do indicate some loss/= reordering, but when I investigated, these ACKs are still used to update RT= O under certain circumstances. Thus the added text there to explicitly excl= ude ACK+SACK for the RTTM mechanism. This caught my attention; I am stunned. I can't believe it :( """ However, the following rule prevents a resulting inflation of the measured = RTT: ... b) the segment does not indicate any loss or reordering, i.e. contains SACK options """ The RTT of the ack contains a SACK reflects the delay when the network is in trouble, and we want to toss it and not update the RTO. It's still 3 days before April 1st. > > >> > In the case of crossing segments where one contains a >> > TSopt and the other doesn't, both sides SHOULD put a TSopt in the >> > segment. >> >> This sounds funny: very likely the one that didn't send TSopt doesn't >> want to dedicate N bytes of option space in every packet. > > This is new text; it was added in 2009 in http://tools.ietf.org/html/draf= t-ietf-tcpm-1323bis-01 > We could leave that case undefined, as in 1323... > > >> > TSopt is required for the two mechanisms described in sections 3.3 >> > and 4.2. There are also other mechanisms that rely on the presence >> > of the TSopt, e.g. [RFC3522]. If a TCP stopped sending TSopt at a= ny >> > time during an established session, it interferes with these >> > mechanisms. This update to [RFC1323] describes explicitly the >> > previous implicit assumption, that each TCP segment must have TSopt= , >> > once negotiated. >> >> No doubt some of us believe such an assumption was "implicit"; and >> quite possibly there are implementations which won't interoperate withou= t >> that assumption being valid. >> >> Nonetheless, I find it hard to believe that any implementations break >> horribly if the assumption fails. >> >> Writing a 1323-bis, the question isn't simply, "What should we have >> said the first time?" We must include, "How do we get here from there?" >> This is hard, IMHO: which is why I suggested a new aption instead. > > I agree, things will usually not go terribly wrong if the assumptions don= 't hold, but the implementations seen behave as described in the latest tex= t. I think it would be save to clearly state, that this is how to actually = use TSopt... > > Richard > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Fri Mar 29 12:53:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2D721F8786 for ; Fri, 29 Mar 2013 12:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNecDHcKVBsg for ; Fri, 29 Mar 2013 12:53:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A9A6721F869A for ; Fri, 29 Mar 2013 12:53:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2TJqwW7024340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Mar 2013 12:52:58 -0700 (PDT) Message-ID: <5155F112.5010707@isi.edu> Date: Fri, 29 Mar 2013 12:52:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Leslie References: <20130328032540.602F2D42A02@lawyers.icir.org> <22EBDF24-9FD3-41AD-816B-2782B0AC2EF5@isi.edu> <20130329133224.GD12940@verdi> In-Reply-To: <20130329133224.GD12940@verdi> 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: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2013 19:53:20 -0000 On 3/29/2013 6:32 AM, John Leslie wrote: > Joe Touch wrote: >> >> On Mar 27, 2013, at 8:25 PM, Mark Allman wrote: >>> >>> I think this is just absurd. This is about PAWS. >> >> If you want absurd, see PAWS. That mechanism can be accomplished >> with a very short option that encodes the top byte(s) of an extended >> sequence number space - in much fewer than 10 bytes. > > I've got to agree with Joe here. PAWS is complicated, non-intutitive, > and drains entirely too much TCP option space. If the function is > important, we should design a better way to do it. Stay tuned ;-) I'm working on it. Not that it affects this discussion, though. Joe From rs@netapp.com Fri Mar 29 23:10:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C661221F85EE for ; Fri, 29 Mar 2013 23:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.08 X-Spam-Level: X-Spam-Status: No, score=-10.08 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYtB7n1hwUQJ for ; Fri, 29 Mar 2013 23:10:35 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id E435E21F859D for ; Fri, 29 Mar 2013 23:10:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,377,1363158000"; d="scan'208";a="249655379" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 29 Mar 2013 23:10:34 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2U6AYn7001175; Fri, 29 Mar 2013 23:10:34 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Fri, 29 Mar 2013 23:10:33 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4A== Date: Sat, 30 Mar 2013 06:10:33 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327151735.7F3FDD35AE3@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24AD28FF@SACEXCMBX02-PRD.hq.netapp.com> <20130327180524.GA12940@verdi> <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> 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.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 30 Mar 2013 06:10:35 -0000 Hi Yuchung, In the following scenario, what should the left side (sender) do, when the last ACK arrives? ---------------------> <---------------- ---------------------> X-------------- -------------------X ---------------------> <------- If RTT is the quantity to be measured, updating with that last ACK (which, = for the sender, updates the left edge of the window - thus is acceptable in= 1323, when ignoring SACK - as most stacks do) would inflate sRTT and RTTva= r, increasing the RTO. And sRTT is *not* the RTT of the network. My point being, if the mechanism is to measure RTT, it should do this (with= the current semantics, the only sensible approach would be that the last A= CK must be ignored). If the point is to only come up with some conservative estimate for RTO (an= d an even more conservative estimate in this case), the current text and im= plementations are fine even though that last ACK does indicate loss... However, the variables sRTT and RTTvar need to have a connotation that they= are *only* intermediary values just used for RTO purposes and nothing else= , and should be renamed that they are NOT to be used for anything but RTO e= stimation. Other (future, experimental) mechanisms need to derive their own= state then. =20 Best regards, =20 =20 Richard Scheffenegger > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Freitag, 29. M=E4rz 2013 20:48 > To: Scheffenegger, Richard > Cc: John Leslie; tcpm@ietf.org > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > WGLC) >=20 > On Thu, Mar 28, 2013 at 4:13 AM, Scheffenegger, Richard > wrote: > > Hi John, > > > >> From: John Leslie [mailto:john@jlc.net] > >> > A TCP MAY send the Timestamp option (TSopt) in an initial > >> > segment (i.e., segment containing a SYN bit and no ACK bit), and > MAY > >> > send a TSopt in other segments only if it received a TSopt in the > >> > initial or segment for the connection. > >> > >> That much is the original RFC 1323 text, right? > > > > With minor editorial changes and an update to RFC2119 wording, yes. > > > > > >> > Once TSopt has been successfully negotiated during the , > >> > exchange, TSopt MUST be sent in every non- segment > for > >> > the duration of the connection. > >> > >> I didn't find this MUST anywhere in RFC 1323. Did I miss something? > > > > No; as mentioned on this list, certain mechanisms assume the permanent > use of Tsopt right after the successful negotiation. This text was added > by David in 2007 ( http://tools.ietf.org/html/draft-borman-1323bis-00 ): > > > > Once a TSopt has been sent or received in a > > non segment, it must be sent in all segments. Once a > > TSopt has been received in a non segment, then any > > successive segment that is received without the RST bit and > > without a TSopt may be ACKed and dropped without further > > processing. > > > > After the discussions on this list, it seemed to be better to not leave > any potential gap between the 3WHS negotiation, and the actual use of the > TS option. All the implementations that I know of effectively work that > way. > > > > > >> > If a non- segment is received without a TSopt, a TCP MAY dro= p > >> > the segment and MAY send an for the last in-sequence > segment. > >> > >> This text confuses me. I don't particularly want to argue it, but > I'm > >> at a loss to understand how it helps. (There are four cases, right? An= d > >> there seem to be a couple of unnamed variables as well.) > > > > Well, the 2nd MAY is superfluous, I guess at this reading. But I'm open > for better wording suggestions. > > > > > >> > A TCP MUST NOT abort a TCP connection if a non- segment is > >> > received without a TSopt. > >> > >> This sounds reasonable at first blush, but I don't see how anyone > could > >> depend on it. > >> > >> > If a TSopt is received on a connection where TSopt was not > negotiated > >> > in the initial three-way handshake, the TSopt MUST be ignored and > the > >> > packet processed normally. > >> > >> This would have been good to include in RFC 1323, but I wonder what > it > >> accomplishes to add it now. > > > > Just to make this behavior explicit. There is another example in the > dreded RTTM mechanism. 1323 just stated that any ACK that indicates > loss/reordering should be excluded. Most ACKs that contain SACK do > indicate some loss/reordering, but when I investigated, these ACKs are > still used to update RTO under certain circumstances. Thus the added text > there to explicitly exclude ACK+SACK for the RTTM mechanism. >=20 > This caught my attention; I am stunned. I can't believe it :( > """ > However, the following rule prevents a resulting inflation of the measure= d > RTT: > ... > b) the segment does not indicate any loss or reordering, i.e. > contains SACK options > """ >=20 > The RTT of the ack contains a SACK reflects the delay when the network > is in trouble, and we want to toss it and not update the RTO. It's > still 3 days before April 1st. >=20 >=20 > > > > > >> > In the case of crossing segments where one contains a > >> > TSopt and the other doesn't, both sides SHOULD put a TSopt in the > >> > segment. > >> > >> This sounds funny: very likely the one that didn't send TSopt > doesn't > >> want to dedicate N bytes of option space in every packet. > > > > This is new text; it was added in 2009 in > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-01 > > We could leave that case undefined, as in 1323... > > > > > >> > TSopt is required for the two mechanisms described in sections 3.= 3 > >> > and 4.2. There are also other mechanisms that rely on the > presence > >> > of the TSopt, e.g. [RFC3522]. If a TCP stopped sending TSopt at > any > >> > time during an established session, it interferes with these > >> > mechanisms. This update to [RFC1323] describes explicitly the > >> > previous implicit assumption, that each TCP segment must have > TSopt, > >> > once negotiated. > >> > >> No doubt some of us believe such an assumption was "implicit"; and > >> quite possibly there are implementations which won't interoperate > without > >> that assumption being valid. > >> > >> Nonetheless, I find it hard to believe that any implementations > break > >> horribly if the assumption fails. > >> > >> Writing a 1323-bis, the question isn't simply, "What should we have > >> said the first time?" We must include, "How do we get here from there?= " > >> This is hard, IMHO: which is why I suggested a new aption instead. > > > > I agree, things will usually not go terribly wrong if the assumptions > don't hold, but the implementations seen behave as described in the lates= t > text. I think it would be save to clearly state, that this is how to > actually use TSopt... > > > > Richard > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm