From nobody Wed Mar 4 04:57:10 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF681A03C7; Wed, 4 Mar 2015 04:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlTTjSgcnyXI; Wed, 4 Mar 2015 04:57:07 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id E3AB11A0390; Wed, 4 Mar 2015 04:57:06 -0800 (PST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id F32301A0032; Wed, 4 Mar 2015 13:57:05 +0100 (CET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 4 Mar 2015 13:57:05 +0100 To: aqm@ietf.org, tcpm IETF list , tsvwg WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [tcpm] A new(ish) study on ECN in the Internet X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 12:57:09 -0000 Greetings, all, We'll be publishing an active measurement study on ECN negotiability and = connectivity risk at PAM 2015, just before the IETF; the author copy of = the paper is at=20 http://ecn.ethz.ch/ecn-pam15.pdf.=20 The key findings are: (1) More than half of the Alexa top million web servers (600k accounting = for duplicate IPs) will happily negotiate and mark ECT0 if you ask = nicely (at least as of September 2014). This mainly reflects people = upgrading Linux servers to kernels where tcp_ecn=3D2 is the default, and = strongly validates changing default configurations as a method for = increasing ECN deployment. (2) 0.42% of these webservers will fail to connect if you try to = negotiate ECN, but simple ECN fallback as in RFC 3168 (retransmitted SYN = ECE CWR sent as SYN) commutes this to a risk of slightly increased = handshake latency. (3) A vanishingly small number (15 / ~600k) of these have *different* = ECN connectivity dependency depending on where you connect from, = indicating that the box breaking ECN is not directly adjacent to the = server. A third of these (6) are GoDaddy parking sites. (4) There is more mangling of the ECN IP header bits than connectivity = dependency, and successful negotiation does not always mean successful = marking. About 2% of IPv4 servers and 15% (!!!) of IPv6 servers signal = in other than expected ways, indicating that negotiated ECN might not be = useful. (5) We appear to have seen two (count 'em, two!) CE markings in the = wild, both from the same webserver (www.grandlyon.com) when probing 600k = IP addresses 3 times from 3 different locations (i.e., 2 out of 5.6 = million flows). This is neither encouraging nor surprising. Bottom line, the risk to connectivity of turning ECN on by default in = clients is vanishingly low, though not yet in the one in ten million = range, when simple fallback as in RFC3168 is implemented. Modern Windows = and Mac OS X do this; Linux doesn't yet, though we have a three line = patch (which, anecdotally, I've been running without incident on my = desktop for the past half year).=20 Given the signaling anomalies, especially on IPv6, defining simple = methods to detect and dynamically ignore anomalous signaling at the = endpoints is probably the next area of work to getting ECN deployable. = There *is* some path dependency of ECN brokenness, but not enough to = make it worth it to continue working on the approach in the expired = draft-kuehlewind-tcpm-ecn-fallback until we have a solution for the = general ECN IP signaling anomalies. I was hoping to get continuous measurements based on a new version of = the measurement and analysis scripts up and running before the IETF, but = this has fallen to task queue triage. We also have a student working on = doing this for things other than the web; all of this is in my queue for = mid-May at this point, so watch this space. Cheers, Brian and Mirja= From nobody Fri Mar 6 08:00:53 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B301A004D; Fri, 6 Mar 2015 08:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKgnxkm6IU5w; Fri, 6 Mar 2015 08:00:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBFC1A006B; Fri, 6 Mar 2015 08:00:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306160043.1251.27894.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 08:00:43 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 16:00:50 -0000 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 : Updating TCP to support Rate-Limited Traffic Authors : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-09.txt Pages : 23 Date : 2015-03-06 Abstract: This document provides a mechanism to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 6 10:33:19 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5AA1A1BA7 for ; Fri, 6 Mar 2015 10:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4zVvUkubOpv for ; Fri, 6 Mar 2015 10:33:16 -0800 (PST) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E4E1A1B72 for ; Fri, 6 Mar 2015 10:33:16 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id t26IXCLY003812; Fri, 6 Mar 2015 12:33:12 -0600 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: David Borman In-Reply-To: <655C07320163294895BBADA28372AF5D16C24E57@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 6 Mar 2015 12:33:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <655C07320163294895BBADA28372AF5D16C24E57@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] TCPM agenda for IETF 92 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:33:18 -0000 > On Feb 23, 2015, at 3:49 AM, Scharf, Michael (Michael) = wrote: >=20 > Folks, >=20 > According to the preliminary agenda = (https://datatracker.ietf.org/meeting/92/agenda.html), TCPM will = probably have the following slot during the Dallas meeting: >=20 > Date: TUESDAY, March 24, 2015, 0900-1130 (Morning Session I) > Room: Oak >=20 > If you are interested in presenting a draft in TCPM, please provide to = the chairs the following information: >=20 > * Title / draft name draft-borman-tcpm-tcp4way-01.txt - This update will be posted this weekend. > * Presenter's name David Borman > * Planned duration 30 min? I=E2=80=99m not sure, but at least 15 min. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Mar 9 05:30:00 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579B51A88A3; Mon, 9 Mar 2015 05:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B87vDJe0r7XR; Mon, 9 Mar 2015 05:29:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D580B1A889F; Mon, 9 Mar 2015 05:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309122939.12972.25241.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 05:29:39 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:29:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP and SCTP RTO Restart Authors : Per Hurtig Anna Brunstrom Andreas Petlund Michael Welzl Filename : draft-ietf-tcpm-rtorestart-05.txt Pages : 14 Date : 2015-03-09 Abstract: This document describes a modified algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 10:15:13 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A560F1A90AB; Mon, 9 Mar 2015 10:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhlCjxLQOS4N; Mon, 9 Mar 2015 10:15:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E041A90BA; Mon, 9 Mar 2015 10:15:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309171500.27001.92442.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 10:15:00 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:15:12 -0000 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 : Problem Statement and Requirements for a More Accurate ECN Feedback Authors : Mirja Kuehlewind Richard Scheffenegger Bob Briscoe Filename : draft-ietf-tcpm-accecn-reqs-08.txt Pages : 16 Date : 2015-03-09 Abstract: Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like ConEx or DCTCP) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accecn-reqs-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 11:20:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7241A9173 for ; Mon, 9 Mar 2015 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GUFQtJi-LeL for ; Mon, 9 Mar 2015 11:20:13 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225D71A9165 for ; Mon, 9 Mar 2015 11:19:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A654A242F9EA; Mon, 9 Mar 2015 18:19:52 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t29IJukK021411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 19:19:56 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 19:19:56 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: Draft agenda for IETF 92 Thread-Index: AdBalaSPZCuAUWOBTpW5AOUv9QFy2w== Date: Mon, 9 Mar 2015 18:19:55 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C511BC@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Draft agenda for IETF 92 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:20:22 -0000 Hi all, I've uploaded a first draft of the TCPM agenda for Dallas, based on the req= uests we have received so far: https://datatracker.ietf.org/meeting/92/agenda/tcpm/ This is an initial draft only, and changes are possible. As of now, we prob= ably have some time left. If you have any suggestions or comments, please let the chairs know.=20 Best regards Michael From nobody Tue Mar 10 10:32:02 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029071A6FCB for ; Tue, 10 Mar 2015 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGtkphD-g5pN for ; Tue, 10 Mar 2015 10:31:59 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7B21A00F5 for ; Tue, 10 Mar 2015 10:31:58 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CE3062780B1 for ; Wed, 11 Mar 2015 02:31:56 +0900 (JST) Received: by wiwl15 with SMTP id l15so5015938wiw.0 for ; Tue, 10 Mar 2015 10:31:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.121.136 with SMTP id lk8mr67405490wjb.49.1426008714457; Tue, 10 Mar 2015 10:31:54 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Tue, 10 Mar 2015 10:31:54 -0700 (PDT) Date: Tue, 10 Mar 2015 10:31:54 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e01227f42df3a590510f2862e Archived-At: Subject: [tcpm] WGLC for draft-ietf-tcpm-newcwv-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:32:01 -0000 --089e01227f42df3a590510f2862e Content-Type: text/plain; charset=UTF-8 Hello folks, This is an announcement that we initiate a WGLC on draft-ietf-tcpm-newcwv-09. This WGLC will continue two weeks and ends March 25th. As we will have a slot for this draft at Dallas meeting, you can provide comments or ask questions on-site before the end of the WGLC. Please check the following URL to get more detailed info about the draft. https://tools.ietf.org/html/draft-ietf-tcpm-newcwv-09 We will appreciate your feedback. Regards, -- Yoshi on behalf of tcpm co-chairs --089e01227f42df3a590510f2862e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello folks,

This is an announ= cement that we initiate a WGLC on draft-ietf-tcpm-newcwv-09.
This= WGLC will continue two weeks and ends March 25th. =C2=A0
As we w= ill have a slot for this draft at Dallas meeting, you can provide comments = or ask questions on-site before the end of the WGLC.

Please check the following URL to get more detailed info about the draft= .

Regards,
--
Yoshi on behalf of tcpm co-chairs
--089e01227f42df3a590510f2862e-- From nobody Tue Mar 10 23:34:56 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECBB1A1ABE for ; Tue, 10 Mar 2015 23:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5nQFzJKzrMa for ; Tue, 10 Mar 2015 23:34:52 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17B51A1AD9 for ; Tue, 10 Mar 2015 23:34:52 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B6A0427810E for ; Wed, 11 Mar 2015 15:34:50 +0900 (JST) Received: by wghl18 with SMTP id l18so6855587wgh.5 for ; Tue, 10 Mar 2015 23:34:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.222.197 with SMTP id qo5mr73540530wjc.142.1426055688605; Tue, 10 Mar 2015 23:34:48 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Tue, 10 Mar 2015 23:34:48 -0700 (PDT) Date: Tue, 10 Mar 2015 23:34:48 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3a99abfd6690510fd7656 Archived-At: Cc: panda@wide.ad.jp Subject: [tcpm] increasing max window size of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 06:34:54 -0000 --001a11c3a99abfd6690510fd7656 Content-Type: text/plain; charset=UTF-8 Hi, We have submitted a short draft which proposes to increase max window size of TCP. If you're interested, please take a look at the following info. Some may say this is a minor thing, but we still believe we need to consider this for future extensions of TCP. We will appreciate your feedback! -- Yoshi & Hiro ------------------------------------------------------------------------- From: Date: Mon, Mar 9, 2015 at 1:09 PM Subject: I-D Action: draft-nishida-tcpm-maxwin-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Increasing Maximum Window Size of TCP Authors : Yoshifumi Nishida Hirochika Asai Filename : draft-nishida-tcpm-maxwin-00.txt Pages : 6 Date : 2015-03-09 Abstract: This document proposes to increase the current max window size allowed in TCP. It describes the current logic that limits the max window size and provides a rationale to relax the limitation as well as the negotiation mechanism to enable this feature safely. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nishida-tcpm-maxwin/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-nishida-tcpm-maxwin-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c3a99abfd6690510fd7656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We have submi= tted a short draft which proposes to increase max window size of TCP.
=
If you're interested, please take a look at the following info.
Some may say this is a minor thing, but we still believe we n= eed to consider this for future extensions of TCP.

We will appreciate your feedback!
--
Yoshi & Hiro<= /div>



-------------------------= ------------------------------------------------
From: <internet-drafts@ietf= .org>
Date: Mon, Mar 9, 2015 at 1:09 PM
Subject: I-D Ac= tion: draft-nishida-tcpm-maxwin-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Increasing Maximum Window Size of TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hirochika Asai
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-maxwin-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-09

Abstract:
=C2=A0 =C2=A0This document proposes to increase the current max window size=
=C2=A0 =C2=A0allowed in TCP.=C2=A0 It describes the current logic that limi= ts the max
=C2=A0 =C2=A0window size and provides a rationale to relax the limitation a= s well
=C2=A0 =C2=A0as the negotiation mechanism to enable this feature safely.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-maxwin/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-nishida-tcpm-maxwin-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c3a99abfd6690510fd7656-- From nobody Wed Mar 11 06:46:45 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A501A010C; Wed, 11 Mar 2015 06:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKkWn6xvGUqU; Wed, 11 Mar 2015 06:46:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CD31AC43A; Wed, 11 Mar 2015 06:46:39 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id F0379A8F13AD7; Wed, 11 Mar 2015 13:46:34 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2BDkZ7Q003147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 14:46:37 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 11 Mar 2015 14:46:37 +0100 From: "Scharf, Michael (Michael)" To: "tcpinc@ietf.org" Thread-Topic: Feedback on EDO? Thread-Index: AdBcAcphoSG3+U2QQLmutmh6AepctQ== Date: Wed, 11 Mar 2015 13:46:36 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 13:46:42 -0000 Hi, TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming = meeting [1]. At this stage, TCPM is really interested in feedback from impl= ementers and potential users, e.g., regarding feature gaps or deployment pr= oblems. In a previous discussion, TCPINC was identified as one potential user of ED= O [2]. I understand that the TCPINC design is still at a early stage. Still= , if there are thoughts on EDO in the TCPINC community, please feel free to= share them on the TCPM list, or please talk us in the next TCPM meeting. Thanks Michael (TCPM co-chair) [1] https://datatracker.ietf.org/meeting/92/agenda/tcpm/ [2] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00429.html From nobody Wed Mar 11 07:38:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23031ACDCF for ; Wed, 11 Mar 2015 07:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwttTzOgKtTi for ; Wed, 11 Mar 2015 07:38:11 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id D545E1ACDDA for ; Wed, 11 Mar 2015 07:38:09 -0700 (PDT) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id C29DE7E839; Thu, 12 Mar 2015 01:38:06 +1100 (EST) Message-ID: <5500531C.1000109@room52.net> Date: Thu, 12 Mar 2015 01:37:16 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/mixed; boundary="------------090509000204080901010707" Archived-At: Cc: Grenville Armitage Subject: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:38:14 -0000 This is a multi-part message in MIME format. --------------090509000204080901010707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [BCCed to freebsd-net@freebsd.org] Hi all, Please consider the code below from FreeBSD 10.1's TCP input processing: /* * In ESTABLISHED state: drop duplicate ACKs; ACK out of range * ACKs. If the ack is in the range * tp->snd_una < th->th_ack <= tp->snd_max * then advance tp->snd_una to th->th_ack and drop * data from the retransmission queue. If this ACK reflects * more up to date window information we update our window information. */ case TCPS_ESTABLISHED: case TCPS_FIN_WAIT_1: case TCPS_FIN_WAIT_2: case TCPS_CLOSE_WAIT: case TCPS_CLOSING: case TCPS_LAST_ACK: if (SEQ_GT(th->th_ack, tp->snd_max)) { TCPSTAT_INC(tcps_rcvacktoomuch); goto dropafterack; } if ((tp->t_flags & TF_SACK_PERMIT) && ((to.to_flags & TOF_SACK) || !TAILQ_EMPTY(&tp->snd_holes))) tcp_sack_doack(tp, &to, th->th_ack); /* Run HHOOK_TCP_ESTABLISHED_IN helper hooks. */ hhook_run_tcp_est_in(tp, th, &to); if (SEQ_LEQ(th->th_ack, tp->snd_una)) { if (tlen == 0 && tiwin == tp->snd_wnd) { TCPSTAT_INC(tcps_rcvdupack); Now for a dupack to be treated as such for the purposes of triggering fast retransmit/fast recovery, the dupack must not update the window as per the "tiwin == tp->snd_wnd" condition above, which has existed since at least BSD 4.4 (I didn't bother looking further back in history). Grenville (CCed) has encountered proof of this condition forcing connections to recover via RTO when legitimate dupacks sent in response to a packet loss also contain a window update. In the example tcpdump excerpt attached, the advertised receive window is growing as the Linux receiver side app reads data from the socket buffer while the dupacks are generated. The FreeBSD sender side sees them as window updates and processes them as such, bypassing the dupack processing code. The send window is consumed and because only dup acks are returning, UNA is not advanced and so the connection stalls, requiring two RTOs to recover from the 2 dropped packets. With SACK in the mix as is the case for the provided example, it seems obvious to me that the existence of SACK blocks could and should be used to realise that a window update combined with a dupack is not a pure window update and therefore should be processed by the dupack handling code for fast retransmit/fast recovery purposes. For connections without SACK, is there any existing guidance on how to deal with this? My Google fu and skimming of the RFCs that seemed relevant to this matter turned up nothing, and so I'm imagining a potential algorithm for inferring if a window update can count as a dupack for fast retransmit/fast recovery purposes or not. Wanted to get some input from others before spending any more time on it though. Cheers, Lawrence --------------090509000204080901010707 Content-Type: text/plain; charset=us-ascii; name="dupackwndupdate.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dupackwndupdate.txt" MDA6MDA6MDAuMDAwMjQxIElQIDE3Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4xNi4xMS42My44 MjogRmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gNzczNCwgb3B0aW9ucyBbbm9wLG5vcCxU UyB2YWwgMjY0ODYxOTEgZWNyIDQxODMxOTQyNzhdLCBsZW5ndGggMAowMDowMDowMC4wMDAy MTYgSVAgMTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0s IGFjayAxMDg4MzQsIHdpbiA3ODI0LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjE5 MSBlY3IgNDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMSB7MTEwMjgyOjExMTczMH1dLCBsZW5n dGggMAowMDowMDowMC4wMDgwMjUgSVAgMTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjEx LjYzLjgyOiBGbGFncyBbLl0sIGFjayAxMDg4MzQsIHdpbiA3OTE1LCBvcHRpb25zIFtub3As bm9wLFRTIHZhbCAyNjQ4NjE5OSBlY3IgNDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMiB7MTEz MTc4OjExNDYyNn1bfHRjcF0+CjAwOjAwOjAwLjAwMDIzMyBJUCAxNzIuMTYuMTAuNjAuNTE2 NzcgPiAxNzIuMTYuMTEuNjMuODI6IEZsYWdzIFsuXSwgYWNrIDEwODgzNCwgd2luIDgwMDUs IG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI2NDg2MjAwIGVjciA0MTgzMTk0Mjc4LG5vcCxu b3Asc2FjayAyIHsxMTMxNzg6MTE2MDc0fVt8dGNwXT4KMDA6MDA6MDAuMDAwMjQ4IElQIDE3 Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4xNi4xMS42My44MjogRmxhZ3MgWy5dLCBhY2sgMTA4 ODM0LCB3aW4gODA5Niwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjY0ODYyMDAgZWNyIDQx ODMxOTQyNzgsbm9wLG5vcCxzYWNrIDIgezExMzE3ODoxMTc1MjJ9W3x0Y3BdPgowMDowMDow MC4wMDAyMTcgSVAgMTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFn cyBbLl0sIGFjayAxMDg4MzQsIHdpbiA4MTg2LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAy NjQ4NjIwMCBlY3IgNDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMiB7MTEzMTc4OjExODk3MH1b fHRjcF0+CjAwOjAwOjAwLjAwMDI2OSBJUCAxNzIuMTYuMTAuNjAuNTE2NzcgPiAxNzIuMTYu MTEuNjMuODI6IEZsYWdzIFsuXSwgYWNrIDEwODgzNCwgd2luIDgyNzcsIG9wdGlvbnMgW25v cCxub3AsVFMgdmFsIDI2NDg2MjAwIGVjciA0MTgzMTk0Mjc4LG5vcCxub3Asc2FjayAyIHsx MTMxNzg6MTIwNDE4fVt8dGNwXT4KMDA6MDA6MDAuMDAwMjQyIElQIDE3Mi4xNi4xMC42MC41 MTY3NyA+IDE3Mi4xNi4xMS42My44MjogRmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gODM2 Nywgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjY0ODYyMDEgZWNyIDQxODMxOTQyNzgsbm9w LG5vcCxzYWNrIDIgezExMzE3ODoxMjE4NjZ9W3x0Y3BdPgowMDowMDowMC4wMDAyNTAgSVAg MTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0sIGFjayAx MDg4MzQsIHdpbiA4NDU4LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjIwMSBlY3Ig NDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMiB7MTEzMTc4OjEyMzMxNH1bfHRjcF0+CjAwOjAw OjAwLjAwMDIwOSBJUCAxNzIuMTYuMTAuNjAuNTE2NzcgPiAxNzIuMTYuMTEuNjMuODI6IEZs YWdzIFsuXSwgYWNrIDEwODgzNCwgd2luIDg1NDgsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFs IDI2NDg2MjAxIGVjciA0MTgzMTk0Mjc4LG5vcCxub3Asc2FjayAyIHsxMTMxNzg6MTI0NzYy fVt8dGNwXT4KMDA6MDA6MDAuMDAwMjYzIElQIDE3Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4x Ni4xMS42My44MjogRmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gODYzOSwgb3B0aW9ucyBb bm9wLG5vcCxUUyB2YWwgMjY0ODYyMDEgZWNyIDQxODMxOTQyNzgsbm9wLG5vcCxzYWNrIDIg ezExMzE3ODoxMjYyMTB9W3x0Y3BdPgowMDowMDowMC4wMDAyNDQgSVAgMTcyLjE2LjEwLjYw LjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0sIGFjayAxMDg4MzQsIHdpbiA4 NzI5LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjIwMiBlY3IgNDE4MzE5NDI3OCxu b3Asbm9wLHNhY2sgMiB7MTEzMTc4OjEyNzY1OH1bfHRjcF0+CjAwOjAwOjAwLjAwMDI0MyBJ UCAxNzIuMTYuMTAuNjAuNTE2NzcgPiAxNzIuMTYuMTEuNjMuODI6IEZsYWdzIFsuXSwgYWNr IDEwODgzNCwgd2luIDg4MjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI2NDg2MjAyIGVj ciA0MTgzMTk0Mjc4LG5vcCxub3Asc2FjayAyIHsxMTMxNzg6MTI5MTA2fVt8dGNwXT4KMDA6 MDA6MDAuMDAwMjE4IElQIDE3Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4xNi4xMS42My44Mjog RmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gODkxMCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2 YWwgMjY0ODYyMDIgZWNyIDQxODMxOTQyNzgsbm9wLG5vcCxzYWNrIDIgezExMzE3ODoxMzA1 NTR9W3x0Y3BdPgowMDowMDowMC4yODI3NjkgSVAgMTcyLjE2LjExLjYzLjgyID4gMTcyLjE2 LjEwLjYwLjUxNjc3OiBGbGFncyBbLl0sIHNlcSAxMDg4MzQ6MTEwMjgyLCBhY2sgMTAwLCB3 aW4gMTA0MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgNDE4MzE5NDYzMiBlY3IgMjY0ODYy MDJdLCBsZW5ndGggMTQ0OAowMDowMDowMC4wMDIyODQgSVAgMTcyLjE2LjEwLjYwLjUxNjc3 ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0sIGFjayAxMTE3MzAsIHdpbiA5MDAxLCBv cHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjQ4NyBlY3IgNDE4MzE5NDYzMixub3Asbm9w LHNhY2sgMSB7MTEzMTc4OjEzMDU1NH1dLCBsZW5ndGggMAowMDowMDowMC4zMzE0MjggSVAg MTcyLjE2LjExLjYzLjgyID4gMTcyLjE2LjEwLjYwLjUxNjc3OiBGbGFncyBbLl0sIHNlcSAx MTE3MzA6MTEzMTc4LCBhY2sgMTAwLCB3aW4gMTA0MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2 YWwgNDE4MzE5NDk2NiBlY3IgMjY0ODY0ODddLCBsZW5ndGggMTQ0OAo= --------------090509000204080901010707-- From nobody Wed Mar 11 07:48:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961061ACDB6 for ; Wed, 11 Mar 2015 07:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKuI5eulxDt6 for ; Wed, 11 Mar 2015 07:48:40 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3891ACCE1 for ; Wed, 11 Mar 2015 07:48:40 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t2BEmc3G024882; Wed, 11 Mar 2015 07:48:39 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 364EDB0463F; Wed, 11 Mar 2015 10:48:38 -0400 (EDT) To: Lawrence Stewart From: Mark Allman In-Reply-To: <5500531C.1000109@room52.net> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Born in the USA X-URL-0: http://www.icir.org/mallman-files/Document82609.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma21958-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Mar 2015 10:48:38 -0400 Sender: mallman@icir.org Message-Id: <20150311144838.364EDB0463F@lawyers.icir.org> Archived-At: Cc: tcpm@ietf.org, Grenville Armitage Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:48:41 -0000 ----------ma21958-1 Content-Type: text/plain Content-Disposition: inline > Now for a dupack to be treated as such for the purposes of triggering > fast retransmit/fast recovery, the dupack must not update the window Right, per RFC 5681. > With SACK in the mix as is the case for the provided example, it seems > obvious to me that the existence of SACK blocks could and should be used > to realise that a window update combined with a dupack is not a pure > window update and therefore should be processed by the dupack handling > code for fast retransmit/fast recovery purposes. Right, per RFC 6675. allman ----------ma21958-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUAVcYACgkQWyrrWs4yIs6cfQCcCF4HwZvJyQpq1rACWpRL3Y5N L3YAnjtwfqHy0ai3HsXcUVbu9TiZuAqs =8GGv -----END PGP SIGNATURE----- ----------ma21958-1-- From nobody Wed Mar 11 08:36:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3411A8799 for ; Wed, 11 Mar 2015 08:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK5V4F7ScK16 for ; Wed, 11 Mar 2015 08:36:50 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2421A0040 for ; Wed, 11 Mar 2015 08:36:50 -0700 (PDT) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 937E07E81E; Thu, 12 Mar 2015 02:36:48 +1100 (EST) Message-ID: <550060DE.2070604@room52.net> Date: Thu, 12 Mar 2015 02:35:58 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mallman@icir.org References: <20150311144838.364EDB0463F@lawyers.icir.org> In-Reply-To: <20150311144838.364EDB0463F@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tcpm@ietf.org, Grenville Armitage Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:36:54 -0000 Hi Mark, On 03/12/15 01:48, Mark Allman wrote: > >> Now for a dupack to be treated as such for the purposes of triggering >> fast retransmit/fast recovery, the dupack must not update the window > > Right, per RFC 5681. But does 5681 (and its predecessors) document the implementation, or did this specific bit of the implementation come about from some work? >> With SACK in the mix as is the case for the provided example, it seems >> obvious to me that the existence of SACK blocks could and should be used >> to realise that a window update combined with a dupack is not a pure >> window update and therefore should be processed by the dupack handling >> code for fast retransmit/fast recovery purposes. > > Right, per RFC 6675. Gah, I missed the key bit of text near the end of the definitions section when I skimmed earlier. Thanks for the (re)pointer. Question still remains whether relaxing the 5681 definition that a dupack for fast retransmit/fast recovery purposes can't update the window is something that could/should be considered for non-SACK connections. Does anyone recall any attempts to specify such an algorithm? Is it not worth the effort given the prevalence of SACK? Cheers, Lawrence From nobody Wed Mar 11 09:04:08 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616A31ACD3B for ; Wed, 11 Mar 2015 09:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWlO_ra0DdkD for ; Wed, 11 Mar 2015 09:04:06 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D11C1ACCDC for ; Wed, 11 Mar 2015 09:01:49 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so1647120iec.0 for ; Wed, 11 Mar 2015 09:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=COr0GR/gFyYRiPe+7TX+8YYnb7WYm/r0wQOuWN/iFCw=; b=UQk+GyB3ogJuip7SMxGL2sW1kr/LQ21YFu5k96psEBPEsgvFTGlLdNdckNPK0U4D+V mHsqJTEgZ1JqI9ll9U6wv0vWIin7gvWH1QJ2terpiKFvN9BYUZxoDcyUYkaNrNVa04/n 4Be1sX+FynzEuLlkukoAh/Qhhu7ret+kk13Gz42wTBCu8KXM5P5aV75ntZsKOn1y50rz zMvf84OjRLXblOVU6uKB0lKJQQykisUhiLHAWmWYLlZUmICNxWnnXo+2lWX5u5e87tXW uKozO9kM4C/3uosHzQkgZVf7G9DjjWSjFfiFM01MGp+Z9Jc67cPhlEGdkH5S6Sn/bcyd LeFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=COr0GR/gFyYRiPe+7TX+8YYnb7WYm/r0wQOuWN/iFCw=; b=Ld90yotzXUDpwyk1OJeErNOfQckmn4mqoh+IozYkgeGJad+iQaIWqR0EjSZcXkxSsZ NIoOF9Nv2GhTc/f4VQgOBaEUanRarC8Pc0+b/O74u2zROsJm4OMT4StNMncuaTfd02ND DgmvldlXL++gHmjchgU8qE8QQY0xa/Eg4eXg1HrENubFFzpRVMOD6R83fBDVT0UcMU5i UJnNGIwiMo5kn7xmYMM6jn6k+ewTHwkzwsRPhoW3kbIFnTuYWVycygNqxDUe3WXMT7MR AOxvDvZ2Q0J+eRg2UXxP0z0RpNUjMhlObmRF6j+Clb4tidf4RoJRt42vjgblZ0o94hRa 7F5g== X-Gm-Message-State: ALoCoQkETAaisn+6NzRoNVckpDNk53kniTuwySlM+Wi6w2SDvalxD1F1g93ahdGKYzzb/it9YMTO X-Received: by 10.50.4.97 with SMTP id j1mr30868736igj.46.1426089708512; Wed, 11 Mar 2015 09:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.70 with HTTP; Wed, 11 Mar 2015 09:01:08 -0700 (PDT) In-Reply-To: <550060DE.2070604@room52.net> References: <20150311144838.364EDB0463F@lawyers.icir.org> <550060DE.2070604@room52.net> From: Yuchung Cheng Date: Wed, 11 Mar 2015 09:01:08 -0700 Message-ID: To: Lawrence Stewart Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Grenville Armitage , "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:04:07 -0000 On Wed, Mar 11, 2015 at 8:35 AM, Lawrence Stewart wrote: > Hi Mark, > > On 03/12/15 01:48, Mark Allman wrote: >> >>> Now for a dupack to be treated as such for the purposes of triggering >>> fast retransmit/fast recovery, the dupack must not update the window >> >> Right, per RFC 5681. > > But does 5681 (and its predecessors) document the implementation, or did > this specific bit of the implementation come about from some work? > >>> With SACK in the mix as is the case for the provided example, it seems >>> obvious to me that the existence of SACK blocks could and should be used >>> to realise that a window update combined with a dupack is not a pure >>> window update and therefore should be processed by the dupack handling >>> code for fast retransmit/fast recovery purposes. >> >> Right, per RFC 6675. > > Gah, I missed the key bit of text near the end of the definitions > section when I skimmed earlier. Thanks for the (re)pointer. > > Question still remains whether relaxing the 5681 definition that a > dupack for fast retransmit/fast recovery purposes can't update the > window is something that could/should be considered for non-SACK > connections. Does anyone recall any attempts to specify such an > algorithm? Is it not worth the effort given the prevalence of SACK? not worth the effort IMO > > Cheers, > Lawrence > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Mar 11 09:19:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE491A92EF for ; Wed, 11 Mar 2015 09:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMBK6tvpAIOo for ; Wed, 11 Mar 2015 09:19:13 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57661ACD67 for ; Wed, 11 Mar 2015 09:19:05 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t2BGJ3Uq007714; Wed, 11 Mar 2015 09:19:04 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2B5F4B0858C; Wed, 11 Mar 2015 12:19:04 -0400 (EDT) To: Lawrence Stewart From: Mark Allman In-Reply-To: <550060DE.2070604@room52.net> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Born in the USA MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma27383-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Mar 2015 12:19:04 -0400 Sender: mallman@icir.org Message-Id: <20150311161904.2B5F4B0858C@lawyers.icir.org> Archived-At: Cc: tcpm@ietf.org, Grenville Armitage Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:19:14 -0000 ----------ma27383-1 Content-Type: text/plain Content-Disposition: inline > > Right, per RFC 5681. > > But does 5681 (and its predecessors) document the implementation, or > did this specific bit of the implementation come about from some work? The spec followed the implementation. For all of 5681. The rule makes perfect sense. An ACK that rolls in with the same ACK number and an updated advertised window is ambiguous. Just as an ACK with the same ack number we have previously seen but with data on it is. We are just deciding to key on an unambiguous signal in this case. That makes good sense to me. > Question still remains whether relaxing the 5681 definition that a > dupack for fast retransmit/fast recovery purposes can't update the > window is something that could/should be considered for non-SACK > connections. Does anyone recall any attempts to specify such an > algorithm? Is it not worth the effort given the prevalence of SACK? If you care about RTOs enough to want to add a bunch of goop to infer cases where loss and window updates happen simultaneously and therefore make it hard to collect the requisite number of dupacks then you should care enough to use SACK. And, SACK is so widely supported I can't see how the right answer to this question is anything but "use SACK". allman ----------ma27383-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUAavgACgkQWyrrWs4yIs6RQwCgiHjQhtwmQtl4Ts3ZIVGDQ4pa 5JsAnRVuiXu8mwzAkaX815HLCWQuuxoY =ayJ4 -----END PGP SIGNATURE----- ----------ma27383-1-- From nobody Wed Mar 11 18:11:49 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2050A1A8944 for ; Wed, 11 Mar 2015 18:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d091CmRFLxWX for ; Wed, 11 Mar 2015 18:11:45 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id E43DE1A88F4 for ; Wed, 11 Mar 2015 18:11:44 -0700 (PDT) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 411CE7E81E; Thu, 12 Mar 2015 12:11:42 +1100 (EST) Message-ID: <5500E79A.4050002@room52.net> Date: Thu, 12 Mar 2015 12:10:50 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mallman@icir.org References: <20150311161904.2B5F4B0858C@lawyers.icir.org> In-Reply-To: <20150311161904.2B5F4B0858C@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tcpm@ietf.org, Grenville Armitage Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 01:11:47 -0000 On 03/12/15 03:19, Mark Allman wrote: > >>> Right, per RFC 5681. >> >> But does 5681 (and its predecessors) document the implementation, or >> did this specific bit of the implementation come about from some work? > > The spec followed the implementation. For all of 5681. > > The rule makes perfect sense. An ACK that rolls in with the same ACK > number and an updated advertised window is ambiguous. Just as an ACK > with the same ack number we have previously seen but with data on it is. > We are just deciding to key on an unambiguous signal in this case. That > makes good sense to me. It does indeed make sense as a conservative default. I was just curious about the history. >> Question still remains whether relaxing the 5681 definition that a >> dupack for fast retransmit/fast recovery purposes can't update the >> window is something that could/should be considered for non-SACK >> connections. Does anyone recall any attempts to specify such an >> algorithm? Is it not worth the effort given the prevalence of SACK? > > If you care about RTOs enough to want to add a bunch of goop to infer > cases where loss and window updates happen simultaneously and therefore > make it hard to collect the requisite number of dupacks then you should > care enough to use SACK. And, SACK is so widely supported I can't see > how the right answer to this question is anything but "use SACK". I desperately want to agree with you and draw a line under this, but at Netflix we still see non-zero percentages of non SACK flows from various classes of consumer electronics device which is annoying and something I have no control over. I don't have recent numbers at hand, but over a ~72 hour period ~12 months ago, there were ~60 device classes out of ~400 that had 1% or higher of non SACK flows, and of those ~60, ~5 had 5% or higher non SACK flows with the highest being 8%. Most of those 60 device classes don't make up any sizeable proportion of our total number of flows, but it would obviously be preferable to achieve the best experience possible on any Netflix enabled device. I will have fresh data in the coming weeks after we roll out some permanent logging changes I've been working on. I shall ponder some more. Thanks to you and Yuchung for the input. Cheers, Lawrence From nobody Wed Mar 11 20:42:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3461A8899 for ; Wed, 11 Mar 2015 20:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbhV9YjlWeOU for ; Wed, 11 Mar 2015 20:42:39 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4582E1A00A8 for ; Wed, 11 Mar 2015 20:42:39 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so13597669iec.2 for ; Wed, 11 Mar 2015 20:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=r1IJPdrtmWmbHkokdXmxHZ2cWWqQ+JXgw+Gso53q+jA=; b=jZbjE1ddmZBmyhIhBvcDy0FwkFfd0TCwzpAkwisqBONyxaNbd3zcZjvgkTKCcxwWT5 lQpmMp/2saFLriEPvAbBQQI300imfmkERk3SEFjEeoBZqT1UKO0t1GtYYiinO04+h1ze kVKpBvqWrZYXS+Fz9gigWC2xuDl4GJzzPp+EjujiK35ApWeQ5BW+6zWARaqdTRkskaUX r5GuVrmEEKcbXyP7jRQmgb6u0gnv2LncK8/VVZdJookyeCHEZAioUN9G8zZtPAspsiOE +iaDXkJFV8wx3X+tAw8IPpWi19h/UC90VNkr5w/lFvSSYX3OH+PmB8ykI54Kl4dbvrAH hLOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=r1IJPdrtmWmbHkokdXmxHZ2cWWqQ+JXgw+Gso53q+jA=; b=EDAcfKJdkKtJJ+loCJzfscYOPc8pktuvjecBHdOovLlo0yA4HWxHZv6fFOa+yRt+4A 8i635ZHEQpKdXC7tLz25k8mnspZs9q9ngFgaKxuZ9jQFfJRsnahLjbzN4QiZUAyf1TX/ NbJDIHmj7+lg98PbN8QI4VxRRO411F+yflBCAd/B4Sw51GQWdgbJOxOA+1ETbKk3CBpO buDiIAPUGQYTHWb0bt20ZGeD8KpHmFDQT+Kewu/vPmDeMAtrDHSJG8Wos22pNsAwmxV8 xZHo4xsrDPPOk3Cjp83hRS/W0+SLIv0PM3wd/RcuoKdLXeCtezwaC21894z0i+Kl0ikD TP4Q== X-Gm-Message-State: ALoCoQmc+J2Bb1GPoktz58+P1JBX7Xb5kCx58uhEY7VyjBWr8X+JwXUdjVDmSnJ3P86mvdPnnbhP X-Received: by 10.43.157.67 with SMTP id lp3mr35324687icc.23.1426131757007; Wed, 11 Mar 2015 20:42:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.70 with HTTP; Wed, 11 Mar 2015 20:41:56 -0700 (PDT) In-Reply-To: <5500E79A.4050002@room52.net> References: <20150311161904.2B5F4B0858C@lawyers.icir.org> <5500E79A.4050002@room52.net> From: Yuchung Cheng Date: Wed, 11 Mar 2015 20:41:56 -0700 Message-ID: To: Lawrence Stewart Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 03:42:40 -0000 On Wed, Mar 11, 2015 at 6:10 PM, Lawrence Stewart wrote: > On 03/12/15 03:19, Mark Allman wrote: >> >>>> Right, per RFC 5681. >>> >>> But does 5681 (and its predecessors) document the implementation, or >>> did this specific bit of the implementation come about from some work? >> >> The spec followed the implementation. For all of 5681. >> >> The rule makes perfect sense. An ACK that rolls in with the same ACK >> number and an updated advertised window is ambiguous. Just as an ACK >> with the same ack number we have previously seen but with data on it is. >> We are just deciding to key on an unambiguous signal in this case. That >> makes good sense to me. > > It does indeed make sense as a conservative default. I was just curious > about the history. > >>> Question still remains whether relaxing the 5681 definition that a >>> dupack for fast retransmit/fast recovery purposes can't update the >>> window is something that could/should be considered for non-SACK >>> connections. Does anyone recall any attempts to specify such an >>> algorithm? Is it not worth the effort given the prevalence of SACK? >> >> If you care about RTOs enough to want to add a bunch of goop to infer >> cases where loss and window updates happen simultaneously and therefore >> make it hard to collect the requisite number of dupacks then you should >> care enough to use SACK. And, SACK is so widely supported I can't see >> how the right answer to this question is anything but "use SACK". > > I desperately want to agree with you and draw a line under this, but at > Netflix we still see non-zero percentages of non SACK flows from various > classes of consumer electronics device which is annoying and something I > have no control over. > > I don't have recent numbers at hand, but over a ~72 hour period ~12 > months ago, there were ~60 device classes out of ~400 that had 1% or > higher of non SACK flows, and of those ~60, ~5 had 5% or higher non SACK > flows with the highest being 8%. Most of those 60 device classes don't > make up any sizeable proportion of our total number of flows, but it > would obviously be preferable to achieve the best experience possible on > any Netflix enabled device. I will have fresh data in the coming weeks > after we roll out some permanent logging changes I've been working on. I suspect that some lack of sack was due to stupid middleboxes removing sack options. They don't know what they are missing. If we spend time to make non-sack happier they stay alive happily. SACK is the most useful feature I've seen in TCP beyond 793. > > I shall ponder some more. Thanks to you and Yuchung for the input. > > Cheers, > Lawrence > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Mar 13 03:21:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8046C1A0037 for ; Fri, 13 Mar 2015 03:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fkqMDvo7VJ5 for ; Fri, 13 Mar 2015 03:21:42 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5790C1A001D for ; Fri, 13 Mar 2015 03:21:41 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,394,1422950400"; d="scan'208,217"; a="30058736" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx141-out.netapp.com with ESMTP; 13 Mar 2015 03:16:41 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 13 Mar 2015 03:16:41 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::c4b3:e711:88fe:6ce%21]) with mapi id 15.00.0995.031; Fri, 13 Mar 2015 03:16:40 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida , "tcpm@ietf.org" Thread-Topic: [tcpm] increasing max window size of TCP Thread-Index: AQHQW8V/OjnxkTb0qkaIx2m3IuhxQZ0aLEbA Date: Fri, 13 Mar 2015 10:16:39 +0000 Message-ID: <00686111035e4aaab2dacd7162e48a2d@hioexcmbx05-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.120.60.35] Content-Type: multipart/alternative; boundary="_000_00686111035e4aaab2dacd7162e48a2dhioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: Cc: "panda@wide.ad.jp" Subject: Re: [tcpm] increasing max window size of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 10:21:45 -0000 --_000_00686111035e4aaab2dacd7162e48a2dhioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNCm11bHRpcGxlIHRpbWVzDQpzL2FyY2hpdmUvYWNoaWV2ZS8NCg0KT25lIGNv bW1lbnQ6IEEgcmVjZWl2ZXIgdGhhdCBzZWVzIFdTID4gMTQgaXMgZXhwZWN0ZWQgdG8gY2xhbXAg V1MgYXQgMTQ7IChzZWUgdGhlIHBhcmFncmFwaCBpbiBSRkM3MzIzIHJpZ2h0IGFmdGVyIHRoZSBv bmUgdGhhdCB5b3UgcXVvdGVkKS4NCg0KU28sIGlmIHlvdSBzaWduYWwgdG8gYSByZWd1bGFyIFJG QzczMjMgcmVjZWl2ZXIgYSBXUyBvZiAxNSwgaWYgd2lsbCBiZWhhdmUgYXMgaWYgV1MgMTQgd2Fz IHNlbnQsIGxpbWl0aW5nIGl0cyBtYXhpbXVtIHNlbmRpbmcgd2luZG93c2l6ZSwgcmlnaHQ/IE5v IGhhcm0gZG9uZSBleGNlcHQgdGhhdCBzZXNzaW9uIGdldHRpbmcgbGVzcyBiYW5kd2lkdGguDQoN CkEgcmVjZWl2ZXIgYWxzbyBpbXBsZW1lbnRpbmcgeW91ciBwcm9wb3NhbCBjb3VsZCwgaG93ZXZl ciwgbWFrZSB1c2Ugb2YgdGhlIG5lYXJseSB0d2ljZSBhcyBsYXJnZSB3aW5kb3dzaXplLiBNb25p dG9yaW5nIG9mIHRoZSBldm9sdXRpb24gb2YgdGhlIHJlY2VpdmUgd2luZG93IHNpZ25hbGVkIHZz LiBkYXRhIHRyYW5zbWl0dGVkIGNvdWxkIGFsbG93IGEgc2VuZGVyIHRvIGRldGVybWluZSBwYXNz aXZlbHksIGlmIHRoZSByZWNlaXZlciBhY3R1YWxseSBzdXBwb3J0cyB0aGUgbGFyZ2VyIHdpbmRv d3NjYWxlIG9wdGlvbi4gQnV0IEnigJltIG5vdCBzdXJlIGlmIHRoaXMgaXMgcmVhbGx5IG5lY2Vz c2FyeeKApiAodGhlIHNpZ25hbGVkIHdpbmRvdyB3b3VsZCBzaHJpbmsgaGFsZiBhcyBmYXN0IGZv ciB1bnByb2Nlc3NlZCBkYXRhIGluIHRoZSByZWNlaXZlIGJ1ZmZlciwgY29tcGFyZWQgdG8gV1Mx NDsgaG93ZXZlciwgdGhlIHN0ZXAgY2hhbmdlIGluIHRoZSB3aW5kb3cgd291bGQgb25seSBoYXBw ZW4gd2hlbiB0aGVyZSBhcmUgMTYga0IgKG9yIDMya0ItMSkgYnl0ZXMgb2YgZGF0YSB1bnByb2Nl c3NlZC4NCg0KQnV0IHRoZSBzZW5kZXIgbXVzdCBzdG9wIHNlbmRpbmcgd2hlbiB0aGUgcmVjZWl2 ZSB3aW5kb3cgaXMgc2lnbmFsZWQgdG8gYmUgemVybyAoZXhjZXB0IGZvciByZXRyYW5zbWlzc2lv bnMpIGVpdGhlciB3YXkuDQoNCkFsc28sIEkgZ3Vlc3MgeW91IHdhbnQgdG8gY2xhbXAgZXZlcnkg b3RoZXIgcmVjZWl2ZWQgdmFsdWUgdGhhbiAxNSBkb3duIHRvIDE0IHN0aWxs4oCmIE5vdCB0aGF0 IHlvdSBzdGFydCBzY2FsaW5nIGJ5ICgyXjI1NSDigJMgMSkuDQoNClNpbmNlIHlvdSBhcmUgZWZm ZWN0aXZlbHkgZG9pbmcgYSBzcGVjaWFsIGNhc2UgaGFuZGxpbmcgd2l0aCBXUz09MTUsIHlvdSBt YXkgd2FudCB0byBkZXNjcmliZSB0aGUgbmVjZXNzYXJ5IG9wZXJhdGlvbnMgdG8gYW4gaW1wbGVt ZW50ZXIgYWxpa2Ugc2VjdGlvbiAyLjMgb2YgUkZDNzMyMywgdGhhdCBpcywgaW5zdGVhZCBvZiBv bmx5IGEgc2ltcGxlIGxlZnQgc2hpZnQgYnkgMTUgYml0cyhtdWx0aXBseSBieSAyXjE1KSwgeW91 IG5lZWQgdG8gbXVsdGlwbHkgYnkgKDJeMTUtMSkgaWYgSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9z YWwgY29ycmVjdGx5LiAoT3IgY291cnNlLCBhIG11bHRpcGxpY2F0aW9uIGJ5IDJeMTUtMSBpcyBh IGxlZnQgc2hpZnQgYnkgMTUsIGZvbGxvd2VkIGJ5IGEgc3VidHJhY3Rpb24gb2YgdGhlIG9yaWdp bmFsIHZhbHVlOyBwZXJoYXBzIGdjYyBldmVuIG9wdGltaXplcyB0aGlzIG11bHRpcGxpY2F0aW9u IG5vd2FkYXlzIOKYuiApDQoNCkJUVywgSSB0aGluayB0aGUgZm9ybXVsYSB5b3UgZ2l2ZSBpbiB0 aGUgbGFzdCBzZW50ZW5jZSBvZiBzZWMgIDEgaXMgb2ZmOyB0aGUgc2lnbmFsZWQgd2luZG93IHNw YW5zIDJeMTYsIGJ1dCB0aGUgbWF4aW11bSB2YWx1ZSBvZiB0aGUgd2luZG93IHNpZ25hbGVkIGlz IDJeMTYtMTsgdGltZXMgKDJeMTUtMSkgZ2l2ZXMgYSBtYXhpbXVtIHdpbmRvdyBvZiAyMTQ3Mzg1 MzQ1DQoNCkkgZG9u4oCZdCB0aGluayBhbiBhZGRpdGlvbmFsIG9wdGlvbiBpcyBuZWNlc3Nhcnkg Zm9yIHRoaXMgY2hhbmdlLCBhbmQgcHJvdmlkZWQgSSB1bmRlcnN0b29kIHlvdXIgaW50ZW50aW9u IGFuZCBjYWxjdWxhdGlvbnMgY29ycmVjdGx5IChhcyBkZXNjcmliZWQgYWJvdmUpLCBJIHdvdWxk IHN1cHBvcnQgdGhpcyBnb2luZyBmb3J3YXJkIGFzIGV4cGVyaW1lbnRhbC4NCg0KQmVzdCByZWdh cmRzLA0KICBSaWNoYXJkDQoNCg0KDQoNCkZyb206IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZb3NoaWZ1bWkgTmlzaGlkYQ0KU2VudDogTWl0dHdvY2gs IDExLiBNw6RyeiAyMDE1IDA3OjM1DQpUbzogdGNwbUBpZXRmLm9yZw0KQ2M6IHBhbmRhQHdpZGUu YWQuanANClN1YmplY3Q6IFt0Y3BtXSBpbmNyZWFzaW5nIG1heCB3aW5kb3cgc2l6ZSBvZiBUQ1AN Cg0KSGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgc2hvcnQgZHJhZnQgd2hpY2ggcHJvcG9zZXMg dG8gaW5jcmVhc2UgbWF4IHdpbmRvdyBzaXplIG9mIFRDUC4NCklmIHlvdSdyZSBpbnRlcmVzdGVk LCBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIGZvbGxvd2luZyBpbmZvLg0KU29tZSBtYXkgc2F5 IHRoaXMgaXMgYSBtaW5vciB0aGluZywgYnV0IHdlIHN0aWxsIGJlbGlldmUgd2UgbmVlZCB0byBj b25zaWRlciB0aGlzIGZvciBmdXR1cmUgZXh0ZW5zaW9ucyBvZiBUQ1AuDQoNCldlIHdpbGwgYXBw cmVjaWF0ZSB5b3VyIGZlZWRiYWNrIQ0KLS0NCllvc2hpICYgSGlybw0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IE1vbiwgTWFyIDksIDIwMTUgYXQgMTowOSBQTQ0KU3Vi amVjdDogSS1EIEFjdGlvbjogZHJhZnQtbmlzaGlkYS10Y3BtLW1heHdpbi0wMC50eHQNClRvOiBp LWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCg0KDQoN CkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IElu Y3JlYXNpbmcgTWF4aW11bSBXaW5kb3cgU2l6ZSBvZiBUQ1ANCiAgICAgICAgQXV0aG9ycyAgICAg ICAgIDogWW9zaGlmdW1pIE5pc2hpZGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgSGlyb2No aWthIEFzYWkNCiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtbmlzaGlkYS10Y3BtLW1h eHdpbi0wMC50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogNg0KICAgICAgICBEYXRlICAg ICAgICAgICAgOiAyMDE1LTAzLTA5DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm9w b3NlcyB0byBpbmNyZWFzZSB0aGUgY3VycmVudCBtYXggd2luZG93IHNpemUNCiAgIGFsbG93ZWQg aW4gVENQLiAgSXQgZGVzY3JpYmVzIHRoZSBjdXJyZW50IGxvZ2ljIHRoYXQgbGltaXRzIHRoZSBt YXgNCiAgIHdpbmRvdyBzaXplIGFuZCBwcm92aWRlcyBhIHJhdGlvbmFsZSB0byByZWxheCB0aGUg bGltaXRhdGlvbiBhcyB3ZWxsDQogICBhcyB0aGUgbmVnb3RpYXRpb24gbWVjaGFuaXNtIHRvIGVu YWJsZSB0aGlzIGZlYXR1cmUgc2FmZWx5Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbmlzaGlkYS10Y3BtLW1heHdpbi8NCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1u aXNoaWRhLXRjcG0tbWF4d2luLTAwDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y ZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnPG1haWx0 bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFk b3ctc2l0ZXMudHh0DQoNCg== --_000_00686111035e4aaab2dacd7162e48a2dhioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkRFLUFUO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIu MGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERS1BVCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFlvc2hpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPm11bHRpcGxlIHRpbWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5zL2FyY2hpdmUvYWNoaWV2ZS8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5PbmUgY29tbWVudDogQSByZWNlaXZlciB0aGF0IHNlZXMgV1MgJmd0OyAx NCBpcyBleHBlY3RlZCB0byBjbGFtcCBXUyBhdCAxNDsgKHNlZSB0aGUgcGFyYWdyYXBoIGluIFJG QzczMjMgcmlnaHQgYWZ0ZXIgdGhlIG9uZSB0aGF0IHlvdSBxdW90ZWQpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgaWYgeW91IHNpZ25hbCB0byBhIHJlZ3VsYXIgUkZD NzMyMyByZWNlaXZlciBhIFdTIG9mIDE1LCBpZiB3aWxsIGJlaGF2ZSBhcyBpZiBXUyAxNCB3YXMg c2VudCwgbGltaXRpbmcgaXRzIG1heGltdW0gc2VuZGluZyB3aW5kb3dzaXplLCByaWdodD8NCiBO byBoYXJtIGRvbmUgZXhjZXB0IHRoYXQgc2Vzc2lvbiBnZXR0aW5nIGxlc3MgYmFuZHdpZHRoLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHJlY2VpdmVyIGFsc28gaW1wbGVt ZW50aW5nIHlvdXIgcHJvcG9zYWwgY291bGQsIGhvd2V2ZXIsIG1ha2UgdXNlIG9mIHRoZSBuZWFy bHkgdHdpY2UgYXMgbGFyZ2Ugd2luZG93c2l6ZS4gTW9uaXRvcmluZyBvZiB0aGUgZXZvbHV0aW9u IG9mIHRoZQ0KIHJlY2VpdmUgd2luZG93IHNpZ25hbGVkIHZzLiBkYXRhIHRyYW5zbWl0dGVkIGNv dWxkIGFsbG93IGEgc2VuZGVyIHRvIGRldGVybWluZSBwYXNzaXZlbHksIGlmIHRoZSByZWNlaXZl ciBhY3R1YWxseSBzdXBwb3J0cyB0aGUgbGFyZ2VyIHdpbmRvd3NjYWxlIG9wdGlvbi4gQnV0IEni gJltIG5vdCBzdXJlIGlmIHRoaXMgaXMgcmVhbGx5IG5lY2Vzc2FyeeKApiAodGhlIHNpZ25hbGVk IHdpbmRvdyB3b3VsZCBzaHJpbmsgaGFsZiBhcyBmYXN0IGZvciB1bnByb2Nlc3NlZA0KIGRhdGEg aW4gdGhlIHJlY2VpdmUgYnVmZmVyLCBjb21wYXJlZCB0byBXUzE0OyBob3dldmVyLCB0aGUgc3Rl cCBjaGFuZ2UgaW4gdGhlIHdpbmRvdyB3b3VsZCBvbmx5IGhhcHBlbiB3aGVuIHRoZXJlIGFyZSAx NiBrQiAob3IgMzJrQi0xKSBieXRlcyBvZiBkYXRhIHVucHJvY2Vzc2VkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgdGhlIHNlbmRlciBtdXN0IHN0b3Agc2VuZGluZyB3 aGVuIHRoZSByZWNlaXZlIHdpbmRvdyBpcyBzaWduYWxlZCB0byBiZSB6ZXJvIChleGNlcHQgZm9y IHJldHJhbnNtaXNzaW9ucykgZWl0aGVyIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QWxzbywgSSBndWVzcyB5b3Ugd2FudCB0byBjbGFtcCBldmVyeSBvdGhlciByZWNl aXZlZCB2YWx1ZSB0aGFuIDE1IGRvd24gdG8gMTQgc3RpbGzigKYgTm90IHRoYXQgeW91IHN0YXJ0 IHNjYWxpbmcgYnkgKDJeMjU1IOKAkyAxKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U2luY2UgeW91IGFyZSBlZmZlY3RpdmVseSBkb2luZyBhIHNwZWNpYWwgY2FzZSBoYW5k bGluZyB3aXRoIFdTPT0xNSwgeW91IG1heSB3YW50IHRvIGRlc2NyaWJlIHRoZSBuZWNlc3Nhcnkg b3BlcmF0aW9ucyB0byBhbiBpbXBsZW1lbnRlciBhbGlrZQ0KIHNlY3Rpb24gMi4zIG9mIFJGQzcz MjMsIHRoYXQgaXMsIGluc3RlYWQgb2Ygb25seSBhIHNpbXBsZSBsZWZ0IHNoaWZ0IGJ5IDE1IGJp dHMobXVsdGlwbHkgYnkgMl4xNSksIHlvdSBuZWVkIHRvIG11bHRpcGx5IGJ5ICgyXjE1LTEpIGlm IEkgdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsIGNvcnJlY3RseS4gKE9yIGNvdXJzZSwgYSBtdWx0 aXBsaWNhdGlvbiBieSAyXjE1LTEgaXMgYSBsZWZ0IHNoaWZ0IGJ5IDE1LCBmb2xsb3dlZCBieSBh IHN1YnRyYWN0aW9uDQogb2YgdGhlIG9yaWdpbmFsIHZhbHVlOyBwZXJoYXBzIGdjYyBldmVuIG9w dGltaXplcyB0aGlzIG11bHRpcGxpY2F0aW9uIG5vd2FkYXlzIDwvc3Bhbj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkJUVywgSSB0aGluayB0aGUgZm9ybXVsYSB5b3UgZ2l2ZSBpbiB0aGUgbGFzdCBzZW50ZW5jZSBv ZiBzZWMmbmJzcDsgMSBpcyBvZmY7IHRoZSBzaWduYWxlZCB3aW5kb3cgc3BhbnMgMl4xNiwgYnV0 IHRoZSBtYXhpbXVtIHZhbHVlIG9mIHRoZSB3aW5kb3cgc2lnbmFsZWQNCiBpcyAyXjE2LTE7IHRp bWVzICgyXjE1LTEpIGdpdmVzIGEgbWF4aW11bSB3aW5kb3cgb2YgPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIxNDczODUzNDU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIGFuIGFkZGl0 aW9uYWwgb3B0aW9uIGlzIG5lY2Vzc2FyeSBmb3IgdGhpcyBjaGFuZ2UsIGFuZCBwcm92aWRlZCBJ IHVuZGVyc3Rvb2QgeW91ciBpbnRlbnRpb24gYW5kIGNhbGN1bGF0aW9ucyBjb3JyZWN0bHkgKGFz IGRlc2NyaWJlZA0KIGFib3ZlKSwgSSB3b3VsZCBzdXBwb3J0IHRoaXMgZ29pbmcgZm9yd2FyZCBh cyBleHBlcmltZW50YWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3Qg cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyBSaWNoYXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPllvc2hpZnVtaSBOaXNoaWRhPGJyPg0KPGI+U2VudDo8L2I+IE1pdHR3 b2NoLCAxMS4gTcOkcnogMjAxNSAwNzozNTxicj4NCjxiPlRvOjwvYj4gdGNwbUBpZXRmLm9yZzxi cj4NCjxiPkNjOjwvYj4gcGFuZGFAd2lkZS5hZC5qcDxicj4NCjxiPlN1YmplY3Q6PC9iPiBbdGNw bV0gaW5jcmVhc2luZyBtYXggd2luZG93IHNpemUgb2YgVENQPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldl IGhhdmUgc3VibWl0dGVkIGEgc2hvcnQgZHJhZnQgd2hpY2ggcHJvcG9zZXMgdG8gaW5jcmVhc2Ug bWF4IHdpbmRvdyBzaXplIG9mIFRDUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSdyZSBpbnRlcmVzdGVkLCBwbGVhc2UgdGFrZSBhIGxv b2sgYXQgdGhlIGZvbGxvd2luZyBpbmZvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIG1heSBzYXkgdGhpcyBpcyBhIG1pbm9y IHRoaW5nLCBidXQgd2Ugc3RpbGwgYmVsaWV2ZSB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoaXMgZm9y IGZ1dHVyZSBleHRlbnNpb25zIG9mIFRDUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCBhcHByZWNpYXRlIHlvdXIgZmVlZGJhY2sh PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9zaGkg JmFtcDsgSGlybzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CkRhdGU6IE1vbiwgTWFyIDksIDIwMTUgYXQgMTowOSBQTTxicj4NClN1YmplY3Q6IEktRCBBY3Rp b246IGRyYWZ0LW5pc2hpZGEtdGNwbS1tYXh3aW4tMDAudHh0PGJyPg0KVG86IDxhIGhyZWY9Im1h aWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VA aWV0Zi5vcmc8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Ljxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBJbmNyZWFzaW5nIE1heGltdW0g V2luZG93IFNpemUgb2YgVENQPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhv cnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBZb3NoaWZ1bWkgTmlzaGlkYTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBIaXJvY2hpa2EgQXNhaTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6IGRyYWZ0LW5pc2hpZGEtdGNwbS1tYXh3aW4tMDAudHh0PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IDY8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAxNS0wMy0wOTxicj4NCjxicj4N CkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRvIGlu Y3JlYXNlIHRoZSBjdXJyZW50IG1heCB3aW5kb3cgc2l6ZTxicj4NCiZuYnNwOyAmbmJzcDthbGxv d2VkIGluIFRDUC4mbmJzcDsgSXQgZGVzY3JpYmVzIHRoZSBjdXJyZW50IGxvZ2ljIHRoYXQgbGlt aXRzIHRoZSBtYXg8YnI+DQombmJzcDsgJm5ic3A7d2luZG93IHNpemUgYW5kIHByb3ZpZGVzIGEg cmF0aW9uYWxlIHRvIHJlbGF4IHRoZSBsaW1pdGF0aW9uIGFzIHdlbGw8YnI+DQombmJzcDsgJm5i c3A7YXMgdGhlIG5lZ290aWF0aW9uIG1lY2hhbmlzbSB0byBlbmFibGUgdGhpcyBmZWF0dXJlIHNh ZmVseS48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1uaXNoaWRhLXRjcG0tbWF4d2luLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW5pc2hpZGEtdGNwbS1tYXh3aW4vPC9h Pjxicj4NCjxicj4NClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Ojxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5pc2hpZGEt dGNwbS1tYXh3aW4tMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1uaXNoaWRhLXRjcG0tbWF4d2luLTAwPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2VJbnRlcm5ldC1EcmFm dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aS1kLWFubm91bmNlPGJyPg0KSW50ZXJuZXQtRHJhZnQ8L2E+IGRpcmVjdG9yaWVzOiA8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPjxicj4NCm9yIDxhIGhyZWY9ImZ0cDovL2Z0 cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0IiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_00686111035e4aaab2dacd7162e48a2dhioexcmbx05prdhqnetappc_-- From nobody Fri Mar 13 03:47:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692C21A00F9 for ; Fri, 13 Mar 2015 03:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvlVpdwBcq1F for ; Fri, 13 Mar 2015 03:47:41 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390241A0016 for ; Fri, 13 Mar 2015 03:47:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,394,1422950400"; d="scan'208";a="29494120" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx144-out.netapp.com with ESMTP; 13 Mar 2015 03:42:40 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 13 Mar 2015 03:42:40 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::c4b3:e711:88fe:6ce%21]) with mapi id 15.00.0995.031; Fri, 13 Mar 2015 03:42:40 -0700 From: "Scheffenegger, Richard" To: Lawrence Stewart Thread-Topic: [tcpm] TCP window updates combined with dup acks sent in response to packet loss Thread-Index: AQHQXBcXoNSpj4sBKE+sgi1N5bokOZ0Yf+wAgAAqNwCAAY2JcA== Date: Fri, 13 Mar 2015 10:42:40 +0000 Message-ID: References: <20150311161904.2B5F4B0858C@lawyers.icir.org> <5500E79A.4050002@room52.net> 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.120.60.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 10:47:49 -0000 Lawrence, Well, I can see that very light-weight implementations of TCP don't support= SACK (IoT; but then, SoCs are nowadays powerful&cheap enough and have enou= gh memory to deal with at least a minimum SACK implementation). For devices capable of decoding video streams, there really is no excuse to= not deploy a SACK capable TCP stack; have you tested those devices that yo= u mention which don't support SACK in house and ruled out path interference= (ie. meddleboxes removing SACK, when they do some Seq# rewriting etc)? Because of the above, I would suspect that you are probably looking at such= path impairments rather than end-device impairments... OTOH, You may want to look into TLP [1]. TLP is also only defined for SACK-= enabled sessions; One thought: If you have TS enabled on these real-world flows you mentioned= , and the data transmitted just before has all those packets sent with newe= r timestamps then the one in the window update - perhaps that could be a hi= gh enough bar to do a one-time TLP in NewReno... One would assume that for a genuine window-update, the reflected timestamps= wouldn't go stale for that long (>1RTT). Perhaps combining the information with what you have in TS may be conservat= ive enough, to do a TLP one RTT after the 3rd window update; note that a no= n-SACK TLP will have to be the next segment after SndUna, not the highest. But when you are implementing this, you probably need to be wary of Eifel d= etection IPR. In this particular case, of course SACK should have triggered the fast retr= ansmission. Best regards, Richard [1] https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng > Sent: Donnerstag, 12. M=E4rz 2015 04:42 > To: Lawrence Stewart > Cc: tcpm@ietf.org Extensions; mallman@icir.org > Subject: Re: [tcpm] TCP window updates combined with dup acks sent in > response to packet loss >=20 > On Wed, Mar 11, 2015 at 6:10 PM, Lawrence Stewart > wrote: > > On 03/12/15 03:19, Mark Allman wrote: > >> > >>>> Right, per RFC 5681. > >>> > >>> But does 5681 (and its predecessors) document the implementation, or > >>> did this specific bit of the implementation come about from some work= ? > >> > >> The spec followed the implementation. For all of 5681. > >> > >> The rule makes perfect sense. An ACK that rolls in with the same ACK > >> number and an updated advertised window is ambiguous. Just as an ACK > >> with the same ack number we have previously seen but with data on it > is. > >> We are just deciding to key on an unambiguous signal in this case. > That > >> makes good sense to me. > > > > It does indeed make sense as a conservative default. I was just curious > > about the history. > > > >>> Question still remains whether relaxing the 5681 definition that a > >>> dupack for fast retransmit/fast recovery purposes can't update the > >>> window is something that could/should be considered for non-SACK > >>> connections. Does anyone recall any attempts to specify such an > >>> algorithm? Is it not worth the effort given the prevalence of SACK? > >> > >> If you care about RTOs enough to want to add a bunch of goop to infer > >> cases where loss and window updates happen simultaneously and therefor= e > >> make it hard to collect the requisite number of dupacks then you shoul= d > >> care enough to use SACK. And, SACK is so widely supported I can't see > >> how the right answer to this question is anything but "use SACK". > > > > I desperately want to agree with you and draw a line under this, but at > > Netflix we still see non-zero percentages of non SACK flows from variou= s > > classes of consumer electronics device which is annoying and something = I > > have no control over. > > > > I don't have recent numbers at hand, but over a ~72 hour period ~12 > > months ago, there were ~60 device classes out of ~400 that had 1% or > > higher of non SACK flows, and of those ~60, ~5 had 5% or higher non SAC= K > > flows with the highest being 8%. Most of those 60 device classes don't > > make up any sizeable proportion of our total number of flows, but it > > would obviously be preferable to achieve the best experience possible o= n > > any Netflix enabled device. I will have fresh data in the coming weeks > > after we roll out some permanent logging changes I've been working on. > I suspect that some lack of sack was due to stupid middleboxes > removing sack options. They don't know what they are missing. >=20 > If we spend time to make non-sack happier they stay alive happily. > SACK is the most useful feature I've seen in TCP beyond 793. >=20 > > > > I shall ponder some more. Thanks to you and Yuchung for the input. > > > > Cheers, > > Lawrence > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Mar 13 09:18:45 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1928C1A8FD2; Fri, 13 Mar 2015 09:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBMFaZGXyc_n; Fri, 13 Mar 2015 09:18:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6577B1A88C4; Fri, 13 Mar 2015 09:18:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150313161834.23078.34866.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 09:18:34 -0700 Archived-At: Cc: tcpm WG Subject: [tcpm] WG Review: TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 16:18:42 -0000 The TCP Maintenance and Minor Extensions (tcpm) working group in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-23. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------------ Current Status: Active WG Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Assigned Area Director: Martin Stiemerling Mailing list Address: tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/ Charter: TCP is currently the Internet's predominant transport protocol. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The focus of the working group is TCP. In cases where small changes are directly applicable to other transports (e.g., SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but other significant additions and changes to other transports are not in scope. TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control. In addition, TCPM may document alternative TCP congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet. Changes of algorithms may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Aug 2013 - Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC Nov 2013 - Submit document on TCP support for rate-limited traffic for publication (status decided as earlier milestone) Nov 2013 - Submit document on an analysis of more detailed ECN feedback in TCP to the IESG for publication as an Informational RFC Mar 2014 - Submit revision of TCP roadmap (RFC 4614) to the IESG for publication as an Informational RFC Mar 2015 - Submit document obsoleting undeployed TCP extensions to the IESG for publication as an Informational RFC Aug 2015 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC From nobody Sat Mar 14 01:52:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27041ACC72 for ; Sat, 14 Mar 2015 01:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8L3vylViVVH for ; Sat, 14 Mar 2015 01:52:51 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2B21A03A1 for ; Sat, 14 Mar 2015 01:52:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,399,1422950400"; d="scan'208";a="29441240" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx143-out.netapp.com with ESMTP; 14 Mar 2015 01:47:30 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 14 Mar 2015 01:47:29 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::90b4:b24a:2e3b:2056%21]) with mapi id 15.00.0995.031; Sat, 14 Mar 2015 01:47:29 -0700 From: "Eggert, Lars" To: tcpm WG , "tsv-ads@tools.ietf.org" Thread-Topic: WG Review: TCP Maintenance and Minor Extensions (tcpm) Thread-Index: AQHQXalqe9wGRUVIck6z8fhCCWhqdZ0cIQYA Date: Sat, 14 Mar 2015 08:47:28 +0000 Message-ID: References: <20150313161834.23078.34866.idtracker@ietfa.amsl.com> In-Reply-To: <20150313161834.23078.34866.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2087) x-originating-ip: [10.120.60.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C86F5D0E57BAB46A41C24829F5E01FA@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WG Review: TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 08:52:53 -0000 Hi, On 2015-3-13, at 17:18, The IESG wrote: >=20 > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control. In addition, > TCPM may document alternative TCP congestion control algorithms > that are known to be widely deployed, and that are considered > safe for large-scale deployment in the Internet. Changes of algorithms > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. I just wanted to confirm whether the chairs and ADs believe that this langu= age would now make it acceptable for TCPM to adopt and publish draft-bensle= y-tcpm-dctcp? Thanks, Lars= From nobody Sat Mar 14 03:52:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F221ACCE4 for ; Sat, 14 Mar 2015 03:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSSXhfVb6WjN for ; Sat, 14 Mar 2015 03:52:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808F81A1BBD for ; Sat, 14 Mar 2015 03:52:17 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 963B3358D2B15; Sat, 14 Mar 2015 10:52:14 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2EAqFTf005591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Mar 2015 11:52:15 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sat, 14 Mar 2015 11:52:15 +0100 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" , tcpm WG , "tsv-ads@tools.ietf.org" Thread-Topic: WG Review: TCP Maintenance and Minor Extensions (tcpm) Thread-Index: AQHQXalx0VPMIM1dz0+/t93YAOXDj50bmukAgAAr1Ng= Date: Sat, 14 Mar 2015 10:52:14 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C5D429@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20150313161834.23078.34866.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.192.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WG Review: TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 10:52:20 -0000 Hi Lars,=0A= =0A= I've already explained my own view in http://www.ietf.org/mail-archive/web/= tcpm/current/msg09435.html. In my point of view, I think DCTCP could be acc= epted in TCPM as informational document with this proposed charter wording,= if there is a strong community consensus that the conditions stated in the= charter are met. However, in http://www.ietf.org/proceedings/89/minutes/mi= nutes-89-tcpm, there were also other suggestions on how the document could = move forward.=0A= =0A= As an individual contributor to TCPM, I think that the conditions for enabl= ing DCTCP currently described in Section 4 of draft-bensley-tcpm-dctcp coul= d be made much more explicit. To me, the question when DCTCP can be safely = used is not an "Implementation Issue" only. To me, a big "warning sign" wou= ld make the document more acceptable. =0A= =0A= Best regards=0A= =0A= Michael (speaking only for myself)=0A= =0A= ________________________________________=0A= Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Eggert, Lars [= lars@netapp.com]=0A= Gesendet: Samstag, 14. M=E4rz 2015 09:47=0A= An: tcpm WG; tsv-ads@tools.ietf.org=0A= Betreff: Re: [tcpm] WG Review: TCP Maintenance and Minor Extensions (tcpm)= =0A= =0A= Hi,=0A= =0A= On 2015-3-13, at 17:18, The IESG wrote:=0A= >=0A= > TCPM also provides a venue for standardization of incremental=0A= > enhancements of TCP's standard congestion control. In addition,=0A= > TCPM may document alternative TCP congestion control algorithms=0A= > that are known to be widely deployed, and that are considered=0A= > safe for large-scale deployment in the Internet. Changes of algorithms=0A= > may require additional review by the IRTF Congestion Control=0A= > Research Group (ICCRG). Fundamental changes to TCP or its congestion=0A= > control algorithms (e.g., departure from loss-based congestion=0A= > control) will be handled by other working groups or will require=0A= > rechartering.=0A= =0A= I just wanted to confirm whether the chairs and ADs believe that this langu= age would now make it acceptable for TCPM to adopt and publish draft-bensle= y-tcpm-dctcp?=0A= =0A= Thanks,=0A= Lars=0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Sat Mar 14 11:25:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08201A00EF for ; Sat, 14 Mar 2015 11:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.821 X-Spam-Level: * X-Spam-Status: No, score=1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvfP6jgkiO9S for ; Sat, 14 Mar 2015 11:25:53 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27AC1A00C8 for ; Sat, 14 Mar 2015 11:25:52 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id ABD39278102 for ; Sun, 15 Mar 2015 03:25:50 +0900 (JST) Received: by wgdm6 with SMTP id m6so10800845wgd.2 for ; Sat, 14 Mar 2015 11:25:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.208.107 with SMTP id md11mr65382379wic.10.1426357548557; Sat, 14 Mar 2015 11:25:48 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Sat, 14 Mar 2015 11:25:48 -0700 (PDT) In-Reply-To: <00686111035e4aaab2dacd7162e48a2d@hioexcmbx05-prd.hq.netapp.com> References: <00686111035e4aaab2dacd7162e48a2d@hioexcmbx05-prd.hq.netapp.com> Date: Sat, 14 Mar 2015 11:25:48 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=001a11c3898e012e80051143bf6c Archived-At: Cc: "tcpm@ietf.org" , "panda@wide.ad.jp" Subject: Re: [tcpm] increasing max window size of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:25:56 -0000 --001a11c3898e012e80051143bf6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Richard, On Fri, Mar 13, 2015 at 3:16 AM, Scheffenegger, Richard wrote: > Hi Yoshi, > > > > multiple times > > s/archive/achieve/ > Ugh.. Thanks for pointing this out. We'll fix them. > > > One comment: A receiver that sees WS > 14 is expected to clamp WS at 14; > (see the paragraph in RFC7323 right after the one that you quoted). > > > > So, if you signal to a regular RFC7323 receiver a WS of 15, if will behav= e > as if WS 14 was sent, limiting its maximum sending windowsize, right? No > harm done except that session getting less bandwidth. > Right. But, I personally would like to not discuss clamping cases in the draft if possible. We would like to avoid this situation rather than allowing it. > > > A receiver also implementing your proposal could, however, make use of th= e > nearly twice as large windowsize. Monitoring of the evolution of the > receive window signaled vs. data transmitted could allow a sender to > determine passively, if the receiver actually supports the larger > windowscale option. But I=E2=80=99m not sure if this is really necessary= =E2=80=A6 (the > signaled window would shrink half as fast for unprocessed data in the > receive buffer, compared to WS14; however, the step change in the window > would only happen when there are 16 kB (or 32kB-1) bytes of data > unprocessed. > Yes. I'm not very sure if this is necessary, either. (as I would like to avoid this) But, I think it is possible. > > But the sender must stop sending when the receive window is signaled to b= e > zero (except for retransmissions) either way. > > > > Also, I guess you want to clamp every other received value than 15 down t= o > 14 still=E2=80=A6 Not that you start scaling by (2^255 =E2=80=93 1). > > > > Since you are effectively doing a special case handling with WS=3D=3D15, = you > may want to describe the necessary operations to an implementer alike > section 2.3 of RFC7323, that is, instead of only a simple left shift by 1= 5 > bits(multiply by 2^15), you need to multiply by (2^15-1) if I understand > your proposal correctly. (Or course, a multiplication by 2^15-1 is a left > shift by 15, followed by a subtraction of the original value; perhaps gcc > even optimizes this multiplication nowadays J ) > Hmm. I've checked 7323, but I couldn't find this formula. I think I missed something. Could you point it out? > BTW, I think the formula you give in the last sentence of sec 1 is off; > the signaled window spans 2^16, but the maximum value of the window > signaled is 2^16-1; times (2^15-1) gives a maximum window of 2147385345 > > > I don=E2=80=99t think an additional option is necessary for this change, = and > provided I understood your intention and calculations correctly (as > described above), I would support this going forward as experimental. > Great! Thank for the feedback! Regards, -- Yoshi > > > > > > *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Yoshifumi > Nishida > *Sent:* Mittwoch, 11. M=C3=A4rz 2015 07:35 > *To:* tcpm@ietf.org > *Cc:* panda@wide.ad.jp > *Subject:* [tcpm] increasing max window size of TCP > > > > Hi, > > > > We have submitted a short draft which proposes to increase max window siz= e > of TCP. > > If you're interested, please take a look at the following info. > > Some may say this is a minor thing, but we still believe we need to > consider this for future extensions of TCP. > > > > We will appreciate your feedback! > > -- > > Yoshi & Hiro > > > > > > > > ------------------------------------------------------------------------- > > From: > Date: Mon, Mar 9, 2015 at 1:09 PM > Subject: I-D Action: draft-nishida-tcpm-maxwin-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Increasing Maximum Window Size of TCP > Authors : Yoshifumi Nishida > Hirochika Asai > Filename : draft-nishida-tcpm-maxwin-00.txt > Pages : 6 > Date : 2015-03-09 > > Abstract: > This document proposes to increase the current max window size > allowed in TCP. It describes the current logic that limits the max > window size and provides a rationale to relax the limitation as well > as the negotiation mechanism to enable this feature safely. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nishida-tcpm-maxwin/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-nishida-tcpm-maxwin-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft > > directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > --001a11c3898e012e80051143bf6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Richard,

=
On Fri, Mar 13, 2015 at 3:16 AM, Scheffenegger, = Richard <rs@netapp.com> wrote:

Hi Yoshi,

=C2=A0

multiple t= imes

s/archive/= achieve/


Ugh.. Thank= s for pointing this out. We'll fix them.

=C2= =A0

One commen= t: A receiver that sees WS > 14 is expected to clamp WS at 14; (see the = paragraph in RFC7323 right after the one that you quoted).

=C2= =A0

So, if you= signal to a regular RFC7323 receiver a WS of 15, if will behave as if WS 1= 4 was sent, limiting its maximum sending windowsize, right? No harm done except that session getting less bandwidth.

<= /div>

Right.=C2=A0
But, I persona= lly would like to not discuss clamping cases in the draft if possible. We w= ould like to avoid this situation rather than allowing it.

=C2= =A0

A receiver= also implementing your proposal could, however, make use of the nearly twi= ce as large windowsize. Monitoring of the evolution of the receive window signaled vs. data transmitted could allow a sender to deter= mine passively, if the receiver actually supports the larger windowscale op= tion. But I=E2=80=99m not sure if this is really necessary=E2=80=A6 (the si= gnaled window would shrink half as fast for unprocessed data in the receive buffer, compared to WS14; however, the step change in = the window would only happen when there are 16 kB (or 32kB-1) bytes of data= unprocessed.


Yes. I= 'm not very sure if this is necessary, either. (as I would like to avoi= d this)=C2=A0
But, I think it is possible.

=

=C2= =A0

But the se= nder must stop sending when the receive window is signaled to be zero (exce= pt for retransmissions) either way.

=C2= =A0

Also, I gu= ess you want to clamp every other received value than 15 down to 14 still= =E2=80=A6 Not that you start scaling by (2^255 =E2=80=93 1).<= /span>

=C2= =A0

Since you = are effectively doing a special case handling with WS=3D=3D15, you may want= to describe the necessary operations to an implementer alike section 2.3 of RFC7323, that is, instead of only a simple left shift by 15= bits(multiply by 2^15), you need to multiply by (2^15-1) if I understand y= our proposal correctly. (Or course, a multiplication by 2^15-1 is a left sh= ift by 15, followed by a subtraction of the original value; perhaps gcc even optimizes this multiplication nowa= days J )


Hmm. I've checked 7323, but I= couldn't find this formula. I think I missed something. Could you poin= t it out?
=C2=A0

BTW, I thi= nk the formula you give in the last sentence of sec=C2=A0 1 is off; the sig= naled window spans 2^16, but the maximum value of the window signaled is 2^16-1; times (2^15-1) gives a maximum window of 2147385345=C2=A0

<= /u>

=C2= =A0

I don=E2= =80=99t think an additional option is necessary for this change, and provid= ed I understood your intention and calculations correctly (as described above), I would support this going forward as experimental.


Great! Thank for the feedback!

Regards,
--
Yoshi=C2=A0
=


=C2= =A0

=C2= =A0

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Mittwoch, 11. M=C3=A4rz 2015 07:35
To: tcpm@ietf.org=
Cc: panda@wide= .ad.jp
Subject: [tcpm] increasing max window size of TCP

=C2=A0

Hi,=C2=A0

=C2=A0

We have submitted a short draft which proposes to in= crease max window size of TCP.

If you're interested, please take a look at the = following info.

Some may say this is a minor thing, but we still bel= ieve we need to consider this for future extensions of TCP.

=C2=A0

We will appreciate your feedback!

--

Yoshi & Hiro

=C2=A0

=C2=A0

=C2=A0

----------------------------------------------------= ---------------------

From: <internet-drafts@ietf.org>
Date: Mon, Mar 9, 2015 at 1:09 PM
Subject: I-D Action: draft-nishida-tcpm-maxwin-00.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Increasing Maximum Window Size of TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hirochika Asai
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-maxwin-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-09

Abstract:
=C2=A0 =C2=A0This document proposes to increase the current max window size=
=C2=A0 =C2=A0allowed in TCP.=C2=A0 It describes the current logic that limi= ts the max
=C2=A0 =C2=A0window size and provides a rationale to relax the limitation a= s well
=C2=A0 =C2=A0as the negotiation mechanism to enable this feature safely.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-maxwin/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-nishida-tcpm-maxwin-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=C2=A0


--001a11c3898e012e80051143bf6c-- From nobody Sat Mar 14 11:36:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37781A00EF for ; Sat, 14 Mar 2015 11:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVVqHhixJi22 for ; Sat, 14 Mar 2015 11:36:37 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F7A1A0039 for ; Sat, 14 Mar 2015 11:36:37 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6CA2C2780E5 for ; Sun, 15 Mar 2015 03:36:35 +0900 (JST) Received: by wetk59 with SMTP id k59so12256202wet.3 for ; Sat, 14 Mar 2015 11:36:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.121.136 with SMTP id lk8mr103321396wjb.49.1426358193106; Sat, 14 Mar 2015 11:36:33 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Sat, 14 Mar 2015 11:36:33 -0700 (PDT) In-Reply-To: <550060DE.2070604@room52.net> References: <20150311144838.364EDB0463F@lawyers.icir.org> <550060DE.2070604@room52.net> Date: Sat, 14 Mar 2015 11:36:33 -0700 Message-ID: From: Yoshifumi Nishida To: Lawrence Stewart Content-Type: multipart/alternative; boundary=089e01227f426c359c051143e584 Archived-At: Cc: "tcpm@ietf.org" , Mark Allman Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:36:39 -0000 --089e01227f426c359c051143e584 Content-Type: text/plain; charset=UTF-8 Hi Lawrence, On Wed, Mar 11, 2015 at 8:35 AM, Lawrence Stewart wrote: Question still remains whether relaxing the 5681 definition that a > dupack for fast retransmit/fast recovery purposes can't update the > window is something that could/should be considered for non-SACK > connections. Does anyone recall any attempts to specify such an > algorithm? Is it not worth the effort given the prevalence of SACK? > Can't we send window updates and dupack separately by using different ACKs? Then, we don't have to relax the 5681 definition. -- Yoshi --089e01227f426c359c051143e584 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lawrence,

On Wed, Mar 11= , 2015 at 8:35 AM, Lawrence Stewart <lstewart@room52.net> = wrote:

Question still remains whether relaxing the 5681 definition that a
dupack for fast retransmit/fast recovery purposes can't update the
window is something that could/should be considered for non-SACK
connections. Does anyone recall any attempts to specify such an
algorithm? Is it not worth the effort given the prevalence of SACK?
=C2=A0
Can't we send window updates and dup= ack separately by using different ACKs?
Then, we don't have t= o relax the 5681 definition.
--
Yoshi
=C2= =A0
--089e01227f426c359c051143e584-- From nobody Sat Mar 14 13:34:48 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823331A0211 for ; Sat, 14 Mar 2015 13:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5cb2QM2bE7Q for ; Sat, 14 Mar 2015 13:34:44 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B851A017F for ; Sat, 14 Mar 2015 13:34:43 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,401,1422950400"; d="scan'208,217"; a="29491469" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx143-out.netapp.com with ESMTP; 14 Mar 2015 13:29:45 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 14 Mar 2015 13:29:42 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Sat, 14 Mar 2015 13:29:42 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] increasing max window size of TCP Thread-Index: AQHQW8V/OjnxkTb0qkaIx2m3IuhxQZ0aLEbAgAKaHQD//5jIQA== Date: Sat, 14 Mar 2015 20:29:42 +0000 Message-ID: References: <00686111035e4aaab2dacd7162e48a2d@hioexcmbx05-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.120.60.36] Content-Type: multipart/alternative; boundary="_000_c3614924df914205aa8556409b2ddcffhioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "panda@wide.ad.jp" Subject: Re: [tcpm] increasing max window size of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 20:34:46 -0000 --_000_c3614924df914205aa8556409b2ddcffhioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNCg0KDQpTbywgaWYgeW91IHNpZ25hbCB0byBhIHJlZ3VsYXIgUkZDNzMyMyBy ZWNlaXZlciBhIFdTIG9mIDE1LCBpZiB3aWxsIGJlaGF2ZSBhcyBpZiBXUyAxNCB3YXMgc2VudCwg bGltaXRpbmcgaXRzIG1heGltdW0gc2VuZGluZyB3aW5kb3dzaXplLCByaWdodD8gTm8gaGFybSBk b25lIGV4Y2VwdCB0aGF0IHNlc3Npb24gZ2V0dGluZyBsZXNzIGJhbmR3aWR0aC4NCg0KUmlnaHQu DQpCdXQsIEkgcGVyc29uYWxseSB3b3VsZCBsaWtlIHRvIG5vdCBkaXNjdXNzIGNsYW1waW5nIGNh c2VzIGluIHRoZSBkcmFmdCBpZiBwb3NzaWJsZS4gV2Ugd291bGQgbGlrZSB0byBhdm9pZCB0aGlz IHNpdHVhdGlvbiByYXRoZXIgdGhhbiBhbGxvd2luZyBpdC4NCg0KQXMgeW91IG1lbnRpb25lZCBp biB0aGUgZHJhZnQsIFdTIGlzIG5vdCByZWFsbHkgbmVnb3RpYXRlZCwganVzdCBvZmZlcmVkOyBJ ZiB5b3Ugb2ZmZXIgV1M9MTUgdG8gYSBsZWdhY3kgcmVjZWl2ZXIsIGl0IHdpbGwgb25seSBzZW5k IHlvdSBhdCBtb3N0ICgyXjE2LTEpKigyXjE0KSBieXRlcyBpbiBvbmUgUlRULCB3aGlsZSBhIHJl Y2VpdmVyIHRoYXQgYWxzbyBzdXBwb3J0cyB0aGlzIGV4dGVuc2lvbiwgd291bGQgc2VuZCB5b3Ug YXQgbW9zdCAoMl4xNi0xKSooMl4xNS0xKSBieXRlc+KApg0KDQpUaGUgcmVzdHJpY3Rpb24gdGhh dCBhbnkgcmVjZWl2ZWQgV1MgdmFsdWUgbGFyZ2VyIHRoYW4gMTQgTVVTVCBiZSBpbnRlcnByZXRl ZCBhcyBXUz0xNCBpcyBoZXJlOg0KDQogICAgIOKAnUlmIGENCiAgIFdpbmRvdyBTY2FsZSBvcHRp b24gaXMgcmVjZWl2ZWQgd2l0aCBhIHNoaWZ0LmNudCB2YWx1ZSBsYXJnZXIgdGhhbg0KICAgMTQs IHRoZSBUQ1AgU0hPVUxEIGxvZyB0aGUgZXJyb3IgYnV0IE1VU1QgdXNlIDE0IGluc3RlYWQgb2Yg dGhlDQogICBzcGVjaWZpZWQgdmFsdWUuICBUaGlzIGlzIHNhZmUgYXMgYSBzZW5kZXIgY2FuIGFs d2F5cyBjaG9vc2UgdG8gb25seQ0KICAgcGFydGlhbGx5IHVzZSBhbnkgc2lnbmFsZWQgcmVjZWl2 ZSB3aW5kb3cuICBJZiB0aGUgcmVjZWl2ZXIgaXMNCiAgIHNjYWxpbmcgYnkgYSBmYWN0b3IgbGFy Z2VyIHRoYW4gMTQgYW5kIHRoZSBzZW5kZXIgaXMgb25seSBzY2FsaW5nIGJ5DQogICAxNCwgdGhl biB0aGUgcmVjZWl2ZSB3aW5kb3cgdXNlZCBieSB0aGUgc2VuZGVyIHdpbGwgYXBwZWFyIHNtYWxs ZXINCiAgIHRoYW4gaXQgaXMgaW4gcmVhbGl0eS7igJ0NCg0KQWxzbywgdGhpcyB0ZXh0IGdpdmUg YSB2ZXJ5IGdvb2QgcmF0aW9uYWxlLCB3aHkgeW91IGRvbuKAmXQgbmVlZCB0byB3b3JyeSB0b28g bXVjaCBhYm91dCB1bmlsYXRlcmFsbHkgc2VuZGluZyBvdXQgV1M9MTUuDQoNCg0KTXkgcG9pbnQg YmVpbmcsIHlvdXIgZXh0ZW5zaW9uIHNob3VsZCBiZSBzYWZlIGZvciBkZXBsb3ltZW50LCB3aXRo b3V0IGFueSBjaGVja2luZyBpZiB0aGUgb3Bwb3NpdGUgc2lkZSBpbnRlcnByZXRzIHRoZSB2YWx1 ZSBwcm9wZXJseSBvciBub3TigKYNCg0KDQoNCg0KU2luY2UgeW91IGFyZSBlZmZlY3RpdmVseSBk b2luZyBhIHNwZWNpYWwgY2FzZSBoYW5kbGluZyB3aXRoIFdTPT0xNSwgeW91IG1heSB3YW50IHRv IGRlc2NyaWJlIHRoZSBuZWNlc3Nhcnkgb3BlcmF0aW9ucyB0byBhbiBpbXBsZW1lbnRlciBhbGlr ZSBzZWN0aW9uIDIuMyBvZiBSRkM3MzIzLCB0aGF0IGlzLCBpbnN0ZWFkIG9mIG9ubHkgYSBzaW1w bGUgbGVmdCBzaGlmdCBieSAxNSBiaXRzKG11bHRpcGx5IGJ5IDJeMTUpLCB5b3UgbmVlZCB0byBt dWx0aXBseSBieSAoMl4xNS0xKSBpZiBJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBjb3JyZWN0 bHkuIChPciBjb3Vyc2UsIGEgbXVsdGlwbGljYXRpb24gYnkgMl4xNS0xIGlzIGEgbGVmdCBzaGlm dCBieSAxNSwgZm9sbG93ZWQgYnkgYSBzdWJ0cmFjdGlvbiBvZiB0aGUgb3JpZ2luYWwgdmFsdWU7 IHBlcmhhcHMgZ2NjIGV2ZW4gb3B0aW1pemVzIHRoaXMgbXVsdGlwbGljYXRpb24gbm93YWRheXMg 4pi6ICkNCg0KSG1tLiBJJ3ZlIGNoZWNrZWQgNzMyMywgYnV0IEkgY291bGRuJ3QgZmluZCB0aGlz IGZvcm11bGEuIEkgdGhpbmsgSSBtaXNzZWQgc29tZXRoaW5nLiBDb3VsZCB5b3UgcG9pbnQgaXQg b3V0Pw0KDQpTZWN0aW9uIDIuMzoNCiDigJxTTkQuV05EID0gU0VHLldORCA8PCBTbmQuV2luZC5T aGlmdOKAnQ0KKGluIEMgbm90YXRpb24sIHdoZXJlIOKAnHggPDwgeeKAnSBpcyBzeW5vbnltb3Vz IHdpdGgg4oCcIHggKjJeeeKAnSkuDQoNCg0KWW91ciBleHRlbnNpb24sIGluIEMsIHdvdWxkIHBy b2JhYmx5IG5lZWQgYSBjb25kaXRpb25hbCBsaWtlDQoNCklmIChTbmQuV2luZC5TaGlmdCA8PSAx NCkNClNORC5XTkQgPSBTRUcuV05EIDw8IFNuZC5XaW5kLlNoaWZ0DQpFbHNlaWYgKFNuZC5XaW5k LlNoaWZ0ID09IDE1KQ0KICAgICAgICBTTkQuV05EID0gU0VHLldORCAqICgyXlNuZC5XaW5kLlNo aWZ0IOKAkyAxKQ0KW1sNCndpdGhvdXQgbXVsdGlwbHk6DQpTTkQuV05EID0gKCBTRUcuV05EIDw8 IFNuZC5XaW5kLlNoaWZ0ICkg4oCTIFNFRy5XTkQNCl1dDQoNCkFuZCBzaW1pbGFyaWx5Og0KDQpJ ZiAoUmN2LldpbmQuU2hpZnQgPD0gMTQpDQogICAgICAgIFNFRy5XTkQgPSBSQ1YuV05EID4+IFJj di5XaW5kLlNoaWZ0DQpFbHNlaWYgKFJjdi5XaW5kLlNoaWZ0ID09IDE1KQ0KICAgICAgICBTRUcu V05EID0gUkNWLldORCAvICgyXlJjdi5XaW5kLlNoaWZ0IOKAkyAxKQ0KDQpbWw0Kd2l0aG91dCBk aXZpc2lvbiAoYWxzbyBmaXRzIGluIHVpbnQzMik6DQpTRUcuV05EID0gKFJDVi5XTkQgKyAoUkNW LldORCA+PiAxNSkgKyAxKSA+PiAxNQ0KDQpEbyB3ZSBjYXJ0ZXIgZm9yIGFyY2hpdGVjdHVyZXMg d2hlcmUgdGhlcmUgaXMgbm8gZWZmaWNpZW50IGRpdmlzaW9uIG9yIG9wdGltaXppbmcgY29tcGls ZXI/DQpdXQ0KDQoNCiAoYW5kIGFjdHVhbGx5LCB0aGUgaW5pdGlhbCBwYXJhZ3JhcGggaW4gU2Vj dGlvbiAyLjIgaGFzIGl0IHdyb25nOg0KDQogIOKAnFRoZSBtYXhpbXVtIHNjYWxlDQogICBleHBv bmVudCBpcyBsaW1pdGVkIHRvIDE0IGZvciBhIG1heGltdW0gcGVybWlzc2libGUgcmVjZWl2ZSB3 aW5kb3cNCiAgIHNpemUgb2YgMSBHaUIgKDJeKDE0KzE2KSnigJwNCg0KdG8gYmUgYWJzb2x1dGVs eSBjb3JyZWN0LCB0aGF0IHNob3VsZCByZWFkDQoNCiAg4oCcVGhlIG1heGltdW0gc2NhbGUNCiAg IGV4cG9uZW50IGlzIGxpbWl0ZWQgdG8gMTQgZm9yIGEgbWF4aW11bSBwZXJtaXNzaWJsZSByZWNl aXZlIHdpbmRvdw0KICAgc2l6ZSBvZiBuZWFybHkgMSBHaUIgKCAoMl4xNiDigJMgMSkgKiAyXjE0 ICnigJwNCg0KRG9u4oCZdCBrbm93IGlmIHRoaXMgd2FycmFudHMgYW4gZXJyYXRhIDopDQoNCg0K DQo= --_000_c3614924df914205aa8556409b2ddcffhioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPkhpIFlvc2hp LDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPiZuYnNwOzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIiBjb2xvcj0i IzFGNDk3RCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6NXB0O21hcmdpbi1ib3R0b206NXB0OyI+ PGZvbnQgY29sb3I9IiMxRjQ5N0QiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6NXB0O21hcmdpbi1ib3R0b206NXB0OyI+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPlNv LCBpZiB5b3Ugc2lnbmFsIHRvIGEgcmVndWxhciBSRkM3MzIzIHJlY2VpdmVyIGEgV1Mgb2YgMTUs IGlmIHdpbGwgYmVoYXZlIGFzIGlmIFdTIDE0IHdhcyBzZW50LCBsaW1pdGluZyBpdHMgbWF4aW11 bSBzZW5kaW5nIHdpbmRvd3NpemUsIHJpZ2h0PyBObyBoYXJtIGRvbmUgZXhjZXB0IHRoYXQgc2Vz c2lvbiBnZXR0aW5nIGxlc3MNCmJhbmR3aWR0aC48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0 OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij5SaWdodC4mbmJz cDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPkJ1dCwgSSBwZXJzb25hbGx5 IHdvdWxkIGxpa2UgdG8gbm90IGRpc2N1c3MgY2xhbXBpbmcgY2FzZXMgaW4gdGhlIGRyYWZ0IGlm IHBvc3NpYmxlLiBXZSB3b3VsZCBsaWtlIHRvIGF2b2lkIHRoaXMgc2l0dWF0aW9uIHJhdGhlciB0 aGFuIGFsbG93aW5nIGl0Ljwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0iMyIgY29sb3I9IiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9y PSIjMUY0OTdEIj5BcyB5b3UgbWVudGlvbmVkIGluIHRoZSBkcmFmdCwgV1MgaXMgbm90IHJlYWxs eSBuZWdvdGlhdGVkLCBqdXN0IG9mZmVyZWQ7IElmIHlvdSBvZmZlciBXUz0xNSB0byBhIGxlZ2Fj eSByZWNlaXZlciwgaXQgd2lsbCBvbmx5IHNlbmQgeW91IGF0IG1vc3QgKDJeMTYtMSkqKDJeMTQp IGJ5dGVzIGluIG9uZSBSVFQsIHdoaWxlIGEgcmVjZWl2ZXIgdGhhdCBhbHNvIHN1cHBvcnRzIHRo aXMgZXh0ZW5zaW9uLA0Kd291bGQgc2VuZCB5b3UgYXQgbW9zdCAoMl4xNi0xKSooMl4xNS0xKSBi eXRlc+KApjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPiZuYnNwOzwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPlRoZSByZXN0cmljdGlvbiB0 aGF0IGFueSByZWNlaXZlZCBXUyB2YWx1ZSBsYXJnZXIgdGhhbiAxNCBNVVNUIGJlIGludGVycHJl dGVkIGFzIFdTPTE0IGlzIGhlcmU6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiIGNvbG9yPSIjMUY0OTdEIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0i IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxmb250IGZhY2U9IkNvdXJpZXIgTmV3 IiBzaXplPSIyIiBjb2xvcj0iYmxhY2siPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPuKA nUlmIGE8L3NwYW4+PC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmll ciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPiZuYnNwOyZuYnNw OyBXaW5kb3cgU2NhbGUgb3B0aW9uIGlzIHJlY2VpdmVkIHdpdGggYSBzaGlmdC5jbnQgdmFsdWUg bGFyZ2VyIHRoYW48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVy IE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7Jm5ic3A7 IDE0LCB0aGUgVENQIFNIT1VMRCBsb2cgdGhlIGVycm9yIGJ1dCBNVVNUIHVzZSAxNCBpbnN0ZWFk IG9mIHRoZTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3 IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsmbmJzcDsgc3Bl Y2lmaWVkIHZhbHVlLiZuYnNwOyBUaGlzIGlzIHNhZmUgYXMgYSBzZW5kZXIgY2FuIGFsd2F5cyBj aG9vc2UgdG8gb25seTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsmbmJz cDsgcGFydGlhbGx5IHVzZSBhbnkgc2lnbmFsZWQgcmVjZWl2ZSB3aW5kb3cuJm5ic3A7IElmIHRo ZSByZWNlaXZlciBpczwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsmbmJz cDsgc2NhbGluZyBieSBhIGZhY3RvciBsYXJnZXIgdGhhbiAxNCBhbmQgdGhlIHNlbmRlciBpcyBv bmx5IHNjYWxpbmcgYnk8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3Vy aWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7Jm5i c3A7IDE0LCB0aGVuIHRoZSByZWNlaXZlIHdpbmRvdyB1c2VkIGJ5IHRoZSBzZW5kZXIgd2lsbCBh cHBlYXIgc21hbGxlcjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsmbmJz cDsgdGhhbiBpdCBpcyBpbiByZWFsaXR5LuKAnTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyIgY29sb3I9IiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGNvbG9yPSIjMUY0OTdEIj5BbHNvLCB0aGlzIHRleHQgZ2l2ZSBhIHZlcnkgZ29vZCBy YXRpb25hbGUsIHdoeSB5b3UgZG9u4oCZdCBuZWVkIHRvIHdvcnJ5IHRvbyBtdWNoIGFib3V0IHVu aWxhdGVyYWxseSBzZW5kaW5nIG91dCBXUz0xNS48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyIgY29sb3I9IiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyIgY29sb3I9IiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGNvbG9yPSIjMUY0OTdEIj5NeSBwb2ludCBiZWluZywgeW91ciBleHRlbnNpb24gc2hvdWxk IGJlIHNhZmUgZm9yIGRlcGxveW1lbnQsIHdpdGhvdXQgYW55IGNoZWNraW5nIGlmIHRoZSBvcHBv c2l0ZSBzaWRlIGludGVycHJldHMgdGhlIHZhbHVlIHByb3Blcmx5IG9yIG5vdOKApjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIiBjb2xvcj0iIzFGNDk3RCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIiBjb2xvcj0iIzFGNDk3 RCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6NXB0O21hcmdpbi1ib3R0b206NXB0OyI+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIiBjb2xvcj0iIzFGNDk3RCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMnB0OyI+PGJyPg0KDQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij5TaW5jZSB5b3UgYXJlIGVmZmVjdGl2ZWx5 IGRvaW5nIGEgc3BlY2lhbCBjYXNlIGhhbmRsaW5nIHdpdGggV1M9PTE1LCB5b3UgbWF5IHdhbnQg dG8gZGVzY3JpYmUgdGhlIG5lY2Vzc2FyeSBvcGVyYXRpb25zIHRvIGFuIGltcGxlbWVudGVyIGFs aWtlIHNlY3Rpb24gMi4zIG9mIFJGQzczMjMsIHRoYXQgaXMsIGluc3RlYWQgb2Ygb25seSBhIHNp bXBsZQ0KbGVmdCBzaGlmdCBieSAxNSBiaXRzKG11bHRpcGx5IGJ5IDJeMTUpLCB5b3UgbmVlZCB0 byBtdWx0aXBseSBieSAoMl4xNS0xKSBpZiBJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBjb3Jy ZWN0bHkuIChPciBjb3Vyc2UsIGEgbXVsdGlwbGljYXRpb24gYnkgMl4xNS0xIGlzIGEgbGVmdCBz aGlmdCBieSAxNSwgZm9sbG93ZWQgYnkgYSBzdWJ0cmFjdGlvbiBvZiB0aGUgb3JpZ2luYWwgdmFs dWU7IHBlcmhhcHMgZ2NjIGV2ZW4gb3B0aW1pemVzIHRoaXMNCm11bHRpcGxpY2F0aW9uIG5vd2Fk YXlzIDwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iV2luZ2RpbmdzIiBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQ7Ij5KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJp IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4gKTwvc3Bhbj48L2ZvbnQ+ PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTJwdDsiPkhtbS4gSSd2ZSBjaGVja2VkIDczMjMsIGJ1dCBJIGNv dWxkbid0IGZpbmQgdGhpcyBmb3JtdWxhLiBJIHRoaW5rIEkgbWlzc2VkIHNvbWV0aGluZy4gQ291 bGQgeW91IHBvaW50IGl0IG91dD88L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiIGNvbG9yPSIjMUY0OTdEIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBj b2xvcj0iIzFGNDk3RCI+U2VjdGlvbiAyLjM6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+IOKA nFNORC5XTkQgPSBTRUcuV05EICZsdDsmbHQ7IFNuZC5XaW5kLlNoaWZ04oCdPC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPihpbiBDIG5vdGF0aW9uLCB3aGVy ZSDigJx4ICZsdDsmbHQ7IHnigJ0gaXMgc3lub255bW91cyB3aXRoIOKAnCB4ICoyXnnigJ0pLjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIiBj b2xvcj0iIzFGNDk3RCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIz IiBjb2xvcj0iIzFGNDk3RCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPllvdXIgZXh0ZW5z aW9uLCBpbiBDLCB3b3VsZCBwcm9iYWJseSBuZWVkIGEgY29uZGl0aW9uYWwgbGlrZTwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIiBjb2xvcj0i IzFGNDk3RCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPklmIChTbmQuV2luZC5TaGlmdCAm bHQ7PSAxNCk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJ0ZXh0LWluZGVudDozNS40cHQ7Ij48 Zm9udCBjb2xvcj0iIzFGNDk3RCI+U05ELldORCA9IFNFRy5XTkQgJmx0OyZsdDsgU25kLldpbmQu U2hpZnQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMUY0OTdEIj5FbHNlaWYgKFNu ZC5XaW5kLlNoaWZ0ID09IDE1KTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTTkQuV05EID0g U0VHLldORCAqICgyXlNuZC5XaW5kLlNoaWZ0IOKAkyAxKTwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgY29sb3I9IiMxRjQ5N0QiPltbIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMx RjQ5N0QiPndpdGhvdXQgbXVsdGlwbHk6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0i IzFGNDk3RCI+U05ELldORCA9ICggU0VHLldORCAmbHQ7Jmx0OyBTbmQuV2luZC5TaGlmdCApIOKA kyBTRUcuV05EPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzFGNDk3RCI+XV08L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyIgY29s b3I9IiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMUY0OTdEIj5BbmQgc2ltaWxhcmlseTo8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMUY0OTdEIj4mbmJzcDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMUY0OTdEIj5JZiAoUmN2LldpbmQuU2hpZnQgJmx0Oz0g MTQpPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFNFRy5XTkQgPSBSQ1YuV05EICZndDsmZ3Q7IFJjdi5XaW5kLlNoaWZ0 PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPkVsc2VpZiAo UmN2LldpbmQuU2hpZnQgPT0gMTUpPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNFRy5XTkQg PSBSQ1YuV05EIC8gKDJeUmN2LldpbmQuU2hpZnQg4oCTIDEpPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiIGNvbG9yPSIjMUY0OTdEIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBjb2xvcj0iIzFGNDk3RCI+W1s8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9y PSIjMUY0OTdEIj53aXRob3V0IGRpdmlzaW9uIChhbHNvIGZpdHMgaW4gdWludDMyKTo8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMUY0OTdEIj5TRUcuV05EID0gKFJDVi5XTkQgJiM0 MzsgKFJDVi5XTkQgJmd0OyZndDsgMTUpICYjNDM7IDEpICZndDsmZ3Q7IDE1PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiIGNvbG9yPSIjMUY0 OTdEIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzFGNDk3RCI+RG8gd2UgY2FydGVyIGZvciBhcmNoaXRl Y3R1cmVzIHdoZXJlIHRoZXJlIGlzIG5vIGVmZmljaWVudCBkaXZpc2lvbiBvciBvcHRpbWl6aW5n IGNvbXBpbGVyPzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxRjQ5N0QiPl1dPC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiIGNv bG9yPSIjMUY0OTdEIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMi IGNvbG9yPSIjMUY0OTdEIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzFGNDk3RCI+IChhbmQgYWN0dWFs bHksIHRoZSBpbml0aWFsIHBhcmFncmFwaCBpbiBTZWN0aW9uIDIuMiBoYXMgaXQgd3Jvbmc6PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiIGNv bG9yPSIjMUY0OTdEIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7IOKAnFRoZSBtYXhpbXVtIHNjYWxlPC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPiZuYnNwOyZuYnNwOyBleHBvbmVudCBpcyBs aW1pdGVkIHRvIDE0IGZvciBhIG1heGltdW0gcGVybWlzc2libGUgcmVjZWl2ZSB3aW5kb3c8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7Jm5ic3A7IHNpemUgb2YgMSBHaUIg KDJeKDE0JiM0MzsxNikp4oCcPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIiBjb2xvcj0iIzFGNDk3RCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29s b3I9IiMxRjQ5N0QiPnRvIGJlIGFic29sdXRlbHkgY29ycmVjdCwgdGhhdCBzaG91bGQgcmVhZDwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTBwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwcHQ7Ij4mbmJzcDsg4oCcVGhlIG1heGltdW0gc2NhbGU8L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMHB0OyI+Jm5ic3A7Jm5ic3A7IGV4cG9uZW50IGlzIGxpbWl0ZWQgdG8gMTQgZm9yIGEg bWF4aW11bSBwZXJtaXNzaWJsZSByZWNlaXZlIHdpbmRvdzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwcHQ7Ij4mbmJzcDsmbmJzcDsgc2l6ZSBvZiBuZWFybHkgMSBHaUIgKCAoMl4xNiDigJMg MSkgKiAyXjE0ICnigJw8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiIGNvbG9yPSIjMUY0OTdEIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0i IzFGNDk3RCI+RG9u4oCZdCBrbm93IGlmIHRoaXMgd2FycmFudHMgYW4gZXJyYXRhIDopPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiIGNvbG9y PSIjMUY0OTdEIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_c3614924df914205aa8556409b2ddcffhioexcmbx05prdhqnetappc_-- From nobody Sat Mar 14 15:02:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5971A0318 for ; Sat, 14 Mar 2015 15:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HMLdcGbuYOx for ; Sat, 14 Mar 2015 15:02:40 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com [15.201.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAF11A026E for ; Sat, 14 Mar 2015 15:02:39 -0700 (PDT) Received: from g9t2301.houston.hp.com (g9t2301.houston.hp.com [16.216.185.78]) by g4t3426.houston.hp.com (Postfix) with ESMTP id 10E26C38 for ; Sat, 14 Mar 2015 22:02:38 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g9t2301.houston.hp.com (Postfix) with ESMTP id C7AE870 for ; Sat, 14 Mar 2015 22:02:38 +0000 (UTC) Message-ID: <5504AFFE.2070306@hp.com> Date: Sat, 14 Mar 2015 15:02:38 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20150311144838.364EDB0463F@lawyers.icir.org> <550060DE.2070604@room52.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 22:02:41 -0000 On 03/14/2015 11:36 AM, Yoshifumi Nishida wrote: > Hi Lawrence, > > On Wed, Mar 11, 2015 at 8:35 AM, Lawrence Stewart > wrote: > > Question still remains whether relaxing the 5681 definition that a > dupack for fast retransmit/fast recovery purposes can't update the > window is something that could/should be considered for non-SACK > connections. Does anyone recall any attempts to specify such an > algorithm? Is it not worth the effort given the prevalence of SACK? > > > Can't we send window updates and dupack separately by using different ACKs? > Then, we don't have to relax the 5681 definition. I've not memorized TCP chapter and verse, but I suspect it is only a SHOULD that one bundle ACKs and window updates. Still, in the broadest handwaving sense, particularly with the presence of the stateless offloads and I suppose copy avoidance, sending a standalone ACK or window update is just as many CPU cycles as sending a data segment. And I suppose considering something like segmentation offload, sending an ACK may actually be more expensive than sending a data segment, since one will get multiple data segments in a single trip down the protocol stack. And receive-offload means receiving a bare ACK or window update is more expensive than receiving a data segment for the same sort of (somewhat handwaving) reasoning. rick jones From nobody Sun Mar 15 07:28:47 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5231A1A65 for ; Sun, 15 Mar 2015 07:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OOx8QvvSk9C for ; Sun, 15 Mar 2015 07:28:44 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314921A1A4E for ; Sun, 15 Mar 2015 07:28:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,404,1422950400"; d="scan'208";a="29057987" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 15 Mar 2015 07:27:44 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 15 Mar 2015 07:27:43 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Sun, 15 Mar 2015 07:27:43 -0700 From: "Scheffenegger, Richard" To: Rick Jones , "tcpm@ietf.org" Thread-Topic: [tcpm] TCP window updates combined with dup acks sent in response to packet loss Thread-Index: AQHQXAp1oNSpj4sBKE+sgi1N5bokOZ0X32cAgATpc4CAADmUAIAAm2rA Date: Sun, 15 Mar 2015 14:27:42 +0000 Message-ID: <3ce771b6e88a46a78b444dbf2699a551@hioexcmbx05-prd.hq.netapp.com> References: <20150311144838.364EDB0463F@lawyers.icir.org> <550060DE.2070604@room52.net> <5504AFFE.2070306@hp.com> In-Reply-To: <5504AFFE.2070306@hp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 14:28:46 -0000 Hi Rick, Isn't most hardware doing receive-offload only on in-sequence segments? Both window updates and reordering (loss) would be handled by the CPU TCP s= tack, I would assume (but it's been a while since I last studied offload-en= gine datasheets). I raised my suspicion that the effect he observes is likely on a path where= something disallows SACK - and it would probably make more sense to put ef= fort in fixing such broken paths. Perhaps Lawrence can come up with (anonymized) samples of the issue; if TS = works there, and the sender has a reasonable good understanding of the RTT,= something like TLP might be safe enough to do... short of RTO recovery. Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Rick Jones > Sent: Samstag, 14. M=E4rz 2015 23:03 > To: tcpm@ietf.org > Subject: Re: [tcpm] TCP window updates combined with dup acks sent in > response to packet loss >=20 > On 03/14/2015 11:36 AM, Yoshifumi Nishida wrote: > > Hi Lawrence, > > > > On Wed, Mar 11, 2015 at 8:35 AM, Lawrence Stewart > > wrote: > > > > Question still remains whether relaxing the 5681 definition that a > > dupack for fast retransmit/fast recovery purposes can't update the > > window is something that could/should be considered for non-SACK > > connections. Does anyone recall any attempts to specify such an > > algorithm? Is it not worth the effort given the prevalence of SACK? > > > > > > Can't we send window updates and dupack separately by using different > ACKs? > > Then, we don't have to relax the 5681 definition. >=20 > I've not memorized TCP chapter and verse, but I suspect it is only a > SHOULD that one bundle ACKs and window updates. Still, in the broadest > handwaving sense, particularly with the presence of the stateless offload= s > and I suppose copy avoidance, sending a standalone ACK or window update i= s > just as many CPU cycles as sending a data segment. >=20 > And I suppose considering something like segmentation offload, sending an > ACK may actually be more expensive than sending a data segment, since one > will get multiple data segments in a single trip down the protocol stack. > And receive-offload means receiving a bare ACK or window update is more > expensive than receiving a data segment for the same sort of (somewhat > handwaving) reasoning. >=20 > rick jones >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Mar 15 11:26:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F191A1B6A for ; Sun, 15 Mar 2015 11:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.821 X-Spam-Level: * X-Spam-Status: No, score=1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMeaA1yAF1XX for ; Sun, 15 Mar 2015 11:26:17 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029031A1B69 for ; Sun, 15 Mar 2015 11:26:16 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 715C427813F for ; Mon, 16 Mar 2015 03:26:13 +0900 (JST) Received: by wgbcc7 with SMTP id cc7so23815831wgb.0 for ; Sun, 15 Mar 2015 11:26:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.195.12.71 with SMTP id eo7mr117441014wjd.3.1426443970931; Sun, 15 Mar 2015 11:26:10 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Sun, 15 Mar 2015 11:26:10 -0700 (PDT) In-Reply-To: References: <00686111035e4aaab2dacd7162e48a2d@hioexcmbx05-prd.hq.netapp.com> Date: Sun, 15 Mar 2015 11:26:10 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=047d7bb04ee42df47a051157deba Archived-At: Cc: "tcpm@ietf.org" , "panda@wide.ad.jp" Subject: Re: [tcpm] increasing max window size of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 18:26:19 -0000 --047d7bb04ee42df47a051157deba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Richard, On Sat, Mar 14, 2015 at 1:29 PM, Scheffenegger, Richard wrote: > Hi Yoshi, > > > > So, if you signal to a regular RFC7323 receiver a WS of 15, if will behav= e > as if WS 14 was sent, limiting its maximum sending windowsize, right? No > harm done except that session getting less bandwidth. > > Right. > But, I personally would like to not discuss clamping cases in the draft i= f > possible. We would like to avoid this situation rather than allowing it. > > As you mentioned in the draft, WS is not really negotiated, just offered; > If you offer WS=3D15 to a legacy receiver, it will only send you at most > (2^16-1)*(2^14) bytes in one RTT, while a receiver that also supports thi= s > extension, would send you at most (2^16-1)*(2^15-1) bytes=E2=80=A6 > > The restriction that any received WS value larger than 14 MUST be > interpreted as WS=3D14 is here: > > =E2=80=9DIf a > Window Scale option is received with a shift.cnt value larger than > 14, the TCP SHOULD log the error but MUST use 14 instead of the > specified value. This is safe as a sender can always choose to only > partially use any signaled receive window. If the receiver is > scaling by a factor larger than 14 and the sender is only scaling by > 14, then the receive window used by the sender will appear smaller > than it is in reality.=E2=80=9D > > Also, this text give a very good rationale, why you don=E2=80=99t need to= worry > too much about unilaterally sending out WS=3D15. > > > My point being, your extension should be safe for deployment, without any > checking if the opposite side interprets the value properly or not=E2=80= =A6 > OK, I see the point. We haven't thought about it, but it's an interesting idea. We'll think this more. > Since you are effectively doing a special case handling with WS=3D=3D15, = you > may want to describe the necessary operations to an implementer alike > section 2.3 of RFC7323, that is, instead of only a simple left shift by 1= 5 > bits(multiply by 2^15), you need to multiply by (2^15-1) if I understand > your proposal correctly. (Or course, a multiplication by 2^15-1 is a left > shift by 15, followed by a subtraction of the original value; perhaps gcc > even optimizes this multiplication nowadays J ) > > Hmm. I've checked 7323, but I couldn't find this formula. I think I misse= d > something. Could you point it out? > > Section 2.3: > =E2=80=9CSND.WND =3D SEG.WND << Snd.Wind.Shift=E2=80=9D > (in C notation, where =E2=80=9Cx << y=E2=80=9D is synonymous with =E2=80= =9C x *2^y=E2=80=9D). > > > Your extension, in C, would probably need a conditional like > > If (Snd.Wind.Shift <=3D 14) > SND.WND =3D SEG.WND << Snd.Wind.Shift > Elseif (Snd.Wind.Shift =3D=3D 15) > SND.WND =3D SEG.WND * (2^Snd.Wind.Shift =E2=80=93 1) > [[ > without multiply: > SND.WND =3D ( SEG.WND << Snd.Wind.Shift ) =E2=80=93 SEG.WND > ]] > > And similarily: > > If (Rcv.Wind.Shift <=3D 14) > SEG.WND =3D RCV.WND >> Rcv.Wind.Shift > Elseif (Rcv.Wind.Shift =3D=3D 15) > SEG.WND =3D RCV.WND / (2^Rcv.Wind.Shift =E2=80=93 1) > > [[ > without division (also fits in uint32): > SEG.WND =3D (RCV.WND + (RCV.WND >> 15) + 1) >> 15 > > Do we carter for architectures where there is no efficient division or > optimizing compiler? > ]] > Oh. Now I see what you mean. Sorry. But, our intention in the draft was to propose (2^16 -1) * 2^15.. I'm not very sure to use 2^15 -1.. Could you elaborate the reason for this? > (and actually, the initial paragraph in Section 2.2 has it wrong: > > =E2=80=9CThe maximum scale > exponent is limited to 14 for a maximum permissible receive window > size of 1 GiB (2^(14+16))=E2=80=9C > > to be absolutely correct, that should read > > =E2=80=9CThe maximum scale > exponent is limited to 14 for a maximum permissible receive window > size of nearly 1 GiB ( (2^16 =E2=80=93 1) * 2^14 )=E2=80=9C > > Don=E2=80=99t know if this warrants an errata :) > Right. It could be an errata. -- Yoshi --047d7bb04ee42df47a051157deba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Sat, Mar 14, 2015 at 1:29 PM, Scheffenegger, Richard <rs@n= etapp.com> wrote:
Hi Yoshi,
=C2=A0
=C2=A0
=C2= =A0
So,= if you signal to a regular RFC7323 receiver a WS of 15, if will behave as = if WS 14 was sent, limiting its maximum sending windowsize, right? No harm = done except that session getting less bandwidth.
=C2=A0
Right.=C2=A0
But, I personally would like to not discuss clamping cases in the draft = if possible. We would like to avoid this situation rather than allowing it.=
=C2=A0
As you mentioned in the draft, WS is no= t really negotiated, just offered; If you offer WS=3D15 to a legacy receive= r, it will only send you at most (2^16-1)*(2^14) bytes in one RTT, while a = receiver that also supports this extension, would send you at most (2^16-1)*(2^15-1) bytes=E2=80=A6
=C2=A0
The restriction that any received WS value lar= ger than 14 MUST be interpreted as WS=3D14 is here:
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9DIf a
=C2=A0=C2=A0= Window Scale option is received with a shift.cnt value larger than<= /font>
=C2=A0=C2=A0= 14, the TCP SHOULD log the error but MUST use 14 instead of the
=C2=A0=C2=A0= specified value.=C2=A0 This is safe as a sender can always choose to only<= /span>
=C2=A0=C2=A0= partially use any signaled receive window.=C2=A0 If the receiver is=
=C2=A0=C2=A0= scaling by a factor larger than 14 and the sender is only scaling by
=C2=A0=C2=A0= 14, then the receive window used by the sender will appear smaller<= /font>
=C2=A0=C2=A0= than it is in reality.=E2=80=9D
=C2=A0
Also, this text give a very good rationale, wh= y you don=E2=80=99t need to worry too much about unilaterally sending out W= S=3D15.
=C2=A0
=C2=A0
My point being, your extension should be safe = for deployment, without any checking if the opposite side interprets the va= lue properly or not=E2=80=A6
<= div>
OK, I see the point. We haven't thought about it, bu= t it's an interesting idea.=C2=A0
We'll think this more.<= /div>
=C2=A0
Since you are effecti= vely doing a special case handling with WS=3D=3D15, you may want to describ= e the necessary operations to an implementer alike section 2.3 of RFC7323, = that is, instead of only a simple left shift by 15 bits(multiply by 2^15), you need to multiply by (2^15-1) i= f I understand your proposal correctly. (Or course, a multiplication by 2^1= 5-1 is a left shift by 15, followed by a subtraction of the original value;= perhaps gcc even optimizes this multiplication nowadays J )
=C2=A0
Hmm. I've checked 7323, but I couldn't find this formula. I thin= k I missed something. Could you point it out?
=C2=A0
Section 2.3:
=E2=80=9CSN= D.WND =3D SEG.WND << Snd.Wind.Shift=E2=80=9D
(in C notation, where =E2=80=9Cx << y=E2= =80=9D is synonymous with =E2=80=9C x *2^y=E2=80=9D).
=C2=A0
=C2=A0
Your extension, in C, would probably need a co= nditional like
=C2=A0
If (Snd.Wind.Shift <=3D 14)
SND.WND =3D SEG.W= ND << Snd.Wind.Shift
Elseif (Snd.Wind.Shift =3D=3D 15)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SND= .WND =3D SEG.WND * (2^Snd.Wind.Shift =E2=80=93 1)
[[
without multiply:
SND.WND =3D ( SEG.WND << Snd.Wind.Shift = ) =E2=80=93 SEG.WND
]]
=C2=A0
And similarily:
=C2=A0
If (Rcv.Wind.Shift <=3D 14)
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SEG.WND =3D RCV.WND >> Rcv.Wind.Shift<= /span>
Elseif (Rcv.Wind.Shift =3D=3D 15)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SEG= .WND =3D RCV.WND / (2^Rcv.Wind.Shift =E2=80=93 1)
=C2=A0
[[
without division (also fits in uint32):=
SEG.WND =3D (RCV.WND + (RCV.WND >> 15) += 1) >> 15
=C2=A0
Do we carter for architectures where there is = no efficient division or optimizing compiler?
]]

Oh. Now I see what you mean. Sorry.
But, ou= r intention in the draft was to propose (2^16 -1) * 2^15.. I'm not very= sure to use 2^15 -1.. Could you elaborate the reason for this?
= =C2=A0
(and actually, the initial paragraph in Secti= on 2.2 has it wrong:
=C2=A0
=C2=A0 =E2= =80=9CThe maximum scale
=C2=A0=C2=A0= exponent is limited to 14 for a maximum permissible receive window<= /font>
=C2=A0=C2=A0= size of 1 GiB (2^(14+16))=E2=80=9C
=C2=A0
to be absolutely correct, that should read
=C2=A0
=C2=A0 =E2= =80=9CThe maximum scale
=C2=A0=C2=A0= exponent is limited to 14 for a maximum permissible receive window<= /font>
=C2=A0=C2=A0= size of nearly 1 GiB ( (2^16 =E2=80=93 1) * 2^14 )=E2=80=9C<= /div>
=C2=A0
Don=E2=80=99t know if this warrants an errata = :)

Right. It cou= ld be an errata.=C2=A0
--
Yoshi
--047d7bb04ee42df47a051157deba-- From nobody Mon Mar 16 23:37:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580011A009E for ; Mon, 16 Mar 2015 23:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CniKE_RDp2Uy for ; Mon, 16 Mar 2015 23:37:38 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7551A00A8 for ; Mon, 16 Mar 2015 23:37:37 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-c6-5507cbaf470d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.C2.19337.FABC7055; Tue, 17 Mar 2015 07:37:35 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Tue, 17 Mar 2015 07:37:35 +0100 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: Initial CWND Thread-Index: AdBgfIAmygwTohlkTe66UpoVK8ZVsQ== Date: Tue, 17 Mar 2015 06:37:34 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA320C6182ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje760+yhBru3a1hsOzmfyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGb8vX2UsmOhUsbf9OGMD41+bLkYODgkBE4nmlexdjJxAppjE hXvr2boYuTiEBI4wSmzZvIYFwlnMKDFl3hVGkCo2ARuJlYe+g9kiAsoSq+9/ALOFBUQlendP YoGIS0m0717OCmHrSRxe2AFmswioSiy/1c8EYvMK+EpcXfAHLM4oICtx//s9sF5mAXGJW0/m M0FcJCCxZM95ZghbVOLl43+sEEcrSUzbmgZRni8xtf0uO8RIQYmTM5+wTGAUmoVk0iwkZbOQ lEHE9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEAuy+AJG9lWMosWpxUm56UbGeqlFmcnFxfl5enmp JZsYgRFxcMtv1R2Ml984HmIU4GBU4uHdMIM9VIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjI6aEhLiegcu5dpcz5mcGF1wM+Uo+y6dwiOvIktXl/woehcj mP9hykbBw5YzfwdMKz8dHvR5TYj87f1iTQv13T2/WBgFRm9zCbp/4Igaz8Gr3j1fZoQeuNn2 X4tDp217R/bFw2erZwdqH/Ho89lxt+MMx0NDvWVPL8709Fz676j1qVUif/7MjFRiKc5INNRi LipOBACrWI8caQIAAA== Archived-At: Subject: [tcpm] Initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 06:37:43 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA320C6182ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi A humble question, anybody has any data on how widely spread the use of Ini= tial CWND =3D 10MSS (or max 14600byte) is ?. I have only looked at a few wireshark logs and cannot make any hard conclus= ion based on that. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "The Earth is a very small stage in a vast cosmic arena" Carl Sagan "Pale Blue Dot" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA320C6182ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

A humble question, anybody has = any data on how widely spread the use of Initial CWND =3D 10MSS (or max 146= 00byte) is ?.

I have only looked at a few wir= eshark logs and cannot make any hard conclusion based on that.

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com= =

www.ericsson.com

 

“The Earth is a very small stage in a

 vast cosmic arena”<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Arial"= ,"sans-serif";color:black;mso-fareast-language:SV">
Carl Sagan “= Pale Blue Dot”
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA320C6182ESESSMB205erics_-- From nobody Tue Mar 17 04:44:26 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C381A036D for ; Tue, 17 Mar 2015 04:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1uZxqf6B_GV for ; Tue, 17 Mar 2015 04:44:21 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EED1A0366 for ; Tue, 17 Mar 2015 04:44:21 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YXpv1-0005Du-P7; Tue, 17 Mar 2015 12:44:19 +0100 Received: from mail-ex01.exprod.uio.no ([129.240.52.4]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YXpv1-0000I0-52; Tue, 17 Mar 2015 12:44:19 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex01.exprod.uio.no (2001:700:100:52::4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 17 Mar 2015 12:44:18 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.1044.021; Tue, 17 Mar 2015 12:44:18 +0100 From: Michael Welzl To: Ingemar Johansson S Thread-Topic: [tcpm] Initial CWND Thread-Index: AQHQYKez1RbMT05L4UigWj69Rt710w== Date: Tue, 17 Mar 2015 11:44:18 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="Windows-1252" Content-ID: <59D248EE8B0B19458F0EF1070D1700D3@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 14 sum msgs/h 5 total rcpts 26482 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EBCE3125A1DC897A41AF3D8D3C36E6DFB8042A15 X-UiO-SPAM-Test: remote_host: 129.240.52.4 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 193 total 641768 max/h 480 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 11:44:23 -0000 Hi, I think it's pretty widely used given the results in table 1 here: http://heim.ifi.uio.no/~michawe/research/publications/networking2014.pdf Now these are only a few data points, but from pretty large CDNs AFAIK. The= n again, the data is old - I did this check in 2013. If you want to repeat the test, this was pretty easy to do. Here's what I d= id: - get a web page, watch wireshark, find a URL of an object (image or someth= ing) that's larger than 10 packets - do the following with help of scapy ( http://www.secdev.org/projects/sca= py/ ): * send a TCP SYN, respond to the SYN/ACK with a correct ACK * disable all outgoing ACKs with the firewall * send a HTTP GET to the address of the large object with scapy * watch how many packets come back, in wireshark ... since you never ACK anything, you only get the initial window, followe= d by single retransmits after an RTO on the server side. That can certainly= be automatized, I did this half-manually. I hope this helps... and I hope others have some more recent data. Cheers, Michael > On 17 Mar 2015, at 07:37, Ingemar Johansson S wrote: >=20 > Hi > =20 > A humble question, anybody has any data on how widely spread the use of I= nitial CWND =3D 10MSS (or max 14600byte) is ?. > I have only looked at a few wireshark logs and cannot make any hard concl= usion based on that. > =20 > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Senior Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > =93The Earth is a very small stage in a=20 > vast cosmic arena=94 > Carl Sagan =93Pale Blue Dot=94 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Mar 17 07:11:37 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC381A1A68 for ; Tue, 17 Mar 2015 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHR-RXGgqPy9 for ; Tue, 17 Mar 2015 07:11:30 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEB11A1A66 for ; Tue, 17 Mar 2015 07:11:29 -0700 (PDT) Received: from [76.167.133.166] ([76.167.133.166:30279] helo=spandex.luckie.org.nz) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 0E/BE-27097-01638055; Tue, 17 Mar 2015 14:11:29 +0000 Received: from mjl by spandex.luckie.org.nz with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YXsDP-0002V1-QG; Tue, 17 Mar 2015 07:11:27 -0700 Date: Tue, 17 Mar 2015 07:11:27 -0700 From: Matthew Luckie To: Michael Welzl Message-ID: <20150317141127.GA9488@spandex.luckie.org.nz> References: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Matthew Luckie X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: tiangewu@caida.org, "tcpm@ietf.org" Subject: Re: [tcpm] Initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:11:34 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I hope this helps... and I hope others have some more recent data. I have a student (Tiange Wu, cc'd) who has been working with various tbit tests who has recent data for ICW. http://www.caida.org/~mjl/icw-1460.png That graph covers 6714 servers in the first alexa 10K on Feb 10 2015. A 1460 MSS was advertised. --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlUINgoACgkQKyuDKSEQAGCBxgCeLUSJqoRkbx/vsPFCNCXdsmnq 95wAoL1tsVQSB981PHBO+epyIGYG7h3+ =SkH9 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From nobody Tue Mar 17 12:54:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3AF1A88BF for ; Tue, 17 Mar 2015 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QQlpAaP03Vx for ; Tue, 17 Mar 2015 12:54:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB101A88CF for ; Tue, 17 Mar 2015 12:54:21 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-08-5508866b71cb Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0C.FC.28835.B6688055; Tue, 17 Mar 2015 20:54:20 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 17 Mar 2015 20:54:19 +0100 From: Ingemar Johansson S To: Michael Welzl , "mjl@caida.org" Thread-Topic: [tcpm] Initial CWND Thread-Index: AdBgfIAmygwTohlkTe66UpoVK8ZVsQAItGEAABMJfTA= Date: Tue, 17 Mar 2015 19:54:18 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA320C7029@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW5OG0eowdHLLBY/zu5ktei8o2+x 7eR8Jgdmjy179zN7LFnyk8lj9eqHzAHMUVw2Kak5mWWpRfp2CVwZqy82shXsE654sGUFYwPj Hf4uRk4OCQETiRffdzBD2GISF+6tZwOxhQSOMEoc3JvUxcgFZC9mlNh45TUrSIJNwEZi5aHv jCC2iIC7xMbjc8CamQWUJZYfm84OYgsLKEjMm7QCqkZR4tSTg+wQtpXE+etPmEBsFgFViWcz PoHFeQV8JXbtfcYMsayRUWL7pUtgzZwCdhKbD7ezgNiMArIS97/fY4FYJi5x68l8JoirBSSW 7DkP9YGoxMvH/1ghbEWJj6/2MULU60ncmDqFDcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQt s5C0zELSsoCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYEwd3PLbagfjweeOhxgFOBiV eHg3zGAPFWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY/55 zz+3bU59k7lxKKb1cEiVnXykfNSDicGXin43m6xpcq+O/8hy9+inH8nmd+7ExE+9esH+H6P2 ne+7RcQEuiYeXyjEmVjR2nNw3qmFChqWb1SSG27rp0wLOWrA6hHhqXyybaaTXKa1ufi/vxPM Z2/9ZbbNZNGXmIQv2xouxUyPCNJp1RfkV2Ipzkg01GIuKk4EAHVLwMKKAgAA Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:54:24 -0000 Hi Thanks Michael and Mathew for the info. It was indeed helpful and answered = my questions more than enough. Regards Ingemar -----Original Message----- From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 Sent: den 17 mars 2015 12:44 To: Ingemar Johansson S Cc: tcpm@ietf.org Subject: Re: [tcpm] Initial CWND Hi, I think it's pretty widely used given the results in table 1 here: http://heim.ifi.uio.no/~michawe/research/publications/networking2014.pdf Now these are only a few data points, but from pretty large CDNs AFAIK. The= n again, the data is old - I did this check in 2013. If you want to repeat the test, this was pretty easy to do. Here's what I d= id: - get a web page, watch wireshark, find a URL of an object (image or someth= ing) that's larger than 10 packets - do the following with help of scapy ( http://www.secdev.org/projects/sca= py/ ): * send a TCP SYN, respond to the SYN/ACK with a correct ACK * disable all outgoing ACKs with the firewall * send a HTTP GET to the address of the large object with scapy * watch how many packets come back, in wireshark ... since you never ACK anything, you only get the initial window, followe= d by single retransmits after an RTO on the server side. That can certainly= be automatized, I did this half-manually. I hope this helps... and I hope others have some more recent data. Cheers, Michael > On 17 Mar 2015, at 07:37, Ingemar Johansson S wrote: >=20 > Hi > =20 > A humble question, anybody has any data on how widely spread the use of I= nitial CWND =3D 10MSS (or max 14600byte) is ?. > I have only looked at a few wireshark logs and cannot make any hard concl= usion based on that. > =20 > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Senior Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > "The Earth is a very small stage in a vast cosmic arena" > Carl Sagan "Pale Blue Dot" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Mar 17 14:17:45 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536761A88F8 for ; Tue, 17 Mar 2015 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0DSM-NlKk65 for ; Tue, 17 Mar 2015 14:17:43 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04531A88F5 for ; Tue, 17 Mar 2015 14:17:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,418,1422950400"; d="scan'208";a="29488289" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 17 Mar 2015 14:12:41 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 17 Mar 2015 14:12:41 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Tue, 17 Mar 2015 14:12:41 -0700 From: "Scheffenegger, Richard" To: Matthew Luckie , Michael Welzl Thread-Topic: [tcpm] Initial CWND Thread-Index: AdBgfIAmygwTohlkTe66UpoVK8ZVsQAZd+oAAAUjn4AAAC8LQA== Date: Tue, 17 Mar 2015 21:12:40 +0000 Message-ID: <2a861eabe2744febbaa1ac8bb3a128df@hioexcmbx05-prd.hq.netapp.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> <20150317141127.GA9488@spandex.luckie.org.nz> In-Reply-To: <20150317141127.GA9488@spandex.luckie.org.nz> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.36] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tiangewu@caida.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:17:44 -0000 Just a note of warning - the alexa top n (with n < something like 10 000) s= ites may not be representative of the overall population. For starters, the topmost sites will all utilize CDNs, load balancers, reve= rse proxys etc, which you'll not find further down in the alexa top 1M list= . Picking a similar sample from some distributed sites further down the list,= and comparing these two samples might be revealing to certain aspects (at = the least, it would be statistically be more valid). We (Brian Trammel et. = al.) found this in our recent ECN testing exercise). Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Matthew Luckie > Sent: Dienstag, 17. M=E4rz 2015 15:11 > To: Michael Welzl > Cc: tiangewu@caida.org; tcpm@ietf.org > Subject: Re: [tcpm] Initial CWND >=20 > > I hope this helps... and I hope others have some more recent data. >=20 > I have a student (Tiange Wu, cc'd) who has been working with various tbit > tests who has recent data for ICW. >=20 > http://www.caida.org/~mjl/icw-1460.png >=20 > That graph covers 6714 servers in the first alexa 10K on Feb 10 2015. > A 1460 MSS was advertised. From nobody Wed Mar 18 03:08:44 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B879C1A0004 for ; Wed, 18 Mar 2015 03:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTtsqHA7xf9F for ; Wed, 18 Mar 2015 03:08:38 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE871A000E for ; Wed, 18 Mar 2015 03:08:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,422,1422950400"; d="scan'208";a="30390614" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx144-out.netapp.com with ESMTP; 18 Mar 2015 03:03:15 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Mar 2015 03:03:15 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Wed, 18 Mar 2015 03:03:15 -0700 From: "Scheffenegger, Richard" To: "tcpm-chairs@tools.ietf.org" Thread-Topic: Adoption of draft-zimmermann-tcpm-cubic? Thread-Index: AdBhYjpPZb+rJ+RBQHOjk5FmqEicXA== Date: Wed, 18 Mar 2015 10:03:14 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 10:08:42 -0000 Michael, Yoshi, Pasi, after the recharter of TCPM, which now specifically states " TCPM may docum= ent alternative TCP congestion control algorithms that are known to be widely deployed", we would like to raise the question = if we can start a call for adoption of https://tools.ietf.org/id/draft-zimm= ermann-tcpm-cubic-00.txt ? During the IETF91, there was strong consensus in= the room to adopt this document and put it on standards track: https://too= ls.ietf.org/wg/tcpm/minutes?item=3Dminutes-91-tcpm.html >From our understanding, Cubic fully qualifies to be considered as a legitim= ate WG document after the recharter. Again, no technical work on the cubic = algorithm would be done, as explained by Lars in Honolulu, just tracking wh= at changes went into the existing implementations since the initial writing= of the document.=20 Best regards, Alex and Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: Dienstag, 17. Februar 2015 20:10 > To: tcpm@ietf.org > Subject: [tcpm] Milestones changed for tcpm WG >=20 > Changed milestone "Submit document obsoleting undeployed TCP extensions t= o > the IESG for publication as an Informational RFC", set state to active > from review, accepting new milestone. >=20 > URL: http://datatracker.ietf.org/wg/tcpm/charter/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Mar 18 03:18:44 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D7D1A0004 for ; Wed, 18 Mar 2015 03:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNHHjj0wJP1S for ; Wed, 18 Mar 2015 03:18:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7D71A000B for ; Wed, 18 Mar 2015 03:18:41 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id CC98E84E27181; Wed, 18 Mar 2015 10:18:37 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2IAIcax010082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Mar 2015 11:18:39 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 18 Mar 2015 11:18:38 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "tcpm-chairs@tools.ietf.org" Thread-Topic: Adoption of draft-zimmermann-tcpm-cubic? Thread-Index: AdBhYjpPZb+rJ+RBQHOjk5FmqEicXAAAbAKg Date: Wed, 18 Mar 2015 10:18:37 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C60F4D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 10:18:43 -0000 My understanding is that TCPM recharting is still pending and IESG waits fo= r potential feedback until March 23 [1]. The chairs are well aware of the strong support for draft-zimmermann-tcpm-c= ubic during IETF 91. We plan to run a formal adoption call once our charter= explicitly allows adoption in TCPM. Michael [1] http://www.ietf.org/mail-archive/web/tcpm/current/msg09489.html > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scheffenegger, > Richard > Sent: Wednesday, March 18, 2015 11:03 AM > To: tcpm-chairs@tools.ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? >=20 > Michael, Yoshi, Pasi, >=20 >=20 > after the recharter of TCPM, which now specifically states " TCPM may > document alternative TCP congestion control algorithms > that are known to be widely deployed", we would like to raise the > question if we can start a call for adoption of > https://tools.ietf.org/id/draft-zimmermann-tcpm-cubic-00.txt ? During > the IETF91, there was strong consensus in the room to adopt this > document and put it on standards track: > https://tools.ietf.org/wg/tcpm/minutes?item=3Dminutes-91-tcpm.html >=20 > >From our understanding, Cubic fully qualifies to be considered as a > legitimate WG document after the recharter. Again, no technical work on > the cubic algorithm would be done, as explained by Lars in Honolulu, > just tracking what changes went into the existing implementations since > the initial writing of the document. >=20 > Best regards, > Alex and Richard >=20 >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of IETF > Secretariat > > Sent: Dienstag, 17. Februar 2015 20:10 > > To: tcpm@ietf.org > > Subject: [tcpm] Milestones changed for tcpm WG > > > > Changed milestone "Submit document obsoleting undeployed TCP > extensions to > > the IESG for publication as an Informational RFC", set state to > active > > from review, accepting new milestone. > > > > URL: http://datatracker.ietf.org/wg/tcpm/charter/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Mar 18 03:27:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1831A0019 for ; Wed, 18 Mar 2015 03:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdn4bokYbcQC for ; Wed, 18 Mar 2015 03:27:22 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B46A1A0013 for ; Wed, 18 Mar 2015 03:27:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,422,1422950400"; d="asc'?scan'208";a="30392624" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx144-out.netapp.com with ESMTP; 18 Mar 2015 03:26:21 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Mar 2015 03:26:21 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::6036:353f:66f7:c599%21]) with mapi id 15.00.0995.031; Wed, 18 Mar 2015 03:26:21 -0700 From: "Zimmermann, Alexander" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? Thread-Index: AdBhYjpPZb+rJ+RBQHOjk5FmqEicXAAAbAKgAA8umAA= Date: Wed, 18 Mar 2015 10:26:20 +0000 Message-ID: <2235E611-C0A1-42A9-9B00-D584FF3C8B3B@netapp.com> References: <655C07320163294895BBADA28372AF5D16C60F4D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C60F4D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4E2C4927-CFC0-42B3-B0C0-188F73C45F57"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 10:27:24 -0000 --Apple-Mail=_4E2C4927-CFC0-42B3-B0C0-188F73C45F57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Michael, > Am 18.03.2015 um 11:18 schrieb Scharf, Michael (Michael) = : >=20 > My understanding is that TCPM recharting is still pending and IESG = waits for potential feedback until March 23 [1]. >=20 > The chairs are well aware of the strong support for = draft-zimmermann-tcpm-cubic during IETF 91. We plan to run a formal = adoption call once our charter explicitly allows adoption in TCPM. Sounds good! Thanks for update Alex >=20 > Michael >=20 >=20 > [1] http://www.ietf.org/mail-archive/web/tcpm/current/msg09489.html >=20 >=20 >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scheffenegger, >> Richard >> Sent: Wednesday, March 18, 2015 11:03 AM >> To: tcpm-chairs@tools.ietf.org >> Cc: tcpm@ietf.org >> Subject: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? >>=20 >> Michael, Yoshi, Pasi, >>=20 >>=20 >> after the recharter of TCPM, which now specifically states " TCPM may >> document alternative TCP congestion control algorithms >> that are known to be widely deployed", we would like to raise the >> question if we can start a call for adoption of >> https://tools.ietf.org/id/draft-zimmermann-tcpm-cubic-00.txt ? During >> the IETF91, there was strong consensus in the room to adopt this >> document and put it on standards track: >> https://tools.ietf.org/wg/tcpm/minutes?item=3Dminutes-91-tcpm.html >>=20 >>> =46rom our understanding, Cubic fully qualifies to be considered as = a >> legitimate WG document after the recharter. Again, no technical work = on >> the cubic algorithm would be done, as explained by Lars in Honolulu, >> just tracking what changes went into the existing implementations = since >> the initial writing of the document. >>=20 >> Best regards, >> Alex and Richard >>=20 >>=20 >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of IETF >> Secretariat >>> Sent: Dienstag, 17. Februar 2015 20:10 >>> To: tcpm@ietf.org >>> Subject: [tcpm] Milestones changed for tcpm WG >>>=20 >>> Changed milestone "Submit document obsoleting undeployed TCP >> extensions to >>> the IESG for publication as an Informational RFC", set state to >> active >>> from review, accepting new milestone. >>>=20 >>> URL: http://datatracker.ietf.org/wg/tcpm/charter/ >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_4E2C4927-CFC0-42B3-B0C0-188F73C45F57 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUJUsoACgkQdyiq39b9uS5KOwCfar+NrMaWS45+fQlZTnSi5NnF 1QoAniOvV2Jfib+xYJyTq1XzHFCmBQXg =OKWr -----END PGP SIGNATURE----- --Apple-Mail=_4E2C4927-CFC0-42B3-B0C0-188F73C45F57-- From nobody Wed Mar 18 13:15:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600831A90D2 for ; Wed, 18 Mar 2015 13:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi4EaASBvGMZ for ; Wed, 18 Mar 2015 13:15:31 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com [15.201.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19511A00FA for ; Wed, 18 Mar 2015 13:15:31 -0700 (PDT) Received: from g4t3433.houston.hp.com (g4t3433.houston.hp.com [16.210.25.219]) by g4t3426.houston.hp.com (Postfix) with ESMTP id EB278AB; Wed, 18 Mar 2015 20:15:30 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g4t3433.houston.hp.com (Postfix) with ESMTP id 98D475F; Wed, 18 Mar 2015 20:15:30 +0000 (UTC) Message-ID: <5509DCE2.800@hp.com> Date: Wed, 18 Mar 2015 13:15:30 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , "tcpm@ietf.org" References: <20150311144838.364EDB0463F@lawyers.icir.org> <550060DE.2070604@room52.net> <5504AFFE.2070306@hp.com> <3ce771b6e88a46a78b444dbf2699a551@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <3ce771b6e88a46a78b444dbf2699a551@hioexcmbx05-prd.hq.netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:15:40 -0000 On 03/15/2015 07:27 AM, Scheffenegger, Richard wrote: > > Hi Rick, > > Isn't most hardware doing receive-offload only on in-sequence segments? > > Both window updates and reordering (loss) would be handled by the CPU > TCP stack, I would assume (but it's been a while since I last studied > offload-engine datasheets). In the Linux world at least, Large Receive Offload in hardware has been "deprecated" in favor of Generic Receive Offload part-way up the stack. The shift was to address concerns on routers where LRO would lead to bogus PathMTU hits. I perhaps simply extrapolated too far from the "can't we separate ACKs and window updates" comment to assume it was meant for the normal data path. rick > I raised my suspicion that the effect he observes is likely on a path > where something disallows SACK - and it would probably make more > sense to put effort in fixing such broken paths. > > Perhaps Lawrence can come up with (anonymized) samples of the issue; > if TS works there, and the sender has a reasonable good understanding > of the RTT, something like TLP might be safe enough to do... short of > RTO recovery. > > Best regards, > Richard > > > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Rick Jones >> Sent: Samstag, 14. Mrz 2015 23:03 >> To: tcpm@ietf.org >> Subject: Re: [tcpm] TCP window updates combined with dup acks sent in >> response to packet loss >> >> On 03/14/2015 11:36 AM, Yoshifumi Nishida wrote: >>> Hi Lawrence, >>> >>> On Wed, Mar 11, 2015 at 8:35 AM, Lawrence Stewart >> > wrote: >>> >>> Question still remains whether relaxing the 5681 definition that a >>> dupack for fast retransmit/fast recovery purposes can't update the >>> window is something that could/should be considered for non-SACK >>> connections. Does anyone recall any attempts to specify such an >>> algorithm? Is it not worth the effort given the prevalence of SACK? >>> >>> >>> Can't we send window updates and dupack separately by using different >> ACKs? >>> Then, we don't have to relax the 5681 definition. >> >> I've not memorized TCP chapter and verse, but I suspect it is only a >> SHOULD that one bundle ACKs and window updates. Still, in the broadest >> handwaving sense, particularly with the presence of the stateless offloads >> and I suppose copy avoidance, sending a standalone ACK or window update is >> just as many CPU cycles as sending a data segment. >> >> And I suppose considering something like segmentation offload, sending an >> ACK may actually be more expensive than sending a data segment, since one >> will get multiple data segments in a single trip down the protocol stack. >> And receive-offload means receiving a bare ACK or window update is more >> expensive than receiving a data segment for the same sort of (somewhat >> handwaving) reasoning. >> >> rick jones >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Mar 18 13:28:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD3C1A88A4 for ; Wed, 18 Mar 2015 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0mgyJIjmVhA for ; Wed, 18 Mar 2015 13:28:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D491A889B for ; Wed, 18 Mar 2015 13:28:37 -0700 (PDT) Received: from vim.isi.edu (vim.isi.edu [128.9.168.184]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t2IKSMZn000030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2015 13:28:22 -0700 (PDT) Message-ID: <5509DFDA.1040801@isi.edu> Date: Wed, 18 Mar 2015 13:28:10 -0700 From: Ted Faber User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20150311144838.364EDB0463F@lawyers.icir.org> <550060DE.2070604@room52.net> <5504AFFE.2070306@hp.com> <3ce771b6e88a46a78b444dbf2699a551@hioexcmbx05-prd.hq.netapp.com> <5509DCE2.800@hp.com> In-Reply-To: <5509DCE2.800@hp.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ELn2RIKXiH9HNwfanUEBhOnArUTpiCS77" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Archived-At: Cc: faber@isi.edu Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:28:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ELn2RIKXiH9HNwfanUEBhOnArUTpiCS77 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/18/2015 13:15, Rick Jones wrote: > On 03/15/2015 07:27 AM, Scheffenegger, Richard wrote: >> >> Hi Rick, >> >> Isn't most hardware doing receive-offload only on in-sequence segments= ? >> >> Both window updates and reordering (loss) would be handled by the CPU >> TCP stack, I would assume (but it's been a while since I last studied >> offload-engine datasheets). >=20 > In the Linux world at least, Large Receive Offload in hardware has been= > "deprecated" in favor of Generic Receive Offload part-way up the stack.= Hi, Rick. On a related note, a student working with Joe Touch and me on implementing the Extended Data Option (EDO) in Linux has encountered some interactions with GRO. We'll have a tech report with the details out in a couple days (including the code) and Joe's sending a presentation to the Dallas IETF. If you're knowledegable about GRO - and it sounds like you are - we'd love to get some feedback. Thanks! --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --ELn2RIKXiH9HNwfanUEBhOnArUTpiCS77 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUJ39sACgkQaUz3f+Zf+Xu4aQCdG3gEN/kIh49tOgPLYGapictB h6IAn0hTzkVJ4dqjYC3VIZ9Tm+5aoVMt =GUUe -----END PGP SIGNATURE----- --ELn2RIKXiH9HNwfanUEBhOnArUTpiCS77-- From nobody Wed Mar 18 18:21:29 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E5B1AC3CC for ; Wed, 18 Mar 2015 18:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abpGSUy_W9SQ for ; Wed, 18 Mar 2015 18:21:27 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C7E1AC407 for ; Wed, 18 Mar 2015 18:20:55 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so44118746obd.3 for ; Wed, 18 Mar 2015 18:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XwrwfNB7mwalcm5tbJ1BfR4dGhS2ZZnrRZbVnC7W5RY=; b=T9FMlyQ6Dn9LlXyNxbf2KhwV7kT69eBleLQ1w/wruNu5D6Ndqu7G7WJWkwnfx+rcVb 3jgTPr8WtiyQtPjz8g0xc2oPh7XulUnPqnGm4tPeAvhm1Pl5dC9YFj3kstnuM6qhahte /64zDWnMjigHEUoNyO5BFV64ypE/Cx8zk1mrXX1wV3/CJrwYJiPe+Tv3mIHCl6xMQn/O P2GpuYM9z78KYVgGukd44ZsjlwtaWmee3KBciMTLMI+5Zo0DVfsNcJPTJdXaNNARR7Ac oPu+Po3E7DoDqHswEjwc5zXkbD9dXtgyOVVC1qPKkr6mvP/xCmXvY3+FMbV8kB4svyHP ECMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XwrwfNB7mwalcm5tbJ1BfR4dGhS2ZZnrRZbVnC7W5RY=; b=QbG1w3lULztktuiVADcWxYVtAQAfhotl6WlPdUMUeK8n96cuwdAP7xS3o3amIj4y4t 4E50mcKi0IDNzQ486CIaHwXSSKDdSyjgpATOQKgHsM+2kAPjiiLHG/itJ9mxJ6RtDpSn +mrJsRYfUCfXNyJiUbgnlwXL2tUJ8bFwVpz/ig8ClFpaw0DWAZthEHudDBprbSccowTI jD515KK8T44PbmO7HMSTt4hyf/2gVFM1v2FtJ8WRKrhMXFZkWWaG5+EHlK/8f5gg5+67 6jFdwA6f1RvR2btYleyTuOdLphxv1yMmtKYPVMdaa2LCo4tYBcUrG0F0StIjvoX5DLuA QhUg== X-Gm-Message-State: ALoCoQkzWcsZePPXwps74F0jA3A9mILDa1Bn629oWBZ4z0YgfZ+Y3xh0iYbMwR9Lqndh5WBGPRy2 MIME-Version: 1.0 X-Received: by 10.202.206.8 with SMTP id e8mr8899427oig.112.1426728054880; Wed, 18 Mar 2015 18:20:54 -0700 (PDT) Received: by 10.202.174.72 with HTTP; Wed, 18 Mar 2015 18:20:54 -0700 (PDT) In-Reply-To: <2235E611-C0A1-42A9-9B00-D584FF3C8B3B@netapp.com> References: <655C07320163294895BBADA28372AF5D16C60F4D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2235E611-C0A1-42A9-9B00-D584FF3C8B3B@netapp.com> Date: Wed, 18 Mar 2015 21:20:54 -0400 Message-ID: From: Neal Cardwell To: "Zimmermann, Alexander" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , Eric Dumazet , "tcpm@ietf.org" Subject: Re: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 01:21:28 -0000 On Wed, Mar 18, 2015 at 6:26 AM, Zimmermann, Alexander wrote: > Hi Michael, > >> Am 18.03.2015 um 11:18 schrieb Scharf, Michael (Michael) : >> >> My understanding is that TCPM recharting is still pending and IESG waits for potential feedback until March 23 [1]. >> >> The chairs are well aware of the strong support for draft-zimmermann-tcpm-cubic during IETF 91. >> We plan to run a formal adoption call once our charter explicitly allows adoption in TCPM. Regarding draft-zimmermann-tcpm-cubic-00: https://tools.ietf.org/id/draft-zimmermann-tcpm-cubic-00.txt I support this draft. But I did want to note that our experience with CUBIC at Google shows that (1) it's important to consider stretch ACKs, and (2) it's critical to carefully consider the maximum rate of cwnd increase for CUBIC in congestion avoidance. I would suggest the following small diffs to the draft: Where the draft says (in sections "3.3. Concave region" and "3.4. Convex region"): In this region, cwnd MUST be incremented by (W(t+RTT) - cwnd)/cwnd for each received ACK. I'd suggest the following new text in these two spots: In this region, cwnd MUST be incremented by min((W(t+RTT) - cwnd)/cwnd, 1/2) for each newly-acknowledged packet. Detailed rationale: (1) First is the issue of the treatment of "stretch ACKs" covering more than 2 packets. The CUBIC paper and the Linux code through v3.18 cap the de facto maximum rate of cwnd increase (in congestion avoidance) at 1 packet for every alternate ACK. In Google's experience with high-BDP paths with receiver hosts using receive offload/aggregation mechanisms (LRO and GRO in Linux terminology), the ACKs for up to 40 or more packets at a time caused this cap of "1 packet for every alternate ACK" to result in cwnd increases that were too slow, leading to underutilization. So our team at Google contributed some changes in v3.19 that changed the rate of increase to be expressed in terms of packets ACKed, rather than number of ACKs. This approach allows full utilization even with receiver offload mechanisms. (2) Second is the issue of the maximum rate of increase of cwnd. As it stands, this document says in section "3.4. Convex region" that: In this region, cwnd MUST be incremented by (W(t+RTT) - cwnd)/cwnd for each received ACK. There is similar language in section "3.3. Concave region". Since the rate of increase of a cubic function can be quite large, if we take this language literally then in steep sections of the curve this can require that the sender "MUST" increase cwnd by quite a large amount. I am not sure what other CUBIC implementations do, but this does not match the CUBIC paper or the Linux implementation. As mentioned above, the CUBIC paper and the Linux code through v3.18 actually cap the de facto maximum rate of cwnd increase (in congestion avoidance) at 1 packet for every alternate ACK. In our recent experiments with using CUBIC for YouTube video traffic using the revised, stretch-ACK-savvy CUBIC logic in Linux v3.19 we saw retransmit rates double due to v3.19 allowing cwnd to increase by 1 packet for every packet ACKed. So in Linux v4.0 we set a limit of increasing cwnd by at most 1 packet for every 2 packets ACKed, which restored the retransmit rates to their previous low levels. For reference: (1) Commits in Linux v3.19 to make CUBIC stretch-ACK-savvy: http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=e73ebb0881ea5534ce606c1d71b4ac44db5c6930 http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=814d488c61260521b1b3cc97063700a5a6667c8f http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=9cd981dcf174d26805a032aefa791436da709bee http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d6b1a8a92a1417f8859a6937d2e6ffe2dfab4e6d (2) Commits slated for Linux v4.0 to fix excessive cwnd growth in CUBIC: http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=9949afa42be0b76f5832db112ce51bb6b35b2abb http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d578e18ce93f5d33a7120fd57c453e22a4c0fc37 neal From nobody Thu Mar 19 09:06:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23F71A1A32 for ; Thu, 19 Mar 2015 09:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBPLOTUA_MvH for ; Thu, 19 Mar 2015 09:06:53 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7461A1A11 for ; Thu, 19 Mar 2015 09:06:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,430,1422950400"; d="asc'?scan'208";a="30691924" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx144-out.netapp.com with ESMTP; 19 Mar 2015 09:01:30 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Mar 2015 09:01:30 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::6036:353f:66f7:c599%21]) with mapi id 15.00.0995.031; Thu, 19 Mar 2015 09:01:30 -0700 From: "Zimmermann, Alexander" To: Neal Cardwell Thread-Topic: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? Thread-Index: AdBhYjpPZb+rJ+RBQHOjk5FmqEicXAAAbAKgAA8umAAAHz5ZAAAevjIA Date: Thu, 19 Mar 2015 16:01:29 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D16C60F4D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2235E611-C0A1-42A9-9B00-D584FF3C8B3B@netapp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_CB11BA13-DE59-4210-876E-830F22070C55"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , Eric Dumazet , "tcpm@ietf.org" Subject: Re: [tcpm] Adoption of draft-zimmermann-tcpm-cubic? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:06:56 -0000 --Apple-Mail=_CB11BA13-DE59-4210-876E-830F22070C55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Neal, thank you so some much for this email. Especially for the summary of the changes you folks did at Google! See inline. > Am 19.03.2015 um 02:20 schrieb Neal Cardwell : >=20 > On Wed, Mar 18, 2015 at 6:26 AM, Zimmermann, Alexander > wrote: >> Hi Michael, >>=20 >>> Am 18.03.2015 um 11:18 schrieb Scharf, Michael (Michael) = : >>>=20 >>> My understanding is that TCPM recharting is still pending and IESG = waits for potential feedback until March 23 [1]. >>>=20 >>> The chairs are well aware of the strong support for = draft-zimmermann-tcpm-cubic during IETF 91. >>> We plan to run a formal adoption call once our charter explicitly = allows adoption in TCPM. >=20 > Regarding draft-zimmermann-tcpm-cubic-00: >=20 > https://tools.ietf.org/id/draft-zimmermann-tcpm-cubic-00.txt >=20 > I support this draft. >=20 > But I did want to note that our experience with CUBIC at Google shows > that (1) it's important to consider stretch ACKs, and (2) it's = critical to > carefully consider the maximum rate of cwnd increase for CUBIC > in congestion avoidance. >=20 > I would suggest the following small diffs to the draft: Ack. If you take a look at my CUBIC presentation at the last IETF (https://tools.ietf.org/agenda/91/slides/slides-91-tcpm-3.pdf), one goal of this exercise will be to incorporate all changes with made to the Linux code so far. You save me a lot of time to scan the code for changes and compare it again w/ the draft. Thanks! >=20 > Where the draft says (in sections "3.3. Concave region" and "3.4. > Convex region"): >=20 > In this region, cwnd MUST be incremented by (W(t+RTT) - cwnd)/cwnd > for each received ACK. >=20 > I'd suggest the following new text in these two spots: >=20 > In this region, cwnd MUST be incremented by > min((W(t+RTT) - cwnd)/cwnd, 1/2) > for each newly-acknowledged packet. >=20 > Detailed rationale: >=20 > (1) First is the issue of the treatment of "stretch ACKs" covering > more than 2 packets. The CUBIC paper and the Linux code through v3.18 > cap the de facto maximum rate of cwnd increase (in congestion > avoidance) at 1 packet for every alternate ACK. In Google's experience > with high-BDP paths with receiver hosts using receive > offload/aggregation mechanisms (LRO and GRO in Linux terminology), the > ACKs for up to 40 or more packets at a time caused this cap of "1 > packet for every alternate ACK" to result in cwnd increases that were > too slow, leading to underutilization. So our team at Google > contributed some changes in v3.19 that changed the rate of increase to > be expressed in terms of packets ACKed, rather than number of ACKs. > This approach allows full utilization even with receiver offload > mechanisms. We may also then recommend ABC for CUBIC when byte based stacks are used=E2=80=A6 >=20 > (2) Second is the issue of the maximum rate of increase of cwnd. As it > stands, this document says in section "3.4. Convex region" that: >=20 > In this region, cwnd MUST be incremented by (W(t+RTT) - cwnd)/cwnd > for each received ACK. >=20 > There is similar language in section "3.3. Concave region". >=20 > Since the rate of increase of a cubic function can be quite large, if > we take this language literally then in steep sections of the curve > this can require that the sender "MUST" increase cwnd by quite > a large amount. >=20 > I am not sure what other CUBIC implementations do, but this does not > match the CUBIC paper or the Linux implementation. As mentioned above, > the CUBIC paper and the Linux code through v3.18 actually cap the de > facto maximum rate of cwnd increase (in congestion avoidance) at 1 > packet for every alternate ACK. >=20 > In our recent experiments with using CUBIC for YouTube video traffic > using the revised, stretch-ACK-savvy CUBIC logic in Linux v3.19 we saw > retransmit rates double due to v3.19 allowing cwnd to increase by 1 > packet for every packet ACKed. >=20 > So in Linux v4.0 we set a limit of increasing cwnd by at most 1 packet > for every 2 packets ACKed, which restored the retransmit rates to > their previous low levels. >=20 > For reference: >=20 > (1) Commits in Linux v3.19 to make CUBIC stretch-ACK-savvy: >=20 > = http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=3De73= ebb0881ea5534ce606c1d71b4ac44db5c6930 > = http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=3D814= d488c61260521b1b3cc97063700a5a6667c8f > = http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=3D9cd= 981dcf174d26805a032aefa791436da709bee > = http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=3Dd6b= 1a8a92a1417f8859a6937d2e6ffe2dfab4e6d >=20 > (2) Commits slated for Linux v4.0 to fix excessive cwnd growth in = CUBIC: >=20 > = http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=3D994= 9afa42be0b76f5832db112ce51bb6b35b2abb > = http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=3Dd57= 8e18ce93f5d33a7120fd57c453e22a4c0fc37 >=20 > neal --Apple-Mail=_CB11BA13-DE59-4210-876E-830F22070C55 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUK8sYACgkQdyiq39b9uS7jWACguuvDxp2Qb+42Hmo0yRVFNAjj w1gAoJnDuYo+PqZcqnJLPcfxb5Krfpdx =ZdHX -----END PGP SIGNATURE----- --Apple-Mail=_CB11BA13-DE59-4210-876E-830F22070C55-- From nobody Sat Mar 21 04:44:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A201A924B for ; Sat, 21 Mar 2015 04:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stZ5d30J-dfQ for ; Sat, 21 Mar 2015 04:44:51 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CBD1A9251 for ; Sat, 21 Mar 2015 04:44:51 -0700 (PDT) Received: by lagg8 with SMTP id g8so104309167lag.1 for ; Sat, 21 Mar 2015 04:44:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1NXipRbp6HFM0bfqLasMwmjEM8r6slxZWyj9EcTaXbc=; b=aP+UA7j0wsih9M9mtre2gcj9Dmff/QHsybY+LH7rwYEX8pNgcXhkazKlX9o0Wxc9W2 Ci3/LUZdapLnsy7UQdc03rXShDUIOg7yW0d05GQnsDWHRTNvNJRtwxGJhHUk68RhstEM imVdwyASCAkV+nwcUsTBfz2Al33UlRVkxlfAy69oVYqGE3tKW9+cLKI2oUp8/knBDipw KHcX/EkJzZivhixc+43Url+FPN7Vkm8fFnwkQ/hKfcUd/iWuOuwBlXzM3o/S5ESSWqWP nwt5Ub+b4PY+Riq7gb/ORbAjJR12D/7/yuXLyEWW97XPI2y5Qw0vCwiIenD+Sbb/Il7S 9+aA== X-Gm-Message-State: ALoCoQlsx3YAZY/8hxQ9WzuIr58ZTkkDMX9dwhRlqHe+8auD2Q1D4RL9imqH/vQquKQEKaGQzI3C MIME-Version: 1.0 X-Received: by 10.112.63.165 with SMTP id h5mr75140099lbs.16.1426938289378; Sat, 21 Mar 2015 04:44:49 -0700 (PDT) Received: by 10.25.24.164 with HTTP; Sat, 21 Mar 2015 04:44:49 -0700 (PDT) In-Reply-To: References: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> Date: Sat, 21 Mar 2015 12:44:49 +0100 Message-ID: From: Hagen Paul Pfeifer To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org" Subject: Re: [tcpm] Initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 11:44:53 -0000 On 17 March 2015 at 12:44, Michael Welzl wrote: > If you want to repeat the test, this was pretty easy to do. Here's what I did: > - get a web page, watch wireshark, find a URL of an object (image or something) that's larger than 10 packets > - do the following with help of scapy ( http://www.secdev.org/projects/scapy/ ): > * send a TCP SYN, respond to the SYN/ACK with a correct ACK > * disable all outgoing ACKs with the firewall > * send a HTTP GET to the address of the large object with scapy > * watch how many packets come back, in wireshark This could and should be less complicated if you want to do this on a large basis: - "Spider" over a list of websites and grab at least a MSS * 10 byte object (probably more because some CDN violates IW10 and IW15 and more). - Capture all data in a pcap file - Analyse the file and check for IW, using a python script: - Separate on a per TCP connection basis - Ignore TWH and HTTP GET request, count first burst hgn From nobody Sat Mar 21 06:59:16 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20C11ABC10 for ; Sat, 21 Mar 2015 06:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjTl-yBTiUrd for ; Sat, 21 Mar 2015 06:59:13 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8FE1ABB19 for ; Sat, 21 Mar 2015 06:59:13 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YZJvj-0000yV-2u; Sat, 21 Mar 2015 14:59:11 +0100 Received: from [31.221.87.81] (helo=[10.32.100.84]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1YZJvi-0002RD-Hf; Sat, 21 Mar 2015 14:59:11 +0100 References: <81564C0D7D4D2A4B9A86C8C7404A13DA320C6182@ESESSMB205.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Michael Welzl Date: Sat, 21 Mar 2015 13:59:08 +0000 To: Hagen Paul Pfeifer X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 1 total rcpts 26681 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C3C25904546D49DFFCE072DD1213C46542890092 X-UiO-SPAM-Test: remote_host: 31.221.87.81 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 149 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org" Subject: Re: [tcpm] Initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 13:59:16 -0000 well this is roughly what i meant when i said "could be automatized" :) Sent from my iPhone > On 21. mars 2015, at 11:44, Hagen Paul Pfeifer wrote: >=20 >> On 17 March 2015 at 12:44, Michael Welzl wrote: >>=20 >> If you want to repeat the test, this was pretty easy to do. Here's what I= did: >> - get a web page, watch wireshark, find a URL of an object (image or some= thing) that's larger than 10 packets >> - do the following with help of scapy ( http://www.secdev.org/projects/s= capy/ ): >> * send a TCP SYN, respond to the SYN/ACK with a correct ACK >> * disable all outgoing ACKs with the firewall >> * send a HTTP GET to the address of the large object with scapy >> * watch how many packets come back, in wireshark >=20 > This could and should be less complicated if you want to do this on a > large basis: >=20 > - "Spider" over a list of websites and grab at least a MSS * 10 byte > object (probably more because some CDN violates IW10 and IW15 and > more). > - Capture all data in a pcap file > - Analyse the file and check for IW, using a python script: > - Separate on a per TCP connection basis > - Ignore TWH and HTTP GET request, count first burst >=20 > hgn From nobody Sun Mar 22 05:17:22 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BE11A908F for ; Sun, 22 Mar 2015 05:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYnuSgSd1SuO for ; Sun, 22 Mar 2015 05:17:19 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3670C1A907C for ; Sun, 22 Mar 2015 05:17:19 -0700 (PDT) Received: by webee49 with SMTP id ee49so7233528web.2 for ; Sun, 22 Mar 2015 05:17:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D0eW4+q26XB0BiCfFDaLLNr1BcZU5PV+c31B8VsN6PM=; b=XyduBeciz+0jClCII6EE86BAVgC/zsDCsg11tOCO7mxUChAnHUszBFTNp2n0Xb3K1t HfVXYxe9kVLDUoL6XB8xok6xtyItu9zuPCne03291q2yfC1Sv77qPhrHNvmWukW0/Ysf Q5SmA/QWo1IKf7RNOlK+HWOkz5Azh+WF2wzwMjI8FkT8vKPJyOrC9RQesV+stAgAYtGt UX8j9MqikNaIrQNMNMB9UGDUsSUEQ0Nk3KFcJSYlPlWm4XhxAPDiDfy84W9U9gyzq4c2 U16QTdKFUKTgR/jPzrwWq1K2J025Zbt7nT481GVBE/VLRDKPDv0//qpYrEo25g0JIBzn oScw== X-Gm-Message-State: ALoCoQnhg/zZprN5kiKAbvQPFicE5qN6G51qVmAds4laKnLI4m8z1+lKTJL+ph6G5qKXU9JEaKPZ MIME-Version: 1.0 X-Received: by 10.180.93.5 with SMTP id cq5mr11094878wib.18.1427026637931; Sun, 22 Mar 2015 05:17:17 -0700 (PDT) Received: by 10.194.134.106 with HTTP; Sun, 22 Mar 2015 05:17:17 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sun, 22 Mar 2015 13:17:17 +0100 Message-ID: From: Olivier Bonaventure To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=f46d043c806ad6d2f20511df87fa Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 12:17:21 -0000 --f46d043c806ad6d2f20511df87fa Content-Type: text/plain; charset=UTF-8 Michael, > > TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming > meeting [1]. At this stage, TCPM is really interested in feedback from > implementers and potential users, e.g., regarding feature gaps or > deployment problems. > > In a previous discussion, TCPINC was identified as one potential user of > EDO [2]. I understand that the TCPINC design is still at a early stage. > Still, if there are thoughts on EDO in the TCPINC community, please feel > free to share them on the TCPM list, or please talk us in the next TCPM > meeting. > > Based on the experience in extending TCP in the mptcp working group, I would be really useful to collect measurements about how deployed middleboxes interact with the EDO option as it is currently defined. The working group should encourage such studies to understand the possible limitations of EDO. Olivier --f46d043c806ad6d2f20511df87fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,
=C2=A0

TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming = meeting [1]. At this stage, TCPM is really interested in feedback from impl= ementers and potential users, e.g., regarding feature gaps or deployment pr= oblems.

In a previous discussion, TCPINC was identified as one potential user of ED= O [2]. I understand that the TCPINC design is still at a early stage. Still= , if there are thoughts on EDO in the TCPINC community, please feel free to= share them on the TCPM list, or please talk us in the next TCPM meeting.


Based on the experien= ce in extending TCP in the mptcp working group, =C2=A0I would be really use= ful to collect measurements about how deployed middleboxes interact with th= e EDO option as it is currently defined. The working group should encourage= such studies to understand the possible limitations of EDO.

=
Olivier
--f46d043c806ad6d2f20511df87fa-- From nobody Sun Mar 22 08:44:51 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C621F1A8A7C for ; Sun, 22 Mar 2015 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9YzlNh9wZIS for ; Sun, 22 Mar 2015 08:44:47 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E381A8A28 for ; Sun, 22 Mar 2015 08:44:46 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C01FB19349E3F; Sun, 22 Mar 2015 15:44:40 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2MFihWU018410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Mar 2015 16:44:44 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 22 Mar 2015 16:44:44 +0100 From: "Scharf, Michael (Michael)" To: Olivier Bonaventure Thread-Topic: [tcpm] Feedback on EDO? Thread-Index: AdBcAcphoSG3+U2QQLmutmh6AepctQIj/buAAAj2Y6A= Date: Sun, 22 Mar 2015 15:44:43 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C64C2D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D16C64C2DFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:44:50 -0000 --_000_655C07320163294895BBADA28372AF5D16C64C2DFR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0xpbWl0ZWQgdG8gVENQTV0NCg0KSW5kZWVkLCB3ZSByZWFsbHkgbG9vayBmb3IgZXhwZXJpbWVu dHMgd2l0aCBFRE8gcmlnaHQgbm93LiBJIGd1ZXNzIFRDUE0gd291bGQgYmUgdmVyeSBvcGVuIHRv IHByZXNlbnRhdGlvbnMgb2YgZXhwZXJpbWVudHMgYW5kIG1lYXN1cmVtZW50IHJlc3VsdHMgZm9y IEVETyAob3Igb3RoZXIgc2NoZW1lcykuDQoNCldlIGNvdWxkIGRpc2N1c3MgcHVibGljYXRpb24g b2YgYW4gKGluZm9ybWF0aW9uYWwpIFJGQyBpbiB0aGlzIHNwYWNlLCBpZiBhIFRDUE0gUkZDIHdh cyBhbiBpbmNlbnRpdmUgZm9yIGV4cGVyaW1lbnRlcnMgdG8gY29tZSB1cCB3aXRoIGdvb2QgZGF0 YS4NCg0KTWljaGFlbA0KDQoNCkZyb206IE9saXZpZXIgQm9uYXZlbnR1cmUgW21haWx0bzpib25h dmVudHVyZUBpZWVlLm9yZ10NClNlbnQ6IFN1bmRheSwgTWFyY2ggMjIsIDIwMTUgMToxNyBQTQ0K VG86IFNjaGFyZiwgTWljaGFlbCAoTWljaGFlbCkNCkNjOiB0Y3BpbmNAaWV0Zi5vcmc7IHRjcG1A aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gRmVlZGJhY2sgb24gRURPPw0KDQpNaWNoYWVs LA0KDQoNClRDUE0gaGFzIHNjaGVkdWxlZCBhIGRpc2N1c3Npb24gb2YgZHJhZnQtaWV0Zi10Y3Bt LXRjcC1lZG8gaW4gdGhlIHVwY29taW5nIG1lZXRpbmcgWzFdLiBBdCB0aGlzIHN0YWdlLCBUQ1BN IGlzIHJlYWxseSBpbnRlcmVzdGVkIGluIGZlZWRiYWNrIGZyb20gaW1wbGVtZW50ZXJzIGFuZCBw b3RlbnRpYWwgdXNlcnMsIGUuZy4sIHJlZ2FyZGluZyBmZWF0dXJlIGdhcHMgb3IgZGVwbG95bWVu dCBwcm9ibGVtcy4NCg0KSW4gYSBwcmV2aW91cyBkaXNjdXNzaW9uLCBUQ1BJTkMgd2FzIGlkZW50 aWZpZWQgYXMgb25lIHBvdGVudGlhbCB1c2VyIG9mIEVETyBbMl0uIEkgdW5kZXJzdGFuZCB0aGF0 IHRoZSBUQ1BJTkMgZGVzaWduIGlzIHN0aWxsIGF0IGEgZWFybHkgc3RhZ2UuIFN0aWxsLCBpZiB0 aGVyZSBhcmUgdGhvdWdodHMgb24gRURPIGluIHRoZSBUQ1BJTkMgY29tbXVuaXR5LCBwbGVhc2Ug ZmVlbCBmcmVlIHRvIHNoYXJlIHRoZW0gb24gdGhlIFRDUE0gbGlzdCwgb3IgcGxlYXNlIHRhbGsg dXMgaW4gdGhlIG5leHQgVENQTSBtZWV0aW5nLg0KDQoNCkJhc2VkIG9uIHRoZSBleHBlcmllbmNl IGluIGV4dGVuZGluZyBUQ1AgaW4gdGhlIG1wdGNwIHdvcmtpbmcgZ3JvdXAsICBJIHdvdWxkIGJl IHJlYWxseSB1c2VmdWwgdG8gY29sbGVjdCBtZWFzdXJlbWVudHMgYWJvdXQgaG93IGRlcGxveWVk IG1pZGRsZWJveGVzIGludGVyYWN0IHdpdGggdGhlIEVETyBvcHRpb24gYXMgaXQgaXMgY3VycmVu dGx5IGRlZmluZWQuIFRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBlbmNvdXJhZ2Ugc3VjaCBzdHVk aWVzIHRvIHVuZGVyc3RhbmQgdGhlIHBvc3NpYmxlIGxpbWl0YXRpb25zIG9mIEVETy4NCg0KT2xp dmllcg0K --_000_655C07320163294895BBADA28372AF5D16C64C2DFR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0xpbWl0ZWQgdG8gVENQTV08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JbmRlZWQsIHdlIHJlYWxseSBsb29rIGZvciBleHBlcmltZW50 cyB3aXRoIEVETyByaWdodCBub3cuIEkgZ3Vlc3MgVENQTSB3b3VsZCBiZSB2ZXJ5IG9wZW4gdG8g cHJlc2VudGF0aW9ucyBvZiBleHBlcmltZW50cyBhbmQgbWVhc3VyZW1lbnQgcmVzdWx0cw0KIGZv ciBFRE8gKG9yIG90aGVyIHNjaGVtZXMpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+V2UgY291bGQgZGlzY3VzcyBwdWJsaWNhdGlvbiBvZiBhbiAoaW5mb3JtYXRpb25hbCkg UkZDIGluIHRoaXMgc3BhY2UsIGlmIGEgVENQTSBSRkMgd2FzIGFuIGluY2VudGl2ZSBmb3IgZXhw ZXJpbWVudGVycyB0byBjb21lIHVwIHdpdGggZ29vZCBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IE9saXZpZXIgQm9uYXZlbnR1cmUgW21haWx0bzpib25hdmVudHVy ZUBpZWVlLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1hcmNoIDIyLCAyMDE1IDE6 MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAoTWljaGFlbCk8YnI+DQo8Yj5D Yzo8L2I+IHRjcGluY0BpZXRmLm9yZzsgdGNwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3RjcG1dIEZlZWRiYWNrIG9uIEVETz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWljaGFlbCw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpUQ1BNIGhhcyBzY2hlZHVsZWQg YSBkaXNjdXNzaW9uIG9mIGRyYWZ0LWlldGYtdGNwbS10Y3AtZWRvIGluIHRoZSB1cGNvbWluZyBt ZWV0aW5nIFsxXS4gQXQgdGhpcyBzdGFnZSwgVENQTSBpcyByZWFsbHkgaW50ZXJlc3RlZCBpbiBm ZWVkYmFjayBmcm9tIGltcGxlbWVudGVycyBhbmQgcG90ZW50aWFsIHVzZXJzLCBlLmcuLCByZWdh cmRpbmcgZmVhdHVyZSBnYXBzIG9yIGRlcGxveW1lbnQgcHJvYmxlbXMuPGJyPg0KPGJyPg0KSW4g YSBwcmV2aW91cyBkaXNjdXNzaW9uLCBUQ1BJTkMgd2FzIGlkZW50aWZpZWQgYXMgb25lIHBvdGVu dGlhbCB1c2VyIG9mIEVETyBbMl0uIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBUQ1BJTkMgZGVzaWdu IGlzIHN0aWxsIGF0IGEgZWFybHkgc3RhZ2UuIFN0aWxsLCBpZiB0aGVyZSBhcmUgdGhvdWdodHMg b24gRURPIGluIHRoZSBUQ1BJTkMgY29tbXVuaXR5LCBwbGVhc2UgZmVlbCBmcmVlIHRvIHNoYXJl IHRoZW0gb24gdGhlIFRDUE0gbGlzdCwgb3INCiBwbGVhc2UgdGFsayB1cyBpbiB0aGUgbmV4dCBU Q1BNIG1lZXRpbmcuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJhc2VkIG9uIHRoZSBleHBlcmllbmNlIGluIGV4dGVuZGluZyBU Q1AgaW4gdGhlIG1wdGNwIHdvcmtpbmcgZ3JvdXAsICZuYnNwO0kgd291bGQgYmUgcmVhbGx5IHVz ZWZ1bCB0byBjb2xsZWN0IG1lYXN1cmVtZW50cyBhYm91dCBob3cgZGVwbG95ZWQgbWlkZGxlYm94 ZXMgaW50ZXJhY3Qgd2l0aCB0aGUgRURPIG9wdGlvbiBhcyBpdCBpcyBjdXJyZW50bHkgZGVmaW5l ZC4gVGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGVuY291cmFnZQ0KIHN1Y2ggc3R1ZGllcyB0byB1 bmRlcnN0YW5kIHRoZSBwb3NzaWJsZSBsaW1pdGF0aW9ucyBvZiBFRE8uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9saXZpZXI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_655C07320163294895BBADA28372AF5D16C64C2DFR712WXCHMBA15z_-- From nobody Mon Mar 23 11:29:12 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BB31AD0B2 for ; Mon, 23 Mar 2015 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxKzFhH01c2K for ; Mon, 23 Mar 2015 11:29:09 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02F71AD0C5 for ; Mon, 23 Mar 2015 11:28:59 -0700 (PDT) Received: by iedm5 with SMTP id m5so42805229ied.3 for ; Mon, 23 Mar 2015 11:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=l6GlkM4kwuj746YVkOv+kNYNvSv7Otc7BVeUpOuLiEM=; b=Aa5M4uiOUMFYnv/TklXlqh9ahL8oyZnaNILG6/2H+s2keBZTE2SYisoD0zPpYZxyfE ijPtsOt+nNSrD8+T+i92nZAC1GTM0J+pYQk9EEmJx5cyFUbwIuhuR677WJfmGXr2272p W8X7WV+mY9udXVRBp9BqCcWie0s5JEjo5s7QE7+LH8j9vOOUQkMeQlxSM1LcvFEWUfRE YcaQiIAUauC+cSTPzCS+QZzRop8dzZ7hBrdQs2gt7rLlejEYUzKD+mlYZqWlDGGFxRTr QCOFiyVkxeCLsuXgT9Mb+lZg57FIbfszhzjtyfpshgcBBWEzbsOrSUHvDRrjqDwApPW5 pjoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=l6GlkM4kwuj746YVkOv+kNYNvSv7Otc7BVeUpOuLiEM=; b=YfY+N8OU3tvg9s1ES7z1eRs2p3921RQqSZgvOTy1K5DXUjfEkUBGJIGdVc/FWfgcOm f5SiIzpg+h9z0wOI1h6k1xY7fL7kWtmCMW2i2xd1JsnzSUnXoWA+rjTko+zX/swAwqI8 tdo7qZblJjyV3EUKevUA8jST3CcNOWzPYtdPj/Kfb9UN8pqe5nkaJvB2XRo+oZ6q4MM/ BcvyrhVlRBMeifHyWccYKuT53SiBO2r1Np93Qnh99PLoRDfkgQJ/h5huZEGQvyDvp1Zx Pv9b+wY60wbD5vmDvsh38Qz4FZ3jo8+SyzpQ+wf5ARAJ/lf3bmqUi2Cibw7RoNwFEe/5 5Tng== X-Gm-Message-State: ALoCoQmuYWBzKixccB8VPV8g3XLIlzN5fu6vep4CaxafTQGa14wTKp3rcgroEsr9jHsuEhZEMYmN X-Received: by 10.107.4.3 with SMTP id 3mr686725ioe.57.1427135338935; Mon, 23 Mar 2015 11:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.79 with HTTP; Mon, 23 Mar 2015 11:28:18 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 23 Mar 2015 13:28:18 -0500 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:29:10 -0000 On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) wrote: > > Hi, > > TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcomin= g meeting [1]. At this stage, TCPM is really interested in feedback from im= plementers and potential users, e.g., regarding feature gaps or deployment = problems. Which (experimental) TCP feature requires EDO? Does tcpcrypt require EDO? Same question applies to proposals extending option space in SYN. > > > In a previous discussion, TCPINC was identified as one potential user of = EDO [2]. I understand that the TCPINC design is still at a early stage. Sti= ll, if there are thoughts on EDO in the TCPINC community, please feel free = to share them on the TCPM list, or please talk us in the next TCPM meeting. > > Thanks > > Michael (TCPM co-chair) > > > [1] https://datatracker.ietf.org/meeting/92/agenda/tcpm/ > > [2] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00429.html > > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc From nobody Mon Mar 23 11:36:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0801AD0C9 for ; Mon, 23 Mar 2015 11:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxqbEpp6pD7E for ; Mon, 23 Mar 2015 11:36:48 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DFC1AD069 for ; Mon, 23 Mar 2015 11:36:48 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so46710887igb.1 for ; Mon, 23 Mar 2015 11:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=MCNVxkii8HsDY3YbSZSlAPXNs+iIngDkdlbZj9ltROg=; b=lQ2eO5/TgrOTb8jgukP0AGi4m10ADVqAdVFaR0QU3PQmCi37a6tYF6gWjS6VCcgwSW QXVGxBla2KE/BtGVMLsC8KJ+aSIHxstQIgv/tz4Cm5GWm+XZWUf6uG1BAWyjnjQqZ7l0 g6mjfn6rMt+Ld3ttr/m7wIXA0ICFNGFS1232mx1UiWWZdksPP/46Sn/aJB+Csz1qagTb CEkC+Uz0wJ4XIdLDAxxAMxUQmn9rJV+KDHlN+a9BKe7yDY5Qy3J3JmDfWerBV1p42TPS STpdyT2wnmaCBUcrnbZYMvrU3C4wZBnqxz55bI2psfOPPRFIG1O3QhDNJgMJ+vZmJSOA M0OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=MCNVxkii8HsDY3YbSZSlAPXNs+iIngDkdlbZj9ltROg=; b=cHgz2vNee1b9bQPZ6OK1HWfyBqp29d2eu37+SIqe7zGRmL6HiNLdOVftDQBjrmKheg N6i43yJ30JL7k1KOhYBqKM/XAaDH4UVo4fV1IHy4J1aCf2vCgM5Z++3vc53wbphidL5L JEUGpmC39fndCEm1gciSgFyW3ZwdmIF15vIyZqXAUuHiWR5Sca4DEueJRv1WcZEQCu5a I41xGDr+Pt3T99iwNujtd/+MH7pp/3MZzwFWkomF3mx4t+wa3u7bwQ/tGW460MD5tLGg b3LSwt9rhzlXYLzEZ9sBCvUUwWGLO1mJKDRQEMG3Io7bGzDvH9s07eTen2dcG9Ipnxvz Yy7w== X-Gm-Message-State: ALoCoQn9PvyzAinPT0V0Wrvvo5BaFdvCwee1wpzgDXJ2Vpx/d3ZM26oBXPeWaNHis5f1qmJsFGjx X-Received: by 10.107.170.220 with SMTP id g89mr683252ioj.85.1427135808255; Mon, 23 Mar 2015 11:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.79 with HTTP; Mon, 23 Mar 2015 11:36:08 -0700 (PDT) From: Yuchung Cheng Date: Mon, 23 Mar 2015 13:36:08 -0500 Message-ID: To: Wesley Eddy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: [tcpm] 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:36:49 -0000 is there an easy way to get the diff of 793 and the latest 793bis? i found reviewing the 793bis directly hard. thanks. From nobody Mon Mar 23 11:52:02 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16AB1AD358; Mon, 23 Mar 2015 11:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IdmhPefEbcR; Mon, 23 Mar 2015 11:51:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2F91A8A7A; Mon, 23 Mar 2015 11:51:53 -0700 (PDT) Received: from [128.9.176.213] (c2-vpn04.isi.edu [128.9.176.213]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t2NIpawa014972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 11:51:37 -0700 (PDT) Message-ID: <551060B7.2000901@isi.edu> Date: Mon, 23 Mar 2015 11:51:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yuchung Cheng , "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:51:57 -0000 On 3/23/2015 11:28 AM, Yuchung Cheng wrote: > On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) > wrote: >> >> Hi, >> >> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming meeting [1]. At this stage, TCPM is really interested in feedback from implementers and potential users, e.g., regarding feature gaps or deployment problems. > > Which (experimental) TCP feature requires EDO? Does tcpcrypt require EDO? > > Same question applies to proposals extending option space in SYN. The answer to both questions in the motivation section of the drafts. Joe From nobody Mon Mar 23 11:52:27 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AD61AD21C for ; Mon, 23 Mar 2015 11:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_ZoEKZJpDQU for ; Mon, 23 Mar 2015 11:52:24 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90EA1AD0CE for ; Mon, 23 Mar 2015 11:52:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,453,1422950400"; d="scan'208";a="32082550" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx141-out.netapp.com with ESMTP; 23 Mar 2015 11:51:23 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 23 Mar 2015 11:51:22 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Mon, 23 Mar 2015 11:51:23 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng , Wesley Eddy Thread-Topic: [tcpm] 793bis Thread-Index: AQHQZZiAR8Ex2WwWeUGODRdq2g7LxZ0qaKXg Date: Mon, 23 Mar 2015 18:51:22 +0000 Message-ID: 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.120.60.36] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:52:26 -0000 Yuchung, Will https://tools.ietf.org/rfcdiff between http://tools.ietf.org/rfc/rfc79= 3.txt and https://tools.ietf.org/id/draft-eddy-rfc793bis-05.txt work for yo= u? https://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/rfc/rfc793.txt&= url2=3Dhttps://tools.ietf.org/id/draft-eddy-rfc793bis-05.txt However, rfcdiff does a bad job - the delta seems to be too large with the = new boilerplate and formatting... Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng > Sent: Montag, 23. M=E4rz 2015 13:36 > To: Wesley Eddy > Cc: tcpm@ietf.org Extensions > Subject: [tcpm] 793bis >=20 > is there an easy way to get the diff of 793 and the latest 793bis? i foun= d > reviewing the 793bis directly hard. >=20 > thanks. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Mar 23 12:26:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABC61B29BA for ; Mon, 23 Mar 2015 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncQXzNFfJ3tS for ; Mon, 23 Mar 2015 12:26:01 -0700 (PDT) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8311B29AE for ; Mon, 23 Mar 2015 12:26:01 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2NJQ0cH012439 for ; Mon, 23 Mar 2015 15:26:00 -0400 Received: (qmail 24781 invoked by uid 0); 23 Mar 2015 19:26:00 -0000 X-TCPREMOTEIP: 31.133.142.231 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?31.133.142.231?) (wes@mti-systems.com@31.133.142.231) by 0 with ESMTPA; 23 Mar 2015 19:25:59 -0000 Message-ID: <551068C5.8020600@mti-systems.com> Date: Mon, 23 Mar 2015 15:25:57 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , Yuchung Cheng References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:26:07 -0000 I suggest the side-by-side rfcdiff format. If you do a diff between -01 and 793, you can see that it pretty much just is 793 in XML2RFC. Beyond that, the revisions can each be thought of like patches, each intended to deal with one (or a small number) of specific things. Doing the diffs between subsequent revisions from -01 and referring to the change descriptions that are within the document *should* be a clear way to follow the trail of changes. If not, then we should figure out a better way together. On 3/23/2015 2:51 PM, Scheffenegger, Richard wrote: > Yuchung, > > Will https://tools.ietf.org/rfcdiff between http://tools.ietf.org/rfc/rfc793.txt and https://tools.ietf.org/id/draft-eddy-rfc793bis-05.txt work for you? > > > https://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/rfc/rfc793.txt&url2=https://tools.ietf.org/id/draft-eddy-rfc793bis-05.txt > > > However, rfcdiff does a bad job - the delta seems to be too large with the new boilerplate and formatting... > > > Best regards, > Richard > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng >> Sent: Montag, 23. Mrz 2015 13:36 >> To: Wesley Eddy >> Cc: tcpm@ietf.org Extensions >> Subject: [tcpm] 793bis >> >> is there an easy way to get the diff of 793 and the latest 793bis? i found >> reviewing the 793bis directly hard. >> >> thanks. >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > -- Wes Eddy MTI Systems From nobody Mon Mar 23 12:45:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB651A0371 for ; Mon, 23 Mar 2015 12:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S2ebEht0Srh for ; Mon, 23 Mar 2015 12:45:04 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id 46C3B1A035F for ; Mon, 23 Mar 2015 12:45:04 -0700 (PDT) Received: from [10.64.27.179] (unknown [69.53.236.236]) by lauren.room52.net (Postfix) with ESMTPSA id A39907E81E; Tue, 24 Mar 2015 06:45:00 +1100 (EST) Message-ID: <55106D39.2040509@room52.net> Date: Mon, 23 Mar 2015 14:44:57 -0500 From: Lawrence Stewart User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20150311161904.2B5F4B0858C@lawyers.icir.org> <5500E79A.4050002@room52.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:45:06 -0000 Hi Richard, Apologies for the delay. On 03/13/15 21:42, Scheffenegger, Richard wrote: > Lawrence, > > Well, I can see that very light-weight implementations of TCP don't > support SACK (IoT; but then, SoCs are nowadays powerful&cheap enough > and have enough memory to deal with at least a minimum SACK > implementation). > > For devices capable of decoding video streams, there really is no > excuse to not deploy a SACK capable TCP stack; have you tested those > devices that you mention which don't support SACK in house and ruled > out path interference (ie. meddleboxes removing SACK, when they do > some Seq# rewriting etc)? There's a mix. I know for sure that some of the devices weren't advertising SACK, and others I have no idea if it was the device or a middle box. After I finish gathering some fresh data to determine how often Netflix is seeing window updates combined with dup acks for non SACK flows which end up triggering an RTO, I'll be able to figure out whether this is worth looking into deeper or not. I just wanted to initiate this initial discussion to figure out what the history around this topic was and gather some thoughts. > Because of the above, I would suspect that you are probably looking > at such path impairments rather than end-device impairments... From my perspective, it makes no difference - if I have to try ensure the highest possible user experience across a TCP session that is being crippled by stupid middle boxes, lucky me :/ > OTOH, You may want to look into TLP [1]. TLP is also only defined for > SACK-enabled sessions; Implementing TLP for FreeBSD has been on my todo list for some time unless someone beats me to it. > One thought: If you have TS enabled on these real-world flows you > mentioned, and the data transmitted just before has all those packets > sent with newer timestamps then the one in the window update - > perhaps that could be a high enough bar to do a one-time TLP in > NewReno... > > > > One would assume that for a genuine window-update, the reflected > timestamps wouldn't go stale for that long (>1RTT). > > Perhaps combining the information with what you have in TS may be > conservative enough, to do a TLP one RTT after the 3rd window update; > note that a non-SACK TLP will have to be the next segment after > SndUna, not the highest. > > But when you are implementing this, you probably need to be wary of > Eifel detection IPR. Sounds plausible. I'll revisit this discussion once I have some fresh data at hand. > In this particular case, of course SACK should have triggered the > fast retransmission. Indeed. Cheers, Lawrence From nobody Mon Mar 23 12:46:44 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A451A034F; Mon, 23 Mar 2015 12:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-nB6yFQBU5m; Mon, 23 Mar 2015 12:46:39 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FB41B29EB; Mon, 23 Mar 2015 12:46:34 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id ED9FA2780BE; Tue, 24 Mar 2015 04:46:31 +0900 (JST) Received: by wgdm6 with SMTP id m6so154568355wgd.2; Mon, 23 Mar 2015 12:46:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.80.37 with SMTP id o5mr21826762wix.65.1427139989518; Mon, 23 Mar 2015 12:46:29 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Mon, 23 Mar 2015 12:46:29 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 23 Mar 2015 12:46:29 -0700 Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: multipart/alternative; boundary=f46d044286441ec0700511f9eca2 Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:46:41 -0000 --f46d044286441ec0700511f9eca2 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 11:28 AM, Yuchung Cheng wrote: > On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) > wrote: > > > > Hi, > > > > TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the > upcoming meeting [1]. At this stage, TCPM is really interested in feedback > from implementers and potential users, e.g., regarding feature gaps or > deployment problems. > > Which (experimental) TCP feature requires EDO? Does tcpcrypt require EDO? > Well, SACK? But, I guess common cases will be a combination of extensions, not a specific one. -- Yoshi > Same question applies to proposals extending option space in SYN. > > > > > > > In a previous discussion, TCPINC was identified as one potential user of > EDO [2]. I understand that the TCPINC design is still at a early stage. > Still, if there are thoughts on EDO in the TCPINC community, please feel > free to share them on the TCPM list, or please talk us in the next TCPM > meeting. > > > > Thanks > > > > Michael (TCPM co-chair) > > > > > > [1] https://datatracker.ietf.org/meeting/92/agenda/tcpm/ > > > > [2] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00429.html > > > > _______________________________________________ > > Tcpinc mailing list > > Tcpinc@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpinc > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --f46d044286441ec0700511f9eca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 23, 2015 at 11:28 AM, Yuchung Cheng <= ycheng@google.com> wrote:
On W= ed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael)
<michael.scharf@alc= atel-lucent.com> wrote:
>
> Hi,
>
> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upco= ming meeting [1]. At this stage, TCPM is really interested in feedback from= implementers and potential users, e.g., regarding feature gaps or deployme= nt problems.

Which (experimental)=C2=A0 TCP feature requires EDO? Does tcpcrypt r= equire EDO?

Well, SACK? But, I guess co= mmon cases will be a combination of extensions, not a specific one.
--
Yoshi



Same question applies to proposals extending option space in SYN.

>
>
> In a previous discussion, TCPINC was identified as one potential user = of EDO [2]. I understand that the TCPINC design is still at a early stage. = Still, if there are thoughts on EDO in the TCPINC community, please feel fr= ee to share them on the TCPM list, or please talk us in the next TCPM meeti= ng.
>
> Thanks
>
> Michael (TCPM co-chair)
>
>
> [1] https://datatracker.ietf.org/meeting/92/agenda/tcpm/ >
> [2] http://www.ietf.org/mail-archive/web/tcpinc/c= urrent/msg00429.html
>
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc

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

--f46d044286441ec0700511f9eca2-- From nobody Mon Mar 23 13:46:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474261B2A2D for ; Mon, 23 Mar 2015 13:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbvbvdGUKtfJ for ; Mon, 23 Mar 2015 13:46:05 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7783A1B2A22 for ; Mon, 23 Mar 2015 13:46:04 -0700 (PDT) Received: by iedm5 with SMTP id m5so45776756ied.3 for ; Mon, 23 Mar 2015 13:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=von5B1dEAUK7W4I0ueDS70sPjtL8fk2ofAcEK5Nu73A=; b=RkGa7V7035oFBfkJu0acJ3qdlZVw5dmtuPSHbqhMnC9jfwkyERvMtjjBrufl2CFaFG iqRlsott+blrGW3p4ceqrtkiE3bKvmqLquBNoGVist4VesMYy6a4oCMky07XdSVjrwq5 qK8DGYElohtRkYQF2TrmPCUkUeFgTRxs/HiIWedIbG3dKsWv+ggpbD92Lf4O/AXGm6QE QMXK+Z5eVuSkz6lPw6AXYmLP1ePtHPDVswVnYVCTCsL2OC7vsWrgisXMqo0ausjpR0U6 bETHav8011+sklHWgmlJ5QY6w50uzPlH7avvF9f/Yk5oeqlTEkj4aBDB+6HdGoZK0p1t Gisw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=von5B1dEAUK7W4I0ueDS70sPjtL8fk2ofAcEK5Nu73A=; b=L+Cilk/kY5cTItNQSVkwPe0Hm8pjFxaMXDKANZQiJXGloCZNOvNNEkdZhPf1I3QjC9 8fN1IncpCXVkJalPgRgfqz2NrUBkJMUwdrejPswaJpXGH90zuOMOqLZzZKdhrNnvdWsG lPqVeEqPKLmlLNladJw9TGw1MPSus49hdLIzdIyLw+Xkjod/X5ALJKvb47tD+xY7Yzvf 6NwBtZ/iODUfh17G/RRBoU7/ceniHto52fn0SXrZq/5jdzgZ8ymwJdbLcryKI6qu0Osf y8GkZnAY0jnsIQ64Mp0Of8ueCJi532aDPC/G+H/Iy4eY+zsN9T8QhWrMQv3HsoH+lqBL 8q6Q== X-Gm-Message-State: ALoCoQnVi+F6t9SnRkEtXvnziTLEjpcE5rFENABrScwW5KSLeZrsyeISdxT/p8DFv9u28jhrOS3B X-Received: by 10.43.110.136 with SMTP id ek8mr22497646icc.87.1427143563916; Mon, 23 Mar 2015 13:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.79 with HTTP; Mon, 23 Mar 2015 13:45:23 -0700 (PDT) In-Reply-To: <551060B7.2000901@isi.edu> References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <551060B7.2000901@isi.edu> From: Yuchung Cheng Date: Mon, 23 Mar 2015 15:45:23 -0500 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:46:06 -0000 On Mon, Mar 23, 2015 at 1:51 PM, Joe Touch wrote: > > > On 3/23/2015 11:28 AM, Yuchung Cheng wrote: >> On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) >> wrote: >>> >>> Hi, >>> >>> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming meeting [1]. At this stage, TCPM is really interested in feedback from implementers and potential users, e.g., regarding feature gaps or deployment problems. >> >> Which (experimental) TCP feature requires EDO? Does tcpcrypt require EDO? >> >> Same question applies to proposals extending option space in SYN. > > The answer to both questions in the motivation section of the drafts. > > Joe Where? """ 1. Introduction TCP's Data Offset is a 4-bit field, which indicates the number of 32-bit words of the entire TCP header [RFC793]. This limits the current total header size to 60 bytes, of which the basic header occupies 20, leaving 40 bytes for options. These 40 bytes are increasingly becoming a limitation to the development of advanced capabilities, such as when SACK [RFC2018][RFC6675] is combined with either Multipath TCP [RFC6824], TCP-AO [RFC5925], or TCP Fast Open [Ch14]. This document specifies the TCP Extended Data Offset (EDO) option, and is independent of (and thus compatible with) IPv4 and IPv6. EDO extends the space available for TCP options, except for the initial SYN and SYN/ACK. This document also explains why the option space of the initial SYN segments cannot be extended as individual segments without severe impact on TCP's initial handshake and the SYN/ACK limitation that results from middlebox misbehavior. """ I also don't see how SACK+ Fast Open demands EDO. An example helps. It's not clear to me that EDO is "required" or "nice-to-have" to use SACK+mptcp+AO. Please clarify. From nobody Mon Mar 23 13:55:19 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF40B1B29B9 for ; Mon, 23 Mar 2015 13:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbtAEKOSxc1r for ; Mon, 23 Mar 2015 13:55:06 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id 459F61AD481 for ; Mon, 23 Mar 2015 13:55:06 -0700 (PDT) Received: from [10.64.27.179] (unknown [69.53.236.236]) by lauren.room52.net (Postfix) with ESMTPSA id B4EE97E81E; Tue, 24 Mar 2015 07:55:03 +1100 (EST) Message-ID: <55107DA5.4030200@room52.net> Date: Mon, 23 Mar 2015 15:55:01 -0500 From: Lawrence Stewart User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20150311144838.364EDB0463F@lawyers.icir.org> <550060DE.2070604@room52.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org" , Mark Allman Subject: Re: [tcpm] TCP window updates combined with dup acks sent in response to packet loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:55:08 -0000 Hi Yoshifumi, Apologies for the delay. On 3/14/2015 1:36 PM, Yoshifumi Nishida wrote: > Hi Lawrence, > > On Wed, Mar 11, 2015 at 8:35 AM, Lawrence Stewart > wrote: > > Question still remains whether relaxing the 5681 definition that a > dupack for fast retransmit/fast recovery purposes can't update the > window is something that could/should be considered for non-SACK > connections. Does anyone recall any attempts to specify such an > algorithm? Is it not worth the effort given the prevalence of SACK? > > > Can't we send window updates and dupack separately by using different ACKs? > Then, we don't have to relax the 5681 definition. We certainly could, but the existence proof that Linux doesn't and the fact that it's perfectly legitimate wire behaviour puts this issue in the grey area. That being said, I'm not advocating any particular course of action - just interested in exploring the history and gathering thoughts. Cheers, Lawrence From nobody Mon Mar 23 14:21:41 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7691B2A64 for ; Mon, 23 Mar 2015 14:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlOwI16UvXM2 for ; Mon, 23 Mar 2015 14:21:37 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16451B2A5D for ; Mon, 23 Mar 2015 14:21:36 -0700 (PDT) Received: from vim.isi.edu (vim.isi.edu [128.9.168.184]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t2NLLFYL015049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 14:21:18 -0700 (PDT) Message-ID: <551083C4.2010603@isi.edu> Date: Mon, 23 Mar 2015 14:21:08 -0700 From: Ted Faber User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <551060B7.2000901@isi.edu> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="raQiwFKIwPw7lNiPCDw5cl53moNev9frp" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Archived-At: Cc: faber@isi.edu Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:21:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --raQiwFKIwPw7lNiPCDw5cl53moNev9frp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/23/2015 13:45, Yuchung Cheng wrote: > On Mon, Mar 23, 2015 at 1:51 PM, Joe Touch wrote: >> >> >> On 3/23/2015 11:28 AM, Yuchung Cheng wrote: >>> On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) >>> wrote: >>>> >>>> Hi, >>>> >>>> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the up= coming meeting [1]. At this stage, TCPM is really interested in feedback = from implementers and potential users, e.g., regarding feature gaps or de= ployment problems. >>> >>> Which (experimental) TCP feature requires EDO? Does tcpcrypt require= EDO? >>> >>> Same question applies to proposals extending option space in SYN. >> >> The answer to both questions in the motivation section of the drafts. >> >> Joe > Where? Huh. I was hoping to be able to point you right at it. I swear there was text in there that discussed the motivation and reasoning, but I don't see it either. There's a little more in the Background section of http://www.isi.edu/publications/trpublic/files/tr-696.pdf but I'd go ahead and say there needs to be a motivation paragraph added to this draf= t. Joe, am I looking right past it? --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --raQiwFKIwPw7lNiPCDw5cl53moNev9frp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUQg8oACgkQaUz3f+Zf+XswsQCg96PFHZD9Aufp1e9pFzQdWc4I y+UAnRffk5P3M3pe5ZeLG3eIgPhkPjOF =S4Tc -----END PGP SIGNATURE----- --raQiwFKIwPw7lNiPCDw5cl53moNev9frp-- From nobody Mon Mar 23 15:19:27 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858321A1B79; Mon, 23 Mar 2015 15:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuQTz1BiC2Rn; Mon, 23 Mar 2015 15:19:23 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FA61A1BD9; Mon, 23 Mar 2015 15:19:22 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t2NMJ13k029198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 15:19:01 -0700 (PDT) Message-ID: <55109155.30804@isi.edu> Date: Mon, 23 Mar 2015 15:19:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yuchung Cheng References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <551060B7.2000901@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:19:24 -0000 On 3/23/2015 1:45 PM, Yuchung Cheng wrote: > On Mon, Mar 23, 2015 at 1:51 PM, Joe Touch wrote: >> >> >> On 3/23/2015 11:28 AM, Yuchung Cheng wrote: >>> On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) >>> wrote: >>>> >>>> Hi, >>>> >>>> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming meeting [1]. At this stage, TCPM is really interested in feedback from implementers and potential users, e.g., regarding feature gaps or deployment problems. >>> >>> Which (experimental) TCP feature requires EDO? Does tcpcrypt require EDO? >>> >>> Same question applies to proposals extending option space in SYN. >> >> The answer to both questions in the motivation section of the drafts. >> >> Joe > Where? EDO: Section 6: Some combinations of the above options may not fit in the existing SYN option space, and (as noted) that space cannot be extended. --- EDO-SYN: 1. Introduction This extension is required to support some combinations of TCP options, notably large ones such as TCP AO [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [Ch14] with other options already typically used in most TCP connections. --- From nobody Mon Mar 23 15:24:14 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE31A1BE5; Mon, 23 Mar 2015 15:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TDAJR_a2U9F; Mon, 23 Mar 2015 15:24:13 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1BF1B2ACC; Mon, 23 Mar 2015 15:23:23 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t2NMMxYX000296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 15:22:59 -0700 (PDT) Message-ID: <55109243.5030700@isi.edu> Date: Mon, 23 Mar 2015 15:22:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yoshifumi Nishida , Yuchung Cheng References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:24:14 -0000 On 3/23/2015 12:46 PM, Yoshifumi Nishida wrote: > > On Mon, Mar 23, 2015 at 11:28 AM, Yuchung Cheng > wrote: > > On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) > > wrote: > > > > Hi, > > > > TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming meeting [1]. At this stage, TCPM is really interested in feedback from implementers and potential users, e.g., regarding feature gaps or deployment problems. > > Which (experimental) TCP feature requires EDO? Does tcpcrypt > require EDO? > > > Well, SACK? But, I guess common cases will be a combination of > extensions, not a specific one. SACK can use as much space as it is given, AFAICT ;-) However, there are no options that *depend* on EDO yet because EDO hasn't been available that long. TCPCRYPT might be revised to used EDO (and EDO-SYN, or some other SYN approach) too. Then again, that would require making it work on TCP rather than on the reliable data stream delivered, but then could also be extended to allow protection against header-based tampering. Joe From nobody Mon Mar 23 15:24:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3131A1BF3 for ; Mon, 23 Mar 2015 15:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOdxreoygYon for ; Mon, 23 Mar 2015 15:24:24 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54C01B2AD2 for ; Mon, 23 Mar 2015 15:24:21 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t2NMNjvi000501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 15:23:45 -0700 (PDT) Message-ID: <55109271.1060901@isi.edu> Date: Mon, 23 Mar 2015 15:23:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ted Faber , tcpm@ietf.org References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <551060B7.2000901@isi.edu> <551083C4.2010603@isi.edu> In-Reply-To: <551083C4.2010603@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:24:30 -0000 On 3/23/2015 2:21 PM, Ted Faber wrote: > On 03/23/2015 13:45, Yuchung Cheng wrote: >> On Mon, Mar 23, 2015 at 1:51 PM, Joe Touch wrote: >>> >>> >>> On 3/23/2015 11:28 AM, Yuchung Cheng wrote: >>>> On Wed, Mar 11, 2015 at 8:46 AM, Scharf, Michael (Michael) >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming meeting [1]. At this stage, TCPM is really interested in feedback from implementers and potential users, e.g., regarding feature gaps or deployment problems. >>>> >>>> Which (experimental) TCP feature requires EDO? Does tcpcrypt require EDO? >>>> >>>> Same question applies to proposals extending option space in SYN. >>> >>> The answer to both questions in the motivation section of the drafts. >>> >>> Joe >> Where? > > Huh. I was hoping to be able to point you right at it. I swear there > was text in there that discussed the motivation and reasoning, but I > don't see it either. > > There's a little more in the Background section of > http://www.isi.edu/publications/trpublic/files/tr-696.pdf but I'd go > ahead and say there needs to be a motivation paragraph added to this draft. > > Joe, am I looking right past it? Yes; see my other post. Point taken - both drafts would benefit from a revision that includes a more detailed description of their potential uses. Joe From nobody Mon Mar 23 15:25:36 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3067E1A1BEC for ; Mon, 23 Mar 2015 15:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqGLqV6fRu3e for ; Mon, 23 Mar 2015 15:25:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996B71A1BE5 for ; Mon, 23 Mar 2015 15:25:32 -0700 (PDT) Received: from vim.isi.edu (vim.isi.edu [128.9.168.184]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t2NMP8Bq001047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 15:25:09 -0700 (PDT) Message-ID: <551092C4.50007@isi.edu> Date: Mon, 23 Mar 2015 15:25:08 -0700 From: Ted Faber User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <551060B7.2000901@isi.edu> <55109155.30804@isi.edu> In-Reply-To: <55109155.30804@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxBcaP1tGB1OBAn1vHLq7NBxbIqfwB5T9" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Archived-At: Cc: faber@isi.edu Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:25:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mxBcaP1tGB1OBAn1vHLq7NBxbIqfwB5T9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/23/2015 15:19, Joe Touch wrote: >=20 > EDO: >=20 > Section 6: > Some combinations of the above options may not fit in the existing > SYN option space, and (as noted) that space cannot be extended. >=20 > --- >=20 > EDO-SYN: >=20 >=20 > 1. Introduction >=20 >=20 > This extension is required to support > some combinations of TCP options, notably large ones such as TCP AO > [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [Ch14] with > other options already typically used in most TCP connections. I think the EDO-SYN paragraph is much more informative, and I'd consider copying it into the intro of EDO. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --mxBcaP1tGB1OBAn1vHLq7NBxbIqfwB5T9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUQksQACgkQaUz3f+Zf+XsdMQCgs8W4lY0o2ZfMzuM4huXJIzGU wMUAn029YN/ppibOhEDtj5HcfGG6QahE =Gkv5 -----END PGP SIGNATURE----- --mxBcaP1tGB1OBAn1vHLq7NBxbIqfwB5T9-- From nobody Mon Mar 23 15:39:09 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB91A0030 for ; Mon, 23 Mar 2015 15:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssQX-5m7K8bv for ; Mon, 23 Mar 2015 15:39:07 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98E5B1A0045 for ; Mon, 23 Mar 2015 15:39:06 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2NMd5SI021758 for ; Mon, 23 Mar 2015 18:39:05 -0400 Received: (qmail 19889 invoked by uid 0); 23 Mar 2015 22:39:05 -0000 X-TCPREMOTEIP: 31.133.168.114 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?31.133.168.114?) (wes@mti-systems.com@31.133.168.114) by 0 with ESMTPA; 23 Mar 2015 22:39:05 -0000 Message-ID: <55109607.6080408@mti-systems.com> Date: Mon, 23 Mar 2015 18:39:03 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Joe Touch , Yoshifumi Nishida , Yuchung Cheng References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <55109243.5030700@isi.edu> In-Reply-To: <55109243.5030700@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpinc@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:39:08 -0000 On 3/23/2015 6:22 PM, Joe Touch wrote: >> > Well, SACK? But, I guess common cases will be a combination of >> > extensions, not a specific one. > SACK can use as much space as it is given, AFAICT ;-) That's right, and there have been multiple studies that even showed it was useful to be able to carry a larger number of SACK blocks. In my opinion, this alone could be worthy motivation, without even trying to enumerate all the experimental or combinations of options that might (or might not) find EDO useful. -- Wes Eddy MTI Systems From nobody Mon Mar 23 16:27:17 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90A1A1BB1 for ; Mon, 23 Mar 2015 16:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVfjb6WcSYJi for ; Mon, 23 Mar 2015 16:27:15 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF051A1B44 for ; Mon, 23 Mar 2015 16:27:15 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so78235519wib.1 for ; Mon, 23 Mar 2015 16:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gFgYXolHfHVotHMsVufMOpUipLZ3lAm5Ims5DIjGRrY=; b=M/OYtWOdpTTfIAsqequTKoKmKM5Nq9G2WQfwb8JIMS0pfrHmrPQmT32KwhHtdB8v8C FSN4gy2IsOOb44n1r5KFJ4hIe8gm2K8BZ9B6kNvKIsufnQsiqI9PtfPxlPa8hgybj1z3 DYf7aT8g0DMU+OekSfEbwGU6rvJOpvfSkOCGdNFdPiJQPnMWujpkzmo2UPK0d5goiRap ah3ex5UFjvYEYvbIh9x9IcQrjfHPaGxMxsFrUQiJZP7e7HLwyb5cR8z5KEpSoI/1Xy3/ 9R2YoVPJnHWuwXLQU2B99aat6S/2Xs7Gk+sK6AUYmnPHzYQbeWtTVPCqMWc609QlZeFj 5+xQ== X-Received: by 10.194.62.167 with SMTP id z7mr2740810wjr.106.1427153234044; Mon, 23 Mar 2015 16:27:14 -0700 (PDT) Received: from dhcp-9c7e.meeting.ietf.org (dhcp-9c7e.meeting.ietf.org. [31.133.156.126]) by mx.google.com with ESMTPSA id dj4sm3518391wjc.13.2015.03.23.16.27.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 16:27:13 -0700 (PDT) Message-ID: <5510A154.1040402@gmail.com> Date: Mon, 23 Mar 2015 18:27:16 -0500 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Eggert, Lars" , tcpm WG , "tsv-ads@tools.ietf.org" References: <20150313161834.23078.34866.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] WG Review: TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 23:27:17 -0000 Hi Lars, Am 14.03.15 um 03:47 schrieb Eggert, Lars: > Hi, > > On 2015-3-13, at 17:18, The IESG wrote: >> >> TCPM also provides a venue for standardization of incremental >> enhancements of TCP's standard congestion control. In addition, >> TCPM may document alternative TCP congestion control algorithms >> that are known to be widely deployed, and that are considered safe >> for large-scale deployment in the Internet. Changes of algorithms >> may require additional review by the IRTF Congestion Control >> Research Group (ICCRG). Fundamental changes to TCP or its >> congestion control algorithms (e.g., departure from loss-based >> congestion control) will be handled by other working groups or will >> require rechartering. > > I just wanted to confirm whether the chairs and ADs believe that this > language would now make it acceptable for TCPM to adopt and publish > draft-bensley-tcpm-dctcp? It would be acceptable as there is "may document alternative TCP congestion control algorithms". Martin From nobody Mon Mar 23 20:33:17 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F7F1B2C36 for ; Mon, 23 Mar 2015 20:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDvSqKcXvnhu for ; Mon, 23 Mar 2015 20:33:05 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FCF1B2BE6 for ; Mon, 23 Mar 2015 20:33:05 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YaFaP-000487-Qj; Tue, 24 Mar 2015 04:33:01 +0100 Received: from [38.96.210.190] (helo=[10.1.212.173]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YaFaP-0003up-6U; Tue, 24 Mar 2015 04:33:01 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <5510A154.1040402@gmail.com> Date: Mon, 23 Mar 2015 22:32:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150313161834.23078.34866.idtracker@ietfa.amsl.com> <5510A154.1040402@gmail.com> To: Martin Stiemerling X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 9 sum msgs/h 3 total rcpts 26814 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9726F5995B20A0897580567A08E797A0A1E967D6 X-UiO-SPAM-Test: remote_host: 38.96.210.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 31 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tsv-ads@tools.ietf.org" , tcpm WG Subject: Re: [tcpm] WG Review: TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 03:33:16 -0000 > On 23. mar. 2015, at 18.27, Martin Stiemerling = wrote: >=20 > Hi Lars, >=20 > Am 14.03.15 um 03:47 schrieb Eggert, Lars: >> Hi, >>=20 >> On 2015-3-13, at 17:18, The IESG wrote: >>>=20 >>> TCPM also provides a venue for standardization of incremental >>> enhancements of TCP's standard congestion control. In addition, >>> TCPM may document alternative TCP congestion control algorithms >>> that are known to be widely deployed, and that are considered safe >>> for large-scale deployment in the Internet. Changes of algorithms >>> may require additional review by the IRTF Congestion Control >>> Research Group (ICCRG). Fundamental changes to TCP or its >>> congestion control algorithms (e.g., departure from loss-based >>> congestion control) will be handled by other working groups or will >>> require rechartering. >>=20 >> I just wanted to confirm whether the chairs and ADs believe that this >> language would now make it acceptable for TCPM to adopt and publish >> draft-bensley-tcpm-dctcp? >=20 > It would be acceptable as there is "may document alternative TCP = congestion control algorithms". .... "that are considered safe for large-scale deployment in the = Internet", in the same sentence. Cheers, Michael From nobody Mon Mar 23 21:18:06 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BC01B2C62 for ; Mon, 23 Mar 2015 21:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkKLkY0cjUc9 for ; Mon, 23 Mar 2015 21:18:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8361B2C65 for ; Mon, 23 Mar 2015 21:18:03 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 886322BA45B98; Tue, 24 Mar 2015 04:18:00 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2O4I0W2009918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 05:18:01 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 05:18:01 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: Link to slides Thread-Index: AdBl6YMdboJfGQlrTL2UZZDyuqsnnQ== Date: Tue, 24 Mar 2015 04:17:59 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C687C3@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.192.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Link to slides X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 04:18:05 -0000 Hi,=0A= =0A= For some unknown reason the slides for tomorrow's TCPM meeting are currentl= y not listed on the materials page, even we uploaded them in time on Sunday= .=0A= =0A= Right now, the slides can be accessed at: http://tools.ietf.org/wg/tcpm/age= nda=0A= =0A= We are currently investing what is going wrong.=0A= =0A= Sorry=0A= =0A= Michael= From nobody Tue Mar 24 05:26:45 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924831A879D for ; Tue, 24 Mar 2015 05:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9IuvvQ19I3y for ; Tue, 24 Mar 2015 05:26:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 05F5A1A899D for ; Tue, 24 Mar 2015 05:26:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 30E9EC94BE; Tue, 24 Mar 2015 08:26:30 -0400 (EDT) Date: Tue, 24 Mar 2015 08:26:30 -0400 From: John Leslie To: "Scharf, Michael (Michael)" Message-ID: <20150324122630.GY39886@verdi> References: <655C07320163294895BBADA28372AF5D16C687C3@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <655C07320163294895BBADA28372AF5D16C687C3@FR712WXCHMBA15.zeu.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Link to slides X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 12:26:43 -0000 Scharf, Michael (Michael) wrote: > > Right now, the slides can be accessed at: http://tools.ietf.org/wg/tcpm/agenda Thank you! And extra thanks for supplying them in .pdf format! -- John Leslie From nobody Tue Mar 24 06:03:51 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E71A01F7 for ; Tue, 24 Mar 2015 06:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnHMfGnnzGsD for ; Tue, 24 Mar 2015 06:03:46 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546ED1A017E for ; Tue, 24 Mar 2015 06:03:46 -0700 (PDT) Received: by wibg7 with SMTP id g7so74142912wib.1 for ; Tue, 24 Mar 2015 06:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NySQPgaFl/AL2jbZkFq5Sqnq+ftK1bFTFrHYS5l907o=; b=li2awX0S8ddExi+D7Cq3S2hrlVpWZnSXG0WcskoyciK/jloaAXNdZsYCJg2N8DJuTQ hJmmYpkOW5gaiTRmqSlUUrrHQ0mwmYxs3YX/KfLvDT9/sKGw0oDsXPPqFA0+1YBibAr7 MfvgCQ48Kl6Swea/DjoY2COb9CEG6v+G0jiEGOsXMTRe3bufcGeAzSV04acBkW8ubYcD Fgj15O9RESIoibmx6nK5YbaOTsY54vxL8066tXtgw9do9eCSzTOVmSihnBExDShwDfbl z0CbqQJXGNK/LQnS1EW/G/apjah+ZfFwTkeme4IVpCUAvQ0PFTtzwdlR8F3XeGKOTh4D dIQw== X-Received: by 10.194.83.66 with SMTP id o2mr7841673wjy.55.1427202225068; Tue, 24 Mar 2015 06:03:45 -0700 (PDT) Received: from dhcp-9c7e.meeting.ietf.org ([2001:67c:370:152:b1d9:e939:a07c:95d1]) by mx.google.com with ESMTPSA id i10sm6001998wja.40.2015.03.24.06.03.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 06:03:44 -0700 (PDT) Message-ID: <551160B5.7040501@gmail.com> Date: Tue, 24 Mar 2015 08:03:49 -0500 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Welzl References: <20150313161834.23078.34866.idtracker@ietfa.amsl.com> <5510A154.1040402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-ads@tools.ietf.org" , tcpm WG Subject: Re: [tcpm] WG Review: TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 13:03:49 -0000 Hi Michael, Am 23.03.15 um 22:32 schrieb Michael Welzl: > >> On 23. mar. 2015, at 18.27, Martin Stiemerling >> wrote: >> >> Hi Lars, >> >> Am 14.03.15 um 03:47 schrieb Eggert, Lars: >>> Hi, >>> >>> On 2015-3-13, at 17:18, The IESG >>> wrote: >>>> >>>> TCPM also provides a venue for standardization of incremental >>>> enhancements of TCP's standard congestion control. In >>>> addition, TCPM may document alternative TCP congestion control >>>> algorithms that are known to be widely deployed, and that are >>>> considered safe for large-scale deployment in the Internet. >>>> Changes of algorithms may require additional review by the IRTF >>>> Congestion Control Research Group (ICCRG). Fundamental changes >>>> to TCP or its congestion control algorithms (e.g., departure >>>> from loss-based congestion control) will be handled by other >>>> working groups or will require rechartering. >>> >>> I just wanted to confirm whether the chairs and ADs believe that >>> this language would now make it acceptable for TCPM to adopt and >>> publish draft-bensley-tcpm-dctcp? >> >> It would be acceptable as there is "may document alternative TCP >> congestion control algorithms". > > .... "that are considered safe for large-scale deployment in the > Internet", in the same sentence. Yeah, I should have mentioned that Michael's response included good hints what would be missing in that respect. In short: What Michael said. Martin From nobody Tue Mar 24 08:05:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8301A87C1; Tue, 24 Mar 2015 08:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGicXRcr1_lC; Tue, 24 Mar 2015 08:05:34 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8A71A87B1; Tue, 24 Mar 2015 08:05:33 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 24 Mar 2015 16:05:07 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 31.133.156.104 X-MDArrival-Date: Tue, 24 Mar 2015 16:05:07 +0100 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <55117D21.9030708@kau.se> Date: Tue, 24 Mar 2015 16:05:05 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "tcpm@ietf.org" , tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] SCTP socket API section needed for rto-restart? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:05:38 -0000 Dear all, In the tcpm session just now there was a discussion as to weather a SCTP socket API section should be added to the rto-restart draft or not. As there was no consensus in the room, we would like feedback from the mailing list. As tsvwg handles SCTP, the question goes to both the tcpm and the tsvwg mailing lists. The draft is at https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-05, and describes a small update to the RTO timer management algorithm. Any other feedback on the document is of course also welcome. Thanks, Anna From nobody Tue Mar 24 08:40:00 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C591A898A; Tue, 24 Mar 2015 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEuF-iRSly_e; Tue, 24 Mar 2015 08:39:56 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5191A8980; Tue, 24 Mar 2015 08:39:55 -0700 (PDT) Received: from [IPv6:2001:67c:370:152:c42a:ebe5:8100:c6c1] (unknown [IPv6:2001:67c:370:152:c42a:ebe5:8100:c6c1]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 06A691C104349; Tue, 24 Mar 2015 16:39:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <55117D21.9030708@kau.se> Date: Tue, 24 Mar 2015 10:39:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F6B508F-9349-4110-9EC6-9BE216C2EB6F@lurchi.franken.de> References: <55117D21.9030708@kau.se> To: Anna Brunstrom X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tcpm@ietf.org" , tsvwg@ietf.org Subject: Re: [tcpm] SCTP socket API section needed for rto-restart? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:39:58 -0000 > On 24 Mar 2015, at 10:05, Anna Brunstrom = wrote: >=20 > Dear all, >=20 > In the tcpm session just now there was a discussion as to weather a = SCTP socket API section should be added to the rto-restart draft or not. = As there was no consensus in the room, we would like feedback from the = mailing list. >=20 > As tsvwg handles SCTP, the question goes to both the tcpm and the = tsvwg mailing lists. >=20 > The draft is at = https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-05, and describes = a small update to the RTO timer management algorithm. Since I brought the point up, let me give the argument on the list = again. For SCTP extensions, we usually provide an informational section how to extend the SCTP socket API defined in RFC 6458. So I brought up the = question whether it is envisioned that you allow an application to enable/disable this feature. If yes, it makes sense to me to add a socket API section describing how to control it for SCTP. I'm willing to contribute text, if wanted. Best regards Michael >=20 > Any other feedback on the document is of course also welcome. >=20 > Thanks, > Anna >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Tue Mar 24 13:47:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359751A017D for ; Tue, 24 Mar 2015 13:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApJ23hZN3Bba for ; Tue, 24 Mar 2015 13:47:55 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570B71A007B for ; Tue, 24 Mar 2015 13:47:55 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so8843377igc.0 for ; Tue, 24 Mar 2015 13:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bl/MBocU7bVAKRnJZqUbb9YtRweeo2PCkyjTTcKmvOA=; b=A2psZJoKvs5Z08sMi6FcTJ1onwIAY6iqLCHTKG/MFldNXIVjvwbbgMG08zE8LNRt3p L53FFhtV0Cd4mbWCNba6Y/yd3EoaRAnd4qi6uG6985/DRHPbxhTx7MRo6VYP5VN6Ahzd fWiB44u3ruIg0oni7ISa2HoP+2UG1hDfl9llqDkL7b4wB7fX+QFYqp9GCkRINDqAU6Pm B3v1JRYipmHyVnk+7f8hjNvZqwoWmsl302CrfTXk2WvCN+//2UhwCyasNR5XBQbXY8rw d70uszp0vSHcvHEBZlnG3ntbQ1QJooz3Zxza38q+NYT6h1dr6Opwyg9xGSAWZMiljRLB wZrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bl/MBocU7bVAKRnJZqUbb9YtRweeo2PCkyjTTcKmvOA=; b=E4he2hswhYr0k93BGESzc3OcUIi1xLqcEcGYdw+5+kFiAYmGh+e2Yzh/QPfiUQGBSO M6WZZHGF1v8VK1fxA48cQX5jUeCmx5p8+SeQ9zY3yk/vnGifgxKFjdnhUVlILPyHnuCR jWhN4Ln8LN2vIqAcnaDzDCpU/3j9H9uUmoyzjv4ecCdHglUdFz3v5L6824roj/u8OCLk 24E0b1y9WFVJksMpJWBOM4fKqHqFWnoC0ObRPWeHeVfuFn7u1EZru6XfoqgGN4GfaNMr HTodRouDhBygE8s2ecj2dOe81fgxev67f9XZnR2xiQ98vo34pogEVG/LvrB2+3aY8dno j96g== X-Gm-Message-State: ALoCoQngtFumRlboIwtAX6hQW/2Kn9b4JOyxYf6eGqLZ6xM3UQWS4v23rq5Ppa2uJMqTmimp8ndw X-Received: by 10.107.165.68 with SMTP id o65mr9370695ioe.56.1427230074834; Tue, 24 Mar 2015 13:47:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.79 with HTTP; Tue, 24 Mar 2015 13:47:14 -0700 (PDT) In-Reply-To: <55109607.6080408@mti-systems.com> References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <55109243.5030700@isi.edu> <55109607.6080408@mti-systems.com> From: Yuchung Cheng Date: Tue, 24 Mar 2015 15:47:14 -0500 Message-ID: To: Wesley Eddy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" , "tcpinc@ietf.org" , Joe Touch Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:47:56 -0000 On Mon, Mar 23, 2015 at 5:39 PM, Wesley Eddy wrote: > On 3/23/2015 6:22 PM, Joe Touch wrote: >>> > Well, SACK? But, I guess common cases will be a combination of >>> > extensions, not a specific one. >> SACK can use as much space as it is given, AFAICT ;-) > > > That's right, and there have been multiple studies that even > showed it was useful to be able to carry a larger number of > SACK blocks. Please share the studies. After today's meeting, my concerns are 1. EDO's incompatibility with HW/SW offload. I am positive we can probably fix the SW-offload but pessimistic about changes in HW-offload. Here is another data point, in addition to the iperf data presented today: (L|G)RO and (G|T)SO are critical for Google Linux servers. 2. Salvage operation when middleboxes strip EDO randomly in the middle of connection > > In my opinion, this alone could be worthy motivation, without > even trying to enumerate all the experimental or combinations > of options that might (or might not) find EDO useful. > > -- > Wes Eddy > MTI Systems From nobody Tue Mar 24 13:53:41 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52391A0242; Tue, 24 Mar 2015 13:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rkMJP9hLQ3x; Tue, 24 Mar 2015 13:53:38 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1131A0364; Tue, 24 Mar 2015 13:53:38 -0700 (PDT) Received: from [10.123.115.93] (usc-secure-wireless-088-093.usc.edu [68.181.88.93]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t2OKr2XJ010174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 13:53:05 -0700 (PDT) Message-ID: <5511CEAE.9090007@isi.edu> Date: Tue, 24 Mar 2015 13:53:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yuchung Cheng , Wesley Eddy References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <55109243.5030700@isi.edu> <55109607.6080408@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" , "tcpinc@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:53:40 -0000 On 3/24/2015 1:47 PM, Yuchung Cheng wrote: > On Mon, Mar 23, 2015 at 5:39 PM, Wesley Eddy wrote: >> On 3/23/2015 6:22 PM, Joe Touch wrote: >>>>> Well, SACK? But, I guess common cases will be a combination of >>>>> extensions, not a specific one. >>> SACK can use as much space as it is given, AFAICT ;-) >> >> >> That's right, and there have been multiple studies that even >> showed it was useful to be able to carry a larger number of >> SACK blocks. > Please share the studies. > > After today's meeting, my concerns are > > 1. EDO's incompatibility with HW/SW offload. I am positive we can > probably fix the SW-offload but pessimistic about changes in > HW-offload. All new options are incompatible with offload that doesn't properly handle options it doesn't understand. In the case of GRO, the software SHOULD handle EDO without error, even if it cannot achieve a performance improvement. The current behavior is clearly incorrect. > 2. Salvage operation when middleboxes strip EDO randomly in the middle > of connection There is no solution to that either, except to develop a mechanism inside the data plane of TCP. At that point, the option would be decoupled from the header, defeating the purpose of most options (which are segment-specific). Joe From nobody Wed Mar 25 08:02:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7835E1A00EC; Tue, 24 Mar 2015 14:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45gm4x_vDAT8; Tue, 24 Mar 2015 14:06:29 -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 058491A1A36; Tue, 24 Mar 2015 14:06:29 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 0711018348D; Tue, 24 Mar 2015 22:06:23 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 0711018348D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1427231183; bh=ZpnK4Zgm7KjLP7fDcKw1ltsq26WcOP8/y+nMyNmclwM=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZA4/Tg1De+lyf0JHw2WbGAxbqWpIsL0Jg4HIeLdJ46w5tCKJzdPUNsLi12w3Z35qP hvGDzQ/FZD7hTwYph7OM1dTDV9ro6fOlrcFjUvofTe+qr8+2NU5Mrq/f+JQBgGBR3z IOdYoEt8FB3/UWQxJyahpuVA0rNtZfK0Ik3SX/Uc= Message-ID: <5511D1D0.4040006@uclouvain.be> Date: Tue, 24 Mar 2015 22:06:24 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , Yuchung Cheng , Wesley Eddy References: <655C07320163294895BBADA28372AF5D16C53584@FR712WXCHMBA15.zeu.alcatel-lucent.com> <55109243.5030700@isi.edu> <55109607.6080408@mti-systems.com> <5511CEAE.9090007@isi.edu> In-Reply-To: <5511CEAE.9090007@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: 0711018348D.A8470 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: X-Mailman-Approved-At: Wed, 25 Mar 2015 08:02:41 -0700 Cc: "tcpm@ietf.org" , "tcpinc@ietf.org" Subject: Re: [tcpm] [tcpinc] Feedback on EDO? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 24 Mar 2015 21:06:37 -0000 Joe, >>>>>> Well, SACK? But, I guess common cases will be a combination of >>>>>> extensions, not a specific one. >>>> SACK can use as much space as it is given, AFAICT ;-) >>> >>> >>> That's right, and there have been multiple studies that even >>> showed it was useful to be able to carry a larger number of >>> SACK blocks. >> Please share the studies. >> >> After today's meeting, my concerns are >> >> 1. EDO's incompatibility with HW/SW offload. I am positive we can >> probably fix the SW-offload but pessimistic about changes in >> HW-offload. > > All new options are incompatible with offload that doesn't properly > handle options it doesn't understand. I'd like to point out that the Multipath TCP design shows that it is possible to design TCP options that are unknown by the existing offload hardware and still remain compatible with them. > > In the case of GRO, the software SHOULD handle EDO without error, even > if it cannot achieve a performance improvement. The current behavior is > clearly incorrect. > >> 2. Salvage operation when middleboxes strip EDO randomly in the middle >> of connection > > There is no solution to that either, except to develop a mechanism > inside the data plane of TCP. At that point, the option would be > decoupled from the header, defeating the purpose of most options (which > are segment-specific). In Multipath TCP, this salvage operation exists thanks to the DSS checksum which is included in the DSS option. EDO does not include this kind of feature and would be vulnerable to strange middlebox. Multipath TCP has been shown to work well through various types of middleboxes, both thanks to lab measurements and through real use, see https://tools.ietf.org/html/draft-ietf-mptcp-experience-01 for additional information and references. Recently, an MPTCP user complained that MPTCP was started with two subflows over a satellite link and quickly switched to a single subflow. A closer analysis revealed that this behavior was caused by a very strange middlebox that interferes with options, see http://blog.multipath-tcp.org/blog/html/2015/01/30/multipath_tcp_through_a_strange_middlebox.html Preserving the end-to-end connectivity, even in the presence of middleboxes must be an objective for a TCP extension like EDO. Otherwise, it won't be useable Olivier From nobody Wed Mar 25 08:02:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6765E1A1A66 for ; Tue, 24 Mar 2015 16:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w7ZkzR-PVLl for ; Tue, 24 Mar 2015 16:10:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id D547E1A1B7C for ; Tue, 24 Mar 2015 16:10:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C274A180092; Tue, 24 Mar 2015 16:08:55 -0700 (PDT) To: fernando@gont.com.ar, ayourtch@cisco.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, michael.scharf@alcatel-lucent.com, nishida@sfc.wide.ad.jp, pasi.sarolahti@iki.fi X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150324230855.C274A180092@rfc-editor.org> Date: Tue, 24 Mar 2015 16:08:55 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 25 Mar 2015 08:02:46 -0700 Cc: yirkajk@vcu.edu, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Technical Errata Reported] RFC6093 (4312) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 23:10:26 -0000 The following errata report has been submitted for RFC6093, "On the Implementation of the TCP Urgent Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6093&eid=4312 -------------------------------------- Type: Technical Reported by: Justin Yirka Section: 3.1 Original Text ------------- Unfortunately, virtually all TCP implementations process TCP urgent indications differently. By default, the last byte of "urgent data" is delivered "out of band" to the application. That is, it is not delivered as part of the normal data stream [UNPv1]. For example, the "out-of-band" byte is read by an application when a recv(2) system call with the MSG_OOB flag set is issued. Corrected Text -------------- Unfortunately, virtually all TCP implementations process TCP urgent indications differently. For example, by default in particular UNIX implementations, the last byte of "urgent data" is delivered "out of band" to the application. That is, it is not delivered as part of the normal data stream [UNPv1]. For example, the "out-of-band" byte is read by an application when a recv(2) system call with the MSG_OOB flag set is issued. Notes ----- The first and latter statements are contradictory, as a default is unlikely to apply when "virtually all" implementations process differently. This correction to include "in particular UNIX implementations" would be appropriate at many points throughout the document in order to differentiate references to implementation specific features and terminology from references to terminology established in prior RFCs. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6093 (draft-ietf-tcpm-urgent-data-07) -------------------------------------- Title : On the Implementation of the TCP Urgent Mechanism Publication Date : January 2011 Author(s) : F. Gont, A. Yourtchenko Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Mar 25 15:31:27 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14801A06E9 for ; Wed, 25 Mar 2015 15:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QYU6Bj8R_GK for ; Wed, 25 Mar 2015 15:31:24 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CDA1ACE57 for ; Wed, 25 Mar 2015 15:31:23 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id D56F083DC1FB6 for ; Wed, 25 Mar 2015 22:31:17 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2PMVMOU011409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Mar 2015 23:31:22 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 23:31:22 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WG acceptance of draft-eddy-rfc793bis-05 - please reply! Thread-Index: AdBnS2qAjku8ptSXRoy25gn0qr3pMg== Date: Wed, 25 Mar 2015 22:31:21 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:31:26 -0000 Hi all, During the Dallas meeting in Dallas, there has been strong and unanimous su= pport for adopting draft-eddy-rfc793bis-05 as new TCPM working group docume= nt. This email therefore starts a WG adoption call of draft-eddy-rfc793bis-05, = which will run on the mailing list until April 8. The chairs suggest to add the following milestone to the TCPM charter: April 2017 Submit RFC793bis document to the IESG for publication as a Pr= oposed Standard The chairs believe that it is consensus in TCPM that RFC793bis will not int= roduce protocol changes that have not already been approved by past consens= us, e.g., by a standards track RFC or by a verified errata. The document is= expected to obsolete RFC 793 and to update RFC 1122, as well as further TC= P specifications. Please explicitly reply to this e-mail if you support WG acceptance. Since = we run the adoption call on the list, please reply even if you have already= hummed in Dallas to support the document. A simple "+1" response is suffic= ient to document support. The chairs will only proceed with WG acceptance if there is a sufficient nu= mber of reviewers who explicitly commit to review upcoming versions of the = RFC793bis draft, prior to submission to IESG. Please let us chairs know now= if you volunteer for reviews, in particular regarding the accuracy of RFC7= 93bis. The chairs will keep track of volunteers. Please help TCPM with revi= ews of this crucial document! If there were any concerns regarding adopting draft-eddy-rfc793bis-05, plea= se speak up. Thanks Michael, Pasi, Yoshifumi From nobody Wed Mar 25 16:09:08 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CBF1AC42A for ; Wed, 25 Mar 2015 16:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwv5A_x-YuBC for ; Wed, 25 Mar 2015 16:08:59 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D003D1A9171 for ; Wed, 25 Mar 2015 16:08:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,467,1422950400"; d="scan'208";a="31694325" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx143-out.netapp.com with ESMTP; 25 Mar 2015 16:03:58 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 25 Mar 2015 16:03:58 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Wed, 25 Mar 2015 16:03:58 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" Thread-Topic: WG acceptance of draft-eddy-rfc793bis-05 - please reply! Thread-Index: AdBnS2qAjku8ptSXRoy25gn0qr3pMgABE8TA Date: Wed, 25 Mar 2015 23:03:57 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:09:01 -0000 All for adoption; milestone might be a bit optimistic I can imagine, but yo= u have to start somewhere... Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Mittwoch, 25. M=E4rz 2015 17:31 > To: tcpm@ietf.org > Subject: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! >=20 > Hi all, >=20 > During the Dallas meeting in Dallas, there has been strong and unanimous > support for adopting draft-eddy-rfc793bis-05 as new TCPM working group > document. >=20 > This email therefore starts a WG adoption call of draft-eddy-rfc793bis-05= , > which will run on the mailing list until April 8. >=20 > The chairs suggest to add the following milestone to the TCPM charter: >=20 > April 2017 Submit RFC793bis document to the IESG for publication as a > Proposed Standard >=20 > The chairs believe that it is consensus in TCPM that RFC793bis will not > introduce protocol changes that have not already been approved by past > consensus, e.g., by a standards track RFC or by a verified errata. The > document is expected to obsolete RFC 793 and to update RFC 1122, as well > as further TCP specifications. >=20 > Please explicitly reply to this e-mail if you support WG acceptance. Sinc= e > we run the adoption call on the list, please reply even if you have > already hummed in Dallas to support the document. A simple "+1" response > is sufficient to document support. >=20 > The chairs will only proceed with WG acceptance if there is a sufficient > number of reviewers who explicitly commit to review upcoming versions of > the RFC793bis draft, prior to submission to IESG. Please let us chairs > know now if you volunteer for reviews, in particular regarding the > accuracy of RFC793bis. The chairs will keep track of volunteers. Please > help TCPM with reviews of this crucial document! >=20 > If there were any concerns regarding adopting draft-eddy-rfc793bis-05, > please speak up. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Mar 25 16:24:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2751B29AB for ; Wed, 25 Mar 2015 16:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U09qIDhk2sGw for ; Wed, 25 Mar 2015 16:24:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301971A9153 for ; Wed, 25 Mar 2015 16:24:01 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1E3D9AE1CE7EC; Wed, 25 Mar 2015 23:23:53 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2PNNvQT007309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 00:23:57 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 00:23:57 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" Thread-Topic: WG acceptance of draft-eddy-rfc793bis-05 - please reply! Thread-Index: AdBnS2qAjku8ptSXRoy25gn0qr3pMgABE8TAAABNTLA= Date: Wed, 25 Mar 2015 23:23:56 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C6BD29@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:24:03 -0000 We have to put in a date. For almost all milestones I recall, TCPM has been= slower than the chairs envisioned originally, and we have always given pri= ority to document quality. This will in particular apply to RFC793bis. But = the chairs keep being optimistic about the WG enthusiasm ;) But we are open to other forecasts. I'd have a preference for numbers small= er than 2020... Michael > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com] > Sent: Thursday, March 26, 2015 12:04 AM > To: Scharf, Michael (Michael) > Cc: tcpm-chairs@tools.ietf.org; tcpm (tcpm@ietf.org) > Subject: RE: WG acceptance of draft-eddy-rfc793bis-05 - please reply! >=20 >=20 > All for adoption; milestone might be a bit optimistic I can imagine, > but you have to start somewhere... >=20 > Richard >=20 >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, > Michael > > (Michael) > > Sent: Mittwoch, 25. M=E4rz 2015 17:31 > > To: tcpm@ietf.org > > Subject: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please > reply! > > > > Hi all, > > > > During the Dallas meeting in Dallas, there has been strong and > unanimous > > support for adopting draft-eddy-rfc793bis-05 as new TCPM working > group > > document. > > > > This email therefore starts a WG adoption call of draft-eddy- > rfc793bis-05, > > which will run on the mailing list until April 8. > > > > The chairs suggest to add the following milestone to the TCPM > charter: > > > > April 2017 Submit RFC793bis document to the IESG for publication > as a > > Proposed Standard > > > > The chairs believe that it is consensus in TCPM that RFC793bis will > not > > introduce protocol changes that have not already been approved by > past > > consensus, e.g., by a standards track RFC or by a verified errata. > The > > document is expected to obsolete RFC 793 and to update RFC 1122, as > well > > as further TCP specifications. > > > > Please explicitly reply to this e-mail if you support WG acceptance. > Since > > we run the adoption call on the list, please reply even if you have > > already hummed in Dallas to support the document. A simple "+1" > response > > is sufficient to document support. > > > > The chairs will only proceed with WG acceptance if there is a > sufficient > > number of reviewers who explicitly commit to review upcoming versions > of > > the RFC793bis draft, prior to submission to IESG. Please let us > chairs > > know now if you volunteer for reviews, in particular regarding the > > accuracy of RFC793bis. The chairs will keep track of volunteers. > Please > > help TCPM with reviews of this crucial document! > > > > If there were any concerns regarding adopting draft-eddy-rfc793bis- > 05, > > please speak up. > > > > Thanks > > > > Michael, Pasi, Yoshifumi > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Mar 25 16:35:13 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6D31B2AB8 for ; Wed, 25 Mar 2015 16:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5XiIFXX3EoO for ; Wed, 25 Mar 2015 16:35:11 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBAC1A8898 for ; Wed, 25 Mar 2015 16:35:11 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id t2PNZ9BI001700; Wed, 25 Mar 2015 16:35:09 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1tbsqrrwau-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Mar 2015 16:35:09 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 17:34:52 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 17:35:08 -0600 From: David Borman To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! Thread-Index: AQHQZ1RTHx6fyKONZUWeGIhMbHWaXQ== Date: Wed, 25 Mar 2015 23:35:07 +0000 Message-ID: <1FDC0AFD-133B-49FB-840A-42CDD02F9850@quantum.com> References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-25_07:2015-03-25,2015-03-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 kscore.is_bulkscore=3.32346927756078e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.0846225539389875 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.0846225539389875 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.0846225539389875 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503250203 Content-Type: text/plain; charset="utf-8" Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:35:12 -0000 KzENCg0KSeKAmW0gYWxzbyB3aWxsaW5nIHRvIGRvIHJldmlldyBvZiB0aGUgZG9jdW1lbnQuDQoN CgktRGF2aWQgQm9ybWFuDQoNCj4gT24gTWFyIDI1LCAyMDE1LCBhdCA1OjMxIFBNLCBTY2hhcmYs IE1pY2hhZWwgKE1pY2hhZWwpIDxtaWNoYWVsLnNjaGFyZkBhbGNhdGVsLWx1Y2VudC5jb20+IHdy b3RlOg0KPiANCj4gSGkgYWxsLA0KPiANCj4gRHVyaW5nIHRoZSBEYWxsYXMgbWVldGluZyBpbiBE YWxsYXMsIHRoZXJlIGhhcyBiZWVuIHN0cm9uZyBhbmQgdW5hbmltb3VzIHN1cHBvcnQgZm9yIGFk b3B0aW5nIGRyYWZ0LWVkZHktcmZjNzkzYmlzLTA1IGFzIG5ldyBUQ1BNIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnQuDQo+IA0KPiBUaGlzIGVtYWlsIHRoZXJlZm9yZSBzdGFydHMgYSBXRyBhZG9wdGlv biBjYWxsIG9mIGRyYWZ0LWVkZHktcmZjNzkzYmlzLTA1LCB3aGljaCB3aWxsIHJ1biBvbiB0aGUg bWFpbGluZyBsaXN0IHVudGlsIEFwcmlsIDguDQo+IA0KPiBUaGUgY2hhaXJzIHN1Z2dlc3QgdG8g YWRkIHRoZSBmb2xsb3dpbmcgbWlsZXN0b25lIHRvIHRoZSBUQ1BNIGNoYXJ0ZXI6DQo+IA0KPiBB cHJpbCAyMDE3ICAgIFN1Ym1pdCBSRkM3OTNiaXMgZG9jdW1lbnQgdG8gdGhlIElFU0cgZm9yIHB1 YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IFRoZSBjaGFpcnMgYmVsaWV2 ZSB0aGF0IGl0IGlzIGNvbnNlbnN1cyBpbiBUQ1BNIHRoYXQgUkZDNzkzYmlzIHdpbGwgbm90IGlu dHJvZHVjZSBwcm90b2NvbCBjaGFuZ2VzIHRoYXQgaGF2ZSBub3QgYWxyZWFkeSBiZWVuIGFwcHJv dmVkIGJ5IHBhc3QgY29uc2Vuc3VzLCBlLmcuLCBieSBhIHN0YW5kYXJkcyB0cmFjayBSRkMgb3Ig YnkgYSB2ZXJpZmllZCBlcnJhdGEuIFRoZSBkb2N1bWVudCBpcyBleHBlY3RlZCB0byBvYnNvbGV0 ZSBSRkMgNzkzIGFuZCB0byB1cGRhdGUgUkZDIDExMjIsIGFzIHdlbGwgYXMgZnVydGhlciBUQ1Ag c3BlY2lmaWNhdGlvbnMuDQo+IA0KPiBQbGVhc2UgZXhwbGljaXRseSByZXBseSB0byB0aGlzIGUt bWFpbCBpZiB5b3Ugc3VwcG9ydCBXRyBhY2NlcHRhbmNlLiBTaW5jZSB3ZSBydW4gdGhlIGFkb3B0 aW9uIGNhbGwgb24gdGhlIGxpc3QsIHBsZWFzZSByZXBseSBldmVuIGlmIHlvdSBoYXZlIGFscmVh ZHkgaHVtbWVkIGluIERhbGxhcyB0byBzdXBwb3J0IHRoZSBkb2N1bWVudC4gQSBzaW1wbGUgIisx IiByZXNwb25zZSBpcyBzdWZmaWNpZW50IHRvIGRvY3VtZW50IHN1cHBvcnQuDQo+IA0KPiBUaGUg Y2hhaXJzIHdpbGwgb25seSBwcm9jZWVkIHdpdGggV0cgYWNjZXB0YW5jZSBpZiB0aGVyZSBpcyBh IHN1ZmZpY2llbnQgbnVtYmVyIG9mIHJldmlld2VycyB3aG8gZXhwbGljaXRseSBjb21taXQgdG8g cmV2aWV3IHVwY29taW5nIHZlcnNpb25zIG9mIHRoZSBSRkM3OTNiaXMgZHJhZnQsIHByaW9yIHRv IHN1Ym1pc3Npb24gdG8gSUVTRy4gUGxlYXNlIGxldCB1cyBjaGFpcnMga25vdyBub3cgaWYgeW91 IHZvbHVudGVlciBmb3IgcmV2aWV3cywgaW4gcGFydGljdWxhciByZWdhcmRpbmcgdGhlIGFjY3Vy YWN5IG9mIFJGQzc5M2Jpcy4gVGhlIGNoYWlycyB3aWxsIGtlZXAgdHJhY2sgb2Ygdm9sdW50ZWVy cy4gUGxlYXNlIGhlbHAgVENQTSB3aXRoIHJldmlld3Mgb2YgdGhpcyBjcnVjaWFsIGRvY3VtZW50 IQ0KPiANCj4gSWYgdGhlcmUgd2VyZSBhbnkgY29uY2VybnMgcmVnYXJkaW5nIGFkb3B0aW5nIGRy YWZ0LWVkZHktcmZjNzkzYmlzLTA1LCBwbGVhc2Ugc3BlYWsgdXAuDQo+IA0KPiBUaGFua3MNCj4g DQo+IE1pY2hhZWwsIFBhc2ksIFlvc2hpZnVtaQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0K Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlz c2lvbiBtYXkgYmUgY29uZmlkZW50aWFsLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZywgb3IgZnVy dGhlciBkaXN0cmlidXRpb24gb2YgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGlzIG5vdCBwZXJt aXR0ZWQgdW5sZXNzIHN1Y2ggcHJpdmlsZWdlIGlzIGV4cGxpY2l0bHkgZ3JhbnRlZCBpbiB3cml0 aW5nIGJ5IFF1YW50dW0uIFF1YW50dW0gcmVzZXJ2ZXMgdGhlIHJpZ2h0IHRvIGhhdmUgZWxlY3Ry b25pYyBjb21tdW5pY2F0aW9ucywgaW5jbHVkaW5nIGVtYWlsIGFuZCBhdHRhY2htZW50cywgc2Vu dCBhY3Jvc3MgaXRzIG5ldHdvcmtzIGZpbHRlcmVkIHRocm91Z2ggYW50aSB2aXJ1cyBhbmQgc3Bh bSBzb2Z0d2FyZSBwcm9ncmFtcyBhbmQgcmV0YWluIHN1Y2ggbWVzc2FnZXMgaW4gb3JkZXIgdG8g Y29tcGx5IHdpdGggYXBwbGljYWJsZSBkYXRhIHNlY3VyaXR5IGFuZCByZXRlbnRpb24gcmVxdWly ZW1lbnRzLiBRdWFudHVtIGlzIG5vdCByZXNwb25zaWJsZSBmb3IgdGhlIHByb3BlciBhbmQgY29t cGxldGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBzdWJzdGFuY2Ugb2YgdGhpcyBjb21tdW5pY2F0aW9u IG9yIGZvciBhbnkgZGVsYXkgaW4gaXRzIHJlY2VpcHQuCg== From nobody Wed Mar 25 16:47:19 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8D71A01BA for ; Wed, 25 Mar 2015 16:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uySEy7AGrtMf for ; Wed, 25 Mar 2015 16:47:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79DE1A906A for ; Wed, 25 Mar 2015 16:47:12 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t2PNkYFo019754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Mar 2015 16:46:34 -0700 (PDT) Message-ID: <551348D9.4090809@isi.edu> Date: Wed, 25 Mar 2015 16:46:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: David Borman , "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <1FDC0AFD-133B-49FB-840A-42CDD02F9850@quantum.com> In-Reply-To: <1FDC0AFD-133B-49FB-840A-42CDD02F9850@quantum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:47:18 -0000 +1, same here. It might be useful to have some fairly clear guidelines of what is considered in-scope and not, FWIW. I certainly would not want to see this become a roll-together of the roadmap. I.e., my preference would be a general rule: - only items that update existing 793 content I.e., a focus on clarification and updating, but not augmenting where possible. Joe On 3/25/2015 4:35 PM, David Borman wrote: > +1 > > I’m also willing to do review of the document. > > -David Borman > >> On Mar 25, 2015, at 5:31 PM, Scharf, Michael (Michael) wrote: >> >> Hi all, >> >> During the Dallas meeting in Dallas, there has been strong and unanimous support for adopting draft-eddy-rfc793bis-05 as new TCPM working group document. >> >> This email therefore starts a WG adoption call of draft-eddy-rfc793bis-05, which will run on the mailing list until April 8. >> >> The chairs suggest to add the following milestone to the TCPM charter: >> >> April 2017 Submit RFC793bis document to the IESG for publication as a Proposed Standard >> >> The chairs believe that it is consensus in TCPM that RFC793bis will not introduce protocol changes that have not already been approved by past consensus, e.g., by a standards track RFC or by a verified errata. The document is expected to obsolete RFC 793 and to update RFC 1122, as well as further TCP specifications. >> >> Please explicitly reply to this e-mail if you support WG acceptance. Since we run the adoption call on the list, please reply even if you have already hummed in Dallas to support the document. A simple "+1" response is sufficient to document support. >> >> The chairs will only proceed with WG acceptance if there is a sufficient number of reviewers who explicitly commit to review upcoming versions of the RFC793bis draft, prior to submission to IESG. Please let us chairs know now if you volunteer for reviews, in particular regarding the accuracy of RFC793bis. The chairs will keep track of volunteers. Please help TCPM with reviews of this crucial document! >> >> If there were any concerns regarding adopting draft-eddy-rfc793bis-05, please speak up. >> >> Thanks >> >> Michael, Pasi, Yoshifumi >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Mar 25 17:11:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8FA1ACCF8 for ; Wed, 25 Mar 2015 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usyM6_mWaQ9Q for ; Wed, 25 Mar 2015 17:11:21 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D671B2AD7 for ; Wed, 25 Mar 2015 17:11:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,468,1422950400"; d="scan'208";a="32644674" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 25 Mar 2015 17:06:20 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 25 Mar 2015 17:06:19 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Wed, 25 Mar 2015 17:06:20 -0700 From: "Scheffenegger, Richard" To: Joe Touch , David Borman , "Scharf, Michael (Michael)" Thread-Topic: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! Thread-Index: AdBnS2qAjku8ptSXRoy25gn0qr3pMgAQ5VmAAABmOYAADhCgUA== Date: Thu, 26 Mar 2015 00:06:19 +0000 Message-ID: <904e4e58fac142e0833ea226fa820934@hioexcmbx05-prd.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <1FDC0AFD-133B-49FB-840A-42CDD02F9850@quantum.com> <551348D9.4090809@isi.edu> In-Reply-To: <551348D9.4090809@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 00:11:23 -0000 Sm9lLA0KDQpJIHdhcyB3b25kZXJpbmcgYWJvdXQgdGhpcyBhcyB3ZWxsOyBXZXMgbWFkZSB0aGUg Y29tbWVudCB0byBhZGQgcGFydHMgb2YgNzMyMyAtIGJ1dCB0aGVuIGFnYWluLCBUUyBhbmQgUEFX UyByZWFsbHkgYXJlIG9wdGlvbmFsIGZlYXR1cmVzLiBJTUhPIGtlZXBpbmcgc3VjaCBpdGVtcyBv dXRzaWRlIHRoZSBkb2N1bWVudCBzaG91bGQgaGVscCBsaW1pdGluZyB0aGUgc2NvcGUgKGFuZCBl ZmZvcnQgdG8gdHJhY2sgZG93biBhbGwgdGhlIG5lY2Vzc2FyeSBjaGFuZ2VzKS4NCg0KDQpCZXN0 IHJlZ2FyZHMsDQogIFJpY2hhcmQNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBK b2UgVG91Y2gNCj4gU2VudDogTWl0dHdvY2gsIDI1LiBNw6RyeiAyMDE1IDE4OjQ3DQo+IFRvOiBE YXZpZCBCb3JtYW47IFNjaGFyZiwgTWljaGFlbCAoTWljaGFlbCkNCj4gQ2M6IHRjcG1AaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBXRyBhY2NlcHRhbmNlIG9mIGRyYWZ0LWVkZHktcmZj NzkzYmlzLTA1IC0gcGxlYXNlDQo+IHJlcGx5IQ0KPiANCj4gKzEsIHNhbWUgaGVyZS4NCj4gDQo+ IEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBoYXZlIHNvbWUgZmFpcmx5IGNsZWFyIGd1aWRlbGluZXMg b2Ygd2hhdCBpcw0KPiBjb25zaWRlcmVkIGluLXNjb3BlIGFuZCBub3QsIEZXSVcuDQo+IA0KPiBJ IGNlcnRhaW5seSB3b3VsZCBub3Qgd2FudCB0byBzZWUgdGhpcyBiZWNvbWUgYSByb2xsLXRvZ2V0 aGVyIG9mIHRoZQ0KPiByb2FkbWFwLiBJLmUuLCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIGEgZ2Vu ZXJhbCBydWxlOg0KPiANCj4gCS0gb25seSBpdGVtcyB0aGF0IHVwZGF0ZSBleGlzdGluZyA3OTMg Y29udGVudA0KPiANCj4gSS5lLiwgYSBmb2N1cyBvbiBjbGFyaWZpY2F0aW9uIGFuZCB1cGRhdGlu ZywgYnV0IG5vdCBhdWdtZW50aW5nIHdoZXJlDQo+IHBvc3NpYmxlLg0KPiANCj4gSm9lDQo+IA0K PiBPbiAzLzI1LzIwMTUgNDozNSBQTSwgRGF2aWQgQm9ybWFuIHdyb3RlOg0KPiA+ICsxDQo+ID4N Cj4gPiBJ4oCZbSBhbHNvIHdpbGxpbmcgdG8gZG8gcmV2aWV3IG9mIHRoZSBkb2N1bWVudC4NCj4g Pg0KPiA+IAktRGF2aWQgQm9ybWFuDQo+ID4NCj4gPj4gT24gTWFyIDI1LCAyMDE1LCBhdCA1OjMx IFBNLCBTY2hhcmYsIE1pY2hhZWwgKE1pY2hhZWwpDQo+IDxtaWNoYWVsLnNjaGFyZkBhbGNhdGVs LWx1Y2VudC5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+PiBIaSBhbGwsDQo+ID4+DQo+ID4+IER1cmlu ZyB0aGUgRGFsbGFzIG1lZXRpbmcgaW4gRGFsbGFzLCB0aGVyZSBoYXMgYmVlbiBzdHJvbmcgYW5k DQo+IHVuYW5pbW91cyBzdXBwb3J0IGZvciBhZG9wdGluZyBkcmFmdC1lZGR5LXJmYzc5M2Jpcy0w NSBhcyBuZXcgVENQTSB3b3JraW5nDQo+IGdyb3VwIGRvY3VtZW50Lg0KPiA+Pg0KPiA+PiBUaGlz IGVtYWlsIHRoZXJlZm9yZSBzdGFydHMgYSBXRyBhZG9wdGlvbiBjYWxsIG9mIGRyYWZ0LWVkZHkt cmZjNzkzYmlzLQ0KPiAwNSwgd2hpY2ggd2lsbCBydW4gb24gdGhlIG1haWxpbmcgbGlzdCB1bnRp bCBBcHJpbCA4Lg0KPiA+Pg0KPiA+PiBUaGUgY2hhaXJzIHN1Z2dlc3QgdG8gYWRkIHRoZSBmb2xs b3dpbmcgbWlsZXN0b25lIHRvIHRoZSBUQ1BNIGNoYXJ0ZXI6DQo+ID4+DQo+ID4+IEFwcmlsIDIw MTcgICAgU3VibWl0IFJGQzc5M2JpcyBkb2N1bWVudCB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRp b24gYXMNCj4gYSBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+Pg0KPiA+PiBUaGUgY2hhaXJzIGJlbGll dmUgdGhhdCBpdCBpcyBjb25zZW5zdXMgaW4gVENQTSB0aGF0IFJGQzc5M2JpcyB3aWxsIG5vdA0K PiBpbnRyb2R1Y2UgcHJvdG9jb2wgY2hhbmdlcyB0aGF0IGhhdmUgbm90IGFscmVhZHkgYmVlbiBh cHByb3ZlZCBieSBwYXN0DQo+IGNvbnNlbnN1cywgZS5nLiwgYnkgYSBzdGFuZGFyZHMgdHJhY2sg UkZDIG9yIGJ5IGEgdmVyaWZpZWQgZXJyYXRhLiBUaGUNCj4gZG9jdW1lbnQgaXMgZXhwZWN0ZWQg dG8gb2Jzb2xldGUgUkZDIDc5MyBhbmQgdG8gdXBkYXRlIFJGQyAxMTIyLCBhcyB3ZWxsDQo+IGFz IGZ1cnRoZXIgVENQIHNwZWNpZmljYXRpb25zLg0KPiA+Pg0KPiA+PiBQbGVhc2UgZXhwbGljaXRs eSByZXBseSB0byB0aGlzIGUtbWFpbCBpZiB5b3Ugc3VwcG9ydCBXRyBhY2NlcHRhbmNlLg0KPiBT aW5jZSB3ZSBydW4gdGhlIGFkb3B0aW9uIGNhbGwgb24gdGhlIGxpc3QsIHBsZWFzZSByZXBseSBl dmVuIGlmIHlvdSBoYXZlDQo+IGFscmVhZHkgaHVtbWVkIGluIERhbGxhcyB0byBzdXBwb3J0IHRo ZSBkb2N1bWVudC4gQSBzaW1wbGUgIisxIiByZXNwb25zZQ0KPiBpcyBzdWZmaWNpZW50IHRvIGRv Y3VtZW50IHN1cHBvcnQuDQo+ID4+DQo+ID4+IFRoZSBjaGFpcnMgd2lsbCBvbmx5IHByb2NlZWQg d2l0aCBXRyBhY2NlcHRhbmNlIGlmIHRoZXJlIGlzIGENCj4gc3VmZmljaWVudCBudW1iZXIgb2Yg cmV2aWV3ZXJzIHdobyBleHBsaWNpdGx5IGNvbW1pdCB0byByZXZpZXcgdXBjb21pbmcNCj4gdmVy c2lvbnMgb2YgdGhlIFJGQzc5M2JpcyBkcmFmdCwgcHJpb3IgdG8gc3VibWlzc2lvbiB0byBJRVNH LiBQbGVhc2UgbGV0DQo+IHVzIGNoYWlycyBrbm93IG5vdyBpZiB5b3Ugdm9sdW50ZWVyIGZvciBy ZXZpZXdzLCBpbiBwYXJ0aWN1bGFyIHJlZ2FyZGluZw0KPiB0aGUgYWNjdXJhY3kgb2YgUkZDNzkz YmlzLiBUaGUgY2hhaXJzIHdpbGwga2VlcCB0cmFjayBvZiB2b2x1bnRlZXJzLg0KPiBQbGVhc2Ug aGVscCBUQ1BNIHdpdGggcmV2aWV3cyBvZiB0aGlzIGNydWNpYWwgZG9jdW1lbnQhDQo+ID4+DQo+ ID4+IElmIHRoZXJlIHdlcmUgYW55IGNvbmNlcm5zIHJlZ2FyZGluZyBhZG9wdGluZyBkcmFmdC1l ZGR5LXJmYzc5M2Jpcy0wNSwNCj4gcGxlYXNlIHNwZWFrIHVwLg0KPiA+Pg0KPiA+PiBUaGFua3MN Cj4gPj4NCj4gPj4gTWljaGFlbCwgUGFzaSwgWW9zaGlmdW1pDQo+ID4+DQo+ID4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHRjcG0gbWFpbGlu ZyBsaXN0DQo+ID4+IHRjcG1AaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90Y3BtDQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIG1heSBiZSBjb25maWRl bnRpYWwuIEFueQ0KPiBkaXNjbG9zdXJlLCBjb3B5aW5nLCBvciBmdXJ0aGVyIGRpc3RyaWJ1dGlv biBvZiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24NCj4gaXMgbm90IHBlcm1pdHRlZCB1bmxlc3Mg c3VjaCBwcml2aWxlZ2UgaXMgZXhwbGljaXRseSBncmFudGVkIGluIHdyaXRpbmcgYnkNCj4gUXVh bnR1bS4gUXVhbnR1bSByZXNlcnZlcyB0aGUgcmlnaHQgdG8gaGF2ZSBlbGVjdHJvbmljIGNvbW11 bmljYXRpb25zLA0KPiBpbmNsdWRpbmcgZW1haWwgYW5kIGF0dGFjaG1lbnRzLCBzZW50IGFjcm9z cyBpdHMgbmV0d29ya3MgZmlsdGVyZWQgdGhyb3VnaA0KPiBhbnRpIHZpcnVzIGFuZCBzcGFtIHNv ZnR3YXJlIHByb2dyYW1zIGFuZCByZXRhaW4gc3VjaCBtZXNzYWdlcyBpbiBvcmRlciB0bw0KPiBj b21wbHkgd2l0aCBhcHBsaWNhYmxlIGRhdGEgc2VjdXJpdHkgYW5kIHJldGVudGlvbiByZXF1aXJl bWVudHMuIFF1YW50dW0NCj4gaXMgbm90IHJlc3BvbnNpYmxlIGZvciB0aGUgcHJvcGVyIGFuZCBj b21wbGV0ZSB0cmFuc21pc3Npb24gb2YgdGhlDQo+IHN1YnN0YW5jZSBvZiB0aGlzIGNvbW11bmlj YXRpb24gb3IgZm9yIGFueSBkZWxheSBpbiBpdHMgcmVjZWlwdC4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHRjcG0gbWFpbGluZyBsaXN0 DQo+ID4gdGNwbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0K From nobody Wed Mar 25 17:12:09 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA841A007D for ; Wed, 25 Mar 2015 17:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTS8OmVYOHmz for ; Wed, 25 Mar 2015 17:12:04 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id BFDDB1A0013 for ; Wed, 25 Mar 2015 17:12:04 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2Q0C2ZP025215 for ; Wed, 25 Mar 2015 20:12:02 -0400 Received: (qmail 14669 invoked by uid 0); 26 Mar 2015 00:12:02 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 26 Mar 2015 00:12:02 -0000 Message-ID: <55134ECF.2040406@mti-systems.com> Date: Wed, 25 Mar 2015 20:11:59 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Joe Touch , David Borman , "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <1FDC0AFD-133B-49FB-840A-42CDD02F9850@quantum.com> <551348D9.4090809@isi.edu> In-Reply-To: <551348D9.4090809@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 00:12:08 -0000 On 3/25/2015 7:46 PM, Joe Touch wrote: > +1, same here. > > It might be useful to have some fairly clear guidelines of what is > considered in-scope and not, FWIW. > > I certainly would not want to see this become a roll-together of the > roadmap. I.e., my preference would be a general rule: > > - only items that update existing 793 content > > I.e., a focus on clarification and updating, but not augmenting where > possible. > I agree, it probably isn't as clear as it should be on this at the moment. While we're adopting, we can fix that! For reference, here's the text on scope in -05: """ The purpose of this document is to bring together all of the IETF Standards Track changes that have been made to the basic TCP functional specification and unify them into an update of the RFC 793 protocol specification. Some companion documents are referenced for important algorithms that TCP uses (e.g. for congestion control), but have not been attempted to include in this document. This is a conscious choice, as this base specification can be used with multiple additional algorithms that are developed and incorporated separately, but all TCP implementations need to implement this specification as a common basis in order to interoperate. As some additional TCP features have become quite complicated themselves (e.g. advanced loss recovery and congestion control), future companion documents may attempt to similarly bring these together. """ The attempt here was to avoid getting into most of the enhancements and improvements that aren't strictly necessary, and just to add pointers to the things that are "really important", for instance to RFC 5681 for congestion control (which 1122 requires to be implemented). This would actually be pretty consistent with the way that 1122 simply points to the Van Jacobson paper for slow-start and congestion avoidance algorithms but doesn't try to describe them. -- Wes Eddy MTI Systems From nobody Wed Mar 25 17:14:49 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A8A1A01A9 for ; Wed, 25 Mar 2015 17:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnBFq2PmTWdR for ; Wed, 25 Mar 2015 17:14:45 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id C854C1A00F3 for ; Wed, 25 Mar 2015 17:14:45 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2Q0EiKe029275 for ; Wed, 25 Mar 2015 20:14:44 -0400 Received: (qmail 3788 invoked by uid 0); 26 Mar 2015 00:14:44 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 26 Mar 2015 00:14:44 -0000 Message-ID: <55134F70.4080302@mti-systems.com> Date: Wed, 25 Mar 2015 20:14:40 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , Joe Touch , David Borman , "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <1FDC0AFD-133B-49FB-840A-42CDD02F9850@quantum.com> <551348D9.4090809@isi.edu> <904e4e58fac142e0833ea226fa820934@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <904e4e58fac142e0833ea226fa820934@hioexcmbx05-prd.hq.netapp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 00:14:47 -0000 On 3/25/2015 8:06 PM, Scheffenegger, Richard wrote: > Joe, > > I was wondering about this as well; Wes made the comment to add parts of 7323 - but then again, TS and PAWS really are optional features. IMHO keeping such items outside the document should help limiting the scope (and effort to track down all the necessary changes). > I may have mis-spoke, but the intention was to *point* to 7323, as highly recommended for performing well in modern networks, but not to suck its content in. -- Wes Eddy MTI Systems From nobody Wed Mar 25 20:38:19 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E3A1A7001 for ; Wed, 25 Mar 2015 20:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_TSX_SLremE for ; Wed, 25 Mar 2015 20:38:15 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5D67D1A6F5D for ; Wed, 25 Mar 2015 20:38:14 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:71ba:da96:9290:e19d] (unknown [IPv6:2001:67c:370:136:71ba:da96:9290:e19d]) by trammell.ch (Postfix) with ESMTPSA id 6AC591A0032; Thu, 26 Mar 2015 04:37:43 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Trammell X-Mailer: iPhone Mail (12D508) In-Reply-To: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 25 Mar 2015 22:37:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 03:38:18 -0000 Approve adoption, will review. Cheers,=20 Brian > On 25 Mar 2015, at 17:31, Scharf, Michael (Michael) wrote: >=20 > Hi all, >=20 > During the Dallas meeting in Dallas, there has been strong and unanimous s= upport for adopting draft-eddy-rfc793bis-05 as new TCPM working group docume= nt. >=20 > This email therefore starts a WG adoption call of draft-eddy-rfc793bis-05,= which will run on the mailing list until April 8. >=20 > The chairs suggest to add the following milestone to the TCPM charter: >=20 > April 2017 Submit RFC793bis document to the IESG for publication as a P= roposed Standard >=20 > The chairs believe that it is consensus in TCPM that RFC793bis will not in= troduce protocol changes that have not already been approved by past consens= us, e.g., by a standards track RFC or by a verified errata. The document is e= xpected to obsolete RFC 793 and to update RFC 1122, as well as further TCP s= pecifications. >=20 > Please explicitly reply to this e-mail if you support WG acceptance. Since= we run the adoption call on the list, please reply even if you have already= hummed in Dallas to support the document. A simple "+1" response is suffici= ent to document support. >=20 > The chairs will only proceed with WG acceptance if there is a sufficient n= umber of reviewers who explicitly commit to review upcoming versions of the R= FC793bis draft, prior to submission to IESG. Please let us chairs know now i= f you volunteer for reviews, in particular regarding the accuracy of RFC793b= is. The chairs will keep track of volunteers. Please help TCPM with reviews o= f this crucial document! >=20 > If there were any concerns regarding adopting draft-eddy-rfc793bis-05, ple= ase speak up. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Mar 26 00:50:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB41A8881 for ; Thu, 26 Mar 2015 00:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V50ik--ffh0j for ; Thu, 26 Mar 2015 00:50:43 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40781ACDD7 for ; Thu, 26 Mar 2015 00:50:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,469,1422950400"; d="scan'208";a="31771400" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx143-out.netapp.com with ESMTP; 26 Mar 2015 00:45:41 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 26 Mar 2015 00:45:41 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::6036:353f:66f7:c599%21]) with mapi id 15.00.0995.031; Thu, 26 Mar 2015 00:45:41 -0700 From: "Zimmermann, Alexander" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! Thread-Index: AdBnS2qAjku8ptSXRoy25gn0qr3pMgAiB6eA Date: Thu, 26 Mar 2015 07:45:40 +0000 Message-ID: <2CA228AF-AAF2-42E6-A144-D53046321736@netapp.com> References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-ID: <237C4B26C4BF9F46A2A60CF640305D6B@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 07:50:45 -0000 +1 for adoption and reviewing > Am 25.03.2015 um 23:31 schrieb Scharf, Michael (Michael) : >=20 > Hi all, >=20 > During the Dallas meeting in Dallas, there has been strong and unanimous = support for adopting draft-eddy-rfc793bis-05 as new TCPM working group docu= ment. >=20 > This email therefore starts a WG adoption call of draft-eddy-rfc793bis-05= , which will run on the mailing list until April 8. >=20 > The chairs suggest to add the following milestone to the TCPM charter: >=20 > April 2017 Submit RFC793bis document to the IESG for publication as a = Proposed Standard >=20 > The chairs believe that it is consensus in TCPM that RFC793bis will not i= ntroduce protocol changes that have not already been approved by past conse= nsus, e.g., by a standards track RFC or by a verified errata. The document = is expected to obsolete RFC 793 and to update RFC 1122, as well as further = TCP specifications. >=20 > Please explicitly reply to this e-mail if you support WG acceptance. Sinc= e we run the adoption call on the list, please reply even if you have alrea= dy hummed in Dallas to support the document. A simple "+1" response is suff= icient to document support. >=20 > The chairs will only proceed with WG acceptance if there is a sufficient = number of reviewers who explicitly commit to review upcoming versions of th= e RFC793bis draft, prior to submission to IESG. Please let us chairs know n= ow if you volunteer for reviews, in particular regarding the accuracy of RF= C793bis. The chairs will keep track of volunteers. Please help TCPM with re= views of this crucial document! >=20 > If there were any concerns regarding adopting draft-eddy-rfc793bis-05, pl= ease speak up. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Mar 26 03:49:17 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4A1B2C5A for ; Thu, 26 Mar 2015 03:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3a-YynLwVva for ; Thu, 26 Mar 2015 03:49:14 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850191B2C54 for ; Thu, 26 Mar 2015 03:49:14 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id CE5C5A4FD8D6A; Thu, 26 Mar 2015 10:49:08 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2QAn80L015163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 11:49:08 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 11:49:07 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" Thread-Topic: WG acceptance of draft-eddy-rfc793bis-05 - please reply! Thread-Index: AdBnS2qAjku8ptSXRoy25gn0qr3pMgABE8TAAABNTLAAF+dP/Q== Date: Thu, 26 Mar 2015 10:49:07 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C6C169@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <655C07320163294895BBADA28372AF5D16C6BD29@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C6BD29@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.192.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 10:49:16 -0000 Regarding the date: The 100th IETF would be in Nov. 2017, probably in Asia-= Pacific.=0A= =0A= Maybe completing RFC 793bis could be an appropriate target for that anniver= sary? (Yes, I know that this may be dreaming and the reasoning doesn't work= in hex numbers, but awaiting IETF 0x80 doesn't seem a good alternative...)= =0A= =0A= Michael= From nobody Thu Mar 26 12:14:59 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EDC1B2A78 for ; Thu, 26 Mar 2015 12:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DqPT2rVIBOx for ; Thu, 26 Mar 2015 12:14:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4971B29E4 for ; Thu, 26 Mar 2015 12:14:54 -0700 (PDT) Received: from [2001:67c:370:160:2cb6:4f80:a90b:de2f] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YbDEx-00037x-TQ; Thu, 26 Mar 2015 20:14:52 +0100 Message-ID: <5514581D.4020909@si6networks.com> Date: Thu, 26 Mar 2015 14:03:57 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> In-Reply-To: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:14:57 -0000 Folks, Thanks to some folks' push over time, and the fact that both co-authors happened to find themselves at IETF 92, we've reposted our latests version of this I-D (since the previous one had expired), in the hopes of making progress. Any comments on this rev will be appreciated. Additionally, I'll repost/fwd Karen's latest comments on this I-D, which will be the basis for the changes in the next rev. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt Date: Thu, 26 Mar 2015 11:55:46 -0700 From: internet-drafts@ietf.org To: Fernando Gont , David Borman , Fernando Gont , David Borman A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-tcpm-tcp-seq-validation Revision: 02 Title: On the Validation of TCP Sequence Numbers Document date: 2015-03-26 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-02.txt Status: https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/ Htmlized: http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-gont-tcpm-tcp-seq-validation-02 Abstract: When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Mar 26 12:15:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC611AC414; Thu, 26 Mar 2015 12:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IlEgDCM8u2J; Thu, 26 Mar 2015 12:15:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 564C31B2A94; Thu, 26 Mar 2015 12:15:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326191507.6398.83538.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 12:15:07 -0700 Archived-At: Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'Problem Statement and Requirements for a More Accurate ECN Feedback' to Informational RFC (draft-ietf-tcpm-accecn-reqs-08.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:15:11 -0000 The IESG has approved the following document: - 'Problem Statement and Requirements for a More Accurate ECN Feedback' (draft-ietf-tcpm-accecn-reqs-08.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ Technical Summary Traditionally the explicit congestion notification can deliver only one congestion signal in a round-trip time with TCP. This Informational document motivates the case for delivering more accurate congestion information for TCP. It discusses high-level requirements for methods for delivering more accurate congestion information, but does not specify such mechanism. Therefore Informational is considered appropriate document type. Working Group Summary The document was reviewed by a few WG participants in its different phases, also during the WGLC. There has been no controversy over it. TCPM chairs believe the document is stable and has gone through a sufficient review, and is ready for publication. Document Quality There are no implementations, as this is solely a requirements document. The reviews done ins mentioned under WG summary. Personnel The document shepherd is Pasi Sarolahti. The responsible AD is Martin Stiemerling. From nobody Thu Mar 26 12:33:41 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79201AC411 for ; Thu, 26 Mar 2015 12:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr6ZVv9-4byF for ; Thu, 26 Mar 2015 12:33:38 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id F08161A9075 for ; Thu, 26 Mar 2015 12:33:29 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2QJXSBW007312 for ; Thu, 26 Mar 2015 15:33:28 -0400 Received: (qmail 20442 invoked by uid 0); 26 Mar 2015 19:33:28 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.3?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 26 Mar 2015 19:33:28 -0000 Message-ID: <55145F03.3010505@mti-systems.com> Date: Thu, 26 Mar 2015 15:33:23 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Fernando Gont , "tcpm@ietf.org" References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> In-Reply-To: <5514581D.4020909@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:33:39 -0000 On 3/26/2015 3:03 PM, Fernando Gont wrote: > Folks, > > Thanks to some folks' push over time, and the fact that both co-authors > happened to find themselves at IETF 92, we've reposted our latests > version of this I-D (since the previous one had expired), in the hopes > of making progress. > > Any comments on this rev will be appreciated. Additionally, I'll > repost/fwd Karen's latest comments on this I-D, which will be the basis > for the changes in the next rev. > I've read it. I think it's quite clear in all regards, and that the draft should definitely be adopted. -- Wes Eddy MTI Systems From nobody Thu Mar 26 12:37:48 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3618E1B2A97 for ; Thu, 26 Mar 2015 12:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-sYszvzfZQK for ; Thu, 26 Mar 2015 12:37:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA92D1A9075 for ; Thu, 26 Mar 2015 12:37:43 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id CC8AC8502EC03 for ; Thu, 26 Mar 2015 19:37:38 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2QJbgG7020358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Mar 2015 20:37:42 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 20:37:42 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WG acceptance of draft-eddy-rfc793bis-05 - correction Thread-Index: AQHQZ/xT211gRMPKuE6FwnqeDmKC0w== Date: Thu, 26 Mar 2015 19:37:42 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C6CF5C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - correction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:37:47 -0000 Hi, I'd like to correct the suggested milestone, given a copy and paste error f= or the document status. Also, I'd like to relax the timing a bit: Nov 2017 Submit RFC793bis document to the IESG for publication as Intern= et Standard Please note that we need further feedback for determining the TCPM consensu= s on adoption. Also, further volunteers for reviews (e.g., from implementers) would really= be welcome. Thanks Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Wednesday, March 25, 2015 11:31 PM > To: tcpm@ietf.org > Subject: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please > reply! >=20 > Hi all, >=20 > During the Dallas meeting in Dallas, there has been strong and > unanimous support for adopting draft-eddy-rfc793bis-05 as new TCPM > working group document. >=20 > This email therefore starts a WG adoption call of draft-eddy-rfc793bis- > 05, which will run on the mailing list until April 8. >=20 > The chairs suggest to add the following milestone to the TCPM charter: >=20 > April 2017 Submit RFC793bis document to the IESG for publication as > a Proposed Standard >=20 > The chairs believe that it is consensus in TCPM that RFC793bis will not > introduce protocol changes that have not already been approved by past > consensus, e.g., by a standards track RFC or by a verified errata. The > document is expected to obsolete RFC 793 and to update RFC 1122, as > well as further TCP specifications. >=20 > Please explicitly reply to this e-mail if you support WG acceptance. > Since we run the adoption call on the list, please reply even if you > have already hummed in Dallas to support the document. A simple "+1" > response is sufficient to document support. >=20 > The chairs will only proceed with WG acceptance if there is a > sufficient number of reviewers who explicitly commit to review upcoming > versions of the RFC793bis draft, prior to submission to IESG. Please > let us chairs know now if you volunteer for reviews, in particular > regarding the accuracy of RFC793bis. The chairs will keep track of > volunteers. Please help TCPM with reviews of this crucial document! >=20 > If there were any concerns regarding adopting draft-eddy-rfc793bis-05, > please speak up. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Mar 26 12:58:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495E81B2B21 for ; Thu, 26 Mar 2015 12:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX18Xu_-NgRY for ; Thu, 26 Mar 2015 12:58:16 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661A61B2B61 for ; Thu, 26 Mar 2015 12:57:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,474,1422950400"; d="scan'208";a="32821589" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx141-out.netapp.com with ESMTP; 26 Mar 2015 12:52:56 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 26 Mar 2015 12:52:55 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Thu, 26 Mar 2015 12:52:55 -0700 From: "Scheffenegger, Richard" To: Fernando Gont , "tcpm@ietf.org" Thread-Topic: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) Thread-Index: AQHQZ/kp/YBE7N9r5k2iLiR288WDK50vLHNg Date: Thu, 26 Mar 2015 19:52:55 +0000 Message-ID: References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> In-Reply-To: <5514581D.4020909@si6networks.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:58:20 -0000 Hi, I've definitely read the earlier version of this draft (and this is only a = repost); odd that I appear to have posted to the list that I also support t= his... Tl;dr: +1 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: Donnerstag, 26. M=E4rz 2015 14:04 > To: tcpm@ietf.org > Subject: [tcpm] TCP SEQ validation (Fwd: New Version Notification for > draft-gont-tcpm-tcp-seq-validation-02.txt) >=20 > Folks, >=20 > Thanks to some folks' push over time, and the fact that both co-authors > happened to find themselves at IETF 92, we've reposted our latests versio= n > of this I-D (since the previous one had expired), in the hopes of making > progress. >=20 > Any comments on this rev will be appreciated. Additionally, I'll > repost/fwd Karen's latest comments on this I-D, which will be the basis > for the changes in the next rev. >=20 > Thanks! >=20 > Best regards, > Fernando >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-tcpm-tcp-seq-validation-02.txt > Date: Thu, 26 Mar 2015 11:55:46 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , David Borman > , Fernando Gont , David > Borman >=20 >=20 > A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt > has been successfully submitted by Fernando Gont and posted to the IETF > repository. >=20 > Name: draft-gont-tcpm-tcp-seq-validation > Revision: 02 > Title: On the Validation of TCP Sequence Numbers > Document date: 2015-03-26 > Group: Individual Submission > Pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation- > 02.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/ > Htmlized: > http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-tcpm-tcp-seq-validation-02 >=20 > Abstract: > When TCP receives packets that lie outside of the receive window, the > corresponding packets are dropped and either an ACK, RST or no > response is generated due to the out-of-window packet, with no > further processing of the packet. Most of the time, this works just > fine and TCP remains stable, especially when a TCP connection has > unidirectional data flow. However, there are three scenarios in > which packets that are outside of the receive window should still > have their ACK field processed, or else a packet war will take place. > The aforementioned issues have affected a number of popular TCP > implementations, typically leading to connection failures, system > crashes, or other undesirable behaviors. This document describes the > three scenarios in which the aforementioned issues might arise, and > formally updates RFC 793 such that these potential problems are > mitigated. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Mar 26 16:23:38 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C37A1A1C03 for ; Thu, 26 Mar 2015 16:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqk_liLQMwJY for ; Thu, 26 Mar 2015 16:23:31 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391361A1B95 for ; Thu, 26 Mar 2015 16:23:29 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A210E2780AF for ; Fri, 27 Mar 2015 08:23:27 +0900 (JST) Received: by wibbg6 with SMTP id bg6so7442336wib.0 for ; Thu, 26 Mar 2015 16:23:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.90.166 with SMTP id bx6mr50989809wib.65.1427412205124; Thu, 26 Mar 2015 16:23:25 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Thu, 26 Mar 2015 16:23:25 -0700 (PDT) In-Reply-To: <5514581D.4020909@si6networks.com> References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> Date: Thu, 26 Mar 2015 16:23:25 -0700 Message-ID: From: Yoshifumi Nishida To: Fernando Gont Content-Type: multipart/alternative; boundary=f46d043bdf866f40ff0512394d93 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:23:34 -0000 --f46d043bdf866f40ff0512394d93 Content-Type: text/plain; charset=UTF-8 Hi, I would like to check people who are willing to support it also agree that this draft is published as a PS and it updates 793, or prefer other ways. -- Yoshi On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont wrote: > Folks, > > Thanks to some folks' push over time, and the fact that both co-authors > happened to find themselves at IETF 92, we've reposted our latests > version of this I-D (since the previous one had expired), in the hopes > of making progress. > > Any comments on this rev will be appreciated. Additionally, I'll > repost/fwd Karen's latest comments on this I-D, which will be the basis > for the changes in the next rev. > > Thanks! > > Best regards, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-tcpm-tcp-seq-validation-02.txt > Date: Thu, 26 Mar 2015 11:55:46 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , David Borman > , Fernando Gont , David > Borman > > > A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-tcpm-tcp-seq-validation > Revision: 02 > Title: On the Validation of TCP Sequence Numbers > Document date: 2015-03-26 > Group: Individual Submission > Pages: 16 > URL: > > http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-02.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/ > Htmlized: > http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-gont-tcpm-tcp-seq-validation-02 > > Abstract: > When TCP receives packets that lie outside of the receive window, the > corresponding packets are dropped and either an ACK, RST or no > response is generated due to the out-of-window packet, with no > further processing of the packet. Most of the time, this works just > fine and TCP remains stable, especially when a TCP connection has > unidirectional data flow. However, there are three scenarios in > which packets that are outside of the receive window should still > have their ACK field processed, or else a packet war will take place. > The aforementioned issues have affected a number of popular TCP > implementations, typically leading to connection failures, system > crashes, or other undesirable behaviors. This document describes the > three scenarios in which the aforementioned issues might arise, and > formally updates RFC 793 such that these potential problems are > mitigated. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --f46d043bdf866f40ff0512394d93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
I would like to check people who are willing= to support it also agree that this draft is published as a PS and it updat= es 793, or prefer other ways.
--
Yoshi

On Thu, Mar 26, 2015 at 12:03 PM, Fe= rnando Gont <fgont@si6networks.com> wrote:
Folks,

Thanks to some folks' push over time, and the fact that both co-authors=
happened to find themselves at IETF 92, we've reposted our latests
version of this I-D (since the previous one had expired), in the hopes
of making progress.

Any comments on this rev will be appreciated. Additionally, I'll
repost/fwd Karen's latest comments on this I-D, which will be the basis=
for the changes in the next rev.

Thanks!

Best regards,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-tcpm-tcp-seq-validation-02.txt
Date: Thu, 26 Mar 2015 11:55:46 -0700
From: internet-drafts@ietf.org<= /a>
To: Fernando Gont <fgont@si6net= works.com>, David Borman
<david.borman@quantum.com>, Fernando Gont <fgont@si6= networks.com>, David
Borman <david.borman@quantum= .com>


A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-tcpm-tcp-seq-valid= ation
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On the Validation of TCP Sequence = Numbers
Document date:=C2=A0 2015-03-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
URL:
http://www.ietf.org/internet-drafts/draft-= gont-tcpm-tcp-seq-validation-02.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-tcpm-tc= p-seq-validation/
Htmlized:
http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-vali= dation-02
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-t= cpm-tcp-seq-validation-02

Abstract:
=C2=A0 =C2=A0When TCP receives packets that lie outside of the receive wind= ow, the
=C2=A0 =C2=A0corresponding packets are dropped and either an ACK, RST or no=
=C2=A0 =C2=A0response is generated due to the out-of-window packet, with no=
=C2=A0 =C2=A0further processing of the packet.=C2=A0 Most of the time, this= works just
=C2=A0 =C2=A0fine and TCP remains stable, especially when a TCP connection = has
=C2=A0 =C2=A0unidirectional data flow.=C2=A0 However, there are three scena= rios in
=C2=A0 =C2=A0which packets that are outside of the receive window should st= ill
=C2=A0 =C2=A0have their ACK field processed, or else a packet war will take= place.
=C2=A0 =C2=A0The aforementioned issues have affected a number of popular TC= P
=C2=A0 =C2=A0implementations, typically leading to connection failures, sys= tem
=C2=A0 =C2=A0crashes, or other undesirable behaviors.=C2=A0 This document d= escribes the
=C2=A0 =C2=A0three scenarios in which the aforementioned issues might arise= , and
=C2=A0 =C2=A0formally updates RFC 793 such that these potential problems ar= e
=C2=A0 =C2=A0mitigated.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

--f46d043bdf866f40ff0512394d93-- From nobody Fri Mar 27 04:46:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B6B1ACD6E for ; Fri, 27 Mar 2015 04:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfDxTXWjlcZb for ; Fri, 27 Mar 2015 04:46:03 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86371ACD72 for ; Fri, 27 Mar 2015 04:46:02 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,478,1422950400"; d="scan'208,217"; a="31384374" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 27 Mar 2015 04:41:02 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 27 Mar 2015 04:41:02 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Fri, 27 Mar 2015 04:41:02 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida , Fernando Gont Thread-Topic: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) Thread-Index: AQHQZ/kp/YBE7N9r5k2iLiR288WDK50v3R2AgABYMYA= Date: Fri, 27 Mar 2015 11:41:02 +0000 Message-ID: <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.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.120.60.35] Content-Type: multipart/alternative; boundary="_000_915de06f7beb41c78b1a0b324ab14287hioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 11:46:05 -0000 --_000_915de06f7beb41c78b1a0b324ab14287hioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCB0aGluayBQUyBpcyB0aGUgcHJvcGVyIHdheSDigJMgdGhlcmUgaXMgbm8gZXhwZXJp bWVudGluZyB3aXRoIGEgYnVnZ3kgc3BlYywgYW5kIEZlcm5hbmRvIHBvaW50ZWQgb3V0LCB0aGF0 IG1vc3Qgc3RhY2tzIGhhZCBmaXhlZCB0aGF0IHBhcnRpY3VsYXIgYnVnIGluIDc5MyBmb3IgcXVp dGUgc29tZSB3aGlsZSwgcmlnaHQ/DQoNClJpY2hhcmQNCg0KDQpGcm9tOiB0Y3BtIFttYWlsdG86 dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9zaGlmdW1pIE5pc2hpZGENClNl bnQ6IERvbm5lcnN0YWcsIDI2LiBNw6RyeiAyMDE1IDE4OjIzDQpUbzogRmVybmFuZG8gR29udA0K Q2M6IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gVENQIFNFUSB2YWxpZGF0aW9u IChGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ29udC10Y3BtLXRjcC1z ZXEtdmFsaWRhdGlvbi0wMi50eHQpDQoNCkhpLA0KSSB3b3VsZCBsaWtlIHRvIGNoZWNrIHBlb3Bs ZSB3aG8gYXJlIHdpbGxpbmcgdG8gc3VwcG9ydCBpdCBhbHNvIGFncmVlIHRoYXQgdGhpcyBkcmFm dCBpcyBwdWJsaXNoZWQgYXMgYSBQUyBhbmQgaXQgdXBkYXRlcyA3OTMsIG9yIHByZWZlciBvdGhl ciB3YXlzLg0KLS0NCllvc2hpDQoNCk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDEyOjAzIFBNLCBG ZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdv cmtzLmNvbT4+IHdyb3RlOg0KRm9sa3MsDQoNClRoYW5rcyB0byBzb21lIGZvbGtzJyBwdXNoIG92 ZXIgdGltZSwgYW5kIHRoZSBmYWN0IHRoYXQgYm90aCBjby1hdXRob3JzDQpoYXBwZW5lZCB0byBm aW5kIHRoZW1zZWx2ZXMgYXQgSUVURiA5Miwgd2UndmUgcmVwb3N0ZWQgb3VyIGxhdGVzdHMNCnZl cnNpb24gb2YgdGhpcyBJLUQgKHNpbmNlIHRoZSBwcmV2aW91cyBvbmUgaGFkIGV4cGlyZWQpLCBp biB0aGUgaG9wZXMNCm9mIG1ha2luZyBwcm9ncmVzcy4NCg0KQW55IGNvbW1lbnRzIG9uIHRoaXMg cmV2IHdpbGwgYmUgYXBwcmVjaWF0ZWQuIEFkZGl0aW9uYWxseSwgSSdsbA0KcmVwb3N0L2Z3ZCBL YXJlbidzIGxhdGVzdCBjb21tZW50cyBvbiB0aGlzIEktRCwgd2hpY2ggd2lsbCBiZSB0aGUgYmFz aXMNCmZvciB0aGUgY2hhbmdlcyBpbiB0aGUgbmV4dCByZXYuDQoNClRoYW5rcyENCg0KQmVzdCBy ZWdhcmRzLA0KRmVybmFuZG8NCg0KDQoNCg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0t LS0tLS0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCmRyYWZ0LWdvbnQt dGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDIudHh0DQpEYXRlOiBUaHUsIDI2IE1hciAyMDE1IDEx OjU1OjQ2IC0wNzAwDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4NClRvOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jr cy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbT4+LCBEYXZpZCBCb3JtYW4NCjxkYXZp ZC5ib3JtYW5AcXVhbnR1bS5jb208bWFpbHRvOmRhdmlkLmJvcm1hbkBxdWFudHVtLmNvbT4+LCBG ZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdv cmtzLmNvbT4+LCBEYXZpZA0KQm9ybWFuIDxkYXZpZC5ib3JtYW5AcXVhbnR1bS5jb208bWFpbHRv OmRhdmlkLmJvcm1hbkBxdWFudHVtLmNvbT4+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWdvbnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IEZlcm5hbmRvIEdvbnQgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYg cmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWdvbnQtdGNwbS10Y3Atc2VxLXZh bGlkYXRpb24NClJldmlzaW9uOiAgICAgICAwMg0KVGl0bGU6ICAgICAgICAgIE9uIHRoZSBWYWxp ZGF0aW9uIG9mIFRDUCBTZXF1ZW5jZSBOdW1iZXJzDQpEb2N1bWVudCBkYXRlOiAgMjAxNS0wMy0y Ng0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAg IDE2DQpVUkw6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250 LXRjcG0tdGNwLXNlcS12YWxpZGF0aW9uLTAyLnR4dA0KU3RhdHVzOg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEtdmFsaWRhdGlvbi8NCkh0 bWxpemVkOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29udC10Y3BtLXRjcC1z ZXEtdmFsaWRhdGlvbi0wMg0KRGlmZjoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWdvbnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDINCg0KQWJzdHJhY3Q6DQogICBX aGVuIFRDUCByZWNlaXZlcyBwYWNrZXRzIHRoYXQgbGllIG91dHNpZGUgb2YgdGhlIHJlY2VpdmUg d2luZG93LCB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgcGFja2V0cyBhcmUgZHJvcHBlZCBhbmQgZWl0 aGVyIGFuIEFDSywgUlNUIG9yIG5vDQogICByZXNwb25zZSBpcyBnZW5lcmF0ZWQgZHVlIHRvIHRo ZSBvdXQtb2Ytd2luZG93IHBhY2tldCwgd2l0aCBubw0KICAgZnVydGhlciBwcm9jZXNzaW5nIG9m IHRoZSBwYWNrZXQuICBNb3N0IG9mIHRoZSB0aW1lLCB0aGlzIHdvcmtzIGp1c3QNCiAgIGZpbmUg YW5kIFRDUCByZW1haW5zIHN0YWJsZSwgZXNwZWNpYWxseSB3aGVuIGEgVENQIGNvbm5lY3Rpb24g aGFzDQogICB1bmlkaXJlY3Rpb25hbCBkYXRhIGZsb3cuICBIb3dldmVyLCB0aGVyZSBhcmUgdGhy ZWUgc2NlbmFyaW9zIGluDQogICB3aGljaCBwYWNrZXRzIHRoYXQgYXJlIG91dHNpZGUgb2YgdGhl IHJlY2VpdmUgd2luZG93IHNob3VsZCBzdGlsbA0KICAgaGF2ZSB0aGVpciBBQ0sgZmllbGQgcHJv Y2Vzc2VkLCBvciBlbHNlIGEgcGFja2V0IHdhciB3aWxsIHRha2UgcGxhY2UuDQogICBUaGUgYWZv cmVtZW50aW9uZWQgaXNzdWVzIGhhdmUgYWZmZWN0ZWQgYSBudW1iZXIgb2YgcG9wdWxhciBUQ1AN CiAgIGltcGxlbWVudGF0aW9ucywgdHlwaWNhbGx5IGxlYWRpbmcgdG8gY29ubmVjdGlvbiBmYWls dXJlcywgc3lzdGVtDQogICBjcmFzaGVzLCBvciBvdGhlciB1bmRlc2lyYWJsZSBiZWhhdmlvcnMu ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUNCiAgIHRocmVlIHNjZW5hcmlvcyBpbiB3aGlj aCB0aGUgYWZvcmVtZW50aW9uZWQgaXNzdWVzIG1pZ2h0IGFyaXNlLCBhbmQNCiAgIGZvcm1hbGx5 IHVwZGF0ZXMgUkZDIDc5MyBzdWNoIHRoYXQgdGhlc2UgcG90ZW50aWFsIHByb2JsZW1zIGFyZQ0K ICAgbWl0aWdhdGVkLg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8 aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFp bGluZyBsaXN0DQp0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCg== --_000_915de06f7beb41c78b1a0b324ab14287hioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkRFLUFUIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgdGhpbmsgUFMgaXMg dGhlIHByb3BlciB3YXkg4oCTIHRoZXJlIGlzIG5vIGV4cGVyaW1lbnRpbmcgd2l0aCBhIGJ1Z2d5 IHNwZWMsIGFuZCBGZXJuYW5kbyBwb2ludGVkIG91dCwgdGhhdCBtb3N0IHN0YWNrcyBoYWQgZml4 ZWQgdGhhdCBwYXJ0aWN1bGFyDQogYnVnIGluIDc5MyBmb3IgcXVpdGUgc29tZSB3aGlsZSwgcmln aHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJpY2hhcmQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5Zb3NoaWZ1bWkgTmlzaGlkYTxicj4NCjxiPlNlbnQ6PC9iPiBEb25uZXJzdGFn LCAyNi4gTcOkcnogMjAxNSAxODoyMzxicj4NCjxiPlRvOjwvYj4gRmVybmFuZG8gR29udDxicj4N CjxiPkNjOjwvYj4gdGNwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1d IFRDUCBTRVEgdmFsaWRhdGlvbiAoRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWdvbnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDIudHh0KTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBjaGVj ayBwZW9wbGUgd2hvIGFyZSB3aWxsaW5nIHRvIHN1cHBvcnQgaXQgYWxzbyBhZ3JlZSB0aGF0IHRo aXMgZHJhZnQgaXMgcHVibGlzaGVkIGFzIGEgUFMgYW5kIGl0IHVwZGF0ZXMgNzkzLCBvciBwcmVm ZXIgb3RoZXIgd2F5cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WW9zaGk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciAy NiwgMjAxNSBhdCAxMjowMyBQTSwgRmVybmFuZG8gR29udCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZn b250QHNpNm5ldHdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZnb250QHNpNm5ldHdvcmtzLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9s a3MsPGJyPg0KPGJyPg0KVGhhbmtzIHRvIHNvbWUgZm9sa3MnIHB1c2ggb3ZlciB0aW1lLCBhbmQg dGhlIGZhY3QgdGhhdCBib3RoIGNvLWF1dGhvcnM8YnI+DQpoYXBwZW5lZCB0byBmaW5kIHRoZW1z ZWx2ZXMgYXQgSUVURiA5Miwgd2UndmUgcmVwb3N0ZWQgb3VyIGxhdGVzdHM8YnI+DQp2ZXJzaW9u IG9mIHRoaXMgSS1EIChzaW5jZSB0aGUgcHJldmlvdXMgb25lIGhhZCBleHBpcmVkKSwgaW4gdGhl IGhvcGVzPGJyPg0Kb2YgbWFraW5nIHByb2dyZXNzLjxicj4NCjxicj4NCkFueSBjb21tZW50cyBv biB0aGlzIHJldiB3aWxsIGJlIGFwcHJlY2lhdGVkLiBBZGRpdGlvbmFsbHksIEknbGw8YnI+DQpy ZXBvc3QvZndkIEthcmVuJ3MgbGF0ZXN0IGNvbW1lbnRzIG9uIHRoaXMgSS1ELCB3aGljaCB3aWxs IGJlIHRoZSBiYXNpczxicj4NCmZvciB0aGUgY2hhbmdlcyBpbiB0aGUgbmV4dCByZXYuPGJyPg0K PGJyPg0KVGhhbmtzITxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpGZXJuYW5kbzxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0t LS0tPGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxicj4NCmRyYWZ0 LWdvbnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDIudHh0PGJyPg0KRGF0ZTogVGh1LCAyNiBN YXIgMjAxNSAxMTo1NTo0NiAtMDcwMDxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpUbzog RmVybmFuZG8gR29udCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbSI+ ZmdvbnRAc2k2bmV0d29ya3MuY29tPC9hPiZndDssIERhdmlkIEJvcm1hbjxicj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86ZGF2aWQuYm9ybWFuQHF1YW50dW0uY29tIj5kYXZpZC5ib3JtYW5AcXVhbnR1 bS5jb208L2E+Jmd0OywgRmVybmFuZG8gR29udCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZnb250QHNp Nm5ldHdvcmtzLmNvbSI+ZmdvbnRAc2k2bmV0d29ya3MuY29tPC9hPiZndDssIERhdmlkPGJyPg0K Qm9ybWFuICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQuYm9ybWFuQHF1YW50dW0uY29tIj5kYXZp ZC5ib3JtYW5AcXVhbnR1bS5jb208L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1nb250LXRjcG0tdGNwLXNlcS12YWxpZGF0aW9uLTAyLnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRmVybmFuZG8gR29udCBhbmQgcG9z dGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEt dmFsaWRhdGlvbjxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAyPGJy Pg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiB0aGUgVmFsaWRh dGlvbiBvZiBUQ1AgU2VxdWVuY2UgTnVtYmVyczxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIw MTUtMDMtMjY8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElu ZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgMTY8YnI+DQpVUkw6PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEtdmFsaWRhdGlvbi0wMi50eHQi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1nb250LXRjcG0tdGNwLXNlcS12YWxpZGF0aW9uLTAyLnR4dDwvYT48YnI+DQpTdGF0dXM6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ29udC10 Y3BtLXRjcC1zZXEtdmFsaWRhdGlvbi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1nb250LXRjcG0tdGNwLXNlcS12YWxpZGF0aW9uLzwvYT48 YnI+DQpIdG1saXplZDo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1nb250LXRjcG0tdGNwLXNlcS12YWxpZGF0aW9uLTAyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEtdmFsaWRhdGlv bi0wMjwvYT48YnI+DQpEaWZmOjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWdvbnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDIiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1nb250LXRjcG0t dGNwLXNlcS12YWxpZGF0aW9uLTAyPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNw OyAmbmJzcDtXaGVuIFRDUCByZWNlaXZlcyBwYWNrZXRzIHRoYXQgbGllIG91dHNpZGUgb2YgdGhl IHJlY2VpdmUgd2luZG93LCB0aGU8YnI+DQombmJzcDsgJm5ic3A7Y29ycmVzcG9uZGluZyBwYWNr ZXRzIGFyZSBkcm9wcGVkIGFuZCBlaXRoZXIgYW4gQUNLLCBSU1Qgb3Igbm88YnI+DQombmJzcDsg Jm5ic3A7cmVzcG9uc2UgaXMgZ2VuZXJhdGVkIGR1ZSB0byB0aGUgb3V0LW9mLXdpbmRvdyBwYWNr ZXQsIHdpdGggbm88YnI+DQombmJzcDsgJm5ic3A7ZnVydGhlciBwcm9jZXNzaW5nIG9mIHRoZSBw YWNrZXQuJm5ic3A7IE1vc3Qgb2YgdGhlIHRpbWUsIHRoaXMgd29ya3MganVzdDxicj4NCiZuYnNw OyAmbmJzcDtmaW5lIGFuZCBUQ1AgcmVtYWlucyBzdGFibGUsIGVzcGVjaWFsbHkgd2hlbiBhIFRD UCBjb25uZWN0aW9uIGhhczxicj4NCiZuYnNwOyAmbmJzcDt1bmlkaXJlY3Rpb25hbCBkYXRhIGZs b3cuJm5ic3A7IEhvd2V2ZXIsIHRoZXJlIGFyZSB0aHJlZSBzY2VuYXJpb3MgaW48YnI+DQombmJz cDsgJm5ic3A7d2hpY2ggcGFja2V0cyB0aGF0IGFyZSBvdXRzaWRlIG9mIHRoZSByZWNlaXZlIHdp bmRvdyBzaG91bGQgc3RpbGw8YnI+DQombmJzcDsgJm5ic3A7aGF2ZSB0aGVpciBBQ0sgZmllbGQg cHJvY2Vzc2VkLCBvciBlbHNlIGEgcGFja2V0IHdhciB3aWxsIHRha2UgcGxhY2UuPGJyPg0KJm5i c3A7ICZuYnNwO1RoZSBhZm9yZW1lbnRpb25lZCBpc3N1ZXMgaGF2ZSBhZmZlY3RlZCBhIG51bWJl ciBvZiBwb3B1bGFyIFRDUDxicj4NCiZuYnNwOyAmbmJzcDtpbXBsZW1lbnRhdGlvbnMsIHR5cGlj YWxseSBsZWFkaW5nIHRvIGNvbm5lY3Rpb24gZmFpbHVyZXMsIHN5c3RlbTxicj4NCiZuYnNwOyAm bmJzcDtjcmFzaGVzLCBvciBvdGhlciB1bmRlc2lyYWJsZSBiZWhhdmlvcnMuJm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHRoZTxicj4NCiZuYnNwOyAmbmJzcDt0aHJlZSBzY2VuYXJpb3Mg aW4gd2hpY2ggdGhlIGFmb3JlbWVudGlvbmVkIGlzc3VlcyBtaWdodCBhcmlzZSwgYW5kPGJyPg0K Jm5ic3A7ICZuYnNwO2Zvcm1hbGx5IHVwZGF0ZXMgUkZDIDc5MyBzdWNoIHRoYXQgdGhlc2UgcG90 ZW50aWFsIHByb2JsZW1zIGFyZTxicj4NCiZuYnNwOyAmbmJzcDttaXRpZ2F0ZWQuPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwv YT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCnRjcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmci PnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_915de06f7beb41c78b1a0b324ab14287hioexcmbx05prdhqnetappc_-- From nobody Fri Mar 27 10:54:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF18B1A8839 for ; Fri, 27 Mar 2015 10:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOnvRBid3xj7 for ; Fri, 27 Mar 2015 10:54:50 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8E31A88F1 for ; Fri, 27 Mar 2015 10:54:48 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 476AC2780E3 for ; Sat, 28 Mar 2015 02:54:46 +0900 (JST) Received: by wiaa2 with SMTP id a2so41403554wia.0 for ; Fri, 27 Mar 2015 10:54:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.80.37 with SMTP id o5mr2624wix.65.1427478883884; Fri, 27 Mar 2015 10:54:43 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Fri, 27 Mar 2015 10:54:43 -0700 (PDT) In-Reply-To: <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> Date: Fri, 27 Mar 2015 10:54:43 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=f46d04428644cc7174051248d3f0 Archived-At: Cc: Fernando Gont , "tcpm@ietf.org" Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:54:52 -0000 --f46d04428644cc7174051248d3f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Richard, On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard wrote: > I would think PS is the proper way =E2=80=93 there is no experimenting w= ith a > buggy spec, and Fernando pointed out, that most stacks had fixed that > particular bug in 793 for quite some while, right? > Yes. I believe no one would argue the bug in 793 pointed out in the draft. Also, I believe the solution presented in the draft is "make sense". What I am wondering is this make sense solution can be the "once for all" solution and we can happily update 793. I guess some implementations have been using a bit different approach than this, which gives me some concerns to update 793. It will be very useful info if some implementations use this approach or have a plan to use this approach. Thanks, -- Yoshi > > *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Yoshifumi > Nishida > *Sent:* Donnerstag, 26. M=C3=A4rz 2015 18:23 > *To:* Fernando Gont > *Cc:* tcpm@ietf.org > *Subject:* Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification > for draft-gont-tcpm-tcp-seq-validation-02.txt) > > > > Hi, > > I would like to check people who are willing to support it also agree tha= t > this draft is published as a PS and it updates 793, or prefer other ways. > > -- > > Yoshi > > > > On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont > wrote: > > Folks, > > Thanks to some folks' push over time, and the fact that both co-authors > happened to find themselves at IETF 92, we've reposted our latests > version of this I-D (since the previous one had expired), in the hopes > of making progress. > > Any comments on this rev will be appreciated. Additionally, I'll > repost/fwd Karen's latest comments on this I-D, which will be the basis > for the changes in the next rev. > > Thanks! > > Best regards, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-tcpm-tcp-seq-validation-02.txt > Date: Thu, 26 Mar 2015 11:55:46 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , David Borman > , Fernando Gont , David > Borman > > > A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-tcpm-tcp-seq-validation > Revision: 02 > Title: On the Validation of TCP Sequence Numbers > Document date: 2015-03-26 > Group: Individual Submission > Pages: 16 > URL: > > http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-02= .txt > Status: > https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/ > Htmlized: > http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-tcpm-tcp-seq-validation-02 > > Abstract: > When TCP receives packets that lie outside of the receive window, the > corresponding packets are dropped and either an ACK, RST or no > response is generated due to the out-of-window packet, with no > further processing of the packet. Most of the time, this works just > fine and TCP remains stable, especially when a TCP connection has > unidirectional data flow. However, there are three scenarios in > which packets that are outside of the receive window should still > have their ACK field processed, or else a packet war will take place. > The aforementioned issues have affected a number of popular TCP > implementations, typically leading to connection failures, system > crashes, or other undesirable behaviors. This document describes the > three scenarios in which the aforementioned issues might arise, and > formally updates RFC 793 such that these potential problems are > mitigated. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --f46d04428644cc7174051248d3f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard <rs@n= etapp.com> wrote:

I would th= ink PS is the proper way =E2=80=93 there is no experimenting with a buggy s= pec, and Fernando pointed out, that most stacks had fixed that particular bug in 793 for quite some while, right?


Yes.=C2=A0 I believe no one would argue the bug in 793= pointed out in the draft. Also, I believe the solution presented in the dr= aft is "make sense".
What I am wondering is this make s= ense solution can be the "once for all" solution and we can happi= ly update 793.=C2=A0
I guess some implementations have been using= a bit different approach than this, which gives me some concerns to update= 793.
It will be very useful info if some implementations use thi= s approach or have a plan to use this approach.

Th= anks,
--
Yoshi

=C2= =A0

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: Donnerstag, 26. M=C3=A4rz 2015 18:23
To: Fernando Gont
Cc: tcpm@ietf.org=
Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notificatio= n for draft-gont-tcpm-tcp-seq-validation-02.txt)

=C2=A0

Hi,

I would like to check people who are willing to supp= ort it also agree that this draft is published as a PS and it updates 793, = or prefer other ways.

--

Yoshi

=C2=A0

On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont <= fgont@si6network= s.com> wrote:

Folks,

Thanks to some folks' push over time, and the fact that both co-authors=
happened to find themselves at IETF 92, we've reposted our latests
version of this I-D (since the previous one had expired), in the hopes
of making progress.

Any comments on this rev will be appreciated. Additionally, I'll
repost/fwd Karen's latest comments on this I-D, which will be the basis=
for the changes in the next rev.

Thanks!

Best regards,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-tcpm-tcp-seq-validation-02.txt
Date: Thu, 26 Mar 2015 11:55:46 -0700
From: interne= t-drafts@ietf.org
To: Fernando Gont <fgont@si6networks.com>, David Borman
<david.bor= man@quantum.com>, Fernando Gont <fgont@si6networks.com>, David
Borman <da= vid.borman@quantum.com>


A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-tcpm-tcp-seq-valid= ation
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On the Validation of TCP Sequence = Numbers
Document date:=C2=A0 2015-03-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
URL:
http://www.ietf.org/internet-drafts/draft-= gont-tcpm-tcp-seq-validation-02.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-tcpm-tc= p-seq-validation/
Htmlized:
http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-vali= dation-02
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-t= cpm-tcp-seq-validation-02

Abstract:
=C2=A0 =C2=A0When TCP receives packets that lie outside of the receive wind= ow, the
=C2=A0 =C2=A0corresponding packets are dropped and either an ACK, RST or no=
=C2=A0 =C2=A0response is generated due to the out-of-window packet, with no=
=C2=A0 =C2=A0further processing of the packet.=C2=A0 Most of the time, this= works just
=C2=A0 =C2=A0fine and TCP remains stable, especially when a TCP connection = has
=C2=A0 =C2=A0unidirectional data flow.=C2=A0 However, there are three scena= rios in
=C2=A0 =C2=A0which packets that are outside of the receive window should st= ill
=C2=A0 =C2=A0have their ACK field processed, or else a packet war will take= place.
=C2=A0 =C2=A0The aforementioned issues have affected a number of popular TC= P
=C2=A0 =C2=A0implementations, typically leading to connection failures, sys= tem
=C2=A0 =C2=A0crashes, or other undesirable behaviors.=C2=A0 This document d= escribes the
=C2=A0 =C2=A0three scenarios in which the aforementioned issues might arise= , and
=C2=A0 =C2=A0formally updates RFC 793 such that these potential problems ar= e
=C2=A0 =C2=A0mitigated.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

=C2=A0


--f46d04428644cc7174051248d3f0-- From nobody Fri Mar 27 18:59:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFE91A036E for ; Fri, 27 Mar 2015 18:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzcgH10rnlbE for ; Fri, 27 Mar 2015 18:59:48 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35EE1A02F1 for ; Fri, 27 Mar 2015 18:59:47 -0700 (PDT) Received: from local-42.weston.borman.com (local-42.weston.borman.com [192.168.1.42]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id t2S1xicO009039; Fri, 27 Mar 2015 19:59:45 -0600 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: David Borman In-Reply-To: Date: Fri, 27 Mar 2015 20:59:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 01:59:51 -0000 Accepting the ACK in a packet one to the left of the window is what was = implemented years (decades?) ago. It=E2=80=99s what I put into BSD/OS, = the comment at that time was: /* * If segment is just one to the left of the = window, * check three special cases: * 1. Don't toss RST in response to 4.2-style = keepalive. * 2. If the only thing to drop is a FIN, we can = drop * it, but check the ACK or we will get into = FIN * wars if our FINs crossed (both CLOSING). * 3. If we have sent a window probe, it may or = may not * have been accepted. If window probes = crossed, * we must accept ACK on segments one to the = left * of the window, or we can get ACK wars = after * exchanging probes. (After sending a = probe, * ACK-only packets are sent with the = pre-probe * sequence number.) * In any of these cases, send ACK to = resynchronize, * but keep on processing for RST or ACK. */ So mainly, the =E2=80=9Caccept the ACK if it is one to the left of the = window=E2=80=9D was the original implementation. The only question is if there are any TCPs out there that actually do a = window probe of more than 1 byte; in that case you=E2=80=99d want to = accept an ACK if it is within the maximum window probe size to the left = of the window. But only the implementations that generate a window = probe of more than one byte would need to worry about that, in case they = had crossing probes with another TCP that also generated probes more = than one byte in length. If you have a one-byte probe crossing with a = multi-byte probe, the one-byte probe check is sufficient to break the = ACK war. So maybe a comment needs to be inserted that if an implementation can = generate a multi-byte probe, then they have to also implement accepting = ACKs in packets within the maximum window probe size that they might = generate. That guarantees that whichever side sends the larger probe, = it=E2=80=99ll accept the ACK from the smaller probe, and the ACK war = will be broken. -David Borman > On Mar 27, 2015, at 12:54 PM, Yoshifumi Nishida = wrote: >=20 > Hi Richard, >=20 > On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard = wrote: > I would think PS is the proper way =E2=80=93 there is no experimenting = with a buggy spec, and Fernando pointed out, that most stacks had fixed = that particular bug in 793 for quite some while, right? >=20 >=20 > Yes. I believe no one would argue the bug in 793 pointed out in the = draft. Also, I believe the solution presented in the draft is "make = sense". > What I am wondering is this make sense solution can be the "once for = all" solution and we can happily update 793.=20 > I guess some implementations have been using a bit different approach = than this, which gives me some concerns to update 793. > It will be very useful info if some implementations use this approach = or have a plan to use this approach. >=20 > Thanks, > -- > Yoshi >=20 > =20 >=20 > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi = Nishida > Sent: Donnerstag, 26. M=C3=A4rz 2015 18:23 > To: Fernando Gont > Cc: tcpm@ietf.org > Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification = for draft-gont-tcpm-tcp-seq-validation-02.txt) >=20 > =20 >=20 > Hi, >=20 > I would like to check people who are willing to support it also agree = that this draft is published as a PS and it updates 793, or prefer other = ways. >=20 > -- >=20 > Yoshi >=20 > =20 >=20 > On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont = wrote: >=20 > Folks, >=20 > Thanks to some folks' push over time, and the fact that both = co-authors > happened to find themselves at IETF 92, we've reposted our latests > version of this I-D (since the previous one had expired), in the hopes > of making progress. >=20 > Any comments on this rev will be appreciated. Additionally, I'll > repost/fwd Karen's latest comments on this I-D, which will be the = basis > for the changes in the next rev. >=20 > Thanks! >=20 > Best regards, > Fernando >=20 >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-tcpm-tcp-seq-validation-02.txt > Date: Thu, 26 Mar 2015 11:55:46 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , David Borman > , Fernando Gont , = David > Borman >=20 >=20 > A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. >=20 > Name: draft-gont-tcpm-tcp-seq-validation > Revision: 02 > Title: On the Validation of TCP Sequence Numbers > Document date: 2015-03-26 > Group: Individual Submission > Pages: 16 > URL: > = http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-02.= txt > Status: > https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/ > Htmlized: > http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-tcpm-tcp-seq-validation-02= >=20 > Abstract: > When TCP receives packets that lie outside of the receive window, = the > corresponding packets are dropped and either an ACK, RST or no > response is generated due to the out-of-window packet, with no > further processing of the packet. Most of the time, this works = just > fine and TCP remains stable, especially when a TCP connection has > unidirectional data flow. However, there are three scenarios in > which packets that are outside of the receive window should still > have their ACK field processed, or else a packet war will take = place. > The aforementioned issues have affected a number of popular TCP > implementations, typically leading to connection failures, system > crashes, or other undesirable behaviors. This document describes = the > three scenarios in which the aforementioned issues might arise, and > formally updates RFC 793 such that these potential problems are > mitigated. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 > =20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Mar 28 05:56:03 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0D1A8777 for ; Sat, 28 Mar 2015 05:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF2iF0bC2-eK for ; Sat, 28 Mar 2015 05:56:01 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC591A8773 for ; Sat, 28 Mar 2015 05:56:01 -0700 (PDT) Received: by igcau2 with SMTP id au2so46516812igc.1 for ; Sat, 28 Mar 2015 05:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=e+/UtLR62Ivbe3GSHxWojFziggV0APdh0+nFjjaiRBw=; b=DjQmXFMIcKd9qCuVSwhpOQiqKvwklEnrgOizUx+u+rzhhHozgbIofpy/irstq2SNeb SdfQYIgMeEroO9JC4t5kPyo+pZsg8ksRbC7WKFfRvj8BAEjjwkjdqepul343R4XtS1jM dhxDdY7bDXaKnTFQ1btiCn6M+MJ8K00CpQ/ueKWwAmoLIJqkCPAsRdEWuGX+aw91KQyj KpcWST2mPlU3Ip/vWixo+9Y1sj7RCKPbafRx7z89oJqDK0r0h9kSY1ZhfVaoDDW6LPam fNVP2WE/P5xZWCUfeCFE3QcMfxjTASUo9NyFw576sIpPWbzSRDBK6ozxe5q1RfEr4K1a 6/mQ== MIME-Version: 1.0 X-Received: by 10.50.253.11 with SMTP id zw11mr5242406igc.18.1427547361224; Sat, 28 Mar 2015 05:56:01 -0700 (PDT) Received: by 10.50.232.172 with HTTP; Sat, 28 Mar 2015 05:56:01 -0700 (PDT) Date: Sat, 28 Mar 2015 12:56:01 +0000 Message-ID: From: Loganaden Velvindron To: tcpm@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [tcpm] Updating rfc6528 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 12:56:02 -0000 Dear All, RFC6528 states that: "3. Proposed Initial Sequence Number Generation Algorithm TCP SHOULD generate its Initial Sequence Numbers with the expression: ISN = M + F(localip, localport, remoteip, remoteport, secretkey) where M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection-id. F() MUST NOT be computable from the outside, or an attacker could still guess at sequence numbers from the ISN used for some other connection. The PRF could be implemented as a cryptographic hash of the concatenation of the connection-id and some secret data; MD5 [RFC1321] would be a good choice for the hash function." However, there has been concerns about md5 as a hash function. This has prompted Implementations like OpenBSD to switch to sha512, since 2014. As there wasn't any major performance penalty, this has been the default since then. I would therefore like to update the RFC to reflect the running code that we have: "; SHA512[rfc6234] would be a good choice for the hash function". We could then remove the section: " It should be noted that while there have been concerns about the security properties of MD5 [RFC6151], the algorithm specified in this document simply aims at reducing the chances of an off-path attacker guessing the ISN of a new connection, and thus in our threat model it is not worth the effort for an attacker to try to learn the secret key. Since MD5 is faster than other "stronger" alternatives, and is used in virtually all existing implementations of this algorithm, we consider that use of MD5 in the specified algorithm is acceptable. However, implementations should consider the trade-offs involved in using functions with stronger security properties, and employ them if it is deemed appropriate. " Feedback welcomed, //Logan C-x-C-c -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From nobody Sat Mar 28 12:49:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635BA1A88F3 for ; Sat, 28 Mar 2015 12:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_17=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCo1uL8ZneH7 for ; Sat, 28 Mar 2015 12:49:53 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F86F1A88EC for ; Sat, 28 Mar 2015 12:49:53 -0700 (PDT) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t2SJnLkF021973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 28 Mar 2015 12:49:31 -0700 (PDT) Message-ID: <551705C1.3070103@isi.edu> Date: Sat, 28 Mar 2015 12:49:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Loganaden Velvindron , tcpm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t2SJnLkF021973 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] Updating rfc6528 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 19:49:54 -0000 On 3/28/2015 5:56 AM, Loganaden Velvindron wrote: > Dear All, > > RFC6528 states that: > > "3. Proposed Initial Sequence Number Generation Algorithm > > TCP SHOULD generate its Initial Sequence Numbers with the expression: > > ISN = M + F(localip, localport, remoteip, remoteport, secretkey) > > where M is the 4 microsecond timer, and F() is a pseudorandom > function (PRF) of the connection-id. F() MUST NOT be computable from > the outside, or an attacker could still guess at sequence numbers > from the ISN used for some other connection. The PRF could be > implemented as a cryptographic hash of the concatenation of the > connection-id and some secret data; MD5 [RFC1321] would be a good > choice for the hash function." > > However, there has been concerns about md5 as a hash function. First, the RFC doesn't require MD5. It doesn't even recommend using a cryptographic hash - that's stated as one possible approach. Second, I'd like to see something more than "concerns about MD5". MD5 isn't being used here as a MAC. We should avoid "knee-jerk security". There's no justification for endorsing a single approach here - diversity is is fine. Until there's a security *justification* for endorsing a single solution, IMO the current text is both sufficient and does not need to be revised. > We could then remove the section: > > " > > It should be noted that while there have been concerns about the > security properties of MD5 [RFC6151], the algorithm specified in this > document simply aims at reducing the chances of an off-path attacker > guessing the ISN of a new connection, and thus in our threat model it > is not worth the effort for an attacker to try to learn the secret > key. ... Absolutely not - it's still as valid for the case of SHA1. In neither case is this being used as a MAC, so MAC strength analysis is simply not relevant. Joe From nobody Sat Mar 28 13:05:37 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9F1A0E10 for ; Sat, 28 Mar 2015 13:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVmXqXFYkNAv for ; Sat, 28 Mar 2015 13:05:35 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D1E1A0A85 for ; Sat, 28 Mar 2015 13:05:34 -0700 (PDT) Received: by iedm5 with SMTP id m5so92606310ied.3 for ; Sat, 28 Mar 2015 13:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iBBMKGeAhGAani6SoJCVOh8o8iXySAjnVX+wY0qES2s=; b=h5dNYa48IHmkfS7G+b5rh6JjF27dx05bIExP9JrthmDb120Oqk3ZWumegbVymP467A UBUMBi6dez3GA/5seABkq5bKzJAB5ooZFBiQp+w7fsOFy+/Xd5OP813zSErPKSygwkDO Bu7/8PxU/MCtOB5r7MJsu4XR7ZsVlIurfp2zJ754OdBnnKqdUK5kz1qnEnqQMks6jN33 uSxVUM12BcQZQOeMajUEyG4yWbV4pPnNYE6NPmG28yN4u/ccZu9lrdpzFLYWoBADbwHg D5a/uWpzVkinjlq9nXw4NzbNK74woAZ1O1a5s7IXQNxoAN91dQGohLvVwiaR8os1jogn eBMg== MIME-Version: 1.0 X-Received: by 10.42.89.72 with SMTP id f8mr52555440icm.24.1427573134409; Sat, 28 Mar 2015 13:05:34 -0700 (PDT) Received: by 10.50.232.172 with HTTP; Sat, 28 Mar 2015 13:05:34 -0700 (PDT) In-Reply-To: <551705C1.3070103@isi.edu> References: <551705C1.3070103@isi.edu> Date: Sat, 28 Mar 2015 20:05:34 +0000 Message-ID: From: Loganaden Velvindron To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] Updating rfc6528 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 20:05:36 -0000 On Sat, Mar 28, 2015 at 7:49 PM, Joe Touch wrote: > > > On 3/28/2015 5:56 AM, Loganaden Velvindron wrote: >> Dear All, >> >> RFC6528 states that: >> >> "3. Proposed Initial Sequence Number Generation Algorithm >> >> TCP SHOULD generate its Initial Sequence Numbers with the expression: >> >> ISN = M + F(localip, localport, remoteip, remoteport, secretkey) >> >> where M is the 4 microsecond timer, and F() is a pseudorandom >> function (PRF) of the connection-id. F() MUST NOT be computable from >> the outside, or an attacker could still guess at sequence numbers >> from the ISN used for some other connection. The PRF could be >> implemented as a cryptographic hash of the concatenation of the >> connection-id and some secret data; MD5 [RFC1321] would be a good >> choice for the hash function." >> >> However, there has been concerns about md5 as a hash function. > > First, the RFC doesn't require MD5. It doesn't even recommend using a > cryptographic hash - that's stated as one possible approach. > > Second, I'd like to see something more than "concerns about MD5". > > MD5 isn't being used here as a MAC. > > We should avoid "knee-jerk security". There's no justification for > endorsing a single approach here - diversity is is fine. > Sure, How about suggesting MD5 and also SHA512. Both of them have been used in production implementations ? I think that it's good that the RFC reflects the different choices that have been used in different implementations. > Until there's a security *justification* for endorsing a single > solution, IMO the current text is both sufficient and does not need to > be revised. > >> We could then remove the section: >> >> " >> >> It should be noted that while there have been concerns about the >> security properties of MD5 [RFC6151], the algorithm specified in this >> document simply aims at reducing the chances of an off-path attacker >> guessing the ISN of a new connection, and thus in our threat model it >> is not worth the effort for an attacker to try to learn the secret >> key. ... > > Absolutely not - it's still as valid for the case of SHA1. In neither > case is this being used as a MAC, so MAC strength analysis is simply not > relevant. > > Joe -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From nobody Sat Mar 28 13:30:09 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A825E1A1E0F for ; Sat, 28 Mar 2015 13:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_X4xpbJBmuT for ; Sat, 28 Mar 2015 13:30:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF101A1DE1 for ; Sat, 28 Mar 2015 13:30:06 -0700 (PDT) Received: from [10.145.154.225] (mobile-166-171-121-250.mycingular.net [166.171.121.250]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t2SKTQCk004735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Mar 2015 13:29:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Sat, 28 Mar 2015 13:27:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6072A10F-EA5A-4AED-9A31-E2E97F92FC67@isi.edu> References: <551705C1.3070103@isi.edu> To: Loganaden Velvindron X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Updating rfc6528 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 20:30:07 -0000 > On Mar 28, 2015, at 1:05 PM, Loganaden Velvindron wr= ote: >=20 >> On Sat, Mar 28, 2015 at 7:49 PM, Joe Touch wrote: >>=20 >>=20 >>> On 3/28/2015 5:56 AM, Loganaden Velvindron wrote: >>> Dear All, >>>=20 >>> RFC6528 states that: >>>=20 >>> "3. Proposed Initial Sequence Number Generation Algorithm >>>=20 >>> TCP SHOULD generate its Initial Sequence Numbers with the expression: >>>=20 >>> ISN =3D M + F(localip, localport, remoteip, remoteport, secretkey) >>>=20 >>> where M is the 4 microsecond timer, and F() is a pseudorandom >>> function (PRF) of the connection-id. F() MUST NOT be computable from >>> the outside, or an attacker could still guess at sequence numbers >>> from the ISN used for some other connection. The PRF could be >>> implemented as a cryptographic hash of the concatenation of the >>> connection-id and some secret data; MD5 [RFC1321] would be a good >>> choice for the hash function." >>>=20 >>> However, there has been concerns about md5 as a hash function. >>=20 >> First, the RFC doesn't require MD5. It doesn't even recommend using a >> cryptographic hash - that's stated as one possible approach. >>=20 >> Second, I'd like to see something more than "concerns about MD5". >>=20 >> MD5 isn't being used here as a MAC. >>=20 >> We should avoid "knee-jerk security". There's no justification for >> endorsing a single approach here - diversity is is fine. >=20 > Sure, How about suggesting MD5 and also SHA512. Both of them have been > used in production implementations ? There is no need for an update at all.=20 > I think that it's good that the RFC reflects the different choices > that have been used in different implementations. The RFC allows choice. Choices have been made. The choice is not important. T= he more examples you give the more it seems otherwise.=20 >> Until there's a security *justification* for endorsing a single >> solution, IMO the current text is both sufficient and does not need to >> be revised. >>=20 >>> We could then remove the section: >>>=20 >>> " >>>=20 >>> It should be noted that while there have been concerns about the >>> security properties of MD5 [RFC6151], the algorithm specified in this >>> document simply aims at reducing the chances of an off-path attacker >>> guessing the ISN of a new connection, and thus in our threat model it >>> is not worth the effort for an attacker to try to learn the secret >>> key. ... >>=20 >> Absolutely not - it's still as valid for the case of SHA1. In neither >> case is this being used as a MAC, so MAC strength analysis is simply not >> relevant. >>=20 >> Joe >=20 >=20 >=20 > --=20 > This message is strictly personal and the opinions expressed do not > represent those of my employers, either past or present. From nobody Sun Mar 29 02:00:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D811A0217 for ; Sun, 29 Mar 2015 02:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-7OmC_NNQrn for ; Sun, 29 Mar 2015 02:00:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4A31A01EA for ; Sun, 29 Mar 2015 02:00:41 -0700 (PDT) Received: from [88.128.80.186] (helo=[10.54.130.118]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Yc957-0000RQ-A2; Sun, 29 Mar 2015 11:00:33 +0200 Message-ID: <5517BF2A.4010205@si6networks.com> Date: Sun, 29 Mar 2015 04:00:26 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yoshifumi Nishida , "Scheffenegger, Richard" References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 09:00:44 -0000 On 03/27/2015 12:54 PM, Yoshifumi Nishida wrote: > Hi Richard, > > On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard > wrote: > > I would think PS is the proper way – there is no experimenting with > a buggy spec, and Fernando pointed out, that most stacks had fixed > that particular bug in 793 for quite some while, right? > > > Yes. I believe no one would argue the bug in 793 pointed out in the > draft. With that in mind, I would propose that we take on this item as a wg item (i.e., have the wg polled about it), and then converge on a fix (or possible fixes). -- it's an I-D.. we don't need to agree on all minor details at this stage. The worst possible outcome is doing nothing about this item. So some fix is better than no fix at all. And since we're heading towards revising RFC793, it's even more important that we get this done... It would be a shame to produce a revision of RC793 that does not address this well-known bug. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 30 10:33:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9D51A9041 for ; Mon, 30 Mar 2015 10:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ7A-1FVPVWh for ; Mon, 30 Mar 2015 10:33:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CCF1A1EF2 for ; Mon, 30 Mar 2015 10:33:52 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t2UHXKRO009508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2015 10:33:21 -0700 (PDT) Message-ID: <551988E1.20907@isi.edu> Date: Mon, 30 Mar 2015 10:33:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Wesley Eddy , "Scheffenegger, Richard" , David Borman , "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <1FDC0AFD-133B-49FB-840A-42CDD02F9850@quantum.com> <551348D9.4090809@isi.edu> <904e4e58fac142e0833ea226fa820934@hioexcmbx05-prd.hq.netapp.com> <55134F70.4080302@mti-systems.com> In-Reply-To: <55134F70.4080302@mti-systems.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 17:33:53 -0000 On 3/25/2015 5:14 PM, Wesley Eddy wrote: > On 3/25/2015 8:06 PM, Scheffenegger, Richard wrote: >> Joe, >> >> I was wondering about this as well; Wes made the comment to add parts of 7323 - but then again, TS and PAWS really are optional features. IMHO keeping such items outside the document should help limiting the scope (and effort to track down all the necessary changes). >> > > > I may have mis-spoke, but the intention was to *point* to 7323, > as highly recommended for performing well in modern networks, but > not to suck its content in. That's useful. This goes back also to the discussion of what to cite when we're talking about TCP. If we mean the core protocol, 793 and its direct successors ought to be sufficient. Joe From nobody Tue Mar 31 08:49:28 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9491ACDCB for ; Tue, 31 Mar 2015 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaE4CjRDRzAX for ; Tue, 31 Mar 2015 08:49:25 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A60C1ACD36 for ; Tue, 31 Mar 2015 08:49:25 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id D0AA7BE634706; Tue, 31 Mar 2015 15:49:20 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2VFn7YG020313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 17:49:21 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 17:49:09 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: IETF 82 minutes - draft Thread-Index: AdBryjlZHtlu8+6hQhiK4h2bE/xHEQ== Date: Tue, 31 Mar 2015 15:49:09 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C7BF61@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] IETF 82 minutes - draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 15:49:27 -0000 Hi all, Many thanks to Gorry and Michael W. for note-taking in Dallas! A merged draft of the TCPM minutes can be found at: http://www.ietf.org/pro= ceedings/92/minutes/minutes-92-tcpm Please let the chairs know any inconsistencies or suggestions for improveme= nt. Thanks Michael From nobody Tue Mar 31 22:40:27 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD7B1A88A6 for ; Tue, 31 Mar 2015 22:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG6CfliuWW-C for ; Tue, 31 Mar 2015 22:40:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5761A889F for ; Tue, 31 Mar 2015 22:40:23 -0700 (PDT) Received: from [109.144.250.84] (helo=[10.232.155.152]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YdBNy-0007Ll-TC; Wed, 01 Apr 2015 07:40:19 +0200 Message-ID: <551B84A6.1010203@si6networks.com> Date: Wed, 01 Apr 2015 07:39:50 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C6BC3D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] WG acceptance of draft-eddy-rfc793bis-05 - please reply! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:40:26 -0000 On 03/25/2015 11:31 PM, Scharf, Michael (Michael) wrote: > Hi all, > > During the Dallas meeting in Dallas, there has been strong and > unanimous support for adopting draft-eddy-rfc793bis-05 as new TCPM > working group document. > > This email therefore starts a WG adoption call of > draft-eddy-rfc793bis-05, which will run on the mailing list until > April 8. I support adoption of this document -- and applaud Wes for the effort. P.S.: I'm willing to review the document. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 31 22:46:34 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335E51A88C9 for ; Tue, 31 Mar 2015 22:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0idRP9qX65LU for ; Tue, 31 Mar 2015 22:46:30 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7CD1A88C4 for ; Tue, 31 Mar 2015 22:46:30 -0700 (PDT) Received: from [109.144.250.84] (helo=[10.232.155.152]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YdBTs-0007Md-1W; Wed, 01 Apr 2015 07:46:24 +0200 Message-ID: <551B8501.1040508@si6networks.com> Date: Wed, 01 Apr 2015 07:41:21 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tcpm-chairs@tools.ietf.org" References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:46:33 -0000 Folks, Would it make sense to do a wg call for adoption of this document? Thanks! Best regards, Fernando On 03/28/2015 02:59 AM, David Borman wrote: > Accepting the ACK in a packet one to the left of the window is what was implemented years (decades?) ago. It’s what I put into BSD/OS, the comment at that time was: > /* > * If segment is just one to the left of the window, > * check three special cases: > * 1. Don't toss RST in response to 4.2-style keepalive. > * 2. If the only thing to drop is a FIN, we can drop > * it, but check the ACK or we will get into FIN > * wars if our FINs crossed (both CLOSING). > * 3. If we have sent a window probe, it may or may not > * have been accepted. If window probes crossed, > * we must accept ACK on segments one to the left > * of the window, or we can get ACK wars after > * exchanging probes. (After sending a probe, > * ACK-only packets are sent with the pre-probe > * sequence number.) > * In any of these cases, send ACK to resynchronize, > * but keep on processing for RST or ACK. > */ > So mainly, the “accept the ACK if it is one to the left of the window” was the original implementation. > > The only question is if there are any TCPs out there that actually do a window probe of more than 1 byte; in that case you’d want to accept an ACK if it is within the maximum window probe size to the left of the window. But only the implementations that generate a window probe of more than one byte would need to worry about that, in case they had crossing probes with another TCP that also generated probes more than one byte in length. If you have a one-byte probe crossing with a multi-byte probe, the one-byte probe check is sufficient to break the ACK war. > > So maybe a comment needs to be inserted that if an implementation can generate a multi-byte probe, then they have to also implement accepting ACKs in packets within the maximum window probe size that they might generate. That guarantees that whichever side sends the larger probe, it’ll accept the ACK from the smaller probe, and the ACK war will be broken. > > -David Borman > >> On Mar 27, 2015, at 12:54 PM, Yoshifumi Nishida wrote: >> >> Hi Richard, >> >> On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard wrote: >> I would think PS is the proper way – there is no experimenting with a buggy spec, and Fernando pointed out, that most stacks had fixed that particular bug in 793 for quite some while, right? >> >> >> Yes. I believe no one would argue the bug in 793 pointed out in the draft. Also, I believe the solution presented in the draft is "make sense". >> What I am wondering is this make sense solution can be the "once for all" solution and we can happily update 793. >> I guess some implementations have been using a bit different approach than this, which gives me some concerns to update 793. >> It will be very useful info if some implementations use this approach or have a plan to use this approach. >> >> Thanks, >> -- >> Yoshi >> >> >> >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi Nishida >> Sent: Donnerstag, 26. März 2015 18:23 >> To: Fernando Gont >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) >> >> >> >> Hi, >> >> I would like to check people who are willing to support it also agree that this draft is published as a PS and it updates 793, or prefer other ways. >> >> -- >> >> Yoshi >> >> >> >> On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont wrote: >> >> Folks, >> >> Thanks to some folks' push over time, and the fact that both co-authors >> happened to find themselves at IETF 92, we've reposted our latests >> version of this I-D (since the previous one had expired), in the hopes >> of making progress. >> >> Any comments on this rev will be appreciated. Additionally, I'll >> repost/fwd Karen's latest comments on this I-D, which will be the basis >> for the changes in the next rev. >> >> Thanks! >> >> Best regards, >> Fernando >> >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-gont-tcpm-tcp-seq-validation-02.txt >> Date: Thu, 26 Mar 2015 11:55:46 -0700 >> From: internet-drafts@ietf.org >> To: Fernando Gont , David Borman >> , Fernando Gont , David >> Borman >> >> >> A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt >> has been successfully submitted by Fernando Gont and posted to the >> IETF repository. >> >> Name: draft-gont-tcpm-tcp-seq-validation >> Revision: 02 >> Title: On the Validation of TCP Sequence Numbers >> Document date: 2015-03-26 >> Group: Individual Submission >> Pages: 16 >> URL: >> http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/ >> Htmlized: >> http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-gont-tcpm-tcp-seq-validation-02 >> >> Abstract: >> When TCP receives packets that lie outside of the receive window, the >> corresponding packets are dropped and either an ACK, RST or no >> response is generated due to the out-of-window packet, with no >> further processing of the packet. Most of the time, this works just >> fine and TCP remains stable, especially when a TCP connection has >> unidirectional data flow. However, there are three scenarios in >> which packets that are outside of the receive window should still >> have their ACK field processed, or else a packet war will take place. >> The aforementioned issues have affected a number of popular TCP >> implementations, typically leading to connection failures, system >> crashes, or other undesirable behaviors. This document describes the >> three scenarios in which the aforementioned issues might arise, and >> formally updates RFC 793 such that these potential problems are >> mitigated. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492