From alexander.zimmermann@comsys.rwth-aachen.de Mon Apr 1 11: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 D8AE71F0CE0 for ; Mon, 1 Apr 2013 11:13:30 -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_DE=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 zZnY9mBFoC+l for ; Mon, 1 Apr 2013 11:13:30 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id C01021F0C74 for ; Mon, 1 Apr 2013 11:13:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from mx-out-1.rwth-aachen.de ([134.130.5.186]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MKL00CMI9AFVM40@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 01 Apr 2013 20:13:28 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.87,387,1363129200"; d="scan'208";a="216405520" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-1.rz.rwth-aachen.de with ESMTP; Mon, 01 Apr 2013 20:13:28 +0200 Received: from [192.168.4.13] ([unknown] [77.109.123.195]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MKL00K3X9AFUS30@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 01 Apr 2013 20:13:27 +0200 (CEST) From: Alexander Zimmermann Message-id: Date: Mon, 01 Apr 2013 20:13:27 +0200 To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1503) Subject: [tcpm] Roadmap for TCP - New Version 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, 01 Apr 2013 18:13:31 -0000 Hi Group, today I finally submit a new version of the TCP roadmap. Sorry for the long delay :-) I include all new RFCs up to the new RFC 6897. Based on a email from Wes I also include all old, forgotten RFC into the roadmap (*). Moreover I change a little bit the structure of the doc. Basically, I introduce some new sections and subsections so that the reader can find more easily the RFCs in question. The new structure is fully aligned with RFC 5783 (Congestion Control in the RFC Series). Happy for feedback Alex --- A new version of I-D, draft-zimmermann-tcpm-tcp-rfc4614bis-01.txt has been successfully submitted by Alexander Zimmermann and posted to the IETF repository. Filename: draft-zimmermann-tcpm-tcp-rfc4614bis Revision: 01 Title: A Roadmap for Transmission Control Protocol (TCP) Specification Documents Creation date: 2013-04-01 Group: Individual Submission Number of pages: 46 URL: http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-tcp-rfc4614bis-01.txt Status: http://datatracker.ietf.org/doc/draft-zimmermann-tcpm-tcp-rfc4614bis Htmlized: http://tools.ietf.org/html/draft-zimmermann-tcpm-tcp-rfc4614bis-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-zimmermann-tcpm-tcp-rfc4614bis-01 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. --- (*) RFC 1191 - Path MTU Discovery RFC 2582 - NewReno predecessor to 3782 RFC 1705 - suggests a TCPng RFC 1144 - VJ TCP header compression RFC 1078 - TCPMUX instead of well-known ports RFC 962 - TCP-4 Prime (probably not worth adding?) RFC 889 - includes analysis of RTT/RTO algorithm RFC 794 - high-level discussion of pre-emption in TCP RFC 761 - early TCP spec, pre 793 RFC 675 - early TCP spec RFC 700 - early analysis RFC 721 - discusses adding "interrupts" // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From ycheng@google.com Mon Apr 1 12:26: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 D709121E809D for ; Mon, 1 Apr 2013 12:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, 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 ijDCQp8YSaz7 for ; Mon, 1 Apr 2013 12:26:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C75921E80A5 for ; Mon, 1 Apr 2013 12:26:26 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so2256839lbi.31 for ; Mon, 01 Apr 2013 12:26:25 -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=OY/fl1rpmyAjILY++50LSe/lVtqKYZ/lysNpN6WG1sA=; b=gYGxSNf+/zS3pclBdnaUAyDkB4CRZzijmBd5Sx4o11DFoDDfXm8KISTL6gYLEKN+vM 1ZhDcaDRTg/CA1OAdK1/cgFZYMnkAsQvrD21S0yLmx1b4IVzuD2qHwEqvWdE7jNU0OeE 4mudzFSil4wpdK8i32Knw7hwHNcjN4jVSQ1b1gBaYyRDLB77ZnCI9cJgi/xHizmHPnim fKbZ/WZuq/SBN42ei1bVtF6F/RmbDOd5sVvlKmmigNTMHxfT6Niom62YCgcWMhVufGS9 8yAS//dZSKZGd9POcUjM6AjJBcoueREsaOYqgXPZTVsP2k60Y+TJOfJDyHDdR0kUDodn Ex0w== 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=OY/fl1rpmyAjILY++50LSe/lVtqKYZ/lysNpN6WG1sA=; b=bPkyGjzhYU6WYl3r54avnBSMJr9bIknu1krs/Cpj0+TqrV2W4LUdt05d7KpybEFDX5 Y4aZ3LCmPqq5OqCksAuFD8+EaSpcZUrA1GymHqwZiY1VJfIpLrIB2e6I3oxFPtHEItAB Q5xul9lLtotaqRvFuCw9JkL+KZh7bpXTYLquK9YEQjIkK5WFElokKND8uxQ8uMGeFGnJ +Lvw4tB5M/hbTlA3E+U9n0aY6Lo+qV8m5dW7tBv0t3Iyx3SQsY2wAyve0R2Y3qyEgkkJ zTFP/0/gWO6+/9Ce41BbkeDx6YXmz090c77Vffr2tUuszZ7wUhks8Pw6tEHuaWSl/HGJ k41g== X-Received: by 10.112.1.169 with SMTP id 9mr2419484lbn.130.1364844385223; Mon, 01 Apr 2013 12:26:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.125.2 with HTTP; Mon, 1 Apr 2013 12:26:05 -0700 (PDT) In-Reply-To: <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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Mon, 1 Apr 2013 12:26:05 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQltQ98WQS54UVTv8iciZgOVp4CQMcgNfo0CVlckX1s+aKfeqwQzE/bjsRF9X/kbf0n+c2o8bKeCe3D4a5klC7QBOIXzC/zFNzw8+1UMNKEHmipF5r7kjLSUY2p9AHfjVUbq/Z3D4LahwHY6h9igAo3IaWqCg/HY14qlJco9BnxfFrFzIRqH3wJeOSrI1tlWG6zZRBRz 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: Mon, 01 Apr 2013 19:26:28 -0000 On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger, Richard wr= ote: > > 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 RTT= var, 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 (wi= th the current semantics, the only sensible approach would be that the last= ACK must be ignored). If I am understanding correctly you (and I) prefer to have accurate RTT estimation instead of the inflated ones. But RFC1323 explicitly prefers the latter. """ 3.4 Which Timestamp to Echo (B) A hole in the sequence space (segment(s) have been lost). The sender will continue sending until the window is filled, and the receiver may be generating ACKs as these out-of-order segments arrive (e.g., to aid "fast retransmit"). The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An ACK for an out-of-order segment should therefore contain the timestamp from the most recent segment that advanced the window. The same situation occurs if segments are re-ordered by the network. """ since the newest -08 (http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-08) does not update the paragraph above, I found the new rule of not taking (inflated) RTT samples on ACK with (D)SACK contradicting. Personally I would prefer the receiver to echo latest timestamps but it's moot b/c it can not be deployed :( I started to see Mark's point on TS RTTM. > > If the point is to only come up with some conservative estimate for RTO (= and an even more conservative estimate in this case), the current text and = implementations are fine even though that last ACK does indicate loss... > > However, the variables sRTT and RTTvar need to have a connotation that th= ey are *only* intermediary values just used for RTO purposes and nothing el= se, and should be renamed that they are NOT to be used for anything but RTO= estimation. Other (future, experimental) mechanisms need to derive their o= wn state then. > > Best regards, > > > 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) >> >> 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 th= e >> >> > 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- segmen= t >> 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 leav= e >> any potential gap between the 3WHS negotiation, and the actual use of th= e >> 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 dr= op >> >> > 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? A= nd >> >> 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 ope= n >> 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 an= d >> the >> >> > packet processed normally. >> >> >> >> This would have been good to include in RFC 1323, but I wonder wha= t >> 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 tex= t >> there to explicitly exclude 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 measur= ed >> 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 th= e >> >> > 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 a= t >> 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 hav= e >> >> 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 late= st >> 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 From nishida@sfc.wide.ad.jp Mon Apr 1 20:56: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 F3EDD21E8187 for ; Mon, 1 Apr 2013 20:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 G0oUdJm8ZrxV for ; Mon, 1 Apr 2013 20:56:02 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0BA21E8119 for ; Mon, 1 Apr 2013 20:56:01 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D9A202780A8 for ; Tue, 2 Apr 2013 12:55:57 +0900 (JST) Received: by mail-lb0-f181.google.com with SMTP id r11so64308lbv.12 for ; Mon, 01 Apr 2013 20:55:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.109.112 with SMTP id hr16mr6929681lab.38.1364874955294; Mon, 01 Apr 2013 20:55:55 -0700 (PDT) Received: by 10.114.4.39 with HTTP; Mon, 1 Apr 2013 20:55:55 -0700 (PDT) In-Reply-To: <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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 1 Apr 2013 20:55:55 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=bcaec54eea70df8e5004d958b64c 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: Tue, 02 Apr 2013 03:56:03 -0000 --bcaec54eea70df8e5004d958b64c Content-Type: text/plain; charset=ISO-8859-1 Hello, On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger, Richard wrote: > > 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 > RTTvar, 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 ACK must be ignored). > Hmm. I have a naive question here. If it must be ignored, why the receiver have to put the TS? -- Yoshifumi --bcaec54eea70df8e5004d958b64c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger, Richard <= span dir=3D"ltr"><rs@= netapp.com> wrote:

Hi Yuchung,

In the following scenario,

what should the left side (sender) do, when the last ACK arrives?

=A0 =A0 <A, TSval=3D1> --------------------->

=A0 =A0<---------------- <ACK(A), TSecr=3D1>

=A0 =A0 <B, TSval=3D2> --------------------->

=A0 =A0 =A0X-------------- <ACK(B), TSecr=3D2>

=A0 =A0 <C, TSval=3D3> -------------------X



=A0 =A0 <D, TSval=3D5> --------------------->

=A0 =A0<------- <ACK(B), SACK(D), TSecr=3D2>


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).

Hmm. I have = a naive question here.
If it must be ignored, why the receiver have to put the TS?

--
Yoshifumi

--bcaec54eea70df8e5004d958b64c-- From rs@netapp.com Mon Apr 1 21:56: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 9C75221F981E for ; Mon, 1 Apr 2013 21:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 1xiVUd6u6Ymd for ; Mon, 1 Apr 2013 21:56:21 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2421F8BD9 for ; Mon, 1 Apr 2013 21:56:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,391,1363158000"; d="scan'208,217";a="36161061" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 01 Apr 2013 21:56:17 -0700 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r324uHuD020175; Mon, 1 Apr 2013 21:56:17 -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; Mon, 1 Apr 2013 21:56:16 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH4= Date: Tue, 2 Apr 2013 04:56:15 +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> <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com>, In-Reply-To: Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E0CCEF31609E47F6BED08117B1D7901Bnetappcom_" 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: Tue, 02 Apr 2013 04:56:21 -0000 --_000_E0CCEF31609E47F6BED08117B1D7901Bnetappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ts is defined with symetric signalling. Also, the receiver can not know, if= and which packet might be lost. The current semantics minimize inflated rttm samples, but the interaction w= ith sack was never (afaik) considered. >From my reading of 1323, acks with sack should be ignored (for the purpose = of rttm, not paws), to keep with the spirit of the mechanism. However, in t= he scenario described (this particular loss pattern and similar events) man= y stacks are not refraining from updating (bloating) rttm (srtt / rttvar) But this is admittedly a minuscle issue (and not the big fish some here wan= t to fry ;) ) Richard Von meinem iPhone gesendet Am 02.04.2013 um 05:56 schrieb "Yoshifumi Nishida" >: Hello, On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger, Richard > wrote: 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). Hmm. I have a naive question here. If it must be ignored, why the receiver have to put the TS? -- Yoshifumi --_000_E0CCEF31609E47F6BED08117B1D7901Bnetappcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ts is defined with symetric signalling. Also, the receiver can not kno= w, if and which packet might be lost. 

The current semantics minimize inflated rttm samples, but the interact= ion with sack was never (afaik) considered. 

From my reading of 1323, acks with sack should be ignored (for the pur= pose of rttm, not paws), to keep with the spirit of the mechanism. However,= in the scenario described (this particular loss pattern and similar events= ) many stacks are not refraining from updating (bloating) rttm (srtt / rttvar)

But this is admittedly a minuscle issue (and not the big fish some her= e want to fry ;) )

Richard

Von meinem iPhone gesendet

Am 02.04.2013 um 05:56 schrieb "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp>:

Hello,

On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger,= Richard <rs= @netapp.com> wrote:

Hi Yuchung,

In the following scenario,

what should the left side (sender) do, when the last ACK arrives?

    <A, TSval=3D1> --------------------->

   <---------------- <ACK(A), TSecr=3D1>

    <B, TSval=3D2> --------------------->

     X-------------- <ACK(B), TSecr=3D2>

    <C, TSval=3D3> -------------------X



    <D, TSval=3D5> --------------------->

   <------- <ACK(B), SACK(D), TSecr=3D2>


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).

Hmm. I have a naive question here.
If it must be ignored, why the receiver have to put the TS?=

--
Yoshifumi

--_000_E0CCEF31609E47F6BED08117B1D7901Bnetappcom_-- From ycheng@google.com Mon Apr 1 22:18: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 7913221F97C7 for ; Mon, 1 Apr 2013 22:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, 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 8+fZCJ3GlbJL for ; Mon, 1 Apr 2013 22:18:39 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2FDD21F9792 for ; Mon, 1 Apr 2013 22:18:23 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so99678lbi.31 for ; Mon, 01 Apr 2013 22:18:22 -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=yPwpEZWg0OJuaJQMjO3dRuAnG2mPiPfnoujA3BT8F/s=; b=JP3AFUCSYYcY89OhvW13DyLXTWL/Dw18oGqwBENyiqT/ttHj6WSmamwjF2Sk4eUSW4 2yqr9ZR1FfVnMjixKYYNK9VP0koA60RPuVJljiT/1/6cKaECtXmrtr28RrdzW+3XV9Yh 29wtUX3fWAmZxbqQMMSxfQLjCbnBfLZT2DDaU/wGkA4KLK/+wNU9OUxMQ9Pgk65Q8qON zmoMLfQ/FwEyeLOLma8Ljx6QcdUc2mRG41POEcg3MTGYUlw2IT8Dh88EvntdXdwcLruA iHccMzxyNZDJJDer/guUL30OEWp7wmpXdEo+UbqRCvMfUeuKoZkgn1+Y4qXoqsxLma5O NG2w== 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=yPwpEZWg0OJuaJQMjO3dRuAnG2mPiPfnoujA3BT8F/s=; b=I51zUGqpQ9xnbx7U2A6pDuJB5tDamA0QRkGVgLF9enHQDf6yLHVPj2iSOuIp0N5+NI oGopx56J9lUYNDcUSFmwNkrE99t1EDxuz+lUtADek2Bd5hs3EPP8HeXzcgl6vyQPJb0I AEpzqr0SQBxIMucFMwP0crHH4jlZ9hlg4AxkUneI2R92IXMhh25U+z2nVLqdHLdz+r4d 4BrNgC9vx/RvEUwpvuTZiGZHbu4ps57cCnsEYHuGiGZnNQDfsvudROd6y1nqP2WDIqWV J3iSdAUjKVhP7c0GbQfBizp7IWvPcej4KfpzZdnFzzm9ntO1KpOACe/98kwKrrNjDjy0 KWuQ== X-Received: by 10.112.155.100 with SMTP id vv4mr1366053lbb.81.1364879902658; Mon, 01 Apr 2013 22:18:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.125.2 with HTTP; Mon, 1 Apr 2013 22:18:02 -0700 (PDT) In-Reply-To: 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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Mon, 1 Apr 2013 22:18:02 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmuedUR/4vz5280BWkvFf+MHriJFczVYhEPuyih3RTiBsCjDGtNmROX5YaTo3AsZTfgIwA/V1D3qnCpVo53tw6J8sBPfMHJowc9UT7IP0vpe8APVcIq1/5aSviJ6haCjDYBPuaDic8glX2LW/mtVA0c+eG5bwHBc711QTEb4eX8G/y33zR7dj0/+jSKs4JpG3iZXtSW 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: Tue, 02 Apr 2013 05:18:40 -0000 On Mon, Apr 1, 2013 at 9:56 PM, Scheffenegger, Richard wrote: > Ts is defined with symetric signalling. Also, the receiver can not know, if > and which packet might be lost. > > The current semantics minimize inflated rttm samples, but the interaction > with sack was never (afaik) considered. > > From my reading of 1323, acks with sack should be ignored (for the purpose > of rttm, not paws), to keep with the spirit of the mechanism. However, in > the scenario described (this particular loss pattern and similar events) > many stacks are not refraining from updating (bloating) rttm (srtt / rttvar) > > But this is admittedly a minuscle issue (and not the big fish some here want > to fry ;) ) Let me repeat my concern: """ section 3.4 (B) A hole in the sequence space (segment(s) have been lost). The sender will continue sending until the window is filled, and the receiver may be generating s as these out-of-order segments arrive (e.g., to aid "fast retransmit"). The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An for an out-of-order segment SHOULD therefore contain the timestamp from the most recent segment that advanced the window. The same situation occurs if segments are re-ordered by the network. """ directly contacts """ section 3.3 b) the segment does not indicate any potential loss or reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC2883] options """ Please clarify. Any data to support this is a problem? If this is minor issue as you said why bother with this change? I don't think this change is small. > > Richard > > Von meinem iPhone gesendet > > Am 02.04.2013 um 05:56 schrieb "Yoshifumi Nishida" : > > Hello, > > On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger, Richard > wrote: >> >> >> 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 RTTvar, >> 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 ACK must be ignored). > > > Hmm. I have a naive question here. > If it must be ignored, why the receiver have to put the TS? > > -- > Yoshifumi > From ycheng@google.com Mon Apr 1 22:20: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 BFCDE21F97FE for ; Mon, 1 Apr 2013 22:20:28 -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 8hRnEHpNmNOp for ; Mon, 1 Apr 2013 22:20:28 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 845F421F9800 for ; Mon, 1 Apr 2013 22:20:27 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so39614lab.2 for ; Mon, 01 Apr 2013 22:20:26 -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=ySjxvV2uYwyQ1dCjqWtlVoykNliX8TB5jIeTGoBrFL8=; b=GIYfG+3fZ9a6pAFWiW2XaPrc6daUi32hSZQMoTMNWlqqmR+jfl6Y+RVsEDDtOmDfEc vwrj2qX/6m59m7F+oe4GgSpH5fexONL6rK+Qp/cfpCGm2lNcW58lDw6Jpi02TENzRd/P T3EWzX8v/aHvp90LmRPC0MQLY9YBCDPh4iBVXnjDL3522BbJZIzW0bSE8u4Z6K+BuF8x PIwdZOPW/u1MLTJlfTchKC4CUydTeCm8XBMiD+aRl0L18YKy2YS0Z+RQTVgk3ginm8WI eJ3DXDVz8qX/vbOObAuXLmPmGoTqW7Fw/TfnaaJ6Ugb3eyepFaFP6MrgpmAiNy9Z0rEg /cUg== 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=ySjxvV2uYwyQ1dCjqWtlVoykNliX8TB5jIeTGoBrFL8=; b=Avcxho9SybV3+8zJOe1iohHaZQBQZv9PqIwmQ8uY7JSglvHayDwdWu5CVT0zo7KL0K U9aKMsrdyju8+qok2aJtAVJCIP7jY7DvF3HmO2Yq7xCZtw7TH7p8atYbTEGylpvFXOs/ maNRA2jSZOfDcokyDiX/kaQq8LFY3xUj1oDM+/zOFmHnpOraHcBZOV4Z398bl1IJdgyd 32E3tHboo0aiiRbUQ2XfyyQ3KAcfAnaHnVA9BfFajkCWWixb6PBjSG1AumAsSLWlaxdY dm7LIIw/0IJ4IPZr2UKO3xNcpKLiAxuUj3eQJYZdylurU3kxVk2NigZyOomWRdgw8mk7 uGnA== X-Received: by 10.152.110.116 with SMTP id hz20mr6899937lab.18.1364880026386; Mon, 01 Apr 2013 22:20:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.125.2 with HTTP; Mon, 1 Apr 2013 22:20:06 -0700 (PDT) In-Reply-To: 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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Mon, 1 Apr 2013 22:20:06 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQklaSTRnFirbMW17NZwtB2PltixWaTCYSQSwWxQo1GvvtptCgZAZHbY8HtIyNQZxlmRoroIBdeHyBEazVVEyL2QG/HyYicAjeGKJOasYXdw7h9254WhRTQ0XpQ1JBX1UCXUhCxtn7NxBHq9wrtC5PK2WgrHjgMKKTHvq87KrZRyVDmipNwjWJ7zEK1cY51EgHRJMLwG 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: Tue, 02 Apr 2013 05:20:29 -0000 On Mon, Apr 1, 2013 at 10:18 PM, Yuchung Cheng wrote: > On Mon, Apr 1, 2013 at 9:56 PM, Scheffenegger, Richard wrote: >> Ts is defined with symetric signalling. Also, the receiver can not know, if >> and which packet might be lost. >> >> The current semantics minimize inflated rttm samples, but the interaction >> with sack was never (afaik) considered. >> >> From my reading of 1323, acks with sack should be ignored (for the purpose >> of rttm, not paws), to keep with the spirit of the mechanism. However, in >> the scenario described (this particular loss pattern and similar events) >> many stacks are not refraining from updating (bloating) rttm (srtt / rttvar) >> >> But this is admittedly a minuscle issue (and not the big fish some here want >> to fry ;) ) > > Let me repeat my concern: > """ > section 3.4 > (B) A hole in the sequence space (segment(s) have been lost). > > The sender will continue sending until the window is filled, and > the receiver may be generating s as these out-of-order > segments arrive (e.g., to aid "fast retransmit"). > > The lost segment is probably a sign of congestion, and in that > situation the sender should be conservative about > retransmission. Furthermore, it is better to overestimate than > underestimate the RTT. An for an out-of-order segment > SHOULD therefore contain the timestamp from the most recent > segment that advanced the window. > > The same situation occurs if segments are re-ordered by the > network. > > """ > directly contacts typo: directly contradicts > """ > section 3.3 > b) the segment does not indicate any potential loss or > reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC2883] > options > """ > > Please clarify. > > Any data to support this is a problem? > > If this is minor issue as you said why bother with this change? I > don't think this change is small. > >> >> Richard >> >> Von meinem iPhone gesendet >> >> Am 02.04.2013 um 05:56 schrieb "Yoshifumi Nishida" : >> >> Hello, >> >> On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger, Richard >> wrote: >>> >>> >>> 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 RTTvar, >>> 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 ACK must be ignored). >> >> >> Hmm. I have a naive question here. >> If it must be ignored, why the receiver have to put the TS? >> >> -- >> Yoshifumi >> From rs@netapp.com Tue Apr 2 05:39: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 EA02F21F977A for ; Tue, 2 Apr 2013 05:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, J_CHICKENPOX_42=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 x7DSfnwOFERR for ; Tue, 2 Apr 2013 05:39:22 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA021F9771 for ; Tue, 2 Apr 2013 05:39:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,393,1363158000"; d="scan'208";a="36280345" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 02 Apr 2013 05:39:21 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r32CdLtO007812; Tue, 2 Apr 2013 05:39:21 -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; Tue, 2 Apr 2013 05:39:20 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAHtuAP//+HsA Date: Tue, 2 Apr 2013 12:39:20 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE0D9E@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@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="us-ascii" 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: Tue, 02 Apr 2013 12:39:23 -0000 Hi Yuchung, Section 3.4 describes the receiver's behavior (ie. when to update TS.recent= ). Section 3.3 describes the sender behavior (what to do when TSecr is receive= d). So, they don't contradict each other, they describe different mechanisms at= different points... In the scenario I have depicted, there is loss in the forward (sender->rece= iver), and backwards (receiver->sender) path. And no, I don't have any data to show how prevalent this particular issue i= s. As that requires a very specific set of circumstances, it's really a nit= . The text should make it clear that an implementer not simply ignores the = presence of a SACK option when processing TSopt... I only found this (some time ago) while testing SACK+TS interactions while = checking the sources of a number of stacks. Richard Scheffenegger > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Dienstag, 02. April 2013 07:18 > To: Scheffenegger, Richard > Cc: Yoshifumi Nishida; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > WGLC) >=20 > On Mon, Apr 1, 2013 at 9:56 PM, Scheffenegger, Richard > wrote: > > Ts is defined with symetric signalling. Also, the receiver can not > > know, if and which packet might be lost. > > > > The current semantics minimize inflated rttm samples, but the > > interaction with sack was never (afaik) considered. > > > > From my reading of 1323, acks with sack should be ignored (for the > > purpose of rttm, not paws), to keep with the spirit of the mechanism. > > However, in the scenario described (this particular loss pattern and > > similar events) many stacks are not refraining from updating > > (bloating) rttm (srtt / rttvar) > > > > But this is admittedly a minuscle issue (and not the big fish some > > here want to fry ;) ) >=20 > Let me repeat my concern: > """ > section 3.4 > (B) A hole in the sequence space (segment(s) have been lost). >=20 > The sender will continue sending until the window is filled, and > the receiver may be generating s as these out-of-order > segments arrive (e.g., to aid "fast retransmit"). >=20 > The lost segment is probably a sign of congestion, and in that > situation the sender should be conservative about > retransmission. Furthermore, it is better to overestimate than > underestimate the RTT. An for an out-of-order segment > SHOULD therefore contain the timestamp from the most recent > segment that advanced the window. >=20 > The same situation occurs if segments are re-ordered by the > network. >=20 > """ > directly contacts > """ > section 3.3 > b) the segment does not indicate any potential loss or > reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC2883] > options > """ >=20 > Please clarify. >=20 > Any data to support this is a problem? >=20 > If this is minor issue as you said why bother with this change? I don't > think this change is small. >=20 > > > > Richard > > > > Von meinem iPhone gesendet > > > > Am 02.04.2013 um 05:56 schrieb "Yoshifumi Nishida" > : > > > > Hello, > > > > On Fri, Mar 29, 2013 at 11:10 PM, Scheffenegger, Richard > > > > wrote: > >> > >> > >> 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 RTTvar, 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 ACK must be ignored). > > > > > > Hmm. I have a naive question here. > > If it must be ignored, why the receiver have to put the TS? > > > > -- > > Yoshifumi > > From rs@netapp.com Tue Apr 2 10:43: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 2356F21F85C2 for ; Tue, 2 Apr 2013 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.499, 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 LqJXpontZHMz for ; Tue, 2 Apr 2013 10:43:34 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3A13921F85C0 for ; Tue, 2 Apr 2013 10:43:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,394,1363158000"; d="scan'208";a="36385710" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 02 Apr 2013 10:43:33 -0700 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 r32HhXD4012233; Tue, 2 Apr 2013 10:43:33 -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, 2 Apr 2013 10:43:33 -0700 From: "Scheffenegger, Richard" To: Alexander Zimmermann Thread-Topic: [tcpm] Roadmap for TCP - New Version Thread-Index: AQHOLwSgJNhMzjvV7US/RrlyS2movJjDLjTQ Date: Tue, 2 Apr 2013 17:43:32 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@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.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] Roadmap for TCP - New Version 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, 02 Apr 2013 17:43:35 -0000 Hi Alex, some random comments while reading your draft: Pg 4, s/not-essential/non-essential/ Also, perhaps a hint should be given when there are Errata for the mentione= d RFCs - particularly non-editorial ones (ie 1323 has a couple of those; bu= t hopefully, 1323bis is published before the roadmap to update the referenc= e :o) ). I wonder how prevalent the checking of errata notes is, when some= one looks up a RFC... 793 also has errata (Fernando Gont's acceptance test criteria update draft)= . Sec3.1 s/ofnvery/of very/ Sec3.2 /and cannot distinguish between congestion-related loss and loss due to infer congestion, transmission errors. =20 some mixup happened here? (trans. Err) after "to"? s/could occours/could occur/ 3.4 eifel detection missing - fwd reference to 4.2? Section 7: FACK (SACK)? Current developments (PRR, IW10) 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: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Alexander Zimmermann > Sent: Montag, 01. April 2013 20:13 > To: tcpm@ietf.org Extensions > Subject: [tcpm] Roadmap for TCP - New Version >=20 > Hi Group, >=20 > today I finally submit a new version of the TCP roadmap. Sorry for the > long delay :-) I include all new RFCs up to the new RFC 6897. Based on a > email from Wes I also include all old, forgotten RFC into the roadmap (*)= . >=20 > Moreover I change a little bit the structure of the doc. Basically, I > introduce some new sections and subsections so that the reader can find > more easily the RFCs in question. The new structure is fully aligned with > RFC 5783 (Congestion Control in the RFC Series). >=20 > Happy for feedback > Alex >=20 > --- >=20 > A new version of I-D, draft-zimmermann-tcpm-tcp-rfc4614bis-01.txt > has been successfully submitted by Alexander Zimmermann and posted to the > IETF repository. >=20 > Filename: draft-zimmermann-tcpm-tcp-rfc4614bis > Revision: 01 > Title: A Roadmap for Transmission Control Protocol (TCP) > Specification Documents > Creation date: 2013-04-01 > Group: Individual Submission > Number of pages: 46 > URL: http://www.ietf.org/internet-drafts/draft-zimmermann- > tcpm-tcp-rfc4614bis-01.txt > Status: http://datatracker.ietf.org/doc/draft-zimmermann-tcpm- > tcp-rfc4614bis > Htmlized: http://tools.ietf.org/html/draft-zimmermann-tcpm-tcp- > rfc4614bis-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-zimmermann-tcpm= - > tcp-rfc4614bis-01 >=20 > Abstract: > This document contains a "roadmap" to the Requests for Comments (RFC) > documents relating to the Internet's Transmission Control Protocol > (TCP). This roadmap provides a brief summary of the documents > defining TCP and various TCP extensions that have accumulated in the > RFC series. This serves as a guide and quick reference for both TCP > implementers and other parties who desire information contained in > the TCP-related RFCs. >=20 > --- >=20 > (*) >=20 > RFC 1191 - Path MTU Discovery > RFC 2582 - NewReno predecessor to 3782 > RFC 1705 - suggests a TCPng > RFC 1144 - VJ TCP header compression > RFC 1078 - TCPMUX instead of well-known ports RFC 962 - TCP-4 Prime > (probably not worth adding?) RFC 889 - includes analysis of RTT/RTO > algorithm RFC 794 - high-level discussion of pre-emption in TCP RFC 761 - > early TCP spec, pre 793 RFC 675 - early TCP spec RFC 700 - early analysis > RFC 721 - discusses adding "interrupts" >=20 >=20 > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: > (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: > http://www.umic-mesh.net // >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From hagen@jauu.net Tue Apr 2 11:28: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 6E63B21F8C35 for ; Tue, 2 Apr 2013 11:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oqBXwpWttH4V for ; Tue, 2 Apr 2013 11:28:35 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA521F8C78 for ; Tue, 2 Apr 2013 11:28:35 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1UN5wY-0008WR-K3; Tue, 02 Apr 2013 20:28:26 +0200 Date: Tue, 2 Apr 2013 20:28:25 +0200 From: Hagen Paul Pfeifer To: "Scheffenegger, Richard" Message-ID: <20130402182825.GD3448@virgo.local> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 02 Apr 2013 18:28:36 -0000 * Scheffenegger, Richard | 2013-04-02 17:43:32 [+0000]: >Section 7: FACK (SACK)? Should be ok ;-) >Current developments (PRR, IW10) I support this section. It is hard to track current development if not reading tcpm constantly. Or just a pointer to https://datatracker.ietf.org/wg/tcpm/ Hagen -- http://protocollabs.com From alexander.zimmermann@comsys.rwth-aachen.de Tue Apr 2 13:55: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 4595721F8C74 for ; Tue, 2 Apr 2013 13:55:34 -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_DE=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 sHJ0xlGlsiSt for ; Tue, 2 Apr 2013 13:55:33 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.rwth-aachen.de [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 81F9E21F87D1 for ; Tue, 2 Apr 2013 13:55:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=iso-8859-1 Received: from mx-out-1.rwth-aachen.de ([134.130.5.186]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MKN006ZPBGJWM50@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 22:55:31 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.87,394,1363129200"; d="scan'208";a="216574424" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-1.rz.rwth-aachen.de with ESMTP; Tue, 02 Apr 2013 22:55:32 +0200 Received: from [10.102.71.225] ([unknown] [217.110.90.50]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MKN00JMWBGJYL60@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 22:55:31 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <515AD370.80107@uclouvain.be> Date: Tue, 02 Apr 2013 22:55:30 +0200 Message-id: <8F0602FE-2007-4DCD-BFDB-7D7DCA79F6E9@comsys.rwth-aachen.de> References: <515AD370.80107@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 02 Apr 2013 20:55:34 -0000 Bonjour Olivier, indeed, it would make sense to exclude RFC 6356 and RFC 6824 from section 4.2 and spend them a dedicated section. I share your opinion that MPTCP is much broader than a congestion control extension. If you would like to send me some introduction text for the new section that would be great! We can also include in the introduction text some references to the other MPTCP RFCs, which are included in section * 6.2. Architectural Guidelines - RFC 6182 * 6.4. Guidance for Developing, Analyzing, and Evaluating TCP - RFC 6181 * 6.5. Implementation Advice - RFC 6897 Alex Am 02.04.2013 um 14:47 schrieb Olivier Bonaventure : > Alexander, >> >> today I finally submit a new version of the TCP roadmap. Sorry for the long >> delay :-) I include all new RFCs up to the new RFC 6897. Based on a email from >> Wes I also include all old, forgotten RFC into the roadmap (*). >> >> Moreover I change a little bit the structure of the doc. Basically, I >> introduce some new sections and subsections so that the reader can find more >> easily the RFCs in question. The new structure is fully aligned with RFC 5783 >> (Congestion Control in the RFC Series). > > In the current version, you have included Multipath TCP RFCs in the congestion control section 4.2. I think that Multipath TCP would be worth a complete section in the document because it is much broader than a congestion control extension. I can propose some text if this can help > > Best regards, > > > Olivier Bonaventure > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From alexander.zimmermann@comsys.rwth-aachen.de Tue Apr 2 14:20: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 B97B721F8CE9 for ; Tue, 2 Apr 2013 14:20:29 -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_DE=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 EThNZq7xcnh0 for ; Tue, 2 Apr 2013 14:20:28 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE5721F8CBE for ; Tue, 2 Apr 2013 14:20:28 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MKN00M67CM3UD40@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 23:20:27 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.87,394,1363129200"; d="scan'208";a="128535329" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-2.rz.rwth-aachen.de with ESMTP; Tue, 02 Apr 2013 23:20:27 +0200 Received: from [10.102.71.225] ([unknown] [217.110.90.50]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MKN00J3GCM2YL70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 23:20:27 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 02 Apr 2013 23:20:26 +0200 Content-transfer-encoding: quoted-printable Message-id: References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 02 Apr 2013 21:20:30 -0000 Hi Richard, thanks for the comments :-) Am 02.04.2013 um 19:43 schrieb "Scheffenegger, Richard" : > Hi Alex, >=20 > some random comments while reading your draft: >=20 >=20 > Pg 4, s/not-essential/non-essential/ fixed >=20 >=20 > Also, perhaps a hint should be given when there are Errata for the = mentioned RFCs - particularly non-editorial ones (ie 1323 has a couple = of those; but hopefully, 1323bis is published before the roadmap to = update the reference :o) ). I wonder how prevalent the checking of = errata notes is, when someone looks up a RFC... Why not... What do you propose? Like this? =20 RFC 6824 E: "TCP Extensions for Multipath Operation with Multiple Addresses" (January 2013) (Errata) This document [RFC6824] presents protocol changes required to add multipath capability to TCP; specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reassembly of data, and termination of sessions. Or completely different? >=20 >=20 > 793 also has errata (Fernando Gont's acceptance test criteria update = draft). >=20 >=20 > Sec3.1 s/ofnvery/of very/ fixed >=20 > Sec3.2 /and cannot distinguish between > congestion-related loss and loss due to infer congestion, > transmission errors. =20 >=20 > some mixup happened here? (trans. Err) after "to"? fixed. Must be a C&P error... >=20 >=20 > s/could occours/could occur/ fixed >=20 >=20 > 3.4 eifel detection missing - fwd reference to 4.2? Eifel detection is still experimental... (as well as DSACK) We can include the fwd ref into the missing intro text of sec. 3.4. OK? >=20 >=20 > Section 7: FACK (SACK)? Yes as well as CUBIC and CompoundTCP >=20 > Current developments (PRR, IW10) OK. Make sense. I will do that. Alex >=20 >=20 > Richard Scheffenegger >=20 > NetApp > rs@netapp.com > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com =20 >=20 > EURO PLAZA > Geb=E4ude G, Stiege 7, 3.OG > Am Euro Platz 2 > A-1120 Wien >=20 >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of >> Alexander Zimmermann >> Sent: Montag, 01. April 2013 20:13 >> To: tcpm@ietf.org Extensions >> Subject: [tcpm] Roadmap for TCP - New Version >>=20 >> Hi Group, >>=20 >> today I finally submit a new version of the TCP roadmap. Sorry for = the >> long delay :-) I include all new RFCs up to the new RFC 6897. Based = on a >> email from Wes I also include all old, forgotten RFC into the roadmap = (*). >>=20 >> Moreover I change a little bit the structure of the doc. Basically, I >> introduce some new sections and subsections so that the reader can = find >> more easily the RFCs in question. The new structure is fully aligned = with >> RFC 5783 (Congestion Control in the RFC Series). >>=20 >> Happy for feedback >> Alex >>=20 >> --- >>=20 >> A new version of I-D, draft-zimmermann-tcpm-tcp-rfc4614bis-01.txt >> has been successfully submitted by Alexander Zimmermann and posted to = the >> IETF repository. >>=20 >> Filename: draft-zimmermann-tcpm-tcp-rfc4614bis >> Revision: 01 >> Title: A Roadmap for Transmission Control Protocol = (TCP) >> Specification Documents >> Creation date: 2013-04-01 >> Group: Individual Submission >> Number of pages: 46 >> URL: = http://www.ietf.org/internet-drafts/draft-zimmermann- >> tcpm-tcp-rfc4614bis-01.txt >> Status: = http://datatracker.ietf.org/doc/draft-zimmermann-tcpm- >> tcp-rfc4614bis >> Htmlized: = http://tools.ietf.org/html/draft-zimmermann-tcpm-tcp- >> rfc4614bis-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-zimmermann-tcpm- >> tcp-rfc4614bis-01 >>=20 >> Abstract: >> This document contains a "roadmap" to the Requests for Comments = (RFC) >> documents relating to the Internet's Transmission Control Protocol >> (TCP). This roadmap provides a brief summary of the documents >> defining TCP and various TCP extensions that have accumulated in the >> RFC series. This serves as a guide and quick reference for both TCP >> implementers and other parties who desire information contained in >> the TCP-related RFCs. >>=20 >> --- >>=20 >> (*) >>=20 >> RFC 1191 - Path MTU Discovery >> RFC 2582 - NewReno predecessor to 3782 >> RFC 1705 - suggests a TCPng >> RFC 1144 - VJ TCP header compression >> RFC 1078 - TCPMUX instead of well-known ports RFC 962 - TCP-4 Prime >> (probably not worth adding?) RFC 889 - includes analysis of RTT/RTO >> algorithm RFC 794 - high-level discussion of pre-emption in TCP RFC = 761 - >> early TCP spec, pre 793 RFC 675 - early TCP spec RFC 700 - early = analysis >> RFC 721 - discusses adding "interrupts" >>=20 >>=20 >> // >> // Dipl.-Inform. Alexander Zimmermann >> // Department of Computer Science, Informatik 4 // RWTH Aachen = University >> // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, = fax: >> (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: >> http://www.umic-mesh.net // >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From alexander.zimmermann@comsys.rwth-aachen.de Tue Apr 2 14:22: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 9F05E21F8DCF for ; Tue, 2 Apr 2013 14:22:13 -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_DE=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 3YMJ+hQXtktX for ; Tue, 2 Apr 2013 14:22:13 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id C905E21F8C45 for ; Tue, 2 Apr 2013 14:22:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MKN00JL8CP0R050@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 23:22:12 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.87,394,1363129200"; d="scan'208";a="128535447" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-2.rz.rwth-aachen.de with ESMTP; Tue, 02 Apr 2013 23:22:12 +0200 Received: from [10.102.71.225] ([unknown] [217.110.90.50]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MKN00J4PCOZYL70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 23:22:12 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <20130402182825.GD3448@virgo.local> Date: Tue, 02 Apr 2013 23:22:11 +0200 Message-id: References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> <20130402182825.GD3448@virgo.local> To: Hagen Paul Pfeifer X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 02 Apr 2013 21:22:14 -0000 Hi Hagen, you support this section with some text? ;-) Alex Am 02.04.2013 um 20:28 schrieb Hagen Paul Pfeifer : > * Scheffenegger, Richard | 2013-04-02 17:43:32 [+0000]: > >> Section 7: FACK (SACK)? > > Should be ok ;-) > >> Current developments (PRR, IW10) > > I support this section. It is hard to track current development if not reading > tcpm constantly. Or just a pointer to https://datatracker.ietf.org/wg/tcpm/ > > > Hagen > > > -- > http://protocollabs.com // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From rs@netapp.com Tue Apr 2 14:32: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 823BC21F85CE for ; Tue, 2 Apr 2013 14:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.266 X-Spam-Level: X-Spam-Status: No, score=-10.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 FdyWN177Q2P9 for ; Tue, 2 Apr 2013 14:32:07 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id ED8B221F85CB for ; Tue, 2 Apr 2013 14:32:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,394,1363158000"; d="scan'208";a="250226474" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 02 Apr 2013 14:32:07 -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 r32LW6iq027631; Tue, 2 Apr 2013 14:32:06 -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; Tue, 2 Apr 2013 14:32:05 -0700 From: "Scheffenegger, Richard" To: Alexander Zimmermann Thread-Topic: [tcpm] Roadmap for TCP - New Version Thread-Index: AQHOLwSgJNhMzjvV7US/RrlyS2movJjDLjTQgAC45AD//4syEA== Date: Tue, 2 Apr 2013 21:32:05 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE1744@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@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.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 02 Apr 2013 21:32:07 -0000 Hi Alex, > Why not... What do you propose? Like this? >=20 >=20 > RFC 6824 E: "TCP Extensions for Multipath Operation with Multiple > Addresses" (January 2013) (Errata) >=20 > This document [RFC6824] presents protocol changes required to add > multipath capability to TCP; specifically, those for signaling and > setting up multiple paths ("subflows"), managing these subflows, > reassembly of data, and termination of sessions. >=20 > Or completely different? Yes, something light-weight like that, when technical errata that affect th= e mechanisms exist. > > 3.4 eifel detection missing - fwd reference to 4.2? >=20 > Eifel detection is still experimental... (as well as DSACK) We can includ= e > the fwd ref into the missing intro text of sec. 3.4. OK? Ok;=20 > > Section 7: FACK (SACK)? >=20 > Yes as well as CUBIC and CompoundTCP For cubic and CTCP there are some (expired) drafts, at least: http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02 I think the only ietf draft so far describing FACK is http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01#section-2= .2 > > Current developments (PRR, IW10) >=20 > OK. Make sense. I will do that. Richard Scheffenegger From alexander.zimmermann@comsys.rwth-aachen.de Tue Apr 2 14:39: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 8496B21F8A11 for ; Tue, 2 Apr 2013 14:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.471 X-Spam-Level: X-Spam-Status: No, score=-5.471 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, FRT_LITTLE=1.555, HELO_EQ_DE=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 8yw9vyAgzui3 for ; Tue, 2 Apr 2013 14:39:13 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id C6D8421F8A0D for ; Tue, 2 Apr 2013 14:39:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MKN002STDHCT7K0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 23:39:12 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.87,394,1363129200"; d="scan'208";a="128536693" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-2.rz.rwth-aachen.de with ESMTP; Tue, 02 Apr 2013 23:39:12 +0200 Received: from [10.102.71.225] ([unknown] [217.110.90.50]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MKN00JEODHBYL70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 02 Apr 2013 23:39:12 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <012C3117EDDB3C4781FD802A8C27DD4F24AE1744@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 02 Apr 2013 23:39:11 +0200 Message-id: <73F6D80D-3A7B-47D2-B598-C6BC3A60FEB8@comsys.rwth-aachen.de> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE1744@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 02 Apr 2013 21:39:13 -0000 Am 02.04.2013 um 23:32 schrieb "Scheffenegger, Richard" : > > I think the only ietf draft so far describing FACK is > > http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01#section-2.2 > I little bit hidden, but FACK is also included in this draft: http://tools.ietf.org/html/draft-mathis-tcp-ratehalving-00 Alex > > > Richard Scheffenegger // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From nishida@sfc.wide.ad.jp Tue Apr 2 23:43: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 E9F7821F84FD for ; Tue, 2 Apr 2013 23:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 q3iL8dj-hF1y for ; Tue, 2 Apr 2013 23:43:20 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0421F84E7 for ; Tue, 2 Apr 2013 23:43:19 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 70DA72780C0 for ; Wed, 3 Apr 2013 15:43:17 +0900 (JST) Received: by mail-lb0-f177.google.com with SMTP id r10so1243550lbi.36 for ; Tue, 02 Apr 2013 23:43:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.19.7 with SMTP id a7mr468764lbe.0.1364971394796; Tue, 02 Apr 2013 23:43:14 -0700 (PDT) Received: by 10.114.4.39 with HTTP; Tue, 2 Apr 2013 23:43:14 -0700 (PDT) In-Reply-To: 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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 2 Apr 2013 23:43:14 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=14dae94734c51d953304d96f2bd5 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: Wed, 03 Apr 2013 06:43:33 -0000 --14dae94734c51d953304d96f2bd5 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, On Mon, Apr 1, 2013 at 9:56 PM, Scheffenegger, Richard wrote: > Ts is defined with symetric signalling. Also, the receiver can not know, if > and which packet might be lost. This is just my personal preference. I'd rather make an exception if we can safely simplify the logic. But, this might be a different draft if we pursue. -- Yoshifumi --14dae94734c51d953304d96f2bd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Mon, Apr 1, 2013 at 9:56 PM, Scheffe= negger, Richard <rs@netapp.com> = wrote:
> Ts is defined with symetric signalling. Also, the receiver c= an not know, if
> and which packet might be lost.=A0

This is just my = personal preference. I'd rather make an exception if we can safely simp= lify the logic.
But, this might be a different draft if we = pursue.
--
Yoshifumi


--14dae94734c51d953304d96f2bd5-- From lars@netapp.com Tue Apr 2 23:48: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 0778221F857E for ; Tue, 2 Apr 2013 23:48:33 -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 2RIKpk640rnF for ; Tue, 2 Apr 2013 23:48:32 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7621F8540 for ; Tue, 2 Apr 2013 23:48:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,399,1363158000"; d="scan'208";a="36577152" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 02 Apr 2013 23:48:32 -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 r336mWPQ004246; Tue, 2 Apr 2013 23:48:32 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Tue, 2 Apr 2013 23:48:31 -0700 From: "Eggert, Lars" To: "Scheffenegger, Richard" Thread-Topic: [tcpm] Roadmap for TCP - New Version Thread-Index: AQHOLwSg8LPB93uRPE2H6eD5eZ6+1pjDqn4AgADbU4A= Date: Wed, 3 Apr 2013 06:48:31 +0000 Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> 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="iso-8859-1" Content-ID: <87A5EEF7E28F63479A1C860100297033@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 03 Apr 2013 06:48:33 -0000 On Apr 2, 2013, at 19:43, "Scheffenegger, Richard" wrote: > Current developments (PRR, IW10) Won't this section be perpetually outdated?=20 Also, given the ephemeral nature of I-Ds, I don't think we should burn ener= gy trying to track them. Those that become RFCs can get added to the roadma= p when they do. Lars= From hagen@jauu.net Wed Apr 3 01:07: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 BBF8221F8606 for ; Wed, 3 Apr 2013 01:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3gUaYhETaymV for ; Wed, 3 Apr 2013 01:07:30 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 1094C21F85EB for ; Wed, 3 Apr 2013 01:07:30 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1UNIj2-0008LR-I6; Wed, 03 Apr 2013 10:07:20 +0200 Date: Wed, 3 Apr 2013 10:07:19 +0200 From: Hagen Paul Pfeifer To: "Eggert, Lars" Message-ID: <20130403080718.GA3195@virgo.local> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 03 Apr 2013 08:07:31 -0000 * Eggert, Lars | 2013-04-03 06:48:31 [+0000]: >Won't this section be perpetually outdated? In the long term yes. But at the end it boils down that a) an I-D was becoming an RFC or b) something happened on that way. That "something" may be of interest for the readers too. For me a handy document is where all development is listed, this should include IW10 and similar topics. Another way is to follow my other idea: provide a reference to [1]. Hagen [1] https://datatracker.ietf.org/wg/tcpm/ From lars@netapp.com Wed Apr 3 01:11: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 9C14E21F87D5 for ; Wed, 3 Apr 2013 01:11:28 -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 L0DoGDndND-x for ; Wed, 3 Apr 2013 01:11:24 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C637B21F86CA for ; Wed, 3 Apr 2013 01:11:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,399,1363158000"; d="scan'208";a="36604859" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 03 Apr 2013 01:11:23 -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 r338BNEm023866; Wed, 3 Apr 2013 01:11:23 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Wed, 3 Apr 2013 01:11:22 -0700 From: "Eggert, Lars" To: Hagen Paul Pfeifer Thread-Topic: [tcpm] Roadmap for TCP - New Version Thread-Index: AQHOLwSg8LPB93uRPE2H6eD5eZ6+1pjDqn4AgADbU4CAABYEgIAAASOA Date: Wed, 3 Apr 2013 08:11:22 +0000 Message-ID: <8A274A11-6AB6-42A8-8109-19636490E671@netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> <20130403080718.GA3195@virgo.local> In-Reply-To: <20130403080718.GA3195@virgo.local> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 03 Apr 2013 08:11:31 -0000 Hi, On Apr 3, 2013, at 10:07, Hagen Paul Pfeifer wrote: > * Eggert, Lars | 2013-04-03 06:48:31 [+0000]: >=20 >> Won't this section be perpetually outdated? >=20 > In the long term yes. But at the end it boils down that a) an I-D was bec= oming > an RFC or b) something happened on that way. That "something" may be of > interest for the readers too. For me a handy document is where all develo= pment > is listed, this should include IW10 and similar topics. yeah, but the point of the document isn't to be a history of TCP standardiz= ation efforts. It's a "start reading here" document for the TCP-related RFC= s. We have mailing list archives and meeting minutes to help people figure = out the "what happened" part. Lars= From rs@netapp.com Wed Apr 3 01:23: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 C56BD21F858B for ; Wed, 3 Apr 2013 01:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 jkUMikLMVeLG for ; Wed, 3 Apr 2013 01:23:20 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 832F221F850C for ; Wed, 3 Apr 2013 01:23:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,399,1363158000"; d="scan'208";a="36608188" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 03 Apr 2013 01:23:20 -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 r338NKOP005714; Wed, 3 Apr 2013 01:23:20 -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; Wed, 3 Apr 2013 01:23: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; Wed, 3 Apr 2013 01:23:19 -0700 From: "Scheffenegger, Richard" To: "Eggert, Lars" , Hagen Paul Pfeifer Thread-Topic: [tcpm] Roadmap for TCP - New Version Thread-Index: AQHOLwSgJNhMzjvV7US/RrlyS2movJjDLjTQgAFXnYCAABYEgIAAASIA//+LAmA= Date: Wed, 3 Apr 2013 08:23:18 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE263A@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> <20130403080718.GA3195@virgo.local> <8A274A11-6AB6-42A8-8109-19636490E671@netapp.com> In-Reply-To: <8A274A11-6AB6-42A8-8109-19636490E671@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] Roadmap for TCP - New Version 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, 03 Apr 2013 08:23:22 -0000 Hi, My original though was actually to include only those I-Ds/papers, which ar= e either a) widely deployed even though not a formal RFC (FACK, Cubic, CTCP) b) current WG items, that are clearly (at least my impression) on the road = to become, or are already an RFC (IW10, PRR, ExOpt). Regarding MPTCP, I don't have a clear opinion right now. If that is include= d, it would surely warrant a section/subsection of its own. Richard Scheffenegger > -----Original Message----- > From: Eggert, Lars > Sent: Mittwoch, 03. April 2013 10:11 > To: Hagen Paul Pfeifer > Cc: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] Roadmap for TCP - New Version >=20 > Hi, >=20 > On Apr 3, 2013, at 10:07, Hagen Paul Pfeifer wrote: > > * Eggert, Lars | 2013-04-03 06:48:31 [+0000]: > > > >> Won't this section be perpetually outdated? > > > > In the long term yes. But at the end it boils down that a) an I-D was > > becoming an RFC or b) something happened on that way. That "something" > > may be of interest for the readers too. For me a handy document is > > where all development is listed, this should include IW10 and similar > topics. >=20 > yeah, but the point of the document isn't to be a history of TCP > standardization efforts. It's a "start reading here" document for the TCP= - > related RFCs. We have mailing list archives and meeting minutes to help > people figure out the "what happened" part. >=20 > Lars From hagen@jauu.net Wed Apr 3 01:24: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 D660A21F861A for ; Wed, 3 Apr 2013 01:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gOVu-QQcqXhS for ; Wed, 3 Apr 2013 01:24:14 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 3336E21F85E7 for ; Wed, 3 Apr 2013 01:24:14 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1UNIzN-0000em-EO; Wed, 03 Apr 2013 10:24:13 +0200 Date: Wed, 3 Apr 2013 10:24:12 +0200 From: Hagen Paul Pfeifer To: "Eggert, Lars" Message-ID: <20130403082412.GC3195@virgo.local> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> <20130403080718.GA3195@virgo.local> <8A274A11-6AB6-42A8-8109-19636490E671@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A274A11-6AB6-42A8-8109-19636490E671@netapp.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 03 Apr 2013 08:24:15 -0000 * Eggert, Lars | 2013-04-03 08:11:22 [+0000]: >yeah, but the point of the document isn't to be a history of TCP >standardization efforts. It's a "start reading here" document for the >TCP-related RFCs. We have mailing list archives and meeting minutes to help >people figure out the "what happened" part. Right, I don't wanted to focus on the history part. I wanted to provide the ongoing effort, the (eventual) future of TCP. Efforts like the mentioned IW10. I mean for a IETF professional like Lars, who knows about IETF mailing list, IETF structure and websites it may sound simple. But for software guys, requirement engineers, new students it is hard to get the broader picture. But yes, I understand that this section will make the document more "fuzzy". I have no shares here so I don't mind. Hagen From rs@netapp.com Wed Apr 3 02:03: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 E81B621F84D8 for ; Wed, 3 Apr 2013 02:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.199, 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 ZRZaaueAevj1 for ; Wed, 3 Apr 2013 02:03:26 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 62D9B21F84AD for ; Wed, 3 Apr 2013 02:03:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,399,1363158000"; d="scan'208,217";a="250322168" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 03 Apr 2013 02:03:26 -0700 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 r3393PS9015649; Wed, 3 Apr 2013 02:03:25 -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; Wed, 3 Apr 2013 02:03:24 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUw Date: Wed, 3 Apr 2013 09:03:24 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@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: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F24AE28DASACEXCMBX02PRDh_" 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: Wed, 03 Apr 2013 09:03:28 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F24AE28DASACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoshifumi, do you propose to remove the text so that the sender ignores any present SA= CK information while processing TSopt (RTTM updates)? Again, this is a very minor issue, but is in-line with the spirit of 1323 R= TTM (don't update RTTM / RTO, when the ACK indicates any loss/reordering). However, any stack that wants to use RTTM for more advanced purposes than a= (very) conservative bound on RTO, needs to have its own logic apart from t= he 1323 logic to deal with that. (Using Linux, this is less of a concern du= e to the per-segment state used for RTTM updates rather than TSopt). But if no consensus can be found with that text, I revert it to the origina= l 1323 text. Best regards, Richard Scheffenegger From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] Sent: Mittwoch, 03. April 2013 08:43 To: Scheffenegger, Richard Cc: tcpm (tcpm@ietf.org) Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Hi Richard, On Mon, Apr 1, 2013 at 9:56 PM, Scheffenegger, Richard > wrote: > Ts is defined with symetric signalling. Also, the receiver can not know, = if > and which packet might be lost. This is just my personal preference. I'd rather make an exception if we can= safely simplify the logic. But, this might be a different draft if we pursue. -- Yoshifumi --_000_012C3117EDDB3C4781FD802A8C27DD4F24AE28DASACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoshifumi,<= /span>

 <= /p>

do you pro= pose to remove the text so that the sender ignores any present SACK informa= tion while processing TSopt (RTTM updates)?

 = ;

Again, thi= s is a very minor issue, but is in-line with the spirit of 1323 RTTM (don&#= 8217;t update RTTM / RTO, when the ACK indicates any loss/reordering).

 = ;

However, a= ny stack that wants to use RTTM for more advanced purposes than a (very) co= nservative bound on RTO, needs to have its own logic apart from the 1323 logic to deal with that. (Using Linux, this is less of a con= cern due to the per-segment state used for RTTM updates rather than TSopt).=

 = ;

 = ;

But if no = consensus can be found with that text, I revert it to the original 1323 tex= t.

 = ;

 = ;

 = ;

Best regar= ds,

 = ;

Richard Scheffenegger


 <= /p>

From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Sent: Mittwoch, 03. April 2013 08:43
To: Scheffenegger, Richard
Cc: tcpm (tcpm@ietf.org)
Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing fo= r WGLC)

 

Hi Richard,

On Mon, Apr 1, 2013 at 9:56 PM, Scheffenegger, Richard <rs@netapp.com> wrote:
> Ts is defined with symetric signalling. Also, the receiver can not kno= w, if
> and which packet might be lost. 

 

This is just my personal preference. I'd rather make= an exception if we can safely simplify the logic.

But, this might be a different draft if we pursue.

--

Yoshifumi

--_000_012C3117EDDB3C4781FD802A8C27DD4F24AE28DASACEXCMBX02PRDh_-- From michael.scharf@alcatel-lucent.com Wed Apr 3 02:04: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 9CADE21F8782 for ; Wed, 3 Apr 2013 02:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 NU4BcnhBlF2c for ; Wed, 3 Apr 2013 02:04:50 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D26FB21F8712 for ; Wed, 3 Apr 2013 02:04:49 -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 r3394ksP016622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Apr 2013 11:04:47 +0200 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; Wed, 3 Apr 2013 11:04:46 +0200 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "Eggert, Lars" , Hagen Paul Pfeifer Date: Wed, 3 Apr 2013 11:04:46 +0200 Thread-Topic: [tcpm] Roadmap for TCP - New Version Thread-Index: AQHOLwSgJNhMzjvV7US/RrlyS2movJjDLjTQgAFXnYCAABYEgIAAASIA//+LAmCAAA0LEA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6F57@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24AE1132@SACEXCMBX02-PRD.hq.netapp.com> <20130403080718.GA3195@virgo.local> <8A274A11-6AB6-42A8-8109-19636490E671@netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE263A@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AE263A@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 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Roadmap for TCP - New Version 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, 03 Apr 2013 09:04:50 -0000 > My original though was actually to include only those=20 > I-Ds/papers, which are either >=20 > a) widely deployed even though not a formal RFC (FACK, Cubic, CTCP) I do believe that stuff that is really widely deployed in the Internet shou= ld be refered to in "7. Undocumented TCP Features" (possibly having several= subsection). But we shouldn't try to document every congestion control algorithm that wa= s ever presented to ICCRG (or elsewhere) ;) > b) current WG items, that are clearly (at least my=20 > impression) on the road to become, or are already an RFC=20 > (IW10, PRR, ExOpt). Unless something strange happens, those three should be an RFC when this do= cument will be published. I think it is fine to refer to them now. > Regarding MPTCP, I don't have a clear opinion right now. If=20 > that is included, it would surely warrant a=20 > section/subsection of its own. I do believe it should very briefly be mentioned, e.g. as Section 4.6. Michael (chair hat off) >=20 > Richard Scheffenegger >=20 >=20 >=20 > > -----Original Message----- > > From: Eggert, Lars > > Sent: Mittwoch, 03. April 2013 10:11 > > To: Hagen Paul Pfeifer > > Cc: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > > Subject: Re: [tcpm] Roadmap for TCP - New Version > >=20 > > Hi, > >=20 > > On Apr 3, 2013, at 10:07, Hagen Paul Pfeifer wrote: > > > * Eggert, Lars | 2013-04-03 06:48:31 [+0000]: > > > > > >> Won't this section be perpetually outdated? > > > > > > In the long term yes. But at the end it boils down that a) an I-D=20 > > > was becoming an RFC or b) something happened on that way.=20 > That "something" > > > may be of interest for the readers too. For me a handy=20 > document is=20 > > > where all development is listed, this should include IW10 and=20 > > > similar > > topics. > >=20 > > yeah, but the point of the document isn't to be a history of TCP=20 > > standardization efforts. It's a "start reading here"=20 > document for the=20 > > TCP- related RFCs. We have mailing list archives and=20 > meeting minutes=20 > > to help people figure out the "what happened" part. > >=20 > > Lars > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From nishida@sfc.wide.ad.jp Wed Apr 3 23:16: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 D022A21F842C for ; Wed, 3 Apr 2013 23:16:32 -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 NuJJVut+FbPv for ; Wed, 3 Apr 2013 23:16:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id A812321F86CB for ; Wed, 3 Apr 2013 23:16:28 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6A7532780BB for ; Thu, 4 Apr 2013 15:16:26 +0900 (JST) Received: by mail-ob0-f173.google.com with SMTP id wn14so1230168obc.32 for ; Wed, 03 Apr 2013 23:16:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.151.9 with SMTP id um9mr3111415obb.89.1365056184997; Wed, 03 Apr 2013 23:16:24 -0700 (PDT) Received: by 10.76.28.103 with HTTP; Wed, 3 Apr 2013 23:16:24 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> Date: Wed, 3 Apr 2013 23:16:24 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=f46d0444e9250164d504d982e975 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: Thu, 04 Apr 2013 06:16:33 -0000 --f46d0444e9250164d504d982e975 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Richard, On Wed, Apr 3, 2013 at 2:03 AM, Scheffenegger, Richard wrote= : > Hi Yoshifumi,**** > > ** ** > > do you propose to remove the text so that the sender ignores any present > SACK information while processing TSopt (RTTM updates)? > ** > > Again, this is a very minor issue, but is in-line with the spirit of 1323 > RTTM (don=92t update RTTM / RTO, when the ACK indicates any loss/reorderi= ng). > Hmm. Which text are you referring to? It sounds good thing, but I'm not proposing yet.. I just prefer not to send TSecr if it's no use for RTTM. Thanks, -- Yoshifumi --f46d0444e9250164d504d982e975 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Wed, Apr 3, 2013 at 2:03 AM, Scheffenegger, Richard <rs@ne= tapp.com> wrote:

Hi Yoshifumi,

=A0<= /p>

do you pro= pose to remove the text so that the sender ignores any present SACK informa= tion while processing TSopt (RTTM updates)?

=A0

Again, thi= s is a very minor issue, but is in-line with the spirit of 1323 RTTM (don= =92t update RTTM / RTO, when the ACK indicates any loss/reordering).=


Hmm. Which text are you = referring to? It sounds good thing, but I'm not proposing yet..
I just prefer not to send TSecr if it's no use for RTTM.=A0

Thanks,
--
Yoshifumi

--f46d0444e9250164d504d982e975-- From rs@netapp.com Thu Apr 4 02:01: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 B445A21F95DB for ; Thu, 4 Apr 2013 02:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 ryooDgeJJZrZ for ; Thu, 4 Apr 2013 02:01:30 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 03FD921F93F6 for ; Thu, 4 Apr 2013 02:01:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,407,1363158000"; d="scan'208";a="36983909" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 04 Apr 2013 02:01:13 -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 r3491CiC023274; Thu, 4 Apr 2013 02:01:13 -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; Thu, 4 Apr 2013 02:00:52 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkA== Date: Thu, 4 Apr 2013 09:00:51 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@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="us-ascii" 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: Thu, 04 Apr 2013 09:01:30 -0000 Hi Yoshifumi, >> do you propose to remove the text so that the=20 >> sender ignores any present SACK information=20 >> while processing TSopt (RTTM updates)? >> =20 >> Again, this is a very minor issue, but is=20 >> in-line with the spirit of 1323 RTTM (don't=20 >> update RTTM / RTO, when the ACK indicates any=20 >> loss/reordering). > > Hmm. Which text are you referring to?=20 I was referring to the (sender side) mechanism, which TSecr may be used to = update RTT, specifically the added point b) in 1323bis-08 RTTM Rule: A TSecr value received in a segment is used to update the averaged RTT measurement only if a) the segment acknowledges some new data, i.e., only if it advances the left edge of the send window, and b) the segment does not indicate any potential loss or reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC2883] options=20 (a) excludes DupACKs (provided the initial ACK was not lost). (b) excludes DupACKs when SACK is negotiated, and when the initial ACK of t= he sequence of DupACKs was lost. It doesn't help non-SACK sessions.=20 > It sounds good thing, but I'm not proposing yet.. > I just prefer not to send TSecr if it's no use for RTTM. Well, that would require a special handling of TSecr=3D0 on the sender side= (linux generally ignored TSopt when TSecr=3D0, which also wasn't proper, b= efore relying solely on sender-side per-segment state for RTTM due to exper= ience with Cubic). Alternatively it requires a change in the basic signalin= g (using a shortened TSopt without the TSecr part), if I understand you cor= rectly. Finally, this would be a receiver side change, while updating a sen= der to ignore TSecr when a SACK opt is present, doesn't break any existing = stacks and interactions, only improves RTTM/RTO handling of the updated sen= der stack. The receiver side change would have unpredictable results as man= y stacks don't have any special logic to determine if TSecr=3D0 signals an = invalid TSecr value, or a valid reflected TSval that just happens to be zer= o. Under some circumstances, negative RTT could be calculated, and that wou= ld not be a good thing... >>> ---------------------> >>> tik >>> <---------------- >>> >>> ---------------------> >>> tik >>> X-------------- >>> >>> -------------------X >>> tik >>> >>> >>> ---------------------> >>> tik >>> <------- <=3D=3D * *) current TSecr (as in 1323) is declared to be TSecr=3D-7; A 1323 stack me= asures a RTT of (-4 - -7)=3D3 in this scenario, rather than ignoring the sa= mple (RTT is assumed to be truly 1 without loss here, e.g. TS clock ticks a= fter sending of the segment, before receiving the ACKs "tik"). A legacy 1323 sender (without special logic for the case TSecr=3D0, e.g. mo= st stacks) with a modified receiver would measure a RTT of (-4 - 0) =3D -4 = here (or a potentially large positive value). Again, if the WG thinks that this minuscule improvement delivered by point = (b) above is not deemed worthwhile, I strongly believe that removing that t= ext is less problematic than suggesting major changes in the TSopt semantic= s. Regards, Richard Scheffenegger From rs@netapp.com Thu Apr 4 02:07: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 1119B21F9619 for ; Thu, 4 Apr 2013 02:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 sVkWQtsHncNw for ; Thu, 4 Apr 2013 02:07:01 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 771BD21F95FC for ; Thu, 4 Apr 2013 02:07:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,407,1363158000"; d="scan'208";a="36985076" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 04 Apr 2013 02:07:01 -0700 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r34970oj000573; Thu, 4 Apr 2013 02:07:01 -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, 4 Apr 2013 02:07:00 -0700 From: "Scheffenegger, Richard" To: "Scheffenegger, Richard" , Yoshifumi Nishida Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g Date: Thu, 4 Apr 2013 09:07:00 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@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: text/plain; charset="us-ascii" 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: Thu, 04 Apr 2013 09:07:02 -0000 On an additional glance, perhaps this text reflects better what an implemen= ter should be looking at: RTTM Rule: A TSecr value received in a segment MAY be used to=20 update the averaged RTT measurement only if Adding a RFC2119 MAY to underline Mark's point that per-segment RTT samplin= g might not be the wisest way to update RTO... Regards, Richard Scheffenegger From ycheng@google.com Thu Apr 4 10:22: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 0836421F8FAC for ; Thu, 4 Apr 2013 10:22:01 -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 vUua-U8hzq8e for ; Thu, 4 Apr 2013 10:22:00 -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 4CA8E21F8F0E for ; Thu, 4 Apr 2013 10:21:59 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so2734561lab.31 for ; Thu, 04 Apr 2013 10:21:59 -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=vcpJZ2OGfeU+lDnXHuBssppFCXjC6/xsyDHstfJ2qy8=; b=ep5Zap9jw+PAmx230zc3loi/GIfqiLYJpobHOOPSGzItgTQLB0WxpJK2+lIWp7M/T2 xdOGt2izmHPwTGB3/jO9DuWH1xWO7BwFY/uSAx/h+wRGDiXY9hf2fnIN0OfAMdTUlNfg jO8/2Pqcg8aRp1g5MI/c+0S2ClyuvjUdB2exRqfBuJnp8GU1eqiYSRp0C/YF8S+D6aNO Kw2Y3N2wD5/M7eunu6UhlJ3rGV/lv6dKUdXPGalr3PQCbQBnfWcfbo/0lXSMWaGQoUnf xnQGn/RvirMNtzvETqAZTkDnQ0Im9VOFFJrsGaLTCJ9Yc5exbKuQquNgNwT1BPEYFCO7 b4Tw== 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=vcpJZ2OGfeU+lDnXHuBssppFCXjC6/xsyDHstfJ2qy8=; b=n7DZcujP9xPx6rYpTAKuW+CPRQrgx3dPEBIE8vNeMvH6qHI4x7hEmwn/iUTA9g+twG f7ajw1ylGJuikncKbIxmLiGOea8fwCV+qLbtIlfT+l4/DFfxZ8R90Vb4a/oXxSFZmq4g 1rnA4HaQvMV1uXWbMvlyO22aR2jMoKwYyoM52a4Q93x+tNY9EjKB0jHcXO0ZSmUkQ+FZ 80B3d60Y88B9M6Yllpw12WoRkfTCpi94/HqSFEooJ4ijE76Qk9W2QmiM9XycF3A3o4FN MpQYXcPE+feLq9GI+n/GF8nRb6mrhQ1uSQiKuZpNzExdesyN93IwoeqU5bTfLPA49ML5 p6mg== X-Received: by 10.112.74.98 with SMTP id s2mr1930521lbv.9.1365096118912; Thu, 04 Apr 2013 10:21:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.74.163 with HTTP; Thu, 4 Apr 2013 10:21:37 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Thu, 4 Apr 2013 10:21:37 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkKR/tdMbSQejJ6Zf5tibzzFiZ4oX+BIRH+iUQ/VVpc6uv7q8EOaoKe2DjsqU/PVJ3Uzpk1bflFw/DhsBrB7W2Um/PmgLvU5LUkIcvArBqkoK6qBLoBnQqsKToLFoFAg2D6hAUmFjIhYKCrujfT/Tc+kGiCC0orN2XUB0YU4vyesWP+eSKl9/sIhwzZE+lLosG8L8Pq 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: Thu, 04 Apr 2013 17:22:01 -0000 I would prefer not changing RTTM section at all, unless data indicate it's worth the change. The existing rule is great to help implementor avoid a common pitfall. The implementor can decide on other smaller cases and RFCs do not have to be so rigid. On Thu, Apr 4, 2013 at 2:07 AM, Scheffenegger, Richard wrote: > > On an additional glance, perhaps this text reflects better what an implementer should be looking at: > > > RTTM Rule: A TSecr value received in a segment MAY be used to > update the averaged RTT measurement only if > > > Adding a RFC2119 MAY to underline Mark's point that per-segment RTT sampling might not be the wisest way to update RTO... > > Regards, > > Richard Scheffenegger > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Tue Apr 9 08:46: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 E78B921F94A4 for ; Tue, 9 Apr 2013 08:46:56 -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 sSzg4lxyLiya for ; Tue, 9 Apr 2013 08:46:56 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3E50621F919D for ; Tue, 9 Apr 2013 08:46:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,439,1363158000"; d="scan'208";a="38783571" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 09 Apr 2013 08:46:52 -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 r39Fkqqf027391; Tue, 9 Apr 2013 08:46:52 -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; Tue, 9 Apr 2013 08:46:51 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng , Yoshifumi Nishida Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g///U9YD/+Lz/oA== Date: Tue, 9 Apr 2013 15:46:50 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@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="us-ascii" 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: Tue, 09 Apr 2013 15:46:57 -0000 Hi Yuchung, Yoshifumi, as the interactions between different options aren't documented really anyw= here I think this update to 1323 would be a good opportunity to at least hi= nt an implementer to the possibility of utilizing other signals as well. These are the sections in the older versions: Original (1323): =20 that is inflated by gaps in sending data. 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. Debated Text (bis-08): inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT: RTTM Rule: A TSecr value received in a segment is used to update the averaged RTT measurement only if a) the segment acknowledges some new data, i.e., only if it advances the left edge of the send window, and b) the segment does not indicate any potential loss or reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC2883] options I propose the following compromise in the text. Updated (bis-09): inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT: RTTM Rule: A TSecr value received in a segment MAY be 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, and does not indicate any potential loss, i.e. no TCP SACK option is present. I repeat, this is a minor corner case, doing little harm if not fixed (infl= ating RTO and delaying loss recovery by timeout slightly). However, I stong= ly feel that this is the correct way to treat RTT updates on the sender sid= e, and if not added in this iteration, it probably won't be added ever... Anyone having strong objections to this text segment? Richard Scheffenegger > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Donnerstag, 04. April 2013 19:22 > To: Scheffenegger, Richard > Cc: Yoshifumi Nishida; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > WGLC) >=20 > I would prefer not changing RTTM section at all, unless data indicate it'= s > worth the change. The existing rule is great to help implementor avoid a > common pitfall. The implementor can decide on other smaller cases and RFC= s > do not have to be so rigid. >=20 > On Thu, Apr 4, 2013 at 2:07 AM, Scheffenegger, Richard > wrote: > > > > On an additional glance, perhaps this text reflects better what an > implementer should be looking at: > > > > > > RTTM Rule: A TSecr value received in a segment MAY be used to > > update the averaged RTT measurement only if > > > > > > Adding a RFC2119 MAY to underline Mark's point that per-segment RTT > sampling might not be the wisest way to update RTO... > > > > Regards, > > > > Richard Scheffenegger > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Tue Apr 9 09:37: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 C388E21F9026 for ; Tue, 9 Apr 2013 09:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 4Wp2i5JihH3f for ; Tue, 9 Apr 2013 09:37:36 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2550221F8F16 for ; Tue, 9 Apr 2013 09:37:32 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so6663689lab.30 for ; Tue, 09 Apr 2013 09:37:32 -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=0/fuQuXjnKUDHhFM3DgVPm8QvLhogtbCWsPzHOfiJXY=; b=Umu60frxJpQQlRP2V/g6s1cW0QMlC+sg5iHb0opvIPg2GuzR4w2wGMxAQKmrvXUWKw 7uhT+zeJJlsWG2qht+vw8epUlXH5ms+wPOFqJbBHfeYnrMHYWyDmDHBsEbf8QiyQXVs2 GWD3xSvzdR5xmZkXx1Jz41PRIWJc+P/vnJPSfcg/o/bc5dCaFh+CcdH3Jeuoi/vzbnRL SGknXZaGoqQsAeC8BLXByu4l36xHbKRk5d03mIF7LpRv6UBVMBpfgCQGFQrqHg4hIyr6 6+iL4xlFTW79V66fQ3H9Pe6mLqRtBwVyRLIESgLuehmZPQXrhKdRo1eWhsKrTQMJNP0W Mo3w== 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=0/fuQuXjnKUDHhFM3DgVPm8QvLhogtbCWsPzHOfiJXY=; b=VQqqDzliClAyc8/DMvcLbNMAZzCetkyLw0wpSk2gTS33iEeOdTHK9GoWtlSjBHMq3k NbQ+7Wl6Iv+CB70kHjMdrCGV7Usc7TLBqgVKBIV5F03tDvAutDEyIdDJx3rJ9+Ds6OpJ MkhQT3vyrmWRqYsdZwFV1I5qMruIF1kLzKdZFiGECvAdxFs5i+x5uqTQZiZ6RsJNlgGR 5d/TZVCwv8+i6ztvX9iIAFRcIzai0xBrdu3fxsXZ4Ffp/Vo8u3Q8kQ4EAUxpPWr17QlQ fJDMkqf44CShGAEob0gGqjNZysDDuf+mz6d1IHAFDGIAuNCi++hyo7O4Lt/U5mrZUKVh 4aWw== X-Received: by 10.152.20.6 with SMTP id j6mr10873193lae.7.1365525451914; Tue, 09 Apr 2013 09:37:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.137.196 with HTTP; Tue, 9 Apr 2013 09:37:11 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Tue, 9 Apr 2013 09:37:11 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=089e013d20347e4fe804d9f02bbc X-Gm-Message-State: ALoCoQljpE8w7yAkimLr4ZA0PN2UoVLbMnxKcfQN2m3DThdRgDMCJfMLG476pIlVMERjOQB9rZrR4ZNY68gGoF/o84gZP7IMi8IKm1d4xT8jE9H0MSWVjqRvVrR1fKsbT+/VtxKmj3VGy86GKakY15kj9POiB5S7jN0b9u0/MWONiBGJS92vqv3VOqUA3zhLDbqfU2NpJ7kZ 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: Tue, 09 Apr 2013 16:37:38 -0000 --089e013d20347e4fe804d9f02bbc Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard wrote: > > Hi Yuchung, Yoshifumi, > > > as the interactions between different options aren't documented really > anywhere I think this update to 1323 would be a good opportunity to at > least hint an implementer to the possibility of utilizing other signals as > well. > > > These are the sections in the older versions: > > Original (1323): > > that is inflated by gaps in sending data. 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. > > Debated Text (bis-08): > > inflated by gaps in sending data. However, the following rule > prevents a resulting inflation of the measured RTT: > > RTTM Rule: A TSecr value received in a segment is used to update > the averaged RTT measurement only if > > a) the segment acknowledges some new data, i.e., only if it > advances the left edge of the send window, and > > b) the segment does not indicate any potential loss or > reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC2883] > options > > > I propose the following compromise in the text. > > > Updated (bis-09): > > inflated by gaps in sending data. However, the following rule > prevents a resulting inflation of the measured RTT: > > RTTM Rule: A TSecr value received in a segment MAY be 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, and does not indicate any potential loss, > i.e. no TCP SACK option is present. > It's a rewording of bis-08 but logically it's the same. > I repeat, this is a minor corner case, doing little harm if not fixed > (inflating RTO and delaying loss recovery by timeout slightly). However, I > stongly feel that this is the correct way to treat RTT updates on the > sender side, and if not added in this iteration, it probably won't be added > ever... > I repeat this will nullify much benefits TS-RTTM provides over regular RTTM. The advantage of TS-RTTM is to sample RTT on ACKs of retransmitted sequences. It's common for these ACKs to both advance SND.UNA and still contain, sometimes new, SACK blocks. Unless you can provide some data to prove this is a bug needs to be addressed, we should not revise RFC by personal feelings. > > Anyone having strong objections to this text segment? > I strongly object. > > > Richard Scheffenegger > > > > > > > -----Original Message----- > > From: Yuchung Cheng [mailto:ycheng@google.com] > > Sent: Donnerstag, 04. April 2013 19:22 > > To: Scheffenegger, Richard > > Cc: Yoshifumi Nishida; tcpm (tcpm@ietf.org) > > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > > WGLC) > > > > I would prefer not changing RTTM section at all, unless data indicate > it's > > worth the change. The existing rule is great to help implementor avoid a > > common pitfall. The implementor can decide on other smaller cases and > RFCs > > do not have to be so rigid. > > > > On Thu, Apr 4, 2013 at 2:07 AM, Scheffenegger, Richard > > wrote: > > > > > > On an additional glance, perhaps this text reflects better what an > > implementer should be looking at: > > > > > > > > > RTTM Rule: A TSecr value received in a segment MAY be used to > > > update the averaged RTT measurement only if > > > > > > > > > Adding a RFC2119 MAY to underline Mark's point that per-segment RTT > > sampling might not be the wisest way to update RTO... > > > > > > Regards, > > > > > > Richard Scheffenegger > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > --089e013d20347e4fe804d9f02bbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard <rs@netapp.com<= /a>> wrote:

Hi Yuchung, Yoshifumi,


as the interactions between different options aren't documented really = anywhere I think this update to 1323 would be a good opportunity to at leas= t hint an implementer to the possibility of utilizing other signals as well= .


These are the sections in the older versions:

Original (1323):

=A0 =A0 =A0 that is inflated by gaps in sending data. =A0However, the follo= wing
=A0 =A0 =A0 rule prevents a resulting inflation of the me= asured RTT:

=A0 =A0 =A0 =A0 =A0 =A0A TSecr value received in a segment is used to= update the
=A0 =A0 =A0 =A0 =A0 =A0averaged RTT measurement only if the segment acknowl= edges
=A0 =A0 =A0 =A0 =A0 =A0some new data, i.e., only if it ad= vances the left edge of the
=A0 =A0 =A0 =A0 =A0 =A0send window.

Debated Text (bis-08):

=A0 =A0inflated by gaps in sending data. =A0However, the following rule
=A0 =A0prevents a resulting inflation of the measured RTT= :

=A0 =A0 =A0 RTTM Rule: A TSecr value received in a segment is used to= update
=A0 =A0 =A0 the averaged RTT measurement only if

=A0 =A0 =A0 a) =A0the segment acknowledges some new= data, i.e., only if it
=A0 =A0 =A0 =A0 =A0 advances the left edge of the send window, and

=A0 =A0 =A0 b) =A0the segment does not indicate any potential loss or
=A0 =A0 =A0 =A0 =A0 reordering, i.e. contains SACK [RFC2018] or D-SACK [RFC= 2883]
=A0 =A0 =A0 =A0 =A0 options


I propose the following compromise in the text.


Updated (bis-09):

=A0 =A0inflated by gaps in sending data. =A0However, the following rule
=A0 =A0prevents a resulting inflation of the measured RTT= :

=A0 =A0 =A0 RTTM Rule: A TSecr value received in a = segment MAY be used to
=A0 =A0 =A0 update the averaged RTT measurement only if the segment =A0 =A0 =A0 acknowledges some new data, i.e. only if it advances the left =A0 =A0 =A0 edge of the send window, and does not indicate any potential lo= ss,
=A0 =A0 =A0 i.e. no TCP SACK option is present.
= It's a rewording of bis-08 but logically it's the same.


I repeat, this is a minor corner case, doing little harm if not fixed (infl= ating RTO and delaying loss recovery by timeout slightly). However, I stong= ly feel that this is the correct way to treat RTT updates on the sender sid= e, and if not added in this iteration, it probably won't be added ever.= ..
I repeat this will nullify much benefits TS-RTTM pr= ovides over regular RTTM. The advantage of TS-RTTM is to sample RTT on ACKs= of retransmitted sequences. It's common for these ACKs to both advance= SND.UNA and still contain, sometimes new, SACK blocks.

Unless you can provide some data to prove t= his is a bug needs to be addressed, we should not revise RFC by personal fe= elings.



Anyone having strong objections to this text segment?
I strongly object.




Richard Scheffenegger





> -----Original Message-----
> From: Yuchung Cheng [mailto:ychen= g@google.com]
> Sent: Donnerstag, 04. April 2013 19:22<= br> > To: Scheffenegger, Richard
> Cc: Yoshifumi Nishida; tcpm (tcpm@ietf.org)
> Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for<= br> > WGLC)
>
> I would prefer not chang= ing RTTM section at all, unless data indicate it's
> worth the change. The existing rule is great to help implementor avoid= a
> common pitfall. The implementor can decide on other smaller cases and = RFCs
> do not have to be so rigid.
>
> On Thu, Apr 4, 2013 at 2:07 AM, Scheffenegger, Richard <rs@netapp.com>
> wrote:
> >
> > On an additional glance, perhaps this text reflects better what a= n
> implementer should be looking at:
> >
> >
> > =A0 =A0 =A0 RTTM Rule: A TSecr value received in a segment MAY be= used to
> > =A0 =A0 =A0 update the averaged RTT measurement only if
> >
> >
> > Adding a RFC2119 MAY to underline Mark's point that per-segme= nt RTT
> sampling might not be the wisest way to update RTO...
> >
> > Regards,
> >
> > Richard Scheffenegger
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm

--089e013d20347e4fe804d9f02bbc-- From mattmathis@google.com Tue Apr 9 09:38: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 3E13E21F900F for ; Tue, 9 Apr 2013 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 cVwzR+2xzcqm for ; Tue, 9 Apr 2013 09:38:26 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 840CD21F8F16 for ; Tue, 9 Apr 2013 09:38:26 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id f27so840466iae.9 for ; Tue, 09 Apr 2013 09:38:21 -0700 (PDT) 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; bh=HfoQjnqWYe6EUYe63neCPm0M83NwR2kTRfol9CTXzdA=; b=dSBMm7H3t9mw0BFLWbbpNUidOJBEl0ICH0JI9h3HjcOmpVGn1RpGydIE38xOMkIw2x 2zXhgyXB+A1oQ/gffi15p3rX8ip74U8jux06T3BWkuDMv2IjKSSf0c0n3g6tMeOA6y8h +JZkd0TsLv694JqaYR0aDR04OlKjxlSgmqqqtKLkaVic+hiUDf2cq7uVC+sTq8eLLlcB 7z71Ly29zBcqJhX8noyrXUJWGlsEFe1bFPaHIZZQ03DPfShpxmCUDIrw9Qe0KUhuzpln LWGiYolFFMjYYdQe6fjmgLS/urZqlBNTX56gPPZYJP3JEtRRL7ZGin8pFLhM9J5c2bSd tlqQ== 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=HfoQjnqWYe6EUYe63neCPm0M83NwR2kTRfol9CTXzdA=; b=OI3W+enmj7ZEHN8h0/tzGwNmyCWaGE/E4u3RN8PdYCFn1RBYlOp10ZFc7FZHLym4AV o9THqVdq79nmcroHglC54CYCrWs6D9xJoFR/kdxTrnx+XvOfdu1g57jD1vtfAwObmFfL ADjmdPrjD4Fmmej8bNq5Qxr4Kuvwwjc4NKDyNmnfIAI53R6eZJYC/Ee5NtB79hLEIeh1 BJAqx4Kp9GubuBd6JAPqmGsPBNIfZxriEPmdthWcm44YxfWG8VTIMSG2oxCkKmY5IWX9 8dweuZlWl0i7cnFX/1BjzAuykni8lUfwv785hir4sXt9ULeBzWghGLYwkUI3ua0iIjSr 0ujQ== MIME-Version: 1.0 X-Received: by 10.50.170.36 with SMTP id aj4mr10423878igc.67.1365525501010; Tue, 09 Apr 2013 09:38:21 -0700 (PDT) Received: by 10.50.91.226 with HTTP; Tue, 9 Apr 2013 09:38:20 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 9 Apr 2013 09:38:20 -0700 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=e89a8f234a516bc69104d9f02e1e X-Gm-Message-State: ALoCoQkK2nO1QwGje0+WKDkTPVBTW3/+Ls9STzRa5+hK8pdpRuJth1q3+w5GrDxSjV7l97F6B981w15DTEU9kA3YgoAgICAB1N3mpGn9c1G8b3MhGgkcUYf1S/6h+VdCG/8uRyAWuQ7Eq9DrY39Wf5I13U2ndBZCmL14GcW9oRZhOnVy97jKKaQUALvGFkr5JPxzHA31F6f/ 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: Tue, 09 Apr 2013 16:38:27 -0000 --e89a8f234a516bc69104d9f02e1e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard wrote: > RTTM Rule: A TSecr value received in a segment MAY be 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, and does not indicate any potential loss, > i.e. no TCP SACK option is present. > I would like to point out that this is over constrained. In particular "acknowledges some new data" explicitly include when snd.fack advances, or even when SACK reports any never retransmitted data, even though disallowed later. There are a number of algorithms (such as this one) that could be improved with: gs/snd.una/snd.fack/g Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. --e89a8f234a516bc69104d9f02e1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard &l= t;rs@netapp.com><= /span> wrote:
RTTM Rule: A TSecr value received in a s= egment MAY be used to
=A0 =A0 =A0 update the averaged RTT measurement only if the segment =A0 =A0 =A0 acknowledges some new data, i.e. only if it advances the left =A0 =A0 =A0 edge of the send window, and does not indicate any potential lo= ss,
=A0 =A0 =A0 i.e. no TCP SACK option is present.

I= would like to point out that this is over constrained. =A0In particular &q= uot;acknowledges some new data" explicitly include when snd.fack advan= ces, or even when SACK reports any never retransmitted data, even though di= sallowed later.

There are a= number of algorithms (such as this one) that could be improved with: gs/sn= d.una/snd.fack/g

Thanks,--MM--
The best way to predict the future is to create it. =A0- Alan Kay

Pr= ivacy matters! =A0We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. =A0 We treat privacy and s= ecurity as matters of life and death, because for some users, they are.
--e89a8f234a516bc69104d9f02e1e-- From touch@isi.edu Tue Apr 9 10:14:09 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 8A62721F91AB for ; Tue, 9 Apr 2013 10:14:09 -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 Lq-roP+6pCIT for ; Tue, 9 Apr 2013 10:14:08 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6F21F8FB2 for ; Tue, 9 Apr 2013 10:14:08 -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 r39HDQos022103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Apr 2013 10:13:26 -0700 (PDT) Message-ID: <51644C23.6080901@isi.edu> Date: Tue, 09 Apr 2013 10:13:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yuchung Cheng References: <2AA8850E-0CC9-46E3-9586-AFC4D8F28D84@ericsson.com> <20130327180524.GA12940@verdi> <012C3117EDDB3C4781FD802A8C27DD4F24AD481F@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.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 \(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: Tue, 09 Apr 2013 17:14:09 -0000 +1 On 4/9/2013 9:37 AM, Yuchung Cheng wrote: > Unless you can provide some data to prove this is a bug needs to be > addressed, we should not revise RFC by personal feelings. From dab@weston.borman.com Tue Apr 9 10:38: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 B60AA21F93ED for ; Tue, 9 Apr 2013 10:38:31 -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_34=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 4LXFDhni205O for ; Tue, 9 Apr 2013 10:38:31 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id E12B221F93DA for ; Tue, 9 Apr 2013 10:38:30 -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 r39HcQ7F025187; Tue, 9 Apr 2013 12:38:27 -0500 (CDT) 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: Date: Tue, 9 Apr 2013 12:38:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <36FAA907-1D2F-4CDC-9C00-4F052B44A5C0@weston.borman.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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> To: Matt Mathis , "tcpm (tcpm@ietf.org)" X-Mailer: Apple Mail (2.1503) 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: Tue, 09 Apr 2013 17:38:31 -0000 Let's take a step back. The goal is that if you are using TSecr to compute the RTT, for use in the RTO, you want a reasonable assurance that it'll be somewhat accurate. That happens when TSecr is from a = packet that was recently received on the remote end. Delayed ACKs add to = latency, so you want to account for that when calculating the RTT. But ACK = packets can be generated for other reasons, and they can't be relied on for = calculating a reasonable RTT, since not all ACKs are generated in direct response to = an incoming packet. Hence, the rules in 1323 for which RTT to echo are intended to include delayed ACKs in the RTT measurement, and the rules for which TSecr can be used for RTO calculations are meant to exclude TSecr values that we know can cause wildly inflated RTT values. The "acknowledges some new data" bit is based on the fact that when the left edge of the window advances, it means that a packet arrived that filled in the hole, and the ACK is being generated in response to that packet. The change from 1323 to exclude RTT calculations if there is potential loss is, in my opinion, overly restrictive. The issue is that corner cases have been identified where due to loss you can get an inflated RTT measurement. But that's not necessarily a bad thing. For purposes of updating the RTO, one inflated RTT isn't going to throw things out of = whack. And if you are hitting this multiple times, maybe that should be = considered part of the latency and included in the RTO, just as 1323 already = includes the latency of delayed ACKs in the RTT measurement. One advantage of TS is that it *can* get reasonable RTT measurements = even when there is some packet loss. Excluding RTT measurements if there is packet loss losses that advantage. So, I see this as a grey area, not absolute. We want to include the situations that are most likely to generate a reasonable RTT = measurement, and exclude the situations that are most likely to generate inflated RTT measurements. We don't need protection for every corner case that might cause an inflated RTT measurement, because the RTO should be somewhat resilient against that. -David Borman =20 On Apr 9, 2013, at 11:38 AM, Matt Mathis wrote: > On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard = wrote: >=20 >> RTTM Rule: A TSecr value received in a segment MAY be 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, and does not indicate any potential = loss, >> i.e. no TCP SACK option is present. >>=20 >=20 > I would like to point out that this is over constrained. In = particular > "acknowledges some new data" explicitly include when snd.fack = advances, or > even when SACK reports any never retransmitted data, even though = disallowed > later. >=20 > There are a number of algorithms (such as this one) that could be = improved > with: gs/snd.una/snd.fack/g >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat = privacy and > security as matters of life and death, because for some users, they = are. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Tue Apr 9 11:14: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 12AA521F9389 for ; Tue, 9 Apr 2013 11:14:11 -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 96n2codQFk2l for ; Tue, 9 Apr 2013 11:14:10 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0F54021F937E for ; Tue, 9 Apr 2013 11:14:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,441,1363158000"; d="scan'208";a="38834303" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 09 Apr 2013 11:14:09 -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 r39IE99A027147; Tue, 9 Apr 2013 11:14: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; Tue, 9 Apr 2013 11:14:09 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g///U9YD/+Lz/oIAPEj+AgABdEXA= Date: Tue, 9 Apr 2013 18:14:08 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@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="us-ascii" 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: Tue, 09 Apr 2013 18:14:11 -0000 Hi Yuchung, > It's a rewording of bis-08 but logically it's the same. Guilty as charged. But formatted differently to look less imposing. >> I repeat, this is a minor corner case, doing little harm=20 >> if not fixed (inflating RTO and delaying loss recovery=20 >> by timeout slightly). However, I stongly feel that this=20 >> is the correct way to treat RTT updates on the sender=20 >> side, and if not added in this iteration, it probably=20 >> won't be added ever... > > I repeat this will nullify much benefits TS-RTTM provides=20 > over regular RTTM. The advantage of TS-RTTM is to sample=20 > RTT on ACKs of retransmitted sequences. It's common for=20 > these ACKs to both advance SND.UNA and still contain,=20 > sometimes new, SACK blocks. Ah, there might be a misconception. This change concerns what the sender is= doing with received TSecr. The receiver, however, is already - according to both 1323 and 1323bis - ke= eping an "outdated" TSrecent, and reflecting that as TSecr, for the *entire= * duration of a loss/reordering event. You simply won't get a proper RTTM sampling using the current TS semantics = during such an episode. I'm merely proposing to limit the impact to the sen= der these semantics can already have, under a specific set of circumstances= . Please have another look at the graph I posted earlier,=20 http://www.ietf.org/mail-archive/web/tcpm/current/msg07810.html and you'll note that TS RTT *will not* deliver any benefits over what linux= is already doing... Actually, the linux stack matching the SACK updates to= the sent segments will most likely sample *accurate* network RTT even duri= ng loss/reordering using the per-segment state. (I've not looked into that = stack deep enough to say this is so, but it's definitely possible using all= the state kept). "Proper" TS RTTM would require that last ACK to have a TSecr=3D5, not TSecr= =3D2. In that case stated (loss of the last in-sequence ACK), 1323 will bloat RTT= /RTO. =20 Best regards, Richard Scheffenegger From rs@netapp.com Tue Apr 9 11:25: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 9095521F95EC for ; Tue, 9 Apr 2013 11:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 CMpFuIMkeYSc for ; Tue, 9 Apr 2013 11:25:17 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 02D9B21F95EF for ; Tue, 9 Apr 2013 11:25:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,441,1363158000"; d="scan'208";a="251454354" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 09 Apr 2013 11:25:17 -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 r39IPFlE026158; Tue, 9 Apr 2013 11:25: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; Tue, 9 Apr 2013 11:25:15 -0700 From: "Scheffenegger, Richard" To: David Borman , Matt Mathis , "tcpm (tcpm@ietf.org)" Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g///U9YD/+Lz/oIAPEpEAgAAQywCAAGnLIA== Date: Tue, 9 Apr 2013 18:25:14 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AEF268@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <36FAA907-1D2F-4CDC-9C00-4F052B44A5C0@weston.borman.com> In-Reply-To: <36FAA907-1D2F-4CDC-9C00-4F052B44A5C0@weston.borman.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: 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: Tue, 09 Apr 2013 18:25:19 -0000 Thank you David and Matt, Then the text should than actually be RTTM Rule: A TSecr value received in a segment MAY be used to update the averaged RTT measurement only if the segment advances the left edge of the send window (e.g. SND.UNA is=20 increased).=20 As Matt pointed out, the old text would apply when SND.FACK advances (or th= e number of bytes marked missing in the scoreboard decreases).=20 But Dave asserts that we don't want to take a RTT Measurement then as this = would definitely inflate the RTT due to the semantics of TSrecent on the re= ceiver side.=20 This must be one of the few cases where you don't want s/snd.una/snd.fack/g Does that now make sense? Richard Scheffenegger > -----Original Message----- > From: David Borman [mailto:dab@weston.borman.com] > Sent: Dienstag, 09. April 2013 19:38 > To: Matt Mathis; tcpm (tcpm@ietf.org) > Cc: Scheffenegger, Richard > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > WGLC) >=20 > Let's take a step back. The goal is that if you are using TSecr to > compute the RTT, for use in the RTO, you want a reasonable assurance that > it'll be somewhat accurate. That happens when TSecr is from a packet tha= t > was recently received on the remote end. Delayed ACKs add to latency, so > you want to account for that when calculating the RTT. But ACK packets > can be generated for other reasons, and they can't be relied on for > calculating a reasonable RTT, since not all ACKs are generated in direct > response to an incoming packet. >=20 > Hence, the rules in 1323 for which RTT to echo are intended to include > delayed ACKs in the RTT measurement, and the rules for which TSecr can be > used for RTO calculations are meant to exclude TSecr values that we know > can cause wildly inflated RTT values. >=20 >=20 > The "acknowledges some new data" bit is based on the fact that when the > left edge of the window advances, it means that a packet arrived that > filled in the hole, and the ACK is being generated in response to that > packet. >=20 > The change from 1323 to exclude RTT calculations if there is potential > loss is, in my opinion, overly restrictive. The issue is that corner > cases have been identified where due to loss you can get an inflated RTT > measurement. But that's not necessarily a bad thing. For purposes of > updating the RTO, one inflated RTT isn't going to throw things out of > whack. > And if you are hitting this multiple times, maybe that should be > considered part of the latency and included in the RTO, just as 1323 > already includes the latency of delayed ACKs in the RTT measurement. >=20 > One advantage of TS is that it *can* get reasonable RTT measurements even > when there is some packet loss. Excluding RTT measurements if there is > packet loss losses that advantage. >=20 > So, I see this as a grey area, not absolute. We want to include the > situations that are most likely to generate a reasonable RTT measurement, > and exclude the situations that are most likely to generate inflated RTT > measurements. We don't need protection for every corner case that might > cause an inflated RTT measurement, because the RTO should be somewhat > resilient against that. >=20 > -David Borman >=20 > On Apr 9, 2013, at 11:38 AM, Matt Mathis wrote: >=20 > > On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard > wrote: > > > >> RTTM Rule: A TSecr value received in a segment MAY be 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, and does not indicate any potential loss= , > >> i.e. no TCP SACK option is present. > >> > > > > I would like to point out that this is over constrained. In > > particular "acknowledges some new data" explicitly include when > > snd.fack advances, or even when SACK reports any never retransmitted > > data, even though disallowed later. > > > > There are a number of algorithms (such as this one) that could be > > improved > > with: gs/snd.una/snd.fack/g > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > Privacy matters! We know from recent events that people are using our > > services to speak in defiance of unjust governments. We treat privacy > and > > security as matters of life and death, because for some users, they are= . > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From mattmathis@google.com Tue Apr 9 14:44: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 C825721F9990 for ; Tue, 9 Apr 2013 14:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.077 X-Spam-Level: X-Spam-Status: No, score=-101.077 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 KdBUtvpyWE7L for ; Tue, 9 Apr 2013 14:44:03 -0700 (PDT) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AB64D21F998B for ; Tue, 9 Apr 2013 14:44:03 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id k38so3051979iah.3 for ; Tue, 09 Apr 2013 14:44:03 -0700 (PDT) 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; bh=UOz518HQMo+chQRCS1RUrG3NHbl2wt5qtlv9QyfYwcA=; b=fsnWUGkIrWX7pZZF2Yg0csp6P3dfydoFcgLc4Kzzv92khUtP/oLrtSL61NzDhl9zRr SBoDft4PHW5G9Fl8dUYAFj4PSVPCYNsly7zpCf+Po+CZOtU0gdOt27JMmG4xmVLikwBX IOXvx3u2GQIR7JmSdacpo3K5+iFi4ttg+pMKFmSkHBnKJkx+UheM9PQlHIFVcassmJSx Xj9yMcSQd13yrho4rdvaS/Dj50Nhud4Z8j1hEq5iEUrk2ApHJ4pfYHcrknk/GUmOhuQc 7Ss6zEjVCavSQTI+5DalejUWHEDBHK6u3BOa51JY99MFR+JtaoRMOGFP1R7NjNr2cef9 ToOg== 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=UOz518HQMo+chQRCS1RUrG3NHbl2wt5qtlv9QyfYwcA=; b=WuWrBzotLNE2wOz1KqwEE8PQC/nlr4+Dhc2kzxqaTYWQXW3jMjA+NadazGjcpbu9re HY1YqanCMvJGD4kcF8GmFYQ2r++ZJdRh64BBDY/5lAVAxeGu5VoJcJogM7NmUVSfKt8a 9q7og8ofUQ4ZCdk2aTfwfoJSHpI9/7CgsSiDA4FytE4hmgYHhmDd7er75pwrUXjQqpP5 aKroyYjE9t9E3S4ZkMoQCttmvNbKdnNqeowiQ2YADNE8ZtKxO4whD1yfciFRg2tB72BU aefpzjf+1VZ0nPFmbqZK5awzZ/gzkkrqUUEoCXWdUIAbnhrgZ7H42E7JZSvOLvpeqVnK dDOg== MIME-Version: 1.0 X-Received: by 10.42.189.199 with SMTP id df7mr15625563icb.16.1365543843212; Tue, 09 Apr 2013 14:44:03 -0700 (PDT) Received: by 10.50.91.226 with HTTP; Tue, 9 Apr 2013 14:44:02 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AEF268@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <36FAA907-1D2F-4CDC-9C00-4F052B44A5C0@weston.borman.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF268@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 9 Apr 2013 14:44:02 -0700 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=485b397dd0dbb33ffe04d9f4730d X-Gm-Message-State: ALoCoQntaz87SyKCkohbGhW4dTKebwuDo92apFP96TTber9uinc7JISnPEaYboiOuRGKJTA0l8obu/pfgOPQvDtnAB7bqc9gMCCrOfoFMXbf0PdygyLFmnFO1H3fCLR2rK1FhTjp6WDtsckBstaV+WZ6ul/ZjFON50aSmksh6P9WFIV7HN8dHD06UIHdmLPcRufKKxFStFow Cc: David Borman , "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: Tue, 09 Apr 2013 21:44:04 -0000 --485b397dd0dbb33ffe04d9f4730d Content-Type: text/plain; charset=ISO-8859-1 Serves me for jumping in late, without fully grocking the thread. Actually if you change both ends s/*.una/*.fack/g would be a good thing. (E.g. have the receiver update TSrecent when it advances seg.fack) However, this does have a bit of a legacy deployment problem... Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Apr 9, 2013 at 11:25 AM, Scheffenegger, Richard wrote: > > Thank you David and Matt, > > Then the text should than actually be > > > RTTM Rule: A TSecr value received in a segment MAY be used to > update the averaged RTT measurement only if the segment > advances the left edge of the send window (e.g. SND.UNA is > increased). > > > As Matt pointed out, the old text would apply when SND.FACK advances (or > the number of bytes marked missing in the scoreboard decreases). > > But Dave asserts that we don't want to take a RTT Measurement then as this > would definitely inflate the RTT due to the semantics of TSrecent on the > receiver side. > > This must be one of the few cases where you don't want s/snd.una/snd.fack/g > > > Does that now make sense? > > > Richard Scheffenegger > > > > -----Original Message----- > > From: David Borman [mailto:dab@weston.borman.com] > > Sent: Dienstag, 09. April 2013 19:38 > > To: Matt Mathis; tcpm (tcpm@ietf.org) > > Cc: Scheffenegger, Richard > > Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for > > WGLC) > > > > Let's take a step back. The goal is that if you are using TSecr to > > compute the RTT, for use in the RTO, you want a reasonable assurance that > > it'll be somewhat accurate. That happens when TSecr is from a packet > that > > was recently received on the remote end. Delayed ACKs add to latency, so > > you want to account for that when calculating the RTT. But ACK packets > > can be generated for other reasons, and they can't be relied on for > > calculating a reasonable RTT, since not all ACKs are generated in direct > > response to an incoming packet. > > > > Hence, the rules in 1323 for which RTT to echo are intended to include > > delayed ACKs in the RTT measurement, and the rules for which TSecr can be > > used for RTO calculations are meant to exclude TSecr values that we know > > can cause wildly inflated RTT values. > > > > > > The "acknowledges some new data" bit is based on the fact that when the > > left edge of the window advances, it means that a packet arrived that > > filled in the hole, and the ACK is being generated in response to that > > packet. > > > > The change from 1323 to exclude RTT calculations if there is potential > > loss is, in my opinion, overly restrictive. The issue is that corner > > cases have been identified where due to loss you can get an inflated RTT > > measurement. But that's not necessarily a bad thing. For purposes of > > updating the RTO, one inflated RTT isn't going to throw things out of > > whack. > > And if you are hitting this multiple times, maybe that should be > > considered part of the latency and included in the RTO, just as 1323 > > already includes the latency of delayed ACKs in the RTT measurement. > > > > One advantage of TS is that it *can* get reasonable RTT measurements even > > when there is some packet loss. Excluding RTT measurements if there is > > packet loss losses that advantage. > > > > So, I see this as a grey area, not absolute. We want to include the > > situations that are most likely to generate a reasonable RTT measurement, > > and exclude the situations that are most likely to generate inflated RTT > > measurements. We don't need protection for every corner case that might > > cause an inflated RTT measurement, because the RTO should be somewhat > > resilient against that. > > > > -David Borman > > > > On Apr 9, 2013, at 11:38 AM, Matt Mathis wrote: > > > > > On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard > > wrote: > > > > > >> RTTM Rule: A TSecr value received in a segment MAY be 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, and does not indicate any potential > loss, > > >> i.e. no TCP SACK option is present. > > >> > > > > > > I would like to point out that this is over constrained. In > > > particular "acknowledges some new data" explicitly include when > > > snd.fack advances, or even when SACK reports any never retransmitted > > > data, even though disallowed later. > > > > > > There are a number of algorithms (such as this one) that could be > > > improved > > > with: gs/snd.una/snd.fack/g > > > > > > Thanks, > > > --MM-- > > > The best way to predict the future is to create it. - Alan Kay > > > > > > Privacy matters! We know from recent events that people are using our > > > services to speak in defiance of unjust governments. We treat privacy > > and > > > security as matters of life and death, because for some users, they > are. > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > --485b397dd0dbb33ffe04d9f4730d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Serves me for jumping in late, without fully grocking the = thread.

Actually if you change both ends=A0s/*.una= /*.fack/g would be a good thing. =A0 (E.g. have the receiver update TSrecen= t when it advances seg.fack) However, this does have a bit of a legacy depl= oyment problem...

Thanks,
--MM--
The best way to predict the future is to create i= t. =A0- Alan Kay

Privacy matters! =A0We know from recent events that= people are using our services to speak in defiance of unjust governments. = =A0 We treat privacy and security as matters of life and death, because for= some users, they are.


On Tue, Apr 9, 2013 at 11:25 AM, Scheffe= negger, Richard <rs@netapp.com> wrote:

Thank you David and Matt,

Then the text should than actually be


=A0 RTTM Rule: A TSecr value received in a segment MAY be used to
=A0 update the averaged RTT measurement only if the segment
=A0 advances the left edge of the send window (e.g. SND.UNA is
=A0 increased).


As Matt pointed out, the old text would apply when SND.FACK advances (or th= e number of bytes marked missing in the scoreboard decreases).

But Dave asserts that we don't want to take a RTT Measurement then as t= his would definitely inflate the RTT due to the semantics of TSrecent on th= e receiver side.

This must be one of the few cases where you don't want s/snd.una/snd.fa= ck/g


Does that now make sense?


Richard Scheffenegger


> -----Original Message-----
> From: David Borman [mailto:da= b@weston.borman.com]
> Sent: Dienstag, 09. April 2013 19:38
> To: Matt Mathis; tcpm (tcpm@ietf.org<= /a>)
> Cc: Scheffenegger, Richard
> Subject: Re: [tcpm] timestamps usage (was Re: 1323bis - preparing for<= br> > WGLC)
>
> Let's take a step ba= ck. =A0The goal is that if you are using TSecr to
> compute the RTT, for use in the RTO, you want a reasonable assurance t= hat
> it'll be somewhat accurate. =A0That happens when TSecr is from a p= acket that
> was recently received on the remote end. =A0Delayed ACKs add to latenc= y, so
> you want to account for that when calculating the RTT. =A0But ACK pack= ets
> can be generated for other reasons, and they can't be relied on fo= r
> calculating a reasonable RTT, since not all ACKs are generated in dire= ct
> response to an incoming packet.
>
> Hence, the rules in 1323 for which RTT to echo are intended to include=
> delayed ACKs in the RTT measurement, and the rules for which TSecr can= be
> used for RTO calculations are meant to exclude TSecr values that we kn= ow
> can cause wildly inflated RTT values.
>
>
> The "acknowledges some new data" bit is based on the fact th= at when the
> left edge of the window advances, it means that a packet arrived that<= br> > filled in the hole, and the ACK is being generated in response to that=
> packet.
>
> The change from 1323 to exclude RTT calculations if there is potential=
> loss is, in my opinion, overly restrictive. =A0The issue is that corne= r
> cases have been identified where due to loss you can get an inflated R= TT
> measurement. =A0But that's not necessarily a bad thing. =A0For pur= poses of
> updating the RTO, one inflated RTT isn't going to throw things out= of
> whack.
> And if you are hitting this multiple times, maybe that should be
> considered part of the latency and included in the RTO, just as 1323 > already includes the latency of delayed ACKs in the RTT measurement. >
> One advantage of TS is that it *can* get reasonable RTT measurements e= ven
> when there is some packet loss. =A0Excluding RTT measurements if there= is
> packet loss losses that advantage.
>
> So, I see this as a grey area, not absolute. =A0We want to include the=
> situations that are most likely to generate a reasonable RTT measureme= nt,
> and exclude the situations that are most likely to generate inflated R= TT
> measurements. =A0We don't need protection for every corner case th= at might
> cause an inflated RTT measurement, because the RTO should be somewhat<= br> > resilient against that.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -David Borman
>
> On Apr 9, 2013, at 11:38 AM, Matt Mathis <mattmathis@google.com> wrote:
>
> > On Tue, Apr 9, 2013 at 8:46 AM, Scheffenegger, Richard
> <rs@netapp.com>wrote:
> >
> >> RTTM Rule: A TSecr value received in a segment MAY be used to=
> >> =A0 =A0 =A0update the averaged RTT measurement only if the se= gment
> >> =A0 =A0 =A0acknowledges some new data, i.e. only if it advanc= es the left
> >> =A0 =A0 =A0edge of the send window, and does not indicate any= potential loss,
> >> =A0 =A0 =A0i.e. no TCP SACK option is present.
> >>
> >
> > I would like to point out that this is over constrained. =A0In > > particular "acknowledges some new data" explicitly incl= ude when
> > snd.fack advances, or even when SACK reports any never retransmit= ted
> > data, even though disallowed later.
> >
> > There are a number of algorithms (such as this one) that could be=
> > improved
> > with: gs/snd.una/snd.fack/g
> >
> > Thanks,
> > --MM--
> > The best way to predict the future is to create it. =A0- Alan Kay=
> >
> > Privacy matters! =A0We know from recent events that people are us= ing our
> > services to speak in defiance of unjust governments. =A0 We treat= privacy
> and
> > security as matters of life and death, because for some users, th= ey are.
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm


--485b397dd0dbb33ffe04d9f4730d-- From rs@netapp.com Tue Apr 9 15:09: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 37B6521F9917 for ; Tue, 9 Apr 2013 15:09:55 -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, 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 ASFbji2QQWBS for ; Tue, 9 Apr 2013 15:09:54 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C43E021F9908 for ; Tue, 9 Apr 2013 15:09:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,441,1363158000"; d="scan'208";a="38909288" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 09 Apr 2013 15:09:54 -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 r39M9s4m008451; Tue, 9 Apr 2013 15:09:54 -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; Tue, 9 Apr 2013 15:09:53 -0700 From: "Scheffenegger, Richard" To: Matt Mathis Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g///U9YD/+Lz/oIAPEpEAgAAQywCAAGnLIP//2tQAgABvPEA= Date: Tue, 9 Apr 2013 22:09:53 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AEF4F1@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <36FAA907-1D2F-4CDC-9C00-4F052B44A5C0@weston.borman.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF268@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Borman , "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: Tue, 09 Apr 2013 22:09:55 -0000 Hi Matt, > From: Matt Mathis [mailto:mattmathis@google.com]=20 > Sent: Dienstag, 09. April 2013 23:44 > > Serves me for jumping in late, without fully grocking the thread. > > Actually if you change both ends s/*.una/*.fack/g would be a=20 > good thing. (E.g. have the receiver update TSrecent when it=20 > advances seg.fack) However, this does have a bit of a legacy=20 > deployment problem... well, that change in the TS semantics to make that change was one of the de= tails in my draft that got me to this 1323bissness, I think... http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-0= 5 (but that draft is too convoluted, working with Brian and Mirja on a better= set of documents). Thanks! Richard Scheffenegger From ycheng@google.com Tue Apr 9 16:33: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 5DB3821F9855 for ; Tue, 9 Apr 2013 16:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 aV0mbks49-md for ; Tue, 9 Apr 2013 16:33:27 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0C721F9854 for ; Tue, 9 Apr 2013 16:33:26 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id o10so7324792lbi.20 for ; Tue, 09 Apr 2013 16:33:26 -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=Da0qMzINBX4srViB3MGf2UsUEH82cCeNwrRbLOnayAw=; b=gt+bvFb9/w6Wenu60HxqsioABKGMH3IFWv3yQ+gW0hguhwP4qzllc3C7D0d5dds8t9 ZY7FfbV4Qcwh74zW7SeYjdT6m41r5wdI1MWbqwcrc4RYZaqp3TxiMdkw/c0XmIEs4Yg7 9SqODlHsd1vS7/OIRLIrkjYeVkAuCC3j4QFj8bHNLcBtbYacmWr6CCydwhqtPw8xAydI rkTUPL248XPOqkS3qS62b1PjG7J/KbMN/f65XLT4xldo0mU2FWP9l3hUGt72OQNx8ILW ra71vzxuriiOM95Ktxo0u5gAVNjX53FS+rppxEyb7UBgwTJe8/vHCDpWDhTBfVoP8HAq P+vQ== 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=Da0qMzINBX4srViB3MGf2UsUEH82cCeNwrRbLOnayAw=; b=gsEWIjeHrRkji5VsZQma7QDouhTirG0CtVv4Ynkin4C4S0XZR05G+czPDSv/ZnUER+ PnQX0Djh5iMgbu2yfp5bIPRw7284dLC1dZS/oNe+RqXxWX3hrTMejsvfOHHUgi4fXwZZ Sln9krQtsyOhN8cP4fSf2YCd/PPbmXl7BZFf5sTJYaFJ6mNRxXd6/WcG9g3AjVFGoVPE RYu5KcHGB9LHfTwGDlX4m+WRJTVGuSCkjF6Db6KAXOXgLVZXR6P+obfSoxnlLN25RfM0 BOXPKma39zyZk1obBKtTl8kGLbH2LHczYWapizldB67a40jeqPNLk0rjBld3733LDyaq VRlA== X-Received: by 10.112.164.65 with SMTP id yo1mr32370lbb.107.1365550406039; Tue, 09 Apr 2013 16:33:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.137.196 with HTTP; Tue, 9 Apr 2013 16:33:05 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Tue, 9 Apr 2013 16:33:05 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=001a11c3484ce00d9804d9f5fa69 X-Gm-Message-State: ALoCoQmZFcAEi7eKp7AHrAX8i1rq97jdd5nMy5+Qpy2c7h697p+FkRe8QJSIj2CNtFFTwSa05HJBw14PEJj087mA6bCjMW174mSs/MZhl4mNVPaGE7LGOHt5FvALT5rDzeSWs2O4fN1KmrpBogC2O9d8tp9Z3AI8dkJ551MjQN7URrzIb54/4VvfSPjNDwCA9yjZTzo/doNJ 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: Tue, 09 Apr 2013 23:33:28 -0000 --001a11c3484ce00d9804d9f5fa69 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 9, 2013 at 11:14 AM, Scheffenegger, Richard wrote: > > Hi Yuchung, > > > It's a rewording of bis-08 but logically it's the same. > > Guilty as charged. But formatted differently to look less imposing. > > >> I repeat, this is a minor corner case, doing little harm > >> if not fixed (inflating RTO and delaying loss recovery > >> by timeout slightly). However, I stongly feel that this > >> is the correct way to treat RTT updates on the sender > >> side, and if not added in this iteration, it probably > >> won't be added ever... > > > > I repeat this will nullify much benefits TS-RTTM provides > > over regular RTTM. The advantage of TS-RTTM is to sample > > RTT on ACKs of retransmitted sequences. It's common for > > these ACKs to both advance SND.UNA and still contain, > > sometimes new, SACK blocks. > > Ah, there might be a misconception. This change concerns what the sender > is doing with received TSecr. > > The receiver, however, is already - according to both 1323 and 1323bis - > keeping an "outdated" TSrecent, and reflecting that as TSecr, for the > *entire* duration of a loss/reordering event. > > You simply won't get a proper RTTM sampling using the current TS semantics > during such an episode. I'm merely proposing to limit the impact to the > sender these semantics can already have, under a specific set of > circumstances. > > Please have another look at the graph I posted earlier, > http://www.ietf.org/mail-archive/web/tcpm/current/msg07810.html > and you'll note that TS RTT *will not* deliver any benefits over what > linux is already doing... Actually, the linux stack matching the SACK > updates to the sent segments will most likely sample *accurate* network RTT > even during loss/reordering using the per-segment state. (I've not looked > into that stack deep enough to say this is so, but it's definitely possible > using all the state kept). > > "Proper" TS RTTM would require that last ACK to have a TSecr=5, not > TSecr=2. > > In that case stated (loss of the last in-sequence ACK), 1323 will bloat > RTT/RTO. > I understand the problem of potential RTT overestimation (before you came up that case) so are the original authors of RFC1323 even it was published before SACK. The "flawed" algorithm has ran years w/ SACK widely deployed w/o obvious problems reported. Now we want to change that b/c some (one?) has strong feels. It's not like major stacks have all fixed the flaw so RFC is outdated/wrong. There are no data no experiments for a non-trivial change. I simply don't buy the approach. > > Best regards, > > Richard Scheffenegger > > --001a11c3484ce00d9804d9f5fa69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 9, 2013 at 11:14 AM, Scheffenegger, Richard <rs@n= etapp.com> wrote:

Hi Yuchung,

> It's a rewording of bis-08 but logically it's the same.

Guilty as charged. But formatted differently to look less imposing.

>> I repeat, this is a minor corner case, doing little harm
>> if not fixed (inflating RTO and delaying loss recovery
>> by timeout slightly). However, I stongly feel that this
>> is the correct way to treat RTT updates on the sender
>> side, and if not added in this iteration, it probably
>> won't be added ever...
>
> I repeat this will nullify much benefits TS-RTTM provides
> over regular RTTM. The advantage of TS-RTTM is to sample
> RTT on ACKs of retransmitted sequences. It's common for
> these ACKs to both advance SND.UNA and still contain,
> sometimes new, SACK blocks.

Ah, there might be a misconception. This change concerns what the sen= der is doing with received TSecr.

The receiver, however, is already - according to both 1323 and 1323bis - ke= eping an "outdated" TSrecent, and reflecting that as TSecr, for t= he *entire* duration of a loss/reordering event.

You simply won't get a proper RTTM sampling using the current TS semant= ics during such an episode. I'm merely proposing to limit the impact to= the sender these semantics can already have, under a specific set of circu= mstances.

Please have another look at the graph I posted earlier,
http://www.ietf.org/mail-archive/web/tcpm/current/msg078= 10.html
and you'll note that TS RTT *will not* deliver any benefits over what l= inux is already doing... Actually, the linux stack matching the SACK update= s to the sent segments will most likely sample *accurate* network RTT even = during loss/reordering using the per-segment state. (I've not looked in= to that stack deep enough to say this is so, but it's definitely possib= le using all the state kept).

"Proper" TS RTTM would require that last ACK to have a TSecr=3D5,= not TSecr=3D2.

In that case stated (loss of the last in-sequence ACK), 1323 will bloat RTT= /RTO.
I understand the problem of potential RTT o= verestimation (before you came up that case) so are the original authors of= RFC1323 even it was published before SACK.

The "flawed" algorithm has ran years w/ SACK = widely deployed w/o obvious problems reported. Now we want to change that b= /c some (one?) has strong feels. It's not like major stacks have all fi= xed the flaw so RFC is outdated/wrong. There are no data no experiments for= a non-trivial change.=A0

I simply don't buy the approach.

Best regards,

Richard Scheffenegger


--001a11c3484ce00d9804d9f5fa69-- From ycheng@google.com Tue Apr 9 21:06: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 780C921F8FD6 for ; Tue, 9 Apr 2013 21:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.826 X-Spam-Level: X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, 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 gW2ZwepNcOb5 for ; Tue, 9 Apr 2013 21:06:29 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 3138921F8F9E for ; Tue, 9 Apr 2013 21:06:28 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id t11so102263lbi.39 for ; Tue, 09 Apr 2013 21:06:19 -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=okvHAfrx9Wo9eCG7uENfPippFOZNvjDqRr8kK+Mt82s=; b=AEZzdNBvM4YNjK8jCG9dp7O0RKtUh97GYrFO0LR7m8KTsZkJvBiAbGLLnbj5srl/C0 zW4Kn5TDouKTM/0qRPW1KbyHvY+Cpls528eMUbzks2SMef7sUkMBaW4NRGSmvLc/x20D y7r+nST0S8NIEHwI6MiVzXCu/W+J3oIrOB7199sp6Vkj6Lo5Dz/48sqjCM12BxhDp6jl VhfV5I4+WsUFXmIne74neQ1k6R+1L1BVYTlSTAJtdFWokfpVJ+dzHfEkLunLNXomcg+g BNx9xwRp3I/fYVSQHOsNuaIYAwzWXiNzlF2S74HAoWQnmBR/GlZQvlw6PeArKvKDmwhx sMFQ== 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=okvHAfrx9Wo9eCG7uENfPippFOZNvjDqRr8kK+Mt82s=; b=QMTue/cnRnCaWUo1gAoIbgXA2wee38WwOLopq+u7jGeG99JfW4t+dZN6cjkks0kcIE VgimMOddPP+x/1/5RY4/DrqMlsNTeIaofCsyx5T9fZM6DpvI0vBMO1dNQMMgu3M8h6w6 LhHQ7KB2Flf0GYZaou/jsB/amuVNrv8smXDQoPbqMvp8UPF3Nwu71ZMMcdWa36iRC9I5 Ft3H3tyJg3qWuYxb/9qTjVSlX3RDZwG9vJHs+FtXmWMGVgAwQgb+QFgIRp8fBlOejkmJ 5M4OCxIGEznxCTNMJ2mrKmyx78znz2i+W+U5KHox2tr9ogR9EUnvTWVfTcB5rGD86MSm qnMw== X-Received: by 10.112.139.226 with SMTP id rb2mr392390lbb.12.1365566778763; Tue, 09 Apr 2013 21:06:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.137.196 with HTTP; Tue, 9 Apr 2013 21:05:58 -0700 (PDT) In-Reply-To: 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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Tue, 9 Apr 2013 21:05:58 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=001a11c329e8c4014404d9f9caed X-Gm-Message-State: ALoCoQll5jl6MIqNoHy3GJnwZrowm7DfOFw1Aa5GmKRu2yVuIalVHrQsnGcnbyuOFyXBR4rfDABIF3uOpiroplgxQ6GR4nRAjc4VNVLYWbBn3g9otsQ0HqrC+T/e+s4OfDxWMrWyHQr5KUpnsuu9+tIggGHg0WxxS/+T3ybpultnbgA040yxnne8ZwH5sRGa6OvRkGYROoMF 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: Wed, 10 Apr 2013 04:06:30 -0000 --001a11c329e8c4014404d9f9caed Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 9, 2013 at 4:33 PM, Yuchung Cheng wrote: > On Tue, Apr 9, 2013 at 11:14 AM, Scheffenegger, Richard wrote: > >> >> Hi Yuchung, >> >> > It's a rewording of bis-08 but logically it's the same. >> >> Guilty as charged. But formatted differently to look less imposing. >> >> >> I repeat, this is a minor corner case, doing little harm >> >> if not fixed (inflating RTO and delaying loss recovery >> >> by timeout slightly). However, I stongly feel that this >> >> is the correct way to treat RTT updates on the sender >> >> side, and if not added in this iteration, it probably >> >> won't be added ever... >> > >> > I repeat this will nullify much benefits TS-RTTM provides >> > over regular RTTM. The advantage of TS-RTTM is to sample >> > RTT on ACKs of retransmitted sequences. It's common for >> > these ACKs to both advance SND.UNA and still contain, >> > sometimes new, SACK blocks. >> >> Ah, there might be a misconception. This change concerns what the sender >> is doing with received TSecr. >> >> The receiver, however, is already - according to both 1323 and 1323bis - >> keeping an "outdated" TSrecent, and reflecting that as TSecr, for the >> *entire* duration of a loss/reordering event. >> >> You simply won't get a proper RTTM sampling using the current TS >> semantics during such an episode. I'm merely proposing to limit the impact >> to the sender these semantics can already have, under a specific set of >> circumstances. >> > >> Please have another look at the graph I posted earlier, >> http://www.ietf.org/mail-archive/web/tcpm/current/msg07810.html >> and you'll note that TS RTT *will not* deliver any benefits over what >> linux is already doing... Actually, the linux stack matching the SACK >> updates to the sent segments will most likely sample *accurate* network RTT >> even during loss/reordering using the per-segment state. (I've not looked >> into that stack deep enough to say this is so, but it's definitely possible >> using all the state kept). >> >> "Proper" TS RTTM would require that last ACK to have a TSecr=5, not >> TSecr=2. >> >> In that case stated (loss of the last in-sequence ACK), 1323 will bloat >> RTT/RTO. >> > I understand the problem of potential RTT overestimation (before you came > up that case) so are the original authors of RFC1323 even it was published > before SACK. > > The "flawed" algorithm has ran years w/ SACK widely deployed w/o obvious > problems reported. Now we want to change that b/c some (one?) has strong > feels. It's not like major stacks have all fixed the flaw so RFC is > outdated/wrong. There are no data no experiments for a non-trivial change. > > I simply don't buy the approach. > To compare with the ack-lost example that Richard provided, let's consider a typical fast recovery. Send 10 packets and the first 7 packets are dropped Got three DUPACKs of SACK 8,8-9,8-10 Fast retransmit 1 plus maybe a few more depending on the algorithm you use. On receiving retransmit of packet 1 (R1), the receiver returns an ACK of 2 with SACK {8-10} and ECR = ts.recent = R1's TS-val. (Similar acks for other fast retransmits.) The latest bis-08 forbids taking TS-RTT samples of these ACKs. Why bother to have TS-RTTM then? >> Best regards, >> >> Richard Scheffenegger >> >> > --001a11c329e8c4014404d9f9caed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 9, 2013 at 4:33 PM, Yuchung Cheng <= ;ycheng@google.com> wrote:

Hi Yuchung,

> It's a rewording of bis-08 but logically it's the same.

Guilty as charged. But formatted differently to look less imposing.

>> I repeat, this is a minor corner case, doing little harm
>> if not fixed (inflating RTO and delaying loss recovery
>> by timeout slightly). However, I stongly feel that this
>> is the correct way to treat RTT updates on the sender
>> side, and if not added in this iteration, it probably
>> won't be added ever...
>
> I repeat this will nullify much benefits TS-RTTM provides
> over regular RTTM. The advantage of TS-RTTM is to sample
> RTT on ACKs of retransmitted sequences. It's common for
> these ACKs to both advance SND.UNA and still contain,
> sometimes new, SACK blocks.

Ah, there might be a misconception. This change concerns what the sen= der is doing with received TSecr.

The receiver, however, is already - according to both 1323 and 1323bis - ke= eping an "outdated" TSrecent, and reflecting that as TSecr, for t= he *entire* duration of a loss/reordering event.

You simply won't get a proper RTTM sampling using the current TS semant= ics during such an episode. I'm merely proposing to limit the impact to= the sender these semantics can already have, under a specific set of circu= mstances.

Please have another look at the graph I posted earlier,
http://www.ietf.org/mail-archive/web/tcpm/current/msg078= 10.html
and you'll note that TS RTT *will not* deliver any benefits over what l= inux is already doing... Actually, the linux stack matching the SACK update= s to the sent segments will most likely sample *accurate* network RTT even = during loss/reordering using the per-segment state. (I've not looked in= to that stack deep enough to say this is so, but it's definitely possib= le using all the state kept).

"Proper" TS RTTM would require that last ACK to have a TSecr=3D5,= not TSecr=3D2.

In that case stated (loss of the last in-sequence ACK), 1323 will bloat RTT= /RTO.
I understand the problem of pot= ential RTT overestimation (before you came up that case) so are the origina= l authors of RFC1323 even it was published before SACK.

The "flawed" algorithm has ran years w/ SACK = widely deployed w/o obvious problems reported. Now we want to change that b= /c some (one?) has strong feels. It's not like major stacks have all fi= xed the flaw so RFC is outdated/wrong. There are no data no experiments for= a non-trivial change.=A0

I simply don't buy the approach.
<= /div>
To compare with the ack-lost example tha= t Richard provided, let's consider a typical fast recovery.

Send 10 packets and the first 7 packets are dropped
Got three DUPACKs of SACK 8,8-9,8-10
Fast ret= ransmit 1 plus maybe a few more depending on the algorithm you use.
On receiving retransmit of packet 1 (R1), the receiver returns a= n ACK of 2 with SACK {8-10} and ECR =3D ts.recent =3D R1's TS-val.
(Similar acks for other fast retransmits.)

The latest bis-08 forbids taking TS-RTT samples of these A= CKs. Why bother to have TS-RTTM then?


Best regards,

Richard Scheffenegger



--001a11c329e8c4014404d9f9caed-- From rs@netapp.com Wed Apr 10 00:37: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 B704221F85A2 for ; Wed, 10 Apr 2013 00:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.774 X-Spam-Level: X-Spam-Status: No, score=-9.774 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_26=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 tqXYZYYLARpg for ; Wed, 10 Apr 2013 00:37:00 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3EC21F85A1 for ; Wed, 10 Apr 2013 00:37:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,444,1363158000"; d="scan'208";a="39037136" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 10 Apr 2013 00:37:00 -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 r3A7axcK007029; Wed, 10 Apr 2013 00:36:59 -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, 10 Apr 2013 00:36:59 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g///U9YD/+Lz/oIAPEj+AgABdEXCAABcjgIAATD4AgAA9DuA= Date: Wed, 10 Apr 2013 07:36:59 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AEF83E@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@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="us-ascii" 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: Wed, 10 Apr 2013 07:37:00 -0000 Hi Yuchung, > To compare with the ack-lost example that Richard provided, let's > consider a typical fast recovery. > > Send 10 packets and the first 7 packets are dropped > > Got three DUPACKs of SACK 8,8-9,8-10 > > Fast retransmit 1 plus maybe a few more depending on the algorithm you=20 > use. >=20 > On receiving retransmit of packet 1 (R1), the receiver returns an ACK > of 2 with SACK {8-10} and ECR =3D ts.recent =3D R1's TS-val. > (Similar acks for other fast retransmits.) >=20 > The latest bis-08 forbids taking TS-RTT samples of these ACKs. Why=20 > bother to have TS-RTTM then? I see your point; the -08 wording would break the TS RTT sampling when the = loss recovery properly closes the outstanding segments from the left. Check= ing that a new ACK only acknowledges one segment (including SACKed data) wh= en SACK is present would be less trivial... Do you (and everyone else) agree with the last iteration for the RTTM rule,= if so then I'd submit the latest text. RTTM Rule: A TSecr value received in a segment MAY be used to update the averaged RTT measurement only if the segment advances the left edge of the send window (e.g. SND.UNA is=20 increased). Best regards, Richard Scheffenegger From nishida@sfc.wide.ad.jp Wed Apr 10 00:39: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 4D19021F8976 for ; Wed, 10 Apr 2013 00:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.777 X-Spam-Level: X-Spam-Status: No, score=-100.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=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 b6zFc3mEx+5r for ; Wed, 10 Apr 2013 00:39:48 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 42F5321F8967 for ; Wed, 10 Apr 2013 00:39:47 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 617712780C2 for ; Wed, 10 Apr 2013 16:39:45 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id fo12so157020lab.10 for ; Wed, 10 Apr 2013 00:39:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.138.198 with SMTP id qs6mr631876lbb.68.1365579582625; Wed, 10 Apr 2013 00:39:42 -0700 (PDT) Received: by 10.114.172.43 with HTTP; Wed, 10 Apr 2013 00:39:42 -0700 (PDT) In-Reply-To: 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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@SACEXCMBX02-PRD.hq.netapp.com> Date: Wed, 10 Apr 2013 00:39:42 -0700 Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: multipart/alternative; boundary=089e01182588ef5fab04d9fcc51d 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: Wed, 10 Apr 2013 07:39:49 -0000 --089e01182588ef5fab04d9fcc51d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 9, 2013 at 9:05 PM, Yuchung Cheng wrote: > > > On Tue, Apr 9, 2013 at 4:33 PM, Yuchung Cheng wrote: > >> On Tue, Apr 9, 2013 at 11:14 AM, Scheffenegger, Richard wrote: >> >>> >>> Hi Yuchung, >>> >>> > It's a rewording of bis-08 but logically it's the same. >>> >>> Guilty as charged. But formatted differently to look less imposing. >>> >>> >> I repeat, this is a minor corner case, doing little harm >>> >> if not fixed (inflating RTO and delaying loss recovery >>> >> by timeout slightly). However, I stongly feel that this >>> >> is the correct way to treat RTT updates on the sender >>> >> side, and if not added in this iteration, it probably >>> >> won't be added ever... >>> > >>> > I repeat this will nullify much benefits TS-RTTM provides >>> > over regular RTTM. The advantage of TS-RTTM is to sample >>> > RTT on ACKs of retransmitted sequences. It's common for >>> > these ACKs to both advance SND.UNA and still contain, >>> > sometimes new, SACK blocks. >>> >>> Ah, there might be a misconception. This change concerns what the sender >>> is doing with received TSecr. >>> >>> The receiver, however, is already - according to both 1323 and 1323bis - >>> keeping an "outdated" TSrecent, and reflecting that as TSecr, for the >>> *entire* duration of a loss/reordering event. >>> >>> You simply won't get a proper RTTM sampling using the current TS >>> semantics during such an episode. I'm merely proposing to limit the impact >>> to the sender these semantics can already have, under a specific set of >>> circumstances. >>> >> >>> Please have another look at the graph I posted earlier, >>> http://www.ietf.org/mail-archive/web/tcpm/current/msg07810.html >>> and you'll note that TS RTT *will not* deliver any benefits over what >>> linux is already doing... Actually, the linux stack matching the SACK >>> updates to the sent segments will most likely sample *accurate* network RTT >>> even during loss/reordering using the per-segment state. (I've not looked >>> into that stack deep enough to say this is so, but it's definitely possible >>> using all the state kept). >>> >>> "Proper" TS RTTM would require that last ACK to have a TSecr=5, not >>> TSecr=2. >>> >>> In that case stated (loss of the last in-sequence ACK), 1323 will bloat >>> RTT/RTO. >>> >> I understand the problem of potential RTT overestimation (before you came >> up that case) so are the original authors of RFC1323 even it was published >> before SACK. >> >> The "flawed" algorithm has ran years w/ SACK widely deployed w/o obvious >> problems reported. Now we want to change that b/c some (one?) has strong >> feels. It's not like major stacks have all fixed the flaw so RFC is >> outdated/wrong. There are no data no experiments for a non-trivial change. >> >> I simply don't buy the approach. >> > To compare with the ack-lost example that Richard provided, let's consider > a typical fast recovery. > > Send 10 packets and the first 7 packets are dropped > Got three DUPACKs of SACK 8,8-9,8-10 > Fast retransmit 1 plus maybe a few more depending on the algorithm you use. > On receiving retransmit of packet 1 (R1), the receiver returns an ACK of 2 > with SACK {8-10} and ECR = ts.recent = R1's TS-val. > (Similar acks for other fast retransmits.) > With this logic, I think the sender will do RTTM without the effect of Delayed ACK. I'm not sure if this is good thing. -- Yoshifumi --089e01182588ef5fab04d9fcc51d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Apr 9, 2013 at 9:05 PM, Yuchung Cheng <ycheng@google.com> wrote:

=
On Tue, Apr 9, 2013 at 4:33 PM, Yuchung Cheng <yche= ng@google.com> wrote:
On Tue, Apr 9, 20= 13 at 11:14 AM, Scheffenegger, Richard <rs@netapp.com> wrote:

Hi Yuchung,

> It's a rewording of bis-08 but logically it's the same.

Guilty as charged. But formatted differently to look less imposing.

>> I repeat, this is a minor corner case, doing little harm
>> if not fixed (inflating RTO and delaying loss recovery
>> by timeout slightly). However, I stongly feel that this
>> is the correct way to treat RTT updates on the sender
>> side, and if not added in this iteration, it probably
>> won't be added ever...
>
> I repeat this will nullify much benefits TS-RTTM provides
> over regular RTTM. The advantage of TS-RTTM is to sample
> RTT on ACKs of retransmitted sequences. It's common for
> these ACKs to both advance SND.UNA and still contain,
> sometimes new, SACK blocks.

Ah, there might be a misconception. This change concerns what the sen= der is doing with received TSecr.

The receiver, however, is already - according to both 1323 and 1323bis - ke= eping an "outdated" TSrecent, and reflecting that as TSecr, for t= he *entire* duration of a loss/reordering event.

You simply won't get a proper RTTM sampling using the current TS semant= ics during such an episode. I'm merely proposing to limit the impact to= the sender these semantics can already have, under a specific set of circu= mstances.

Please have another look at the graph I posted earlier,
http://www.ietf.org/mail-archive/web/tcpm/current/msg078= 10.html
and you'll note that TS RTT *will not* deliver any benefits over what l= inux is already doing... Actually, the linux stack matching the SACK update= s to the sent segments will most likely sample *accurate* network RTT even = during loss/reordering using the per-segment state. (I've not looked in= to that stack deep enough to say this is so, but it's definitely possib= le using all the state kept).

"Proper" TS RTTM would require that last ACK to have a TSecr=3D5,= not TSecr=3D2.

In that case stated (loss of the last in-sequence ACK), 1323 will bloat RTT= /RTO.
I understand the problem of pot= ential RTT overestimation (before you came up that case) so are the origina= l authors of RFC1323 even it was published before SACK.

The "flawed" algorithm has ran years w/ SACK = widely deployed w/o obvious problems reported. Now we want to change that b= /c some (one?) has strong feels. It's not like major stacks have all fi= xed the flaw so RFC is outdated/wrong. There are no data no experiments for= a non-trivial change.=A0

I simply don't buy the approach.
<= /div>
To compare with the ack-lost examp= le that Richard provided, let's consider a typical fast recovery.

Send 10 packets and the first 7 packets are dropped
Got three DUPACKs of SACK 8,8-9,8-10
Fast retransmit 1 plus may= be a few more depending on the algorithm you use.
On receiving retransmit of packet 1 (R1), the receiver returns an ACK = of 2 with SACK {8-10} and ECR =3D ts.recent =3D R1's TS-val.
= (Similar acks for other fast retransmits.)

With this logic, I think the sender will do RTTM = without the effect of Delayed ACK.
I'm not sure if this= is good thing.
--
Yoshifumi

=A0
--089e01182588ef5fab04d9fcc51d-- From yding@cs.helsinki.fi Wed Apr 10 05:44: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 57FDB21F9614 for ; Wed, 10 Apr 2013 05:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 1STxyFeCx--V for ; Wed, 10 Apr 2013 05:44:20 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D0621F9610 for ; Wed, 10 Apr 2013 05:44:18 -0700 (PDT) Received: from [128.214.9.154] (wel-33.cs.helsinki.fi [128.214.9.154]) (AUTH: PLAIN yding, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 10 Apr 2013 15:44:16 +0300 id 00068A70.51655EA1.00003EFB Message-ID: <51655EA0.8030407@cs.helsinki.fi> Date: Wed, 10 Apr 2013 15:44:16 +0300 From: Aaron Yi DING Organization: Helsinki University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: tcpm@ietf.org References: <20130107183600.E376A59343C@lawyers.icir.org> In-Reply-To: <20130107183600.E376A59343C@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] bufferbloat paper 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, 10 Apr 2013 12:44:23 -0000 On 07/01/13 20:36, Mark Allman wrote: > [I tried to post this in a couple places to ensure I hit folks who would > be interested. If you end up with multiple copies of the email, my > apologies. --allman] > > I know bufferbloat has been an interest of lots of folks recently. So, > I thought I'd flog a recent paper that presents a little data on the > topic ... > > Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer > Communication Review, 43(1), January 2013. > http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf > > Its an initial paper. I think more data would be great! > > allman One related work: Ilpo Järvinen et al. "Effect of Competing TCP Traffic on Interactive Real-Time Communication", Passive and Active Measurement Conference (PAM 2013), March 2013. paper http://www.cs.helsinki.fi/group/wibra/pam13.pdf slides http://pam2013.comp.polyu.edu.hk/ma/slides/slides_10.pdf -- Aaron From ycheng@google.com Wed Apr 10 10:27: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 DD8FD21F8EB2 for ; Wed, 10 Apr 2013 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.777 X-Spam-Level: X-Spam-Status: No, score=-100.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=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 dWsm0WWwS0ui for ; Wed, 10 Apr 2013 10:27:07 -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 CCC4F21F8EB1 for ; Wed, 10 Apr 2013 10:27:06 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id er20so692552lab.14 for ; Wed, 10 Apr 2013 10:27: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; bh=pOAaActmKTKfZK/pl1pVjEhqTFZkt0+tmd9EDKOJadc=; b=mXt/XCCLVQ74KegGMQT3rLCAZbO84XUtEysyRt4SL9UrRuNxvHzU/2ZjX90FHExdLG 5hAX46pN/oQOmazLFAeNG3vTRJfzNFzXCpLucJNRSaaqNDcVpP/eAxoHa5qZ6kKhhtYT 371VeuXVIHwCKv807l1abcEnKpS9vH7yKTvbUw8Aomwt41ypkKnxDh86xi14mmYVYHDK BwjxIw+vfSont4hBhefYY9pePF2kLCJiwqyQPxvR0j4X7z7wqaCO+SZEnQtPVKM6LJz0 uT8IP38xO5B+wKhOpYiTyU0PYxd7WyLh2S3DSYyhEtj8QjT+ivVUkGE0XIkc5NRcsb3Y ILng== 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=pOAaActmKTKfZK/pl1pVjEhqTFZkt0+tmd9EDKOJadc=; b=NjOVuixhaU6NLSVR6LGtw26d7cQ++Cjt9btJVMCE9q4xy3h+LQVWGcWwfaJuTmipvM ZI+ZZSXgXfX4rtTC/q5XGWT68m/+upDeDP6bxLhRi+gJ/70ma3kE+6l/QLlLZ6v+HOSy +daMBUJlQZiTQl4SWbrvq4NIHljQn17+RgvFfYI0WAurkF7Zs3fF6TA7bgMCQ8Alc+JY ZcHPdiVHC6Gh4W8o+W8B7xqQtbXaVIvzc0eZHr18QvOmCVwr0r4afeFyio2pJPetLgWU 2JfeHZ82lkb5s5l8WrgpF0Dl0TeMc2MklnXBwb3ECHv9lXfQvt5ihy18t//L7JXr2J9J SfWg== X-Received: by 10.112.132.2 with SMTP id oq2mr1658977lbb.5.1365614825658; Wed, 10 Apr 2013 10:27:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.137.196 with HTTP; Wed, 10 Apr 2013 10:26:45 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AEF83E@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF83E@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Wed, 10 Apr 2013 10:26:45 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=047d7b3a823a9582e204da04fab5 X-Gm-Message-State: ALoCoQngx/2JzgY0heaHNnDrUjhPcM9DaSdOQ47swAZ5HeKcop10+f8rn9waGGR6pik2WLFxRg4DET2uQIkqT55661v2tmTVeYvGyKjhFigYGPEV30JMKLqHl3KZDAsQwvr2VWVnnw0gNwIyKJgNqXFXwa37XoN89JfYBu2jq8n1SPRekNqBM8sGddsbXCFjjfLu5y+vw1jk 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: Wed, 10 Apr 2013 17:27:08 -0000 --047d7b3a823a9582e204da04fab5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 10, 2013 at 12:36 AM, Scheffenegger, Richard wrote: > > Hi Yuchung, > > > To compare with the ack-lost example that Richard provided, let's > > consider a typical fast recovery. > > > > Send 10 packets and the first 7 packets are dropped > > > > Got three DUPACKs of SACK 8,8-9,8-10 > > > > Fast retransmit 1 plus maybe a few more depending on the algorithm you > > use. > > > > On receiving retransmit of packet 1 (R1), the receiver returns an ACK > > of 2 with SACK {8-10} and ECR = ts.recent = R1's TS-val. > > (Similar acks for other fast retransmits.) > > > > The latest bis-08 forbids taking TS-RTT samples of these ACKs. Why > > bother to have TS-RTTM then? > > I see your point; the -08 wording would break the TS RTT sampling when the > loss recovery properly closes the outstanding segments from the left. > Checking that a new ACK only acknowledges one segment (including SACKed > data) when SACK is present would be less trivial... > > Do you (and everyone else) agree with the last iteration for the RTTM > rule, if so then I'd submit the latest text. > > RTTM Rule: A TSecr value received in a segment MAY be used to > update the averaged RTT measurement only if the segment > advances the left edge of the send window (e.g. SND.UNA is > increased). > What's wrong with the original text? "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." If you must make a change (for reasons I am not sure), I suggest take up Matt's comments: " A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data including selective acknowledged ones. " > > Best regards, > > Richard Scheffenegger > > > > > > --047d7b3a823a9582e204da04fab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 10, 2013 at 12:36 AM, Scheffenegger, Richard <rs@netapp.c= om> wrote:

Hi Yuchung,

> To compare with the ack-lost example that Richard provided, let's<= br> > consider a typical fast recovery.
>
> Send 10 packets and the first 7 packets are dropped
>
> Got three DUPACKs of SACK 8,8-9,8-10
>
> Fast retransmit 1 plus maybe a few more depending on the algorithm you=
> use.
>
> On receiving retransmit of packet 1 (R1), the receiver returns an ACK<= br> > of 2 with SACK {8-10} and ECR =3D ts.recent =3D R1's TS-val.
> (Similar acks for other fast retransmits.)
>
> The latest bis-08 forbids taking TS-RTT samples of these ACKs. Why
> bother to have TS-RTTM then?

I see your point; the -08 wording would break the TS RTT sampling whe= n the loss recovery properly closes the outstanding segments from the left.= Checking that a new ACK only acknowledges one segment (including SACKed da= ta) when SACK is present would be less trivial...

Do you (and everyone else) agree with the last iteration for the RTTM rule,= if so then I'd submit the latest text.

=A0 RTTM Rule: A TSecr value received in a segment MAY be used to
=A0 update the averaged RTT measurement only if the segment
=A0 advances the left edge of the send window (e.g.= SND.UNA is
=A0 increased).
What's wrong with the = original text?

"A TSecr value received in a segment is= used to update the=A0
averaged R= TT measurement only if the segment acknowledges
some new data, i.e., only= if it advances the left edge of the
send windo= w."
If you must make a change (for reasons I am not sure), I suggest= take up Matt's comments:

"
A TSecr value recei= ved in a segment is used to update the=A0
averaged RTT mea= surement only if the segment acknowledges
some new data including selective ack= nowledged ones.
"
=A0

Best regards,

Richard Scheffenegger






--047d7b3a823a9582e204da04fab5-- From rs@netapp.com Wed Apr 10 10:53: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 6EFD421F8D46 for ; Wed, 10 Apr 2013 10:53:00 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_41=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 WPf10MPcuIb2 for ; Wed, 10 Apr 2013 10:52:59 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id D9A4E21F8D33 for ; Wed, 10 Apr 2013 10:52:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,449,1363158000"; d="scan'208";a="39199372" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 10 Apr 2013 10:52:59 -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 r3AHqxYN027052; Wed, 10 Apr 2013 10:52:59 -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, 10 Apr 2013 10:52:58 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g///U9YD/+Lz/oIAPEj+AgABdEXCAABcjgIAATD4AgAA9DuCAAKKugIAAcO2Q Date: Wed, 10 Apr 2013 17:52:58 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AF0DCF@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF83E@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.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "Matthew Mathis \(mattmathis@google.com\)" 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, 10 Apr 2013 17:53:00 -0000 Hi Yuchung, >> Do you (and everyone else) agree with the last iteration for the RTTM ru= le, if so then I'd submit the latest text. >> >> RTTM Rule: A TSecr value received in a segment MAY be used to >> update the averaged RTT measurement only if the segment >> advances the left edge of the send window (e.g. SND.UNA is >> increased). > > What's wrong with the original text? > > "A TSecr value received in a segment is used to update the=20 > averaged RTT measurement only if the segment acknowledges > some new data, i.e., only if it advances the left edge of the > send window." >=20 > If you must make a change (for reasons I am not sure), I suggest take up = Matt's comments: > > " > A TSecr value received in a segment is used to update the=20 > averaged RTT measurement only if the segment acknowledges > some new data including selective acknowledged ones. > " The way the receiver handles TSecr... Only when the left window advances, t= he receiver updates TS.recent. The wording the the original 1323 and Matt's suggested text would allow tha= t sample, which is then bloated: ---------------------> (advance left window edge, update= TS.recent=3D1) <---------------- -------------------X ---------------------> (don't advance left window edge, = don't update TS.recent) <------- ---------------------> (don't advance left window edge, = don't update TS.recent) <----- The two last ACKs both acknowledge some new data, but the left window edge = is not updated - on the receiver side. If these ACKs are used for RTTM, the= samples are inflated due to the receiver side handling when TS.recent is u= pdated... So, I think the proper wording should only point to an update of SND.UNA, n= ot "new data". Regards, Richard Scheffenegger From ycheng@google.com Wed Apr 10 16:39: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 BDF6621F8DB4 for ; Wed, 10 Apr 2013 16:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.477 X-Spam-Level: X-Spam-Status: No, score=-100.477 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_41=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 rqnVUF6kqNcC for ; Wed, 10 Apr 2013 16:39:45 -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 C813B21F8DBB for ; Wed, 10 Apr 2013 16:39:41 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id er20so976977lab.0 for ; Wed, 10 Apr 2013 16:39:40 -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=FRCI3f3vnJOXN8AeD/4962K1MdnibuloVIuAKyqo63Q=; b=BEVcDb/8STvt9VaIlSGmqY0qjfCHfI+MYWRQJ34zU7lzmyIlOiq0qeT+rpNaqMhBL7 VWCFyTq0U8+bzrnYcpUnIbSD6OZHVBP+sGtrf9ga67G4TFkH6rcc2z65us1uZOGTi/rk PkAWFUjX2gIncOOZKxHZCP03G432KGKaeRWOPG1N8NqP4PbCxjjHLP5A4UhLqASygh++ A0lezFcNvwGVVR0RurWGXmk7FCghNBxKS7iRruS5F5OHXmdgjSvqi2QSDnNGkx6im9bI 8oZ0R8FllsUT6umGGPxPV519goJU5YbmXPLpu3QuUuyK2ZcuPQP/vCYCmVCpu5+um0Lk kt4Q== 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=FRCI3f3vnJOXN8AeD/4962K1MdnibuloVIuAKyqo63Q=; b=Q3L3cRjr1K9ztXodoG/j1QrbpoQsjJaKeDUjB4IvHFWNo1z0uZv7C2ZUwLVxDTSh4G LgnV6RDSNCKSWelfA6dDfmpPHIlPupaKq69eknyACR6q1LDSH6ToVXtMNYAt4stLNVq1 hnPJAFsmOtrO/uzlVP580XNX+qUJV14ShGJYk9bvK7fAdREaFp+6ThcEUWKmYdKBD+RD fiq+povz+PV3Cf4h7JdHju9ofgB7AoTVP2cHpb58HVxvoa5XiOTTiHVTAwt++Ii0efwM r2uZnHnZYSnaNlp9u1oE/V+EuN1w/N2WfkDkpiTtcYu3XIrNKDgShA2y4LP2tqgUMqT/ A9BQ== X-Received: by 10.112.6.234 with SMTP id e10mr2204121lba.46.1365637180068; Wed, 10 Apr 2013 16:39:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.74.81 with HTTP; Wed, 10 Apr 2013 16:39:20 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AF0DCF@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF83E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AF0DCF@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Wed, 10 Apr 2013 16:39:20 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=14dae94732cb02af7804da0a2ffe X-Gm-Message-State: ALoCoQlVVixFqnERHbkjB/0DmaaXpdDWlmokKWNGO7S0yjciHmcK5GzuqpWUJj+JpIC/KTzdoLHDCxW2CiBl8tRmTorUkY/fOJmUJ6ZNgJ8+41krUaIqPd4pwPgn6Gd3FbwILJJrp1W1Oj1oDeltfpuj75fMwDv5joUbIQL5CSbGdYSHn4Zr3YiUrhoPKlK5vvoDoMnrKm4y Cc: "tcpm \(tcpm@ietf.org\)" , "Matthew Mathis \(mattmathis@google.com\)" 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, 10 Apr 2013 23:39:45 -0000 --14dae94732cb02af7804da0a2ffe Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 10, 2013 at 10:52 AM, Scheffenegger, Richard wrote: > Hi Yuchung, > > > >> Do you (and everyone else) agree with the last iteration for the RTTM > rule, if so then I'd submit the latest text. > >> > >> RTTM Rule: A TSecr value received in a segment MAY be used to > >> update the averaged RTT measurement only if the segment > >> advances the left edge of the send window (e.g. SND.UNA is > >> increased). > > > > What's wrong with the original text? > > > > "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." > > > > If you must make a change (for reasons I am not sure), I suggest take up > Matt's comments: > > > > " > > A TSecr value received in a segment is used to update the > > averaged RTT measurement only if the segment acknowledges > > some new data including selective acknowledged ones. > > " > > The way the receiver handles TSecr... Only when the left window advances, > the receiver updates TS.recent. > > The wording the the original 1323 and Matt's suggested text would allow > that sample, which is then bloated: > > > ---------------------> (advance left window edge, update > TS.recent=1) > > <---------------- > > -------------------X > > > > ---------------------> (don't advance left window edge, > don't update TS.recent) > > <------- > > ---------------------> (don't advance left window edge, > don't update TS.recent) > > <----- > > The two last ACKs both acknowledge some new data, but the left window edge > is not updated - on the receiver side. If these ACKs are used for RTTM, the > samples are inflated due to the receiver side handling when TS.recent is > updated... > > So, I think the proper wording should only point to an update of SND.UNA, > not "new data". > Good point. I prefer to keep original text to your new text but the latter is OK. I am not sure what's new in the new text tho. > > Regards, > > Richard Scheffenegger > > > --14dae94732cb02af7804da0a2ffe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 10, 2013 at 10:52 AM, Scheffenegger, Richard <rs@netapp.c= om> wrote:
Hi Yuchung,


>> Do you (and everyone else) agree with the last iteration for the R= TTM rule, if so then I'd submit the latest text.
>>
>> =A0RTTM Rule: A TSecr value received in a segment MAY be used to >> =A0update the averaged RTT measurement only if the segment
>> =A0advances the left edge of the send window (e.g. SND.UNA is
>> =A0increased).
>
> What's wrong with the original text?
>
> "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."
>
> If you must make a change (for reasons I am not sure), I suggest take = up Matt's comments:
>
> "
> =A0A TSecr value received in a segment is used to update the
> =A0averaged RTT measurement only if the segment acknowledges
> =A0some new data including selective acknowledged ones.
> "

The way the receiver handles TSecr... Only when the left window advan= ces, the receiver updates TS.recent.

The wording the the original 1323 and Matt's suggested text would allow= that sample, which is then bloated:


=A0 =A0 <A, TSval=3D1> ---------------------> (advance left window= edge, update TS.recent=3D1)

=A0 =A0<---------------- <ACK(A), TSecr=3D1>

=A0 =A0 <B, TSval=3D2> -------------------X



=A0 =A0 <C, TSval=3D3> ---------------------> (don't advance l= eft window edge, don't update TS.recent)

=A0 =A0<------- <ACK(A), SACK(C), TSecr=3D1>

=A0 =A0 <D, TSval=3D5> ---------------------> (don't advance l= eft window edge, don't update TS.recent)

=A0 =A0<----- <ACK(B), SACK(C,D), TSecr=3D1>

The two last ACKs both acknowledge some new data, but the left window edge = is not updated - on the receiver side. If these ACKs are used for RTTM, the= samples are inflated due to the receiver side handling when TS.recent is u= pdated...

So, I think the proper wording should only point to an update of SND.UNA, n= ot "new data".
Good point. I prefer to keep = original text to your new text but the latter is OK. I am not sure what'= ;s new in the new text tho.



Regards,

Richard Scheffenegger



--14dae94732cb02af7804da0a2ffe-- From rs@netapp.com Thu Apr 11 00:20: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 42EB921F8E9A for ; Thu, 11 Apr 2013 00:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_41=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 kKgUpm+m1ixK for ; Thu, 11 Apr 2013 00:20:45 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 526A721F8EA2 for ; Thu, 11 Apr 2013 00:20:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,454,1363158000"; d="scan'208";a="39392362" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 11 Apr 2013 00:20:36 -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 r3B7KaHA029299; Thu, 11 Apr 2013 00:20:36 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht04-prd.hq.netapp.com (10.106.77.34) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 11 Apr 2013 00:20:35 -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, 11 Apr 2013 00:20:35 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] timestamps usage (was Re: 1323bis - preparing for WGLC) Thread-Index: AQHOKv414Jse4n2cVkSldOUqGLB9C5i6Le6A//+WYxCAAIZZAIAAoyjQgAKeIwCAADNC4IAFDBiA//+bhH6AAiWRAP//rMUwADvCFwAACeYwkAAStp/g///U9YD/+Lz/oIAPEj+AgABdEXCAABcjgIAATD4AgAA9DuCAAKKugIAAcO2Q///3LAD///aCcA== Date: Thu, 11 Apr 2013 07:20:34 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AF17F5@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> <012C3117EDDB3C4781FD802A8C27DD4F24ADB923@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE28DA@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4794@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE484E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEEF73@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF221@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AEF83E@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F24AF0DCF@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.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "Matthew Mathis \(mattmathis@google.com\)" 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, 11 Apr 2013 07:20:46 -0000 Hi Yuchung, > Good point. I prefer to keep original text to your new text but the latte= r is OK. I am not sure what's new in the new text tho. Matt made me aware of a potential misinterpretation. The original text had "only if the segment acknowledges some new data", whi= ch could be interpreted - in conjunction with SACK (FACK) - that ACKs with = new SACK blocks would qualify. My suggestion has "only if the segment advances the left edge of the send w= indow" explicitly, not only as an example, thus ruling out ACKs with new SA= CK blocks. And we have the MAY, to indicate that not every possible RTT sample must be= used to update sRTT / RTTvar, as Marks research clearly indicated the limi= ted benefit of per-packet RTT samples. Best regards, Richard On Wed, Apr 10, 2013 at 10:52 AM, Scheffenegger, Richard wr= ote: Hi Yuchung, >> Do you (and everyone else) agree with the last iteration for the RTTM ru= le, if so then I'd submit the latest text. >> >> =A0RTTM Rule: A TSecr value received in a segment MAY be used to >> =A0update the averaged RTT measurement only if the segment >> =A0advances the left edge of the send window (e.g. SND.UNA is >> =A0increased). > > What's wrong with the original text? > > "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." > > If you must make a change (for reasons I am not sure), I suggest take up = Matt's comments: > > " > =A0A TSecr value received in a segment is used to update the > =A0averaged RTT measurement only if the segment acknowledges > =A0some new data including selective acknowledged ones. > " The way the receiver handles TSecr... Only when the left window advances, t= he receiver updates TS.recent. The wording the the original 1323 and Matt's suggested text would allow tha= t sample, which is then bloated: =A0 =A0 ---------------------> (advance left window edge, up= date TS.recent=3D1) =A0 =A0<---------------- =A0 =A0 -------------------X =A0 =A0 ---------------------> (don't advance left window ed= ge, don't update TS.recent) =A0 =A0<------- =A0 =A0 ---------------------> (don't advance left window ed= ge, don't update TS.recent) =A0 =A0<----- The two last ACKs both acknowledge some new data, but the left window edge = is not updated - on the receiver side. If these ACKs are used for RTTM, the= samples are inflated due to the receiver side handling when TS.recent is u= pdated... So, I think the proper wording should only point to an update of SND.UNA, n= ot "new data". Regards, Richard Scheffenegger From internet-drafts@ietf.org Fri Apr 12 00:51: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 8A84721F8C77; Fri, 12 Apr 2013 00:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, 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 BDQhXPRK9kjh; Fri, 12 Apr 2013 00:51:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C0421F8C4F; Fri, 12 Apr 2013 00:51: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.43.p4 Message-ID: <20130412075133.23915.72156.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 00:51:33 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-09.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, 12 Apr 2013 07:51:39 -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-09.txt Pages : 44 Date : 2013-04-12 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Fri Apr 12 17:55: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 57E4B21F8E9E for ; Fri, 12 Apr 2013 17:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 CrZ2qVjw7WFG for ; Fri, 12 Apr 2013 17:55:37 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E53BA21F8E9A for ; Fri, 12 Apr 2013 17:55:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,466,1363158000"; d="scan'208";a="40067657" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 12 Apr 2013 17:55:37 -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 r3D0tbXA002544; Fri, 12 Apr 2013 17:55:37 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.247]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 17:55:37 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: Manual DIFF 1323bis-09 vs. RFC1323 Thread-Index: Ac434Xhy+rVPFrhHTSaWoNuHromDdw== Date: Sat, 13 Apr 2013 00:55:36 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B1C1D0@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 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] Manual DIFF 1323bis-09 vs. RFC1323 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, 13 Apr 2013 00:55:38 -0000 Hi, In preparation for the upcoming WGLC of this document, I provide a color co= ded DIFF for easier verification of the critical sections to review. It can also be viewed here: https://docs.google.com/file/d/0B7EMOyVNNe1_QVZnd1F0S2NQQnc/edit?usp=3Dshar= ing As all the tools I'm aware of have their difficulties processing heavily re= formatted text, I prepared the formatted doc manually (so not all typos, br= acket changes etc are marked). Yellow sections weren't compared (primarily Appendix D, and some of the dyn= amic stuff (TOC, Refereces).=20 Green is the new text (-09), including 3 additional typos I found during th= e preparation in -09 (so there will be another iteration for WGLC). Red is text from RFC1323, removed from the 1323bis-09 version. Can a native speaker please comment if the choice of adverb is correct in t= hese two instances: " The choice of incoming timestamps to be saved for this comparison MUST guar= antee a value that is monotonically / [monotone] increasing. =20 " However, the receiver treats the timestamp as simply a monotonically / [monotone] increa= sing serial number, without any necessary connection to its clock. =20 " Best regards, Richard From nhb_web@nexgo.de Sat Apr 13 05:52: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 B875621F84D4 for ; Sat, 13 Apr 2013 05:52:41 -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 efEkxPWmqVTn for ; Sat, 13 Apr 2013 05:52:41 -0700 (PDT) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by ietfa.amsl.com (Postfix) with ESMTP id B033421F84CE for ; Sat, 13 Apr 2013 05:52:40 -0700 (PDT) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mx.arcor.de (Postfix) with ESMTP id DD68D30596 for ; Sat, 13 Apr 2013 14:52:38 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id D31D714ACF4 for ; Sat, 13 Apr 2013 14:52:38 +0200 (CEST) X-Greylist: Passed host: 82.83.253.210 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-05.arcor-online.net C5971E41A5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nexgo.de; s=mail-in; t=1365857558; bh=1aP1nBBJHqFVyfcXVGmFKwk+R8XrwOjTPcLLLGY5lnk=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=KJqpZ9tmqIkzpd+xyEWj9+FWXgHEcvnX2mmwq0vtLGMJvAuQkqDWQ/eGx85fOk/A+ P8ftrmgCRg98/DG0fP4IH1KMtenrIo0rfgfTBqmV/aH1wxM22ZdiSvTbsb1MulJsEK BjJsc0Ysr9jlHwhpG2S18i292h8/VbK8hxF/brxk= Received: from [192.168.25.241] (dslc-082-083-253-210.pools.arcor-ip.net [82.83.253.210]) (Authenticated sender: nhb@arcor.de) by mail-in-05.arcor-online.net (Postfix) with ESMTPSA id C5971E41A5 for ; Sat, 13 Apr 2013 14:52:38 +0200 (CEST) Message-ID: <51695516.50505@nexgo.de> Date: Sat, 13 Apr 2013 14:52:38 +0200 From: Hendrik Brummermann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [tcpm] TCP Fast Open and dynamic IP-address assignments 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, 13 Apr 2013 14:15:27 -0000 The section on security consideration mentions carrier grade NAT as a potential issue. A similar issues exists in the context of dynamic IP-address assignments: An adversary may request a TFO cookie and disconnect from the Internet. A new user will get the same IP-address. But the adversary can still send packets with the TFO cookie, spoofing this ip-address as source. In addition to the reflection of large answer packets to the current user, this makes it likely that the current user is blamed for malicious actions caused by the adversary. Log files on the server will show the IP-address and the current timestamp. While the NAT gateway may prevent TCP Fast Open by filtering the flags, there seems to be no way an Internet user can protect himself against the previous user of his ip-address. From ycheng@google.com Sat Apr 13 13:24: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 B116C21F861A for ; Sat, 13 Apr 2013 13:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.227 X-Spam-Level: X-Spam-Status: No, score=-101.227 tagged_above=-999 required=5 tests=[AWL=0.750, 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 3XHedIORB2UZ for ; Sat, 13 Apr 2013 13:24:25 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBB821F8615 for ; Sat, 13 Apr 2013 13:24:24 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eh20so2318529lab.6 for ; Sat, 13 Apr 2013 13:24:23 -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=nAnudtaKODukxLEzNb4Kt8ilK+Ef+VGOwskkpI2suIk=; b=HJojM3aZc9vpfgYwFd8tV0C5RDXCy/hBzfTZJQGqVAEvPFdpAoZ/aoqBOrnlBsBDSs 0IoEgbokrl2K88XAu7pK/bqionhyiWzm/1PdD/PfYBWuPwlCh5u9OpdU6ImxKxdxUDp/ Z9BTEAjI5gpbf2pkPjzz2+XVrl7LOdMco7XrCn6xe/Hz5rFVwZrCN+qtslssh0W1ln3t dBCGngQgXRBChm0XMNS4d7uFoKcA3PQOZhGoTLvtBinOwfja3faAyvO3dBoaHTgE9GnH F1axrBTFDa9TaRV+rXyH04KRyaM8ViU2AjnvjK+Vujw43pStG/0tlHkhas7ZMF6Dsc5R lwCA== 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=nAnudtaKODukxLEzNb4Kt8ilK+Ef+VGOwskkpI2suIk=; b=WotkCsyDXMDcTRNhh3TF5B0tE1uipTg+bJNSa+kf1bbrlBAFgsiTuCzvGlQKSxvwOB cqjC86vuMG0N+jyPB1c5KqfqYLrMAXRq+6/YDYyY0juAffwejrdQwmS5mGcFWTCZUFpU l6XvNnsNj7jRbl8Pfuk5Bt2FgmwFq/IdBR+eZxKCuh+uqyjb5dd4orrqnPkGjtVz9Ipj vjIVaXHvATBCSHf6z4wELUUbK02IgZyd5t5lX4Pn81pM77kvnKmnXLiTfDhFEvg25Prg iGkFzq8eMxer7Zt11U4zXo4pjBkHH2UQp1VbqlFXpvpWWKJmxo/Kb2BljpcQConEW4CW t8Hg== X-Received: by 10.112.133.198 with SMTP id pe6mr7564275lbb.103.1365884663258; Sat, 13 Apr 2013 13:24:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.148.34 with HTTP; Sat, 13 Apr 2013 13:24:03 -0700 (PDT) In-Reply-To: <51695516.50505@nexgo.de> References: <51695516.50505@nexgo.de> From: Yuchung Cheng Date: Sat, 13 Apr 2013 13:24:03 -0700 Message-ID: To: Hendrik Brummermann Content-Type: multipart/alternative; boundary=047d7b3a837428832e04da43ce12 X-Gm-Message-State: ALoCoQmyKC8HnM+ZXAKBn3LAT2uHu3GSK5XVfeB5IeTpJO/xsVScExk8xTCSGZ2Rr06/809mMweudWx7vleJvnV9iXKL7GWaCOD1fGFwcS3UHiOG68NMRKCJ69Omxy3bLOlMn6LtB+LGrx4U6SHSeAOP7ju/UqvGyKLR0gYav3EPUN7JCUVmpFxzIC9KRxiGMUedENPo73Ow Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCP Fast Open and dynamic IP-address assignments 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, 13 Apr 2013 20:24:25 -0000 --047d7b3a837428832e04da43ce12 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 13, 2013 at 5:52 AM, Hendrik Brummermann wrote: > The section on security consideration mentions carrier grade NAT as a > potential issue. A similar issues exists in the context of dynamic > IP-address assignments: > > An adversary may request a TFO cookie and disconnect from the Internet. > A new user will get the same IP-address. But the adversary can still > send packets with the TFO cookie, spoofing this ip-address as source. > Are you suggesting the current text http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-03#section-6 is not clear on this case? happy to revise if it's not clear. > > In addition to the reflection of large answer packets to the current > user, this makes it likely that the current user is blamed for malicious > actions caused by the adversary. Log files on the server will show the > IP-address and the current timestamp. > so is a regular SYN flood. btw the "large answer" packets are limited to the initial TCP congestion window > > While the NAT gateway may prevent TCP Fast Open by filtering the flags, > there seems to be no way an Internet user can protect himself against > the previous user of his ip-address. > yes if the ISP allows any user to send IP packet with (previously owned) spoofed IP packet. (and so is regular syn flood). _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --047d7b3a837428832e04da43ce12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Apr 13, 2013 at 5:52 AM, Hendrik Brummermann <nhb_web@nexgo= .de> wrote:
The section on security consideration mentions carrier gra= de NAT as a
potential issue. A similar issues exists in the context of dynamic
IP-address assignments:

An adversary may request a TFO cookie and disconnect from the Internet.
A new user will get the same IP-address. But the adversary can still
send packets with the TFO cookie, spoofing this ip-address as source.
Are you suggesting the current text=A0
is not clear on this case? happy to revise if it's not= clear.
=A0

In addition to the reflection of large answer packets to the current
user, this makes it likely that the current user is blamed for malicious actions caused by the adversary. Log files on the server will show the
IP-address and the current timestamp.
so is a re= gular SYN flood. btw the "large answer" packets are limited to th= e initial TCP congestion window

While the NAT gateway may prevent TCP Fast Open by filtering the flags,
there seems to be no way an Internet user can protect himself against
the previous user of his ip-address.
yes if the = ISP allows any user to send IP packet with (previously owned) spoofed IP pa= cket.=A0
(and so is regular syn flood).

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

--047d7b3a837428832e04da43ce12-- From nhb_web@nexgo.de Sun Apr 14 15:53: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 7F28B21F8CEC for ; Sun, 14 Apr 2013 15:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 2jxg3JCNtBUd for ; Sun, 14 Apr 2013 15:53:11 -0700 (PDT) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by ietfa.amsl.com (Postfix) with ESMTP id 75BE021F8CA1 for ; Sun, 14 Apr 2013 15:53:10 -0700 (PDT) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mx.arcor.de (Postfix) with ESMTP id 999DC15C376 for ; Mon, 15 Apr 2013 00:53:09 +0200 (CEST) Received: from mail-in-13.arcor-online.net (mail-in-13.arcor-online.net [151.189.21.53]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id 91CE418461 for ; Mon, 15 Apr 2013 00:53:09 +0200 (CEST) X-Greylist: Passed host: 82.83.193.9 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-13.arcor-online.net 7C86A21236B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nexgo.de; s=mail-in; t=1365979989; bh=O0rJ6bR6+PSy04HMEhF0ip64R4cplntoGpUvCdxcc14=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nVcPjVMvxthLH+hHUFOcWjiw2AXZNjkqj5sFS5wSKJ+DSE6RNha/NnpeCRpXaFrus ej3RnG+1i5j8XBwxR935D7MFsBqMjwdJ9V7cdHTak0SKrb6RJsDSJLnCRXHYey8xvb TscVwcfKnXXRwL+9/o6WJwdHgc/rN+zBlxany5lc= Received: from [192.168.25.241] (dslc-082-083-193-009.pools.arcor-ip.net [82.83.193.9]) (Authenticated sender: nhb@arcor.de) by mail-in-13.arcor-online.net (Postfix) with ESMTPSA id 7C86A21236B for ; Mon, 15 Apr 2013 00:53:09 +0200 (CEST) Message-ID: <516B3356.1050306@nexgo.de> Date: Mon, 15 Apr 2013 00:53:10 +0200 From: Hendrik Brummermann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "tcpm@ietf.org Extensions" References: <51695516.50505@nexgo.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP Fast Open and dynamic IP-address assignments 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, 14 Apr 2013 22:53:12 -0000 Am 13.04.2013 22:24, schrieb Yuchung Cheng: > On Sat, Apr 13, 2013 at 5:52 AM, Hendrik Brummermann wrote: >> The section on security consideration mentions carrier grade NAT as a >> potential issue. A similar issues exists in the context of dynamic >> IP-address assignments: >> An adversary may request a TFO cookie and disconnect from the Internet. >> A new user will get the same IP-address. But the adversary can still >> send packets with the TFO cookie, spoofing this ip-address as source. > Are you suggesting the current text > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-03#section-6 > is not clear on this case? happy to revise if it's not clear. I am sorry, I missed the last paragraph of the introduction section. PPP/PPPoE is used by most boardband providers at least in Germany instead of DHCP. Large ISP here force an IP-change on end-users every 24 hours. >> In addition to the reflection of large answer packets to the current >> user, this makes it likely that the current user is blamed for malicious >> actions caused by the adversary. Log files on the server will show the >> IP-address and the current timestamp. > so is a regular SYN flood. btw the "large answer" packets are limited to > the initial TCP congestion window In case of a syn flood it is widely assumed that the source address is forged. But in case of webserver logs, it is reasonable likely that the source address and timestamp will lead to the real origin of the connection. It may either be the attacker themselves or a relay which might be used with or without permission. (Yes, a TCP three way handshake can be faked in some circumstances, but this is reasonable unlikely). It may be a good idea to document the risks of TFO in the context of blaming innocent clients more clearly. It basically means that each log entry timestamp gets blurred into a timeframe which goes back into the past for the validation duration of the TFO cookie. >> While the NAT gateway may prevent TCP Fast Open by filtering the flags, >> there seems to be no way an Internet user can protect himself against >> the previous user of his ip-address. > yes if the ISP allows any user to send IP packet with (previously owned) > spoofed IP packet. The packets may be sent using another ISP. From ycheng@google.com Mon Apr 15 08:55: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 A443C21F9060 for ; Mon, 15 Apr 2013 08:55:22 -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 jzs6xSUF+UmK for ; Mon, 15 Apr 2013 08:55:22 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id A105921F9381 for ; Mon, 15 Apr 2013 08:55:20 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y8so4682615lbh.35 for ; Mon, 15 Apr 2013 08:55:09 -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=cikNgN++Cx+qHL8y65iwLdg71ARmpPyAp+250i14wnA=; b=PoBo+R7+LjSRcthq0th/YA25UO7Ho4kEMYWwxCWC3kN5+uU7n3CwqYASALnVu/sihF lUXP/bMyEtw5K0kWBzQ+nlfgilbU9kQuP9H3CV/WnhXsRc/G5bICmnhgm6YXo2hvxN7+ lVUHBLRPpvvOSIPqRYu1Wbr/xcgiWsfo8KH906GMCvuGaWT9aouNLvMV4dRDLldAuvo/ iSj8lE+/UAWFkkp/8isHoNO2+yd+mgC+HRxfp18+H2oRwQbrZmrCmQCy1Pxl8b3+F7uD rgHJNwiYW09ThzVbbRxus+YVJg2h0xxEr6vj+50leKg2ADp5Xl8F0kenw4si3IsEp4Hw q9hA== 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=cikNgN++Cx+qHL8y65iwLdg71ARmpPyAp+250i14wnA=; b=MFw5iMITEGn1Ij3BE0PTPKgdciYQqRH/12v9C5P4z8MblVd4sb0YQSwwempQNhvKRl SjNhcYpotNKBIBhwMz1lAngL6O0R/MkJUv3I6ruRCqaovP8zZsnEQU66tSHvAgqww4Mq o+0mkIKB6J2m8gdsRxm9oN6CGjJCo998j4ZMb0+uqB7hKjkJA+Pe9Lf6NoukK8km5cgV dUJGojNQK+e8+if3t4ksDzM/Zj16+XAsEOJblSNojr2dq1m2RJfsjCGncjkpgHdZmV3i /8wex0wMnKk37ZioN10rLsbqVJfcOAng/6ijkXmASz+jzJ2Kp6UfKM+ko9dIo9qxfb4W 9m/Q== X-Received: by 10.112.133.198 with SMTP id pe6mr10563964lbb.103.1366041309514; Mon, 15 Apr 2013 08:55:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.148.34 with HTTP; Mon, 15 Apr 2013 08:54:48 -0700 (PDT) In-Reply-To: <20130412075133.23915.72156.idtracker@ietfa.amsl.com> References: <20130412075133.23915.72156.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 15 Apr 2013 08:54:48 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlqchCu3ac0xvaRQg08tEB6ye7/MrxYQERauc4Mhi02i9O+NrWgRfYGszP5w+veu6eyI8/VJhe89LLloknDYasDJbAh5siuAFDBz3Q2vHIFDVcYrLk6UCl5JppiAllbNtplf7nXXtnlg3VjSAHKYtwPwnND63hlMKCBgHR1qKaLmRvvBTjIbCvBdCBACR+3OLiEeFZN Cc: "tcpm@ietf.org Extensions" , i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-09.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, 15 Apr 2013 15:55:23 -0000 Section 3 looks good to me. On Fri, Apr 12, 2013 at 12:51 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 : TCP Extensions for High Performance > Author(s) : David Borman > Bob Braden > Van Jacobson > Richard Scheffenegger > Filename : draft-ietf-tcpm-1323bis-09.txt > Pages : 44 > Date : 2013-04-12 > > 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-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-09 > > > 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 Tue Apr 16 06:43: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 2403821F970B for ; Tue, 16 Apr 2013 06:43:31 -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 v-ixjLFVyQsm for ; Tue, 16 Apr 2013 06:43:30 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id AFAC821F9706 for ; Tue, 16 Apr 2013 06:43:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,485,1363158000"; d="scan'208";a="20105923" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 16 Apr 2013 06:43:25 -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 r3GDhP39019350; Tue, 16 Apr 2013 06:43:25 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.247]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 06:43:24 -0700 From: "Scheffenegger, Richard" To: Kevin Lahey Thread-Topic: [tcpm] Manual DIFF 1323bis-09 vs. RFC1323 Thread-Index: Ac434Xhy+rVPFrhHTSaWoNuHromDdwChu8uAAA+QWIA= Date: Tue, 16 Apr 2013 13:43:24 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B20E52@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24B1C1D0@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Manual DIFF 1323bis-09 vs. RFC1323 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, 16 Apr 2013 13:43:31 -0000 Hi Kevin, Perhaps this link will work better: https://docs.google.com/file/d/0B7EMOyVNNe1_aklIZXhMME9ESGc/edit?usp=3Dshar= ing it should show you an overview of the pages to the left, where the color sh= ould make the new sections 1.4, 2.4, 4.7, 6 and AppE, and the heavy edited = section 3.2, 3.3, 4.2, AppA stand out. This is also an update, to show the changes in AppD (s/my.TSClock/Snd.TSClo= ck/g - as defined in AppC as the session-specific clock source). I'll submit a (hopefully final) update to this draft momentarily. Richard Scheffenegger > -----Original Message----- > From: Kevin Lahey [mailto:kevin.lahey@oracle.com] > > It can also be viewed here: > > > > > https://docs.google.com/file/d/0B7EMOyVNNe1_QVZnd1F0S2NQQnc/edit?usp=3Dsh= ari > ng >=20 > The URL doesn't work for me, but that may be my problem getting out > through the corporate proxy. >=20 From internet-drafts@ietf.org Tue Apr 16 06:45: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 D471221F9718; Tue, 16 Apr 2013 06:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, 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 foDZzBlImqKr; Tue, 16 Apr 2013 06:45:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF5A21F8D28; Tue, 16 Apr 2013 06:45:25 -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.p4 Message-ID: <20130416134525.31463.63781.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 06:45:25 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.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, 16 Apr 2013 13:45:26 -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-10.txt Pages : 44 Date : 2013-04-16 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Tue Apr 16 06:54: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 B6DA621F973B for ; Tue, 16 Apr 2013 06:54:24 -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 Sg23+3qpBMaJ for ; Tue, 16 Apr 2013 06:54:24 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 277A721F973A for ; Tue, 16 Apr 2013 06:54:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,486,1363158000"; d="scan'208";a="41103782" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 16 Apr 2013 06:54:23 -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 r3GDsNpC003558; Tue, 16 Apr 2013 06:54:23 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.247]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 06:54:23 -0700 From: "Scheffenegger, Richard" To: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.txt Thread-Index: AQHOOqjJj4MjkAcQJk+iFLGrVhce6pjY3N1w Date: Tue, 16 Apr 2013 13:54:22 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B20EEA@SACEXCMBX02-PRD.hq.netapp.com> References: <20130416134525.31463.63781.idtracker@ietfa.amsl.com> In-Reply-To: <20130416134525.31463.63781.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.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.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, 16 Apr 2013 13:54:24 -0000 Hi group, This is the version that I believe is ready for WGLC.=20 Since -09, only a few editorial nits have been raised (thanks Yuchung).=20 Unless someone objects, I'd like to ask the WG Chairs to formally perform t= he last call. Again, to help reviewers of this document, the main changes have been marke= d in color here, with the exception of the nits below: https://docs.google.com/file/d/0B7EMOyVNNe1_aklIZXhMME9ESGc/edit?usp=3Dshar= ing Best regards, Richard Using proper SI units: - used is 2^16 =3D 65K bytes. + used is 2^16 =3D 64 KiB. - MUST be limited to 14 (which allows windows of 2^30 =3D 1 Gbyte). If a =09 + MUST be limited to 14 (which allows windows of 2^30 =3D 1 GiB). If a=09 - Expanding the TCP window beyond 64K for IPv6 allows Jumbograms =09 - [RFC2675] to be used when the local network supports packets larger =09 - than 64K. When larger TCP segments are used, the TCP checksum becomes =09 - weaker. =09 + Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms =20 + [RFC2675] to be used when the local network supports packets larger=09 + than 64 KiB. When larger TCP segments are used, the TCP checksum=09 + becomes weaker.=09 =09 - sent in a single packet is 65495 bytes (64K - 1 -- size of =09 + sent in a single packet is 65495 bytes (64 KiB - 1 -- size of=09 =09 Nits (eg vs ie): =09 - RTTM Rule: A TSecr value received in a segment MAY be used to =09 - update the averaged RTT measurement only if the segment advances =09 - the left edge of the send window (e.g. SND.UNA is increased). =09 =09 + RTTM Rule: A TSecr value received in a segment MAY be used to update = =09 + the averaged RTT measurement only if the segment advances= =09 + the left edge of the send window, i.e. SND.UNA is=09 + increased.=09 Non RFC2119 UPPERCASES removed: - suppose delivery of some of C.1, ... Z.1 is delayed until AFTER =09 + suppose delivery of some of C.1, ... Z.1 is delayed until *after*=09 - perform the header prediction step H2 FIRST, and perform H1 and H3 =09 + perform the header prediction step H2 *first*, and perform H1 and H3=09 (Note: The uppercase FIRST appears in RFC1323, not in draft 1323bis-09) From ycheng@google.com Tue Apr 16 11:21: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 232DC21F96F0 for ; Tue, 16 Apr 2013 11:21:21 -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 KPkryhpxVc4E for ; Tue, 16 Apr 2013 11:21:18 -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 33A3221F9711 for ; Tue, 16 Apr 2013 11:21:13 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id el20so735160lab.37 for ; Tue, 16 Apr 2013 11:21:12 -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=8DnSsg9PKH5rW90F4+P+DF5z9hSGcMvj3bq0fPlZcJM=; b=ZT0/Rm+3cykT27iuX2gcIUa0BIOwcOamiX95t7PfhE8vh89USPlsENhQV7gBk0z2Gz 1om6tbsST29AkybAW7EDUlGa7ahkKtZHCxoQ2VYVnxpTD8Oy07WCMrusD+2tTWZL9jbR nSbbrJHZfDd0+TztOhRUVYwIcMfb8l7UJnu8j84GHl0XOnKnWF3+2wl84XhObeOetPbz COmLMGEK0kCx7GAarZ3DANL1pdkZV/58PkIE2BQVFaJyjq+OtXUDwAr+ONe+ttvz04Ht S8BUwIrz00A8ASBcEqS1cCQ9mG++zSJu4pzKqcgCF2lMCQu2AGzXuYAnGPRlMJLVzggg 08tg== 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=8DnSsg9PKH5rW90F4+P+DF5z9hSGcMvj3bq0fPlZcJM=; b=f7uLnUgZDbv+FcDLMlMJvPo2BYgQTfkLKzQe++TMuCCJRT9Tz2XU8RtHHi/gdqvJ5r ze1mQYrNfaytTCjknVK7PdRJXgGtXV/9eK8Ug/72pm7KJM1uVLOs+1CcIuz2ARY19HGu cI2eXPN+If5ZUMMYT07TQweHyzuqvq9s12PsDqIN8Qwr8GFGQOAOzkHnDl3cpVUhN0Vo UbO/NnX6KOH41lavRsF5hKGMiJGJPP3ZF3bdwUusG3BG7vbLXt84nPRU/15phV15/wpo iHByZdcP7QvMRCCJOsNF2aYH4cg6QcWDrGu4ocHV0LB/FTVZVITBqxvFrRta48qmlZar 2x2g== X-Received: by 10.112.19.196 with SMTP id h4mr1884828lbe.111.1366136471949; Tue, 16 Apr 2013 11:21:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.148.34 with HTTP; Tue, 16 Apr 2013 11:20:51 -0700 (PDT) In-Reply-To: <516B3356.1050306@nexgo.de> References: <51695516.50505@nexgo.de> <516B3356.1050306@nexgo.de> From: Yuchung Cheng Date: Tue, 16 Apr 2013 11:20:51 -0700 Message-ID: To: Hendrik Brummermann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnbnZC7QRx/EGxtDxnTJYvqx8JE220g2R6KS7UVMPUpRm0EAA8307NiUt2ZIlBlu1gbqtogE0GcEuR2VLEu1VFDTRNv2lDRU6Y36hvkG2aQGk9FVsXx02yO8bEBPWqhA1SQOVYzgCkpoXgCn+Op9tNGccszl34qSsjbsizu7ksR6SAPePO1Bm0cQfNYDZ/IOt5YVQXS Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCP Fast Open and dynamic IP-address assignments 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, 16 Apr 2013 18:21:21 -0000 On Sun, Apr 14, 2013 at 3:53 PM, Hendrik Brummermann wrote: > Am 13.04.2013 22:24, schrieb Yuchung Cheng: >> On Sat, Apr 13, 2013 at 5:52 AM, Hendrik Brummermann wrote: >>> The section on security consideration mentions carrier grade NAT as a >>> potential issue. A similar issues exists in the context of dynamic >>> IP-address assignments: >>> An adversary may request a TFO cookie and disconnect from the Internet. >>> A new user will get the same IP-address. But the adversary can still >>> send packets with the TFO cookie, spoofing this ip-address as source. >> Are you suggesting the current text >> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-03#section-6 >> is not clear on this case? happy to revise if it's not clear. > > I am sorry, I missed the last paragraph of the introduction section. > > PPP/PPPoE is used by most boardband providers at least in Germany > instead of DHCP. Large ISP here force an IP-change on end-users every 24 > hours. > > >>> In addition to the reflection of large answer packets to the current >>> user, this makes it likely that the current user is blamed for malicious >>> actions caused by the adversary. Log files on the server will show the >>> IP-address and the current timestamp. >> so is a regular SYN flood. btw the "large answer" packets are limited to >> the initial TCP congestion window > > In case of a syn flood it is widely assumed that the source address is > forged. But in case of webserver logs, it is reasonable likely that the > source address and timestamp will lead to the real origin of the > connection. It may either be the attacker themselves or a relay which > might be used with or without permission. (Yes, a TCP three way > handshake can be faked in some circumstances, but this is reasonable > unlikely). > > It may be a good idea to document the risks of TFO in the context of > blaming innocent clients more clearly. It basically means that each log > entry timestamp gets blurred into a timeframe which goes back into the > past for the validation duration of the TFO cookie. Great point. Will incorporate that in the security section of next revision. Thanks. > > >>> While the NAT gateway may prevent TCP Fast Open by filtering the flags, >>> there seems to be no way an Internet user can protect himself against >>> the previous user of his ip-address. >> yes if the ISP allows any user to send IP packet with (previously owned) >> spoofed IP packet. > > The packets may be sent using another ISP. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Tue Apr 16 12:31: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 1CF0921F9730 for ; Tue, 16 Apr 2013 12:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[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 uok+T1hZc2KB for ; Tue, 16 Apr 2013 12:31:47 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3673E21F9727 for ; Tue, 16 Apr 2013 12:31:47 -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 5163EC560076D68B; Tue, 16 Apr 2013 22:31:43 +0300 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <17450_1366120484_516D5824_17450_123_1_012C3117EDDB3C4781FD802A8C27DD4F24B20EEA@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 16 Apr 2013 22:31:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130416134525.31463.63781.idtracker@ietfa.amsl.com> <17450_1366120484_516D5824_17450_123_1_012C3117EDDB3C4781FD802A8C27DD4F24B20EEA@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1283) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.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, 16 Apr 2013 19:31:48 -0000 Thanks, Richard, and everyone for the recent active discussion. To summarize the chairs' understanding of the current status: * The issue with RTTM (and its use with SACK) is now resolved in a way = that seems acceptable to everyone. * The current text on timestamp option negotiation and its usage is = something that most people can live with. It is understood that there is = no uniform agreement in the group about the late timestamp negotiation = issue, but the current approach of mandatory early negotiation seems to = have the support of the majority who spoke up, in addition to being = compatible with RFC 1323 (and the current implementation base). There was also some discussion of the appropriateness of the whole = timestamp mechanism, e.g. for PAWS, and possibly doing this in a new, = simpler way. This is all interesting, as are the other discussed = enhancements on timestamps, but now that there finally is momentum going = on finalizing our (long overdue) charter item on = maintenance/clarification update of RFC 1323, we should try to get this = document done. This should not prevent further work on advanced = mechanisms in this space. Is the above an appropriate summary of the current status? If so, and = there are no other immediate issues, the document seems to be ready for = WGLC. - Pasi, Yoshifumi and Michael On Apr 16, 2013, at 4:54 PM, Scheffenegger, Richard wrote: > Hi group, >=20 > This is the version that I believe is ready for WGLC.=20 >=20 >=20 > Since -09, only a few editorial nits have been raised (thanks = Yuchung).=20 >=20 > Unless someone objects, I'd like to ask the WG Chairs to formally = perform the last call. >=20 >=20 > Again, to help reviewers of this document, the main changes have been = marked in color here, with the exception of the nits below: >=20 > = https://docs.google.com/file/d/0B7EMOyVNNe1_aklIZXhMME9ESGc/edit?usp=3Dsha= ring >=20 >=20 >=20 > Best regards, > Richard >=20 >=20 > Using proper SI units: >=20 > - used is 2^16 =3D 65K bytes. > + used is 2^16 =3D 64 KiB. >=20 > - MUST be limited to 14 (which allows windows of 2^30 =3D 1 Gbyte). If = a =09 > + MUST be limited to 14 (which allows windows of 2^30 =3D 1 GiB). If a=09= >=20 > - Expanding the TCP window beyond 64K for IPv6 allows Jumbograms =09= > - [RFC2675] to be used when the local network supports packets larger =09= > - than 64K. When larger TCP segments are used, the TCP checksum = becomes =09 > - weaker. =09 > + Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms =20= > + [RFC2675] to be used when the local network supports packets larger=09= > + than 64 KiB. When larger TCP segments are used, the TCP checksum=09 > + becomes weaker.=09 > =09 > - sent in a single packet is 65495 bytes (64K - 1 -- size of =09 > + sent in a single packet is 65495 bytes (64 KiB - 1 -- size of=09 > =09 >=20 > Nits (eg vs ie): > =09 > - RTTM Rule: A TSecr value received in a segment MAY be used to =09= > - update the averaged RTT measurement only if the segment advances = =09 > - the left edge of the send window (e.g. SND.UNA is increased). =09= > =09 > + RTTM Rule: A TSecr value received in a segment MAY be used to = update =09 > + the averaged RTT measurement only if the segment = advances=09 > + the left edge of the send window, i.e. SND.UNA is=09 > + increased.=09 >=20 >=20 >=20 > Non RFC2119 UPPERCASES removed: >=20 > - suppose delivery of some of C.1, ... Z.1 is delayed until AFTER =09= > + suppose delivery of some of C.1, ... Z.1 is delayed until *after*=09 >=20 > - perform the header prediction step H2 FIRST, and perform H1 and H3 =09= > + perform the header prediction step H2 *first*, and perform H1 and H3=09= >=20 > (Note: The uppercase FIRST appears in RFC1323, not in draft = 1323bis-09) >=20 >=20 From olivier.bonaventure@uclouvain.be Wed Apr 17 04:42: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 06D3121F8C4F for ; Wed, 17 Apr 2013 04:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 nmcxo1pHDuZy for ; Wed, 17 Apr 2013 04:42:05 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id ED00021F8C23 for ; Wed, 17 Apr 2013 04:42:04 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 557C211EA2C; Wed, 17 Apr 2013 13:41:58 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 557C211EA2C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1366198918; bh=RCzkuBm2BQ+4dSHlEoebyCCVIXGoSQUMPNeOMHElI2Y=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SP5UJS7L/81BIBbh/Fjc5LSvB5MaGO+S1N3ZzCwCJZJV9J1dwB8Ty2YOv5tkIyTV2 BjN0vGt8B/eBt4rMBp2LMPWy2728Vwmr/JbZ6AzPvCTTz4zswXXS94wDNW6Tc98zmx DoyiboyljpHGnK1037k+V14QWysTHATIpfM/vqbE= Message-ID: <516E8A9F.40509@uclouvain.be> Date: Wed, 17 Apr 2013 13:42:23 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pasi Sarolahti References: <20130416134525.31463.63781.idtracker@ietfa.amsl.com> <17450_1366120484_516D5824_17450_123_1_012C3117EDDB3C4781FD802A8C27DD4F24B20EEA@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 557C211EA2C.A37D0 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:42:06 -0000 Pasi, > Thanks, Richard, and everyone for the recent active discussion. > > To summarize the chairs' understanding of the current status: > > * The issue with RTTM (and its use with SACK) is now resolved in a way that seems acceptable to everyone. > > * The current text on timestamp option negotiation and its usage is something that most people can live with. It is understood that there is no uniform agreement in the group about the late timestamp negotiation issue, but the current approach of mandatory early negotiation seems to have the support of the majority who spoke up, in addition to being compatible with RFC 1323 (and the current implementation base). > > There was also some discussion of the appropriateness of the whole timestamp mechanism, e.g. for PAWS, and possibly doing this in a new, simpler way. This is all interesting, as are the other discussed enhancements on timestamps, but now that there finally is momentum going on finalizing our (long overdue) charter item on maintenance/clarification update of RFC 1323, we should try to get this document done. This should not prevent further work on advanced mechanisms in this space. > > Is the above an appropriate summary of the current status? If so, and there are no other immediate issues, the document seems to be ready for WGLC. There is one issue that is not discussed in the draft and could be worthwhile documenting (or maybe it needs an entire document that covers all TCP extensions). The security section contains the following about middleboxes : Middle boxes and options: If a middle box removes TCP options from the segment, such as TSopt, a high speed connection that needs PAWS would not have that protection. In this situation, an implementer could provide a mechanism for the application to determine whether or not PAWS is in use on the connection, and chose to terminate the connection if that protection doesn't exist. Mechanisms to protect the TCP header from modification should also protect the TCP options. There are unfortunately several problems with middleboxes beyond this (minor) one that would be worth being discussed concerning the WSCALE option. The WSCALE option modifies the semantics of the window field in the TCP header. This modificiation has implications for the endpoints of the connection, but also for all middleboxes that process the TCP segments on the path. A middlebox can remove the WSCALE option in the SYN segment but it should never remove the WSCALE option in the SYN/ACK segment. Otherwise, the endhost will not negotiate correctly the window scaling factor. A stateful firewall, that uses the window field to detect whether a received segment is inside the current window should also support the WSCALE option and apply the scaling when processing segments. Otherwise, the firewall should remove the WSCALE option from both SYN and SYN/ACK segments. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From rs@netapp.com Wed Apr 17 07:18: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 7B44E21F8ADC for ; Wed, 17 Apr 2013 07:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 M3vKP9YiDr4L for ; Wed, 17 Apr 2013 07:18:48 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E87E821F86D5 for ; Wed, 17 Apr 2013 07:18:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,492,1363158000"; d="scan'208";a="41547155" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 17 Apr 2013 07:18:48 -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 r3HEImU8010266; Wed, 17 Apr 2013 07:18:48 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.247]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 07:18:48 -0700 From: "Scheffenegger, Richard" To: "Olivier.Bonaventure@uclouvain.be" , Pasi Sarolahti Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.txt Thread-Index: AQHOOqjJj4MjkAcQJk+iFLGrVhce6pjZPL9XgAGEiID//7FB4A== Date: Wed, 17 Apr 2013 14:18:47 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B25033@SACEXCMBX02-PRD.hq.netapp.com> References: <20130416134525.31463.63781.idtracker@ietfa.amsl.com> <17450_1366120484_516D5824_17450_123_1_012C3117EDDB3C4781FD802A8C27DD4F24B20EEA@SACEXCMBX02-PRD.hq.netapp.com> <516E8A9F.40509@uclouvain.be> In-Reply-To: <516E8A9F.40509@uclouvain.be> 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 \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.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, 17 Apr 2013 14:18:49 -0000 Hi Olivier, > There are unfortunately several problems with middleboxes beyond this > (minor) one that would be worth being discussed concerning the WSCALE > option. >=20 > The WSCALE option modifies the semantics of the window field in the TCP > header. This modificiation has implications for the endpoints of the > connection, but also for all middleboxes that process the TCP segments on > the path. >=20 > A middlebox can remove the WSCALE option in the SYN segment but it should > never remove the WSCALE option in the SYN/ACK segment. Otherwise, the > endhost will not negotiate correctly the window scaling factor. > > A stateful firewall, that uses the window field to detect whether a > received segment is inside the current window should also support the > WSCALE option and apply the scaling when processing segments. Otherwise, > the firewall should remove the WSCALE option from both SYN and SYN/ACK > segments. True, this is an issue for the receiver and middleboxes more close to the r= eceiver than the misbehaving middlebox: Sndr --------> MB1 --------> MB2 --------> Rcvr =20 =20 <-------- MB3 <-------- <-------- In such a scenario you are correct, the Receiver and Middlebox MB2 will ass= ume that Window Scale was successfully negotiated between end host, when in= fact it was not (due to stripping of WS in MB3). For the session and integrity, this is not that much of an issue (the Sndr = will simply drop segments beyond the unscaled window), and such sessions ar= e likely to suffer bad performance because of that. Does such a performance issue (self-inflicted, if the misbehaving middlebox= is in the same administrative domain as either host) need to be considered= a security risk? There is one risk, coming from non-compliant use of timestamps, though, as = demonstrated with early implementations of Cubic. As TSopt is not required = to have integrity checks (e.g. cryptographic hash in low order bits), but u= sually is a 1:1 mapping of a 32 bit clock counter, a receiver can potential= ly influence a sender in unintended ways (in the case of Cubic, a unfair la= rge share of bandwidth). However, this RFC does not endorse any receiver side use of the TSval field= other than for PAWS, thus that aspect is also not mentioned in 1323bis. Best regards, Richard Scheffenegger From olivier.bonaventure@uclouvain.be Wed Apr 17 10:59: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 84CF821F8972 for ; Wed, 17 Apr 2013 10:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 x88ohh3js2OR for ; Wed, 17 Apr 2013 10:58:58 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A340821F8659 for ; Wed, 17 Apr 2013 10:58:58 -0700 (PDT) Received: from mbpobo.local (unknown [78.129.84.108]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 19FE711FA28; Wed, 17 Apr 2013 19:58:52 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 19FE711FA28 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1366221532; bh=8q+/FSYz6tL+mF6wrawhpaWa5WkXkeZfnmxMelbaJ2A=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Pn7ZtcglMLYBDLAWMk62O78NI7eHXz/eRILcYSOOiQfK6YPzC/ZfeYCECMYlYN/Oa ldRG4F/LxjjFGtTk0vaSDQYrzbFQGQpU6IPKy71rFyTUI265ueoSZb9HM0FuUFGKvK vZT0BU8aPsW4fpotdCyidd8n7+TkHkiWa4ZFMGf4= Message-ID: <516EE2F6.9020606@uclouvain.be> Date: Wed, 17 Apr 2013 19:59:18 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20130416134525.31463.63781.idtracker@ietfa.amsl.com> <17450_1366120484_516D5824_17450_123_1_012C3117EDDB3C4781FD802A8C27DD4F24B20EEA@SACEXCMBX02-PRD.hq.netapp.com> <516E8A9F.40509@uclouvain.be> <012C3117EDDB3C4781FD802A8C27DD4F24B25033@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B25033@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 19FE711FA28.A7505 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:59:00 -0000 Richard, > >> There are unfortunately several problems with middleboxes beyond this >> (minor) one that would be worth being discussed concerning the WSCALE >> option. >> >> The WSCALE option modifies the semantics of the window field in the TCP >> header. This modificiation has implications for the endpoints of the >> connection, but also for all middleboxes that process the TCP segments on >> the path. >> >> A middlebox can remove the WSCALE option in the SYN segment but it should >> never remove the WSCALE option in the SYN/ACK segment. Otherwise, the >> endhost will not negotiate correctly the window scaling factor. >> >> A stateful firewall, that uses the window field to detect whether a >> received segment is inside the current window should also support the >> WSCALE option and apply the scaling when processing segments. Otherwise, >> the firewall should remove the WSCALE option from both SYN and SYN/ACK >> segments. > > True, this is an issue for the receiver and middleboxes more close to the receiver than the misbehaving middlebox: > > Sndr --------> MB1 --------> MB2 --------> Rcvr > > > <-------- MB3 <-------- <-------- > > > In such a scenario you are correct, the Receiver and Middlebox MB2 will assume that Window Scale was successfully negotiated between end host, when in fact it was not (due to stripping of WS in MB3). A middlebox that removes WS from SYN/ACK is rely annoying because the Sender and the Receiver do not agree on the Window Scale. Assume that they both use a window scale of 14 bits. The sender will not scale its window since it did not receive a WScale option. On the other hand, the receiver will consider that a scaling of 14 is used. It will scale its window and consider the window to be scaled when receiving segments. > For the session and integrity, this is not that much of an issue (the Sndr will simply drop segments beyond the unscaled window), and such sessions are likely to suffer bad performance because of that. The performance will be very weak and it will be difficult to detect the problem on the TCP stack (except maybe by sending some kind of probe packets). > Does such a performance issue (self-inflicted, if the misbehaving middlebox is in the same administrative domain as either host) need to be considered a security risk? > This is not as such a security risk, but middleboxes only appear in the security section of the draft. It might be worth putting a middlebox section in the draft so that middlebox developpers pay attention. RFC1323 is pretty old, but a few years ago some firewalls had problems dealing with RFC1323 and these are still deployed http://kb.pert.geant.net/PERTKB/WindowScalingProblems > There is one risk, coming from non-compliant use of timestamps, though, as demonstrated with early implementations of Cubic. As TSopt is not required to have integrity checks (e.g. cryptographic hash in low order bits), but usually is a 1:1 mapping of a 32 bit clock counter, a receiver can potentially influence a sender in unintended ways (in the case of Cubic, a unfair large share of bandwidth). > > However, this RFC does not endorse any receiver side use of the TSval field other than for PAWS, thus that aspect is also not mentioned in 1323bis. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From pasi.sarolahti@iki.fi Wed Apr 17 12:10: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 075E921F85F5 for ; Wed, 17 Apr 2013 12:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 X9UNMhXgULg4 for ; Wed, 17 Apr 2013 12:10:56 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4E121F8585 for ; Wed, 17 Apr 2013 12:10:55 -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 5163EC5600889CDC; Wed, 17 Apr 2013 22:10:43 +0300 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Pasi Sarolahti In-Reply-To: <516EE2F6.9020606@uclouvain.be> Date: Wed, 17 Apr 2013 22:10:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <738AA451-EB73-4FBE-853D-D66D80A5325E@iki.fi> References: <20130416134525.31463.63781.idtracker@ietfa.amsl.com> <17450_1366120484_516D5824_17450_123_1_012C3117EDDB3C4781FD802A8C27DD4F24B20EEA@SACEXCMBX02-PRD.hq.netapp.com> <516E8A9F.40509@uclouvain.be> <012C3117EDDB3C4781FD802A8C27DD4F24B25033@SACEXCMBX02-PRD.hq.netapp.com> <516EE2F6.9020606@uclouvain.be> To: X-Mailer: Apple Mail (2.1283) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-10.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, 17 Apr 2013 19:10:57 -0000 On Apr 17, 2013, at 8:59 PM, Olivier Bonaventure wrote: >> Does such a performance issue (self-inflicted, if the misbehaving = middlebox is in the same administrative domain as either host) need to = be considered a security risk? >=20 > This is not as such a security risk, but middleboxes only appear in = the security section of the draft. It might be worth putting a middlebox = section in the draft so that middlebox developpers pay attention. = RFC1323 is pretty old, but a few years ago some firewalls had problems = dealing with RFC1323 and these are still deployed = http://kb.pert.geant.net/PERTKB/WindowScalingProblems Thanks, Olivier, for pointing out this. I agree that the problem seems = worthwhile to be documented. There are probably no easy solutions to = detect and go around this, but at least it would be good to make the = readers aware of the possible problems with middleboxes. I hope this is = a rare problem by now, but as you point out, this might be a hiding = issue, because it does not break connections. - Pasi From rs@netapp.com Thu Apr 18 02:59: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 6571B21F8BB7 for ; Thu, 18 Apr 2013 02:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 YwdxVqRRclMe for ; Thu, 18 Apr 2013 02:59:53 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id CDE8121F859A for ; Thu, 18 Apr 2013 02:59:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,500,1363158000"; d="scan'208";a="253038975" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 18 Apr 2013 02:59:53 -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 r3I9xrBX003188; Thu, 18 Apr 2013 02:59:53 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.247]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Thu, 18 Apr 2013 02:59:53 -0700 From: "Scheffenegger, Richard" To: "Olivier.Bonaventure@uclouvain.be" , Pasi Sarolahti Thread-Topic: 1323bis Security section - Middleboxes Thread-Index: Ac48G2KPmHYZqaHlTbKYcEypCQULxg== Date: Thu, 18 Apr 2013 09:59:52 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] 1323bis Security section - Middleboxes 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, 18 Apr 2013 09:59:54 -0000 I have re-ordered the (new) text passage in section 6, including Olivier's = comments. Also, I changed the text around removal of options slightly, to properly ap= ply to the options discussed in 1323bis... Including modifications (twiggin= g TSval/Tsecr is fine if done symmetrically, but changing WS is not). Comments on this updated section? Regards, Richard=20 6. Security Considerations The TCP sequence space is a fixed size, and as the window becomes larger it becomes easier for an attacker to generate forged packets that can fall within the TCP window, and be accepted as valid segments. While use of timestamps and PAWS can help to mitigate this, when using PAWS, if an attacker is able to forge a packet that is acceptable to the TCP connection, a timestamp that is in the future would cause valid segments to be dropped due to PAWS checks. Hence, implementers should take care to not open the TCP window drastically beyond the requirements of the connection. A naive implementation that derives the timestamp clock value directly from a system uptime clock may unintentionally leak this information to an attacker. This does not directly compromise any of the mechanisms described in this document. However, this may be valuable information to a potential attacker. An implementer should evaluate the potential impact and mitigate this accordingly (i.e. by using a random offset for the timestamp clock on each connection, or using an external, real-time derived timestamp clock source). Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms [RFC2675] to be used when the local network supports packets larger than 64 KiB. When larger TCP segments are used, the TCP checksum becomes weaker. Mechanisms to protect the TCP header from modification should also protect the TCP options. Middleboxes and TCP options: A middlebox may remove TCP options described in this document from the segment, but it must not delete any of these options in a segment. A middlebox should never remove or modify the Window Scale option in the segment. Otherwise, the endhost will not negotiate the window scaling factor correctly. The Window Scale option modifies the semantics of the window field in the TCP header. This modification has implications for the endpoints of the connection, but also for all middleboxes that process the TCP segments on the path. A stateful firewall, that uses the window field to detect whether a received segment is inside the current window should also support the Window Scale option and apply the scaling when processing segments. Otherwise, the firewall should remove the Window Scale option from the segment. If a middlebox removes TCP options from the segment, such as the Timestamp option, a high speed connection that needs PAWS would not have that protection. In this situation, an implementer could provide a mechanism for the application to determine whether or not PAWS is in use on the connection, and chose to terminate the connection if that protection doesn't exist. From john@jlc.net Thu Apr 18 07:18: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 76BD121F8B98 for ; Thu, 18 Apr 2013 07:18:53 -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 JZiiIAvMsyEW for ; Thu, 18 Apr 2013 07:18:53 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EBEBB21F8B8F for ; Thu, 18 Apr 2013 07:18:52 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 70D2A33C26; Thu, 18 Apr 2013 10:18:52 -0400 (EDT) Date: Thu, 18 Apr 2013 10:18:52 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20130418141852.GB19632@verdi> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 18 Apr 2013 14:18:53 -0000 Scheffenegger, Richard wrote: > > 6. Security Considerations >... > Middleboxes and TCP options: > > A middlebox may remove TCP options described in this document from > the segment, but it must not delete any of these options in > a segment. This whole issue is such a kludge that I fear to tread... Though rare, it is possible for TCP SYNs to overlap. If one end's middlebox removes the Window Scale option and the other doesn't, there is the opportunity for one side to believe Window Scale is enabled while the other side doesn't. Thus, IMHO, a middlebox should _never_ remove the Window Scale option: if it can't manage a Window-Scaled connection, it should refuse to establish one by dropping the SYN rather than by just dropping the option. (I don't think either way of rejecting Window Scale is reasonable: by now any middlebox that cares in the least about Window Scaling should have learned how to do it right.) -- John Leslie From touch@isi.edu Thu Apr 18 10:37:42 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 EAC1521F9193 for ; Thu, 18 Apr 2013 10:37:42 -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 jFhm5TDkJ7W5 for ; Thu, 18 Apr 2013 10:37:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 748CD21F9049 for ; Thu, 18 Apr 2013 10:37:42 -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 r3IHbBwf017221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Apr 2013 10:37:11 -0700 (PDT) Message-ID: <51702F40.9090105@isi.edu> Date: Thu, 18 Apr 2013 10:37:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@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 Security section - Middleboxes 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, 18 Apr 2013 17:37:43 -0000 Hi, all, On 4/18/2013 2:59 AM, Scheffenegger, Richard wrote: ... > Middleboxes and TCP options: > > A middlebox may remove TCP options described in this document from > the segment, but it must not delete any of these options in > a segment. I disagree with any recommendation in any IETF standard that suggests that it is *ever* appropriate for a middlebox to add, delete, or modify a TCP header in any way. ... > A stateful firewall, that uses the window field to detect whether > a received segment is inside the current window should also > support the Window Scale option and apply the scaling when > processing segments. Otherwise, the firewall should remove the > Window Scale option from the segment. For the same reason, I disagree with the above. At best, the firewall should drop that SYN segment. > If a middlebox removes TCP options from the segment, such > as the Timestamp option, a high speed connection that needs PAWS > would not have that protection. In this situation, an implementer > could provide a mechanism for the application to determine whether > or not PAWS is in use on the connection, and chose to terminate > the connection if that protection doesn't exist. Options are not "pick and choose" for transits; they are "all or none". They need to stay out of the way of the endpoints. Joe From ycheng@google.com Thu Apr 18 13:30: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 0221D21F9057 for ; Thu, 18 Apr 2013 13:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.811 X-Spam-Level: X-Spam-Status: No, score=-103.811 tagged_above=-999 required=5 tests=[AWL=-0.834, 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 f6PI2xr0X7G1 for ; Thu, 18 Apr 2013 13:30:11 -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 1EC7921F902B for ; Thu, 18 Apr 2013 13:30:10 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id v10so3115301lbd.30 for ; Thu, 18 Apr 2013 13:30:10 -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=C84HpQ1j+0WC/39xkjWrwOtK+NPaM3LJx6/SrgjdUZ0=; b=CnGbj1sGSL6xpk4VrWQ6jtjTZuc2gRkB57nHKqFDbnPQFvIeXByJ9PyY9oF4bv7B5s 7mKLSW/N/hOLKG6pNrKQjEgORX/w9GytwG97KPqjths9XI2PY4UA0xvpB/IPsjLcA/Y5 KsEfAeYCB9Qjma7Z4L74klQ5ZB9x3fq/2X8rNndgWHIoiIqRBBqQ/wEcKsCzazAybg6j 38hTEX5FHKIPqHa5rqXHzBWmQO/I91mkkVADhZJr8nEhCKDKMW9OyiUhiA9pMuPP5xhB 0nXprScz2vmLc6ZCEiYwfQHpVGKCjQPKMpPIKnQxajpxEyDEWKV+KGa4iWHpMG5zOlgJ Vw4g== 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=C84HpQ1j+0WC/39xkjWrwOtK+NPaM3LJx6/SrgjdUZ0=; b=GJG/XpqqdP3KoBQVNT6Ko00UDwpZ0UiZ8L6ppDSYjmmfZ7bsrwkv6763TGHguxsK4b 1+ZKOVOwhhrRh7ZZbyjQ9BPIOmCthNFRl1Dixain+6BUrJVgGTosV+mb92UibtZqaok7 r9htPG7rH85oAkJuWBLBrftrU9UCfU+yJceQBQ+SgKMQN2IWvjpt+MtBSf1NMaWg1g9x YfSFOKQBsAZyZEs4Gt3wv12ko/HA+cVRq0Ooux4drVJ8qyoIKbrHTA6zDnECOg+tAHum MwHcDh9uqDJOY7wkYnHdnEOPI5VbPfhzNaaj9ouJurjqQBt1RPXEIVg5trOunN3zjfmH iyPQ== X-Received: by 10.112.135.3 with SMTP id po3mr3516043lbb.103.1366317009929; Thu, 18 Apr 2013 13:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.148.34 with HTTP; Thu, 18 Apr 2013 13:29:49 -0700 (PDT) In-Reply-To: <51702F40.9090105@isi.edu> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> From: Yuchung Cheng Date: Thu, 18 Apr 2013 13:29:49 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmLYRNr15/kr/QXjK+LMARyrsgEt6GBiq1vkeLAzfNRsyYqADC7U4EhDRkKTrajRyZKYxwU1CzhLSrCzfRLEUUUGjsEe+4d7sj1Ao2fX6x3qap0ATBh5/qCpcUdSGYkZcwvcnnRpP2VfUer1KpX8J90kt9VuWAQ7M7cfFRB+AVv5GjZABV1/tTzk2m6u2PeSsSK/CNQ Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 18 Apr 2013 20:30:12 -0000 On Thu, Apr 18, 2013 at 10:37 AM, Joe Touch wrote: > Hi, all, > > On 4/18/2013 2:59 AM, Scheffenegger, Richard wrote: > ... > >> Middleboxes and TCP options: >> >> A middlebox may remove TCP options described in this document from >> the segment, but it must not delete any of these options in >> a segment. > > > I disagree with any recommendation in any IETF standard that suggests that > it is *ever* appropriate for a middlebox to add, delete, or modify a TCP > header in any way. I can not agree more what Joe said. Let's not advice or accommodate these mis-behaviors. > > ... > >> A stateful firewall, that uses the window field to detect whether >> a received segment is inside the current window should also >> support the Window Scale option and apply the scaling when >> processing segments. Otherwise, the firewall should remove the >> Window Scale option from the segment. > > > For the same reason, I disagree with the above. At best, the firewall should > drop that SYN segment. > > >> If a middlebox removes TCP options from the segment, such >> as the Timestamp option, a high speed connection that needs PAWS >> would not have that protection. In this situation, an implementer >> could provide a mechanism for the application to determine whether >> or not PAWS is in use on the connection, and chose to terminate >> the connection if that protection doesn't exist. > > > Options are not "pick and choose" for transits; they are "all or none". They > need to stay out of the way of the endpoints. > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gorry@erg.abdn.ac.uk Thu Apr 18 23:55: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 1241621F8FDA for ; Thu, 18 Apr 2013 23:55:58 -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 jNFAvMp5efGR for ; Thu, 18 Apr 2013 23:55:57 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5759421F9012 for ; Thu, 18 Apr 2013 23:55:57 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id F37082B43B3; Fri, 19 Apr 2013 07:55:55 +0100 (BST) Received: from 82.111.117.67 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 19 Apr 2013 07:55:56 +0100 Message-ID: <1b387ee8c077c9209c262b029856ac6b.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20130418141852.GB19632@verdi> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <20130418141852.GB19632@verdi> Date: Fri, 19 Apr 2013 07:55:56 +0100 From: gorry@erg.abdn.ac.uk To: "John Leslie" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 06:55:58 -0000 +1 Gorry Fairhurst > Scheffenegger, Richard wrote: >> >> 6. Security Considerations >>... >> Middleboxes and TCP options: >> >> A middlebox may remove TCP options described in this document from >> the segment, but it must not delete any of these options in >> a segment. > > This whole issue is such a kludge that I fear to tread... > > Though rare, it is possible for TCP SYNs to overlap. If one end's > middlebox removes the Window Scale option and the other doesn't, > there is the opportunity for one side to believe Window Scale is > enabled while the other side doesn't. > > Thus, IMHO, a middlebox should _never_ remove the Window Scale > option: if it can't manage a Window-Scaled connection, it should > refuse to establish one by dropping the SYN rather than by just > dropping the option. > > (I don't think either way of rejecting Window Scale is reasonable: > by now any middlebox that cares in the least about Window Scaling > should have learned how to do it right.) > > -- > John Leslie > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From olivier.bonaventure@uclouvain.be Fri Apr 19 00: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 078F421F902B for ; Fri, 19 Apr 2013 00:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Tg7TxwHvtojN for ; Fri, 19 Apr 2013 00:26:42 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC1F21F90CD for ; Fri, 19 Apr 2013 00:26:42 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id D00FB1C69B6; Fri, 19 Apr 2013 09:26:34 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be D00FB1C69B6 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1366356394; bh=8VpTa57FNNiMCw9zUIpGoEUwwIrHvzZ9sP47+Conm8Q=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=DQKGJEGSWmhL/kdWd2zwYD3/SIVyz8m+41nPHPSyb8qiubMHkmpmwoBaDhgaSPry2 7KjtFjZzZ6aAM9Gor8rn6aqTBl1gBIaLOt8ya14Szjzr8+t1xN2Q8cHy58K+dIonj+ 9xi3Y7ZOv2jokHMvgier1i6myL8j37bcclbHduoY= Message-ID: <5170F1AA.4080903@uclouvain.be> Date: Fri, 19 Apr 2013 09:26:34 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Joe Touch References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> In-Reply-To: <51702F40.9090105@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D00FB1C69B6.A56AC X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 07:26:43 -0000 Joe, > > On 4/18/2013 2:59 AM, Scheffenegger, Richard wrote: > ... >> Middleboxes and TCP options: >> >> A middlebox may remove TCP options described in this document from >> the segment, but it must not delete any of these options in >> a segment. > > I disagree with any recommendation in any IETF standard that suggests > that it is *ever* appropriate for a middlebox to add, delete, or modify > a TCP header in any way. We have two options. We remain strong believer of the end-to-end model and apply the ostrich principle and consider that middleboxes should not exist and thus we never mention middleboxes anywhere. We understand that the Internet has evolved and whether we like it or not, there are middleboxes. Since these boxes are likely to stay, we document the problems that they may cause and try to ensure that middlebox implementers do not mess more with TCP and its evolvability in the future. I think that the IETF should be pragmatic. > ... >> A stateful firewall, that uses the window field to detect whether >> a received segment is inside the current window should also >> support the Window Scale option and apply the scaling when >> processing segments. Otherwise, the firewall should remove the >> Window Scale option from the segment. > > For the same reason, I disagree with the above. At best, the firewall should drop that SYN segment. In this case, I'd prefer to have on a path a firewall that removes a TCP option than a firewall that drops SYN with a given option. We already suffer too much from devices that drop packets that contain "unknown" protocols for the deployment of SCTP for example to suggest to do this for TCP options. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From c.raiciu@cs.ucl.ac.uk Fri Apr 19 01: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 AF04621F8B64 for ; Fri, 19 Apr 2013 01:24: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 YUb497X+7lqX for ; Fri, 19 Apr 2013 01:24:26 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 45C2A21F8B5F for ; Fri, 19 Apr 2013 01:24:26 -0700 (PDT) Received: from [141.85.37.195] (helo=[10.0.0.107]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1UT6bU-000BHG-Kv; Fri, 19 Apr 2013 09:23:32 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <5170F1AA.4080903@uclouvain.be> Date: Fri, 19 Apr 2013 11:24:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7F2C7893-A1DD-466B-B639-595BEE9E8299@cs.ucl.ac.uk> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> <5170F1AA.4080903@uclouvain.be> To: Olivier.Bonaventure@uclouvain.be X-Mailer: Apple Mail (2.1085) Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 08:24:27 -0000 I like the end-to-end principle as much as the next guy. It's nice and = clean and it allows endpoints to easily reason about what happens to = their packets in the network, fostering inovation. However, I share Olivier's view with regards to middleboxes: they are = here to stay because they are needed. Scorn from the IETF will not make = them go away. Middleboxes are living proof that: - the end-to-end Internet architecture is inadequate for most of its = users (think operators, corporations) that MUST ensure some level of = security and (to a lesser extent) performance optimization - quick, easy to deploy, local patches (i.e. middleboxes) are preferred = by operators to undeployable principled solutions. Instead of trying to leave middleboxes out of the Internet architecture = as we have done so far, we need to make them an explicit part of the = architecture. At the very least, at the IETF we should understand how = existing and new TCP extensions interact will middleboxes, and try to = steer these middleboxes to do the "right" thing. The design of MPTCP = took 5 long years because of middleboxes, and our efforts to understand = what they do in practice, and to work with them rather than against = them.=20 I imagine any non-trivial change to TCP faces the same hurdles. Cheers, Costin On 19 Apr 2013, at 10:26, Olivier Bonaventure wrote: > Joe, >>=20 >> On 4/18/2013 2:59 AM, Scheffenegger, Richard wrote: >> ... >>> Middleboxes and TCP options: >>>=20 >>> A middlebox may remove TCP options described in this document = from >>> the segment, but it must not delete any of these options = in >>> a segment. >>=20 >> I disagree with any recommendation in any IETF standard that suggests >> that it is *ever* appropriate for a middlebox to add, delete, or = modify >> a TCP header in any way. >=20 >=20 > We have two options. >=20 > We remain strong believer of the end-to-end model and apply the = ostrich principle and consider that middleboxes should not exist and = thus we never mention middleboxes anywhere. >=20 > We understand that the Internet has evolved and whether we like it or = not, there are middleboxes. Since these boxes are likely to stay, we = document the problems that they may cause and try to ensure that = middlebox implementers do not mess more with TCP and its evolvability in = the future. >=20 >=20 > I think that the IETF should be pragmatic. >=20 >> ... >>> A stateful firewall, that uses the window field to detect = whether >>> a received segment is inside the current window should also >>> support the Window Scale option and apply the scaling when >>> processing segments. Otherwise, the firewall should remove = the >>> Window Scale option from the segment. >>=20 >> For the same reason, I disagree with the above. At best, the firewall = should drop that SYN segment. >=20 > In this case, I'd prefer to have on a path a firewall that removes a = TCP option than a firewall that drops SYN with a given option. We = already suffer too much from devices that drop packets that contain = "unknown" protocols for the deployment of SCTP for example to suggest to = do this for TCP options. >=20 >=20 > Olivier >=20 >=20 >=20 > --=20 > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Fri Apr 19 02:26: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 BD4F121F8B60 for ; Fri, 19 Apr 2013 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 6WNHcTxxUcKw for ; Fri, 19 Apr 2013 02:26:52 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2721F8AA8 for ; Fri, 19 Apr 2013 02:26:51 -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 r3J9QlIv028674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Apr 2013 11:26:48 +0200 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, 19 Apr 2013 11:26:47 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch , "Scheffenegger, Richard" Date: Fri, 19 Apr 2013 11:26:46 +0200 Thread-Topic: [tcpm] 1323bis Security section - Middleboxes Thread-Index: Ac48W320i+nzRLcSSEu4tKwKVAOByAAgpVOg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A7150@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> In-Reply-To: <51702F40.9090105@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 Security section - Middleboxes 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, 19 Apr 2013 09:26:52 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Thursday, April 18, 2013 7:37 PM > To: Scheffenegger, Richard > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] 1323bis Security section - Middleboxes >=20 > Hi, all, >=20 > On 4/18/2013 2:59 AM, Scheffenegger, Richard wrote: > ... > > Middleboxes and TCP options: > > > > A middlebox may remove TCP options described in this=20 > document from > > the segment, but it must not delete any of=20 > these options in > > a segment. >=20 > I disagree with any recommendation in any IETF standard that=20 > suggests that it is *ever* appropriate for a middlebox to=20 > add, delete, or modify a TCP header in any way. I personally find it very useful to document what will go wrong if middlebo= xes remove those options. But the phrasing "A middlebox may remove..." is certainly problematic. IMHO= , we should clearly state that middleboxes MUST NOT remove RFC 1313 options= , and we should specifically document the issues of removing options in to explain why. Unfortunately, it is likely that some middleboxes will violate that MUST NO= T, but then we have at least documented the issues with the . [App= arently, RFC 6919 has a bug since "REALLY REALLY MUST NOT" is missing). Michael (random IETF contributor) > ... > > A stateful firewall, that uses the window field to=20 > detect whether > > a received segment is inside the current window should also > > support the Window Scale option and apply the scaling when > > processing segments. Otherwise, the firewall should=20 > remove the > > Window Scale option from the segment. >=20 > For the same reason, I disagree with the above. At best, the=20 > firewall should drop that SYN segment. >=20 > > If a middlebox removes TCP options from the =20 > segment, such > > as the Timestamp option, a high speed connection=20 > that needs PAWS > > would not have that protection. In this situation,=20 > an implementer > > could provide a mechanism for the application to=20 > determine whether > > or not PAWS is in use on the connection, and chose=20 > to terminate > > the connection if that protection doesn't exist. >=20 > Options are not "pick and choose" for transits; they are "all=20 > or none".=20 > They need to stay out of the way of the endpoints. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From pasi.sarolahti@iki.fi Fri Apr 19 07:28: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 EB0FB21F867B for ; Fri, 19 Apr 2013 07:28:57 -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 t9Hn6bkrTkDE for ; Fri, 19 Apr 2013 07:28:57 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2252E21F84F2 for ; Fri, 19 Apr 2013 07:28:56 -0700 (PDT) Received: from pc123.netlab.hut.fi (130.233.154.123) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F40200A6F0EA; Fri, 19 Apr 2013 17:28:46 +0300 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 19 Apr 2013 17:28:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1283) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 14:28:58 -0000 On Apr 18, 2013, at 12:59 PM, Scheffenegger, Richard wrote: > Middleboxes and TCP options: >=20 > A middlebox may remove TCP options described in this document = from > the segment, but it must not delete any of these options in > a segment. Like others, I don't like the "may remove..." part of this text, but I = think it would be good to shortly describe the known problems with = middleboxes related to window scaling. I'm not sure if Security = Considerations is the right section for this text, though. The page Olivier mentioned = (http://kb.pert.geant.net/PERTKB/WindowScalingProblems) describes also = another problem: some firewalls do in-window checks and drop = out-of-window packets, but ignore the window scale option. This does not = break the connection, but damages performance. The nasty thing is that = there are no obvious ways to detect this problem. - Pasi From pasi.sarolahti@iki.fi Fri Apr 19 07:37: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 87F7C21F9530 for ; Fri, 19 Apr 2013 07:37:36 -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 MtT17FFmZbgA for ; Fri, 19 Apr 2013 07:37:36 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB97121F955A for ; Fri, 19 Apr 2013 07:37:34 -0700 (PDT) Received: from pc123.tct.hut.fi (130.233.154.123) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F40200A70630; Fri, 19 Apr 2013 17:37:18 +0300 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <14318_1366363624_51710DE8_14318_71_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A7150@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Fri, 19 Apr 2013 17:37:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <89EC3D7D-EDE5-4374-8903-17DB8DB906CA@iki.fi> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> <14318_1366363624_51710DE8_14318_71_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A7150@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1283) Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 14:37:36 -0000 On Apr 19, 2013, at 12:26 PM, Scharf, Michael (Michael) wrote: > But the phrasing "A middlebox may remove..." is certainly problematic. = IMHO, we should clearly state that middleboxes MUST NOT remove RFC 1313 = options, and we should specifically document the issues of removing = options in to explain why. Isn't there any dedicated RFC on middlebox requirements for TCP saying = that middleboxes MUST NOT touch any TCP option? My feeling is that we = shouldn't give normative middlebox requirements in this document. The = midbox developers are unlikely to find them here in any case. But as said, it doesn't hurt to describe the known problems. - Pasi From olivier.bonaventure@uclouvain.be Fri Apr 19 07:45:42 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 0C28321F8F12 for ; Fri, 19 Apr 2013 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 gH5ayaGbWITR for ; Fri, 19 Apr 2013 07:45:41 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3206C21F8F05 for ; Fri, 19 Apr 2013 07:45:41 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1E86C1C6D9C; Fri, 19 Apr 2013 16:45:26 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 1E86C1C6D9C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1366382726; bh=wX1m2+Ldjp9pOnXgNcL3Xa0yw7rspHJlD+A9U1ZdN4U=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fxpcThLTa0HCFtGXUft1skMw0m11AG76qCoGKUrHFJxPKrbpiZX19sqeag4SVto1R UFeWNkhJxuYpJyeDR583pQB1jbiUe1ufajfv8Mgqscz3aJd8eaVIAmtqaszYNWNPT3 4jWifTGH7/AgFm/FJKxjTiBwPLlOFHZEwfp2fN44= Message-ID: <51715885.5080200@uclouvain.be> Date: Fri, 19 Apr 2013 16:45:25 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pasi Sarolahti References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1E86C1C6D9C.A3776 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:45:42 -0000 Pasi, > >> Middleboxes and TCP options: >> >> A middlebox may remove TCP options described in this document from >> the segment, but it must not delete any of these options in >> a segment. > > Like others, I don't like the "may remove..." part of this text, but I think it would be good to shortly describe the known problems with middleboxes related to window scaling. I'm not sure if Security Considerations is the right section for this text, though. > > The page Olivier mentioned (http://kb.pert.geant.net/PERTKB/WindowScalingProblems) describes also another problem: some firewalls do in-window checks and drop out-of-window packets, but ignore the window scale option. This does not break the connection, but damages performance. The nasty thing is that there are no obvious ways to detect this problem. There is a long list of problems related to TCP extensions that are not well supported by middleboxes. Another example is SACK. One would expect SACK to always work if negotiated by the endhosts. Unfortunately, some firewalls break this by randomizing the TCP sequence numbers. See e.g. (extract from https://supportforums.cisco.com/docs/DOC-12668 ) Even when TCP SACK is permitted through the FWSM, there is a problem introduced by TCP Sequence Number Randomization feature that is enabled by default. The feature hides the sequence numbers generated by the endpoints behind the higher security interface by shifting them by a certain value (determined in a random fashion for each TCP connection). However, the feature does not rewrite the right and left edge values embedded into TCP SACK option. As a result, a TCP ACK requesting selective retransmission that traverses from a lower- to higher-security interface makes no sense to the inside endpoint (since the TCP sequence numbers embedded into the SACK option represent the “randomized” values known only on the outside of the FWSM). This post dates from 2010. SACK only appeared in 1996. I guess that we can easily find stories like this one from many middlebox vendors. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From olivier.bonaventure@uclouvain.be Fri Apr 19 07:49: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 1E42721F8D70 for ; Fri, 19 Apr 2013 07:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ktzL-esWHOQ6 for ; Fri, 19 Apr 2013 07:49:30 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id D058E21F8D2C for ; Fri, 19 Apr 2013 07:49:29 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 47FE11C6DA9; Fri, 19 Apr 2013 16:49:22 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 47FE11C6DA9 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1366382962; bh=TbRZs9ZeKRLxSXtDBv6Y8G9cyop+uXono8FHdyjETdk=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GjgTKg5Fm688RjmhqU4oNt2VFhfCxPh/mmClMYtpFoLkilpwBap2zt8uN5km8hN1H d2myFnh6Dh68yX1hDo71FvPwR6wnUV1wnncmN9X8mgbNNQuqv7FvIBHwxeWj5com6z 8fetwJ5oDRdlQhpgciD7BSJRh4pYsYHK0PA0n5gs= Message-ID: <51715972.4010704@uclouvain.be> Date: Fri, 19 Apr 2013 16:49:22 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pasi Sarolahti References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> <14318_1366363624_51710DE8_14318_71_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A7150@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <89EC3D7D-EDE5-4374-8903-17DB8DB906CA@iki.fi> In-Reply-To: <89EC3D7D-EDE5-4374-8903-17DB8DB906CA@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 47FE11C6DA9.A4A20 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 1323bis Security section - Middleboxes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:49:31 -0000 Pasi, >> But the phrasing "A middlebox may remove..." is certainly problematic. IMHO, we should clearly state that middleboxes MUST NOT remove RFC 1313 options, and we should specifically document the issues of removing options in to explain why. > > Isn't there any dedicated RFC on middlebox requirements for TCP saying that middleboxes MUST NOT touch any TCP option? I'm afraid that most vendors have deployed boxes that allow to do that based on requests from customers. Consider e.g. http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpnorm.html > My feeling is that we shouldn't give normative middlebox requirements in this document. The midbox developers are unlikely to find them here in any case. It might be worth having a "middlebox" section in each TCP specification to discuss the possible interactions between a TCP extension and middleboxes. If the WG believes that such a document could be useful, we could contribute based on the lessons learned from Multipath TCP. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From michael.scharf@alcatel-lucent.com Fri Apr 19 07:49: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 BB12321F8F70 for ; Fri, 19 Apr 2013 07:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 KAZ9mmnzAjaa for ; Fri, 19 Apr 2013 07:49:49 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id E49A821F8F6E for ; Fri, 19 Apr 2013 07:49:48 -0700 (PDT) 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 r3JEnj3X015168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Apr 2013 16:49:45 +0200 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; Fri, 19 Apr 2013 16:49:45 +0200 From: "Scharf, Michael (Michael)" To: Pasi Sarolahti Date: Fri, 19 Apr 2013 16:49:43 +0200 Thread-Topic: [tcpm] 1323bis Security section - Middleboxes Thread-Index: Ac49C2c7tB2yINbUTN2wf1F/3zswPwAALZuw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A71B1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> <14318_1366363624_51710DE8_14318_71_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A7150@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <89EC3D7D-EDE5-4374-8903-17DB8DB906CA@iki.fi> In-Reply-To: <89EC3D7D-EDE5-4374-8903-17DB8DB906CA@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.83 Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 14:49:49 -0000 > > But the phrasing "A middlebox may remove..." is certainly=20 > problematic. IMHO, we should clearly state that middleboxes=20 > MUST NOT remove RFC 1313 options, and we should specifically=20 > document the issues of removing options in to explain why. >=20 > Isn't there any dedicated RFC on middlebox requirements for=20 > TCP saying that middleboxes MUST NOT touch any TCP option? My=20 > feeling is that we shouldn't give normative middlebox=20 > requirements in this document. The midbox developers are=20 > unlikely to find them here in any case. Yes, I agree that normative statements on middleboxes are probably not in-s= cope of TCPM. My e-mail was probably written a bit too fast... =20 > But as said, it doesn't hurt to describe the known problems. That is my main point as well. Michael From dab@weston.borman.com Fri Apr 19 07:54: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 E7B4B21F8E79 for ; Fri, 19 Apr 2013 07:54:23 -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 MDU809HrH8q6 for ; Fri, 19 Apr 2013 07:54:23 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB021F8E6F for ; Fri, 19 Apr 2013 07:54:21 -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 r3JEs87F016364; Fri, 19 Apr 2013 09:54:09 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Borman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 19 Apr 2013 09:54:08 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 14:54:24 -0000 On Apr 18, 2013, at 4:59 AM, "Scheffenegger, Richard" wrote: ... > Middleboxes and TCP options: > > A middlebox may remove TCP options described in this document from > the segment, but it must not delete any of these options in > a segment. > > A middlebox should never remove or modify the Window Scale option > in the segment. Otherwise, the endhost will not > negotiate the window scaling factor correctly. > > The Window Scale option modifies the semantics of the window field > in the TCP header. This modification has implications for the > endpoints of the connection, but also for all middleboxes that > process the TCP segments on the path. > > A stateful firewall, that uses the window field to detect whether > a received segment is inside the current window should also > support the Window Scale option and apply the scaling when > processing segments. Otherwise, the firewall should remove the > Window Scale option from the segment. > > If a middlebox removes TCP options from the segment, such > as the Timestamp option, a high speed connection that needs PAWS > would not have that protection. In this situation, an implementer > could provide a mechanism for the application to determine whether > or not PAWS is in use on the connection, and chose to terminate > the connection if that protection doesn't exist. This whole section needs to be reworked, many valid points have been brought up. I agree with Joe, middleboxes shouldn't be removing TCP options. We should discourage that, pointing out examples of how things can go wrong. Here's my proposal for rewriting the middlebox section: Middle boxes and TCP options: Some middle boxes have been known to remove the TCP options described in this document from the segment. Middle boxes should not remove TCP options from segments, and must not remove TCP options from segments. Examples of issues that can arise when middle boxes remove these TCP options include: o If a Window Scale option is removed from a segment, the end hosts will not negotiate the window scaling factor correctly. Middle boxes must not remove the Window Scale option from segments. o If a stateful firewall uses the window field to detect whether a received segment is inside the current window, and does not support the Window Scale option, it will not be able to correctly determine whether or not a packet is in the window. These middle boxes must also support the Window Scale option and apply that scaling when processing segments. If the window scale cannot be determined, it must not do window based processing. o If the Timestamp option is removed from the segment, high speed connections that need PAWS would not have that protection. Middle boxes should not remove the Timestamp option. Implementations that depend on PAWS could provide a mechanism for the application to determine whether or not PAWS is in use on the connection, and choose to terminate the connection if that protection doesn't exist. This is not just to protect the connection against middle boxes that might remove the Timestamp option, but also against remote hosts that do not have Timestamp support. Rewriting it this way puts up front that middle boxes should not be mucking with TCP options, and support for this position is provided by the examples that point out ways that things can break when middle boxes do muck with TCP options. -David Borman From michael.scharf@alcatel-lucent.com Fri Apr 19 08:07: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 6E43D21F8FA5 for ; Fri, 19 Apr 2013 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 KaGVNC3l4TOx for ; Fri, 19 Apr 2013 08:07:15 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5A11321F8F00 for ; Fri, 19 Apr 2013 08:07:05 -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 r3JF73E1019505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Apr 2013 17:07:03 +0200 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, 19 Apr 2013 17:07:02 +0200 From: "Scharf, Michael (Michael)" To: "Olivier.Bonaventure@uclouvain.be" , Pasi Sarolahti Date: Fri, 19 Apr 2013 17:07:02 +0200 Thread-Topic: [tcpm] 1323bis Security section - Middleboxes Thread-Index: Ac49DRv5Ll8aA7kgSrm5R/JpHkYA6AAAMtVw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A71B2@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> <14318_1366363624_51710DE8_14318_71_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A7150@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <89EC3D7D-EDE5-4374-8903-17DB8DB906CA@iki.fi> <51715972.4010704@uclouvain.be> In-Reply-To: <51715972.4010704@uclouvain.be> 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 \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 15:07:16 -0000 > >> But the phrasing "A middlebox may remove..." is certainly=20 > problematic. IMHO, we should clearly state that middleboxes=20 > MUST NOT remove RFC 1313 options, and we should specifically=20 > document the issues of removing options in to explain why. > > > > Isn't there any dedicated RFC on middlebox requirements for=20 > TCP saying that middleboxes MUST NOT touch any TCP option? So far, I haven't found that RFC, at least RFC 3234 and RFC 5382 doesn't ad= dress TCP options. > I'm afraid that most vendors have deployed boxes that allow=20 > to do that based on requests from customers. Consider e.g. >=20 > http://www.cisco.com/en/US/docs/security/asa/asa82/configurati > on/guide/conns_tcpnorm.html >=20 > > My feeling is that we shouldn't give normative middlebox=20 > requirements in this document. The midbox developers are=20 > unlikely to find them here in any case. >=20 > It might be worth having a "middlebox" section in each TCP=20 > specification to discuss the possible interactions between a=20 > TCP extension and middleboxes. I don't think that every TCP specification has to discuss middleboxes. For = instance, some TCPM documents don't affect the header at all, and thus give= middleboxes few opportunities to mess up stuff...=20 > If the WG believes that such a document could be useful, we=20 > could contribute based on the lessons learned from Multipath TCP. The core question would be whether TCPM is actually the right place for tha= t, given that TCPM focuses on the endpoints. But a document that describes = the currently known issues and its impact on endpoints could be interesting= . A lot of that would be independent of MPTCP. Michael (chair hat off) = From touch@isi.edu Fri Apr 19 08:20: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 DB0DF21F940B for ; Fri, 19 Apr 2013 08:20:30 -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 MR7J7An2N2za for ; Fri, 19 Apr 2013 08:20:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 61C6721F8E96 for ; Fri, 19 Apr 2013 08:20: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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r3JFJQmk007428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Apr 2013 08:19:35 -0700 (PDT) Message-ID: <5171607E.8080900@isi.edu> Date: Fri, 19 Apr 2013 08:19:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51702F40.9090105@isi.edu> <14318_1366363624_51710DE8_14318_71_1_2A886F9088894347A3BE0CC5B7A85F3E9AB12A7150@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <89EC3D7D-EDE5-4374-8903-17DB8DB906CA@iki.fi> <2A886F9088894347A3BE0CC5B7A85F3E9AB12A71B1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A71B1@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 Security section - Middleboxes 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, 19 Apr 2013 15:20:31 -0000 On 4/19/2013 7:49 AM, Scharf, Michael (Michael) wrote: >>> But the phrasing "A middlebox may remove..." is certainly >> problematic. IMHO, we should clearly state that middleboxes >> MUST NOT remove RFC 1313 options, and we should specifically >> document the issues of removing options in to explain why. >> >> Isn't there any dedicated RFC on middlebox requirements for >> TCP saying that middleboxes MUST NOT touch any TCP option? My >> feeling is that we shouldn't give normative middlebox >> requirements in this document. The midbox developers are >> unlikely to find them here in any case. > > Yes, I agree that normative statements on middleboxes are probably not in-scope of TCPM. My e-mail was probably written a bit too fast... I disagree; normative statements about TCP are precisely our scope. I agree that a general statement about middlebox behavior is out of scope for this doc, but I felt the current proposal - which focused on these options - was reasonable and appropriate, and definitely in scope both for this WG and this doc. Joe > >> But as said, it doesn't hurt to describe the known problems. > > That is my main point as well. > > Michael > From touch@isi.edu Fri Apr 19 08:26: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 3750E21F95EF for ; Fri, 19 Apr 2013 08:26: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=[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 FyW1-OnF4TIC for ; Fri, 19 Apr 2013 08:26:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AB60021F95E9 for ; Fri, 19 Apr 2013 08:26:38 -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 r3JFPtUd008878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Apr 2013 08:26:04 -0700 (PDT) Message-ID: <51716203.2030109@isi.edu> Date: Fri, 19 Apr 2013 08:25:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: David Borman References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.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 \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 15:26:39 -0000 This text is fine too, but IMO the only "NOT"s have to be "MUST NOT". SHOULD NOT should only ever be used when there is a known specific reason for an exception, and when that exception is given. Using that term in this context is saying it's OK for middleboxes to remove options, and I don't think this WG should EVER say that. So... On 4/19/2013 7:54 AM, David Borman wrote: ... > Here's my proposal for rewriting the middlebox section: > > > Middle boxes and TCP options: > > Some middle boxes have been known to remove the TCP options > described in this document from the segment. Middle boxes > should not remove TCP options from segments, and must MUST NOT... and MUST NOT > not remove TCP options from segments. Examples of > issues that can arise when middle boxes remove these TCP options > include: > > o If a Window Scale option is removed from a segment, > the end hosts will not negotiate the window scaling factor correctly. > Middle boxes must not remove the Window Scale option from > segments. > > o If a stateful firewall uses the window field to detect whether > a received segment is inside the current window, and does not > support the Window Scale option, it will not be able to correctly > determine whether or not a packet is in the window. These > middle boxes must also support the Window Scale option and apply > that scaling when processing segments. If the window scale cannot > be determined, it must not do window based processing. > > o If the Timestamp option is removed from the segment, high > speed connections that need PAWS would not have that protection. > Middle boxes should not remove the Timestamp option. > > Implementations that depend on PAWS could provide a mechanism for > the application to determine whether or not PAWS is in use on > the connection, and choose to terminate the connection if that > protection doesn't exist. This is not just to protect the connection > against middle boxes that might remove the Timestamp option, but > also against remote hosts that do not have Timestamp support. > > > Rewriting it this way puts up front that middle boxes should not must not, IMO. > be mucking with TCP options, and support for this position is > provided by the examples that point out ways that things can break > when middle boxes do muck with TCP options. > > -David Borman > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From cabo@tzi.org Fri Apr 19 09:46: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 32F5F21F9590 for ; Fri, 19 Apr 2013 09:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tjnRzURU0Gni for ; Fri, 19 Apr 2013 09:45:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8121F955E for ; Fri, 19 Apr 2013 09:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3JGjuYK002138; Fri, 19 Apr 2013 18:45:56 +0200 (CEST) Received: from [192.168.217.105] (p548909B4.dip0.t-ipconnect.de [84.137.9.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A3D2F37A7; Fri, 19 Apr 2013 18:45:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51716203.2030109@isi.edu> Date: Fri, 19 Apr 2013 18:45:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.org> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51716203.2030109@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: David Borman , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 16:46:00 -0000 On Apr 19, 2013, at 17:25, Joe Touch wrote: > MUST NOT... and MUST NOT Yeah, we really need a 6919bis with "MUST NOT (BUT WE KNOW YOU WILL)". On the other hand, for now a "REALLY SHOULD NOT" is probably close = enough. Gr=FC=DFe, Carsten From touch@isi.edu Fri Apr 19 09:51:32 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 A94F921F95B4 for ; Fri, 19 Apr 2013 09:51:30 -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 VcxK3Wv9ldWO for ; Fri, 19 Apr 2013 09:51:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D2D9D21F960A for ; Fri, 19 Apr 2013 09:51:24 -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 r3JGnqg0023699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Apr 2013 09:50:01 -0700 (PDT) Message-ID: <517175B0.4090002@isi.edu> Date: Fri, 19 Apr 2013 09:49:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carsten Bormann References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51716203.2030109@isi.edu> <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.org> In-Reply-To: <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.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: David Borman , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 16:51:33 -0000 On 4/19/2013 9:45 AM, Carsten Bormann wrote: > On Apr 19, 2013, at 17:25, Joe Touch wrote: > >> MUST NOT... and MUST NOT > > Yeah, we really need a 6919bis with "MUST NOT (BUT WE KNOW YOU WILL)". > On the other hand, for now a "REALLY SHOULD NOT" is probably close enough. Are you arguing for SHOULD NOT or MUST NOT in that case? IMO, MUST NOT already accounts for those who don't. Things break or do things that are not intended, and we don't understand the ways in which it might be safe to do otherwise. Short of a longer discussion on all the combination of alternatives, IMO we should stay with the "party line" of MUST NOT on these. Joe From cabo@tzi.org Fri Apr 19 10:01: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 9F5BD21F95F4 for ; Fri, 19 Apr 2013 10:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 KDyN4TV6Z53I for ; Fri, 19 Apr 2013 10:01:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 556BD21F944A for ; Fri, 19 Apr 2013 10:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3JH1js4028990; Fri, 19 Apr 2013 19:01:45 +0200 (CEST) Received: from [192.168.217.105] (p548909B4.dip0.t-ipconnect.de [84.137.9.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40B4137B0; Fri, 19 Apr 2013 19:01:45 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <517175B0.4090002@isi.edu> Date: Fri, 19 Apr 2013 19:01:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <273D1100-BDE3-4D39-82DA-0769141E3610@tzi.org> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51716203.2030109@isi.edu> <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.org> <517175B0.4090002@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: David Borman , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 17:01:50 -0000 On Apr 19, 2013, at 18:49, Joe Touch wrote: > Are you arguing for SHOULD NOT or MUST NOT in that case? No, I'm arguing for not using any RFC 2119 language in the security = considerations. The security considerations should document what the security = considerations of a protocol are. If there are RFC 2119 level requirements, they should be in the = definition of the protocol. Gr=FC=DFe, Carsten From touch@isi.edu Fri Apr 19 10:41: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 26BEA21F93B4 for ; Fri, 19 Apr 2013 10:41:31 -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 rxw8XHTaepJO for ; Fri, 19 Apr 2013 10:41:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF821F93AA for ; Fri, 19 Apr 2013 10:41:29 -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 r3JHf3RY004083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Apr 2013 10:41:08 -0700 (PDT) Message-ID: <517181A9.9070509@isi.edu> Date: Fri, 19 Apr 2013 10:40:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carsten Bormann References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51716203.2030109@isi.edu> <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.org> <517175B0.4090002@isi.edu> <273D1100-BDE3-4D39-82DA-0769141E3610@tzi.org> In-Reply-To: <273D1100-BDE3-4D39-82DA-0769141E3610@tzi.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: David Borman , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 17:41:31 -0000 On 4/19/2013 10:01 AM, Carsten Bormann wrote: > On Apr 19, 2013, at 18:49, Joe Touch wrote: > >> Are you arguing for SHOULD NOT or MUST NOT in that case? > > No, I'm arguing for not using any RFC 2119 language in the security considerations. > The security considerations should document what the security considerations of a protocol are. > If there are RFC 2119 level requirements, they should be in the definition of the protocol. Oh - I'm not sure I agree. 2119-words seem appropriate in security considerations when they are specific to security. That's not the case for this doc; this isn't a "security" issue. IMO, that language is important, but I agree it's probably better placed elsewhere in this doc. Joe From rs@netapp.com Fri Apr 19 11:23: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 637C221F9075 for ; Fri, 19 Apr 2013 11:23:23 -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 6Ldm1rcDtVmf for ; Fri, 19 Apr 2013 11:23:22 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2B21F8D6A for ; Fri, 19 Apr 2013 11:23:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,510,1363158000"; d="scan'208";a="42479393" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 19 Apr 2013 11:23:22 -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 r3JINME9000694; Fri, 19 Apr 2013 11:23:22 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.247]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0342.003; Fri, 19 Apr 2013 11:23:22 -0700 From: "Scheffenegger, Richard" To: Joe Touch , Carsten Bormann Thread-Topic: [tcpm] 1323bis Security section - Middleboxes Thread-Index: Ac48G2KPmHYZqaHlTbKYcEypCQULxgBLQhMAAAEcKoAAAssbAAAAI3cAAABqGQAAAV6ggAANPtrg Date: Fri, 19 Apr 2013 18:23:21 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B2F173@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51716203.2030109@isi.edu> <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.org> <517175B0.4090002@isi.edu> <273D1100-BDE3-4D39-82DA-0769141E3610@tzi.org> <517181A9.9070509@isi.edu> In-Reply-To: <517181A9.9070509@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Borman , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 18:23:23 -0000 How about moving the relevant sections of text forward to the normative tex= t about window scale / timestamps, as an additional section (e.g. "2.5. Mid= dlebox considerations for the Window Scale Option"; "3.5 Middlebox consider= ations for the Timestamp Option") Would that work to have normative text with MUST NOTs? Regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Freitag, 19. April 2013 19:41 > To: Carsten Bormann > Cc: David Borman; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] 1323bis Security section - Middleboxes >=20 >=20 >=20 > On 4/19/2013 10:01 AM, Carsten Bormann wrote: > > On Apr 19, 2013, at 18:49, Joe Touch wrote: > > > >> Are you arguing for SHOULD NOT or MUST NOT in that case? > > > > No, I'm arguing for not using any RFC 2119 language in the security > considerations. > > The security considerations should document what the security > considerations of a protocol are. > > If there are RFC 2119 level requirements, they should be in the > definition of the protocol. >=20 > Oh - I'm not sure I agree. 2119-words seem appropriate in security > considerations when they are specific to security. >=20 > That's not the case for this doc; this isn't a "security" issue. IMO, tha= t > language is important, but I agree it's probably better placed elsewhere > in this doc. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From cabo@tzi.org Fri Apr 19 11:56: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 8049E21F9298 for ; Fri, 19 Apr 2013 11:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 7ZWHgnmKwr+6 for ; Fri, 19 Apr 2013 11:56:19 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9B24A21F91BC for ; Fri, 19 Apr 2013 11:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3JIuGlX013570; Fri, 19 Apr 2013 20:56:16 +0200 (CEST) Received: from [192.168.217.105] (p548909B4.dip0.t-ipconnect.de [84.137.9.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E198237EF; Fri, 19 Apr 2013 20:56:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B2F173@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 19 Apr 2013 20:56:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30E05EA0-DB38-4B93-B4A8-4C3378D96896@tzi.org> References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51716203.2030109@isi.edu> <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.org> <517175B0.4090002@isi.edu> <273D1100-BDE3-4D39-82DA-0769141E3610@tzi.org> <517181A9.9070509@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24B2F173@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: David Borman , "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 18:56:19 -0000 Actually, I think there is simply some confusion about the meaning of = some existing text. The current text in draft-ietf-tcpm-1323bis-10.txt is descriptive. It is like "In a storm, a roof tile may fall on your head. In this = case, call a doctor." Changing it into "In a storm, a roof tile MUST NOT fall on your head. = In this case, call a doctor." doesn't accomplish much. But then "In a storm, a roof tile may fall on your head. In this case, = call a doctor." could be read as "In a storm, a roof tile MAY fall on your head. In this case, call a = doctor." which certainly is not the intention. So maybe sticking with the descriptive text, leaving it in the security = considerations (because it is about the damage that is done in the name = of security, hmm), but adding "TCP works best if people won't drop roof tiles on your head" may be the = right thing. Gr=FC=DFe, Carsten From touch@isi.edu Fri Apr 19 13:15: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 79DDA21F8FC4 for ; Fri, 19 Apr 2013 13:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 OOXgg9qufRRj for ; Fri, 19 Apr 2013 13:15:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0436521F8AB0 for ; Fri, 19 Apr 2013 13:15:05 -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 r3JKEgpw016732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Apr 2013 13:14:42 -0700 (PDT) Message-ID: <5171A5B5.2080306@isi.edu> Date: Fri, 19 Apr 2013 13:14:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carsten Bormann References: <012C3117EDDB3C4781FD802A8C27DD4F24B28698@SACEXCMBX02-PRD.hq.netapp.com> <51716203.2030109@isi.edu> <53A001B1-C240-4BBC-A618-56D970DB4049@tzi.org> <517175B0.4090002@isi.edu> <273D1100-BDE3-4D39-82DA-0769141E3610@tzi.org> <517181A9.9070509@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24B2F173@SACEXCMBX02-PRD.hq.netapp.com> <30E05EA0-DB38-4B93-B4A8-4C3378D96896@tzi.org> In-Reply-To: <30E05EA0-DB38-4B93-B4A8-4C3378D96896@tzi.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: David Borman , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis Security section - Middleboxes 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, 19 Apr 2013 20:15:06 -0000 On 4/19/2013 11:56 AM, Carsten Bormann wrote: > Actually, I think there is simply some confusion about the meaning of some existing text. > > The current text in draft-ietf-tcpm-1323bis-10.txt is descriptive. > It is like "In a storm, a roof tile may fall on your head. In this case, call a doctor." > > Changing it into "In a storm, a roof tile MUST NOT fall on your head. In this case, call a doctor." doesn't accomplish much. > > But then "In a storm, a roof tile may fall on your head. In this case, call a doctor." could be read as > "In a storm, a roof tile MAY fall on your head. In this case, call a doctor." which certainly is not the intention. > > So maybe sticking with the descriptive text, leaving it in the security considerations (because it is about the damage that is done in the name of security, hmm), but adding > "TCP works best if people won't drop roof tiles on your head" may be the right thing. Omitting the requirement seems fine - there's nothing about these options that specific to midboxes, so it does seem unnecessary to make specific recommendations about these options and midboxes *either way*. Joe From internet-drafts@ietf.org Mon Apr 22 03:22: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 8594511E80A2; Mon, 22 Apr 2013 03:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, 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 8nPC32dTvHlt; Mon, 22 Apr 2013 03:22:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CACC021F8BC7; Mon, 22 Apr 2013 03:22:00 -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.44.p3 Message-ID: <20130422102200.15478.55429.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 03:22:00 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-11.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, 22 Apr 2013 10:22:01 -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-11.txt Pages : 44 Date : 2013-04-22 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Mon Apr 22 03:24: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 01D9A21F84CD; Mon, 22 Apr 2013 03:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.985 X-Spam-Level: X-Spam-Status: No, score=-9.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 0bYk33mpszfI; Mon, 22 Apr 2013 03:24:11 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 69FA021F84AD; Mon, 22 Apr 2013 03:24:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,525,1363158000"; d="scan'208";a="43371880" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 22 Apr 2013 03:24:11 -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 r3MAOBCG012636; Mon, 22 Apr 2013 03:24:11 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.247]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0342.003; Mon, 22 Apr 2013 03:24:10 -0700 From: "Scheffenegger, Richard" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-11.txt Thread-Index: AQHOP0M+5bKhUR+WI0qqQhAt7KXvZJjiCGUA Date: Mon, 22 Apr 2013 10:24:10 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B32D1A@SACEXCMBX02-PRD.hq.netapp.com> References: <20130422102200.15478.55429.idtracker@ietfa.amsl.com> In-Reply-To: <20130422102200.15478.55429.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.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] I-D Action: draft-ietf-tcpm-1323bis-11.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, 22 Apr 2013 10:24:12 -0000 This is the version with the updated descriptive text in section 6, using t= he text provided by David. All RFC2119 wording was removed, and slight editorial edits (formatting, re= ordering of paragraphs) in that section were made. Any final comments? Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Montag, 22. April 2013 12:22 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-11.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 : TCP Extensions for High Performance > Author(s) : David Borman > Bob Braden > Van Jacobson > Richard Scheffenegger > Filename : draft-ietf-tcpm-1323bis-11.txt > Pages : 44 > Date : 2013-04-22 >=20 > 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). >=20 > This document updates and obsoletes RFC 1323. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-11 >=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 hammondjohnson@hushmail.com Sat Apr 27 15:48: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 707A921F8ADC for ; Sat, 27 Apr 2013 15:48:28 -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 FLOrSJPdk5ZJ for ; Sat, 27 Apr 2013 15:48:28 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 955B221F8899 for ; Sat, 27 Apr 2013 15:48:22 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id E23EC307A2 for ; Sat, 27 Apr 2013 17:51:33 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:51:33 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A3F41E6736; Sat, 27 Apr 2013 17:51:33 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:51:32 -0400 To: tcpm@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175133.A3F41E6736@smtp.hushmail.com> Subject: [tcpm] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 22:48:28 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From pasi.sarolahti@iki.fi Mon Apr 29 02:05: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 A1CDB21F9D14 for ; Mon, 29 Apr 2013 02:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 i3guv99EYUNY for ; Mon, 29 Apr 2013 02:05:23 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 76BC921F9D13 for ; Mon, 29 Apr 2013 02:05:23 -0700 (PDT) Received: from pc120.tct.hut.fi (130.233.154.120) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F2012AF86D for tcpm@ietf.org; Mon, 29 Apr 2013 12:05:22 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 29 Apr 2013 12:05:36 +0300 To: "tcpm (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [tcpm] WGLC for 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, 29 Apr 2013 09:05:24 -0000 Hi, WG chairs believe that the earlier outstanding issues have been = addressed in the latest version of 1323bis, and the document starts to = be ready to be submitted for publication. Therefore, this mail starts a = working group last call for draft-ietf-tcpm-1323bis-11 ("TCP Extensions = for High Performance"). The WG last call runs for two weeks, until Monday, May 13th. Please send = any comments on the mailing list by then. Also notifications of = approving the current version (even without other comments) are helpful. The draft is available at = http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-11 Thanks! - Pasi From wwwrun@rfc-editor.org Mon Apr 29 11:51: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 AAF4F21F8529; Mon, 29 Apr 2013 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 tGjibCXXQ77m; Mon, 29 Apr 2013 11:51:45 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BA74421F9804; Mon, 29 Apr 2013 11:51:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4D80CB1E015; Mon, 29 Apr 2013 11:50:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130429185059.4D80CB1E015@rfc-editor.org> Date: Mon, 29 Apr 2013 11:50:59 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6928 on Increasing TCP's Initial Window 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, 29 Apr 2013 18:51:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6928 Title: Increasing TCP's Initial Window Author: J. Chu, N. Dukkipati, Y. Cheng, M. Mathis Status: Experimental Stream: IETF Date: April 2013 Mailbox: hkchu@google.com, nanditad@google.com, ycheng@google.com, mattmathis@google.com Pages: 24 Characters: 56523 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-initcwnd-08.txt URL: http://www.rfc-editor.org/rfc/rfc6928.txt This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC