From rs@netapp.com Sat Jun 1 06:57:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1654021F9A99 for ; Sat, 1 Jun 2013 06:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLgXY66OPlIh for ; Sat, 1 Jun 2013 06:57:41 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 31A8621F99A9 for ; Sat, 1 Jun 2013 06:57:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,783,1363158000"; d="scan'208";a="60371315" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 01 Jun 2013 06:57:39 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r51Dvdkn007682; Sat, 1 Jun 2013 06:57:39 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Sat, 1 Jun 2013 06:57:39 -0700 From: "Scheffenegger, Richard" To: Tim Shepard , Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: AQHOXi9RxpOgcpwlv0GGPZ5muXL+75kg4PzA Date: Sat, 1 Jun 2013 13:57:37 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> References: Your message of Fri, 31 May 2013 10:24:59 -0700. <51A8DCEB.2090401@isi.edu> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Fernando Gont , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 13:57:45 -0000 Hi Tim, I agree with your reasoning, and think that IF Tsopt was established, under= the current semantics, subsequent segments without Tsopt MUST not be accep= ted. Sending an ACK for the last in-sequence segment MAY be allowed (but a recei= ver should not keep sending such an ACK excessively - if it would, and the = reason for the non-TSopt segments is a path change where TSopt is being str= ipped, it could result in a permanent exchange of data/ack, without any for= ward progress... Although the sender would continuously shrink the cwnd, an= d limit the wasted bandwidth.) Olivier remarked, that sometimes a sender might push out the TSopt in favor= of other options (MPTCP, SACK). While I believe that even then a segment s= hould not be accepted, if it lacks TSopt, I was wondering if there is any b= enefit to be had, to allow a fully in-sequence packet to be accepted then (= shinking the acceptance window basically to one particular sequence number)= . OTOH, the point of SACK is that it being sent during reorder / loss events,= so a rule like above wouldn't be all that helpful really... Does anyone know why Linux does accept non TSopt segments at any time? In any case, the only proper way for PAWS would be to not accept non-TSopt = segments after TSopt has been negotiated. Regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Tim Shepard > Sent: Freitag, 31. Mai 2013 20:48 > To: Joe Touch > Cc: Fernando Gont; tcpm@ietf.org Extensions > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt >=20 >=20 >=20 > If a TCP connection has succesfully negotiated timestamp option on, and a > segment shows up with no timestamp option, I can think of only two reason= s > for this: >=20 > 1. The other TCP is buggy in some way. (Or maybe *this* > TCP implementation is buggy in some way and corrupted > the TCB block variable that remembers whether we've got > timestamp options on or off. In any case, there is a > bug.) >=20 > 2. The segment that arrived is from some old TCP connection, > probably to or from some previous user of a reused IP > address. >=20 > (The MSL is a pure myth. There's no way to guarantee any > upper bound for how long some packet may be delayed in > transit. 15+ years ago I did a trivially easy > demonstration that delayed several ping packets for over > an hour (over lunch), with no Internet routers involved, > on a LAN using hardware that was in widespread use at the > time. E.g. Someone trips over a cable which slightly > dislodges it, then hours or days later, someone later > notices and pushes it back in.) >=20 >=20 > So, you can either accept the packet (A) or drop the packet (B). >=20 > 1. (A) hmm... other end is buggy, *maybe* accepting the packet > would be the right thing. >=20 > 1. (B) other end is buggy, dropping the packet *might* cause a > TCP connection to get stuck that otherwise would not > have gotten stuck. (Hard to say... the other end is buggy!) >=20 >=20 > 2. (A) data corruption (if the packet is otherwise acceptable) >=20 > 2. (B) clearly the right thing to do. >=20 >=20 > With no reliable way to distinguish case 1 from case 2 at the receiver, m= y > gut is to prefer option B and live with the possible downside of the 1. > (B) situation. >=20 >=20 > I also think letting the connection get stuck in the 1. (B) situation has > an upside... it might draw attention to the bug and cause the bug to get > fixed. >=20 > ... as long as there is no ambiguity on which of the two TCP > implementations is buggy. (If we have this problem, then we have a much > bigger problem.) >=20 >=20 > -Tim Shepard > shep@alum.mit.edu > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From andre@freebsd.org Sat Jun 1 09:52:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A0821F9E45 for ; Sat, 1 Jun 2013 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHwldqw4ERyc for ; Sat, 1 Jun 2013 09:52:20 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id E571421F9CEB for ; Sat, 1 Jun 2013 09:52:19 -0700 (PDT) Received: (qmail 75402 invoked from network); 1 Jun 2013 17:50:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Jun 2013 17:50:08 -0000 Message-ID: <51AA26B8.7080700@freebsd.org> Date: Sat, 01 Jun 2013 18:52:08 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: Your message of Fri, 31 May 2013 10:24:59 -0700. <51A8DCEB.2090401@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "tcpm@ietf.org Extensions" , Tim Shepard , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:52:25 -0000 On 01.06.2013 15:57, Scheffenegger, Richard wrote: > Hi Tim, > > I agree with your reasoning, and think that IF Tsopt was established, under the current > semantics, subsequent segments without Tsopt MUST not be accepted. The problem seems to be that timestamps are used for two separate purposes: a) better RTT measurements; b) PAWS. For a) a missing TSopt on a segment wouldn't be fatal, however which timestamp shall the receiver reflect from now on? The last one seen? That would lead to a rapid inflation in apparent RTT seen on the sender. For b) a missing TSopt is fatal since it makes it impossible to determine if this segment is actually valid or not. > Sending an ACK for the last in-sequence segment MAY be allowed (but a receiver should not keep > sending such an ACK excessively - if it would, and the reason for the non-TSopt segments is a > path change where TSopt is being stripped, it could result in a permanent exchange of data/ack, > without any forward progress... Although the sender would continuously shrink the cwnd, and limit > the wasted bandwidth.) The more useful behavior is to ignore the segment missing TSopt. Sending an ACK doesn't magically fix the bug on the other side and leads to an ACK war in the worst case. > Olivier remarked, that sometimes a sender might push out the TSopt in favor of other options > (MPTCP, SACK). While I believe that even then a segment should not be accepted, if it lacks > TSopt, I was wondering if there is any benefit to be had, to allow a fully in-sequence packet to > be accepted then (shinking the acceptance window basically to one particular sequence number). TSopt should never be pushed out by other options. Doing so would be a bug. One wouldn't expect other always present options (MPTCP for example) to be pushed out either. > OTOH, the point of SACK is that it being sent during reorder / loss events, so a rule like above > wouldn't be all that helpful really... > > Does anyone know why Linux does accept non TSopt segments at any time? FreeBSD behaves the same. I once changed syncache to require TSopt in the ACK completing the 3WHS when it was negotiated during SYN/SYN-ACK. It was reverted a short time later because someone reported a problem where some buggy device on the path responded with an ACK in parallel to the original host but missing TSopt. Since the buggy device was slightly faster a RST was sent and the connection attempt aborted. I have no idea why the buggy device responded in parallel with the real endpoint... After the acceptance test was relaxed again there was no further detailed analysis and it was never found out what kind of device caused the trouble along the path. The reverse check where TSopt must not be present when not negotiated is still in place and hasn't caused any known problems. Other errors with TSopt (not) present in established state are currently not logged. I should add in the next days. > In any case, the only proper way for PAWS would be to not accept non-TSopt segments after TSopt > has been negotiated. Agreed. -- Andre From ycheng@google.com Sat Jun 1 09:54:43 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B31A21F9B94 for ; Sat, 1 Jun 2013 09:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-UZCExIPAXt for ; Sat, 1 Jun 2013 09:54:38 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9B921F9B81 for ; Sat, 1 Jun 2013 09:54:38 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id q15so361020lbi.27 for ; Sat, 01 Jun 2013 09:54:37 -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=thzKC7fcs6IYCn26YbS8drpHUXvmLUEUs+CkNfTweic=; b=UAMhjmH3ANW57MoRxZiyWHrKvayKcoRFemZji5eUyj9W8r/pTaoO+eOPomwJGOpcZS BsPMux67X3u6e0KDxPWW0iPvE78tn616E8J9NxGvGJIsAnNSbQObHRwovNzPjg942sOh +cuBrKrzNsNY2+mZ7zztO+kulC1VcziCZcwG/U6RnQMwR4OJLaFfoMMB+N4FrhWei7+7 P0ZN1tSFboubFhryzWtr7zW02niFOkzeS690kJPZtqIHnEFTh6M0B3K1YbD54xb80t3B 1NbpGqPfG5sErwjJtuzo7XATBrX247zXLH81XjnpoiFtbKZefs0n7MvByukP4GNm8fjv G6Aw== X-Google-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:x-gm-message-state; bh=thzKC7fcs6IYCn26YbS8drpHUXvmLUEUs+CkNfTweic=; b=DhGYgnk85JXYX4CsiaymWx48PQmwL1qDHte/LimRJmPVIP/kkynv9+CYt/kAPUnwW3 ZcS3CLUw+GmrPMh1Bv+F+XMHxjKE79LcGwLTlrvLntPc4rSLVf0FaHtLPpBF79DYM9jb ZTBvR2/FAGPYPmdQ0602BdiTRXDhdhL1PEGm7lw1sjOyMLf9+9ohqtXrEp5HaFfYHuzV HtluOjv2dyH8O1cA9iAVHh00diMi85oANK8s3/TjIoO36dDskPZ0guQU7cagYAQfwIJJ YFjrq7CsGDlMXjZl4qhJFvGsUqXd6QyFD9klJKNqJB99U/Y02EftIyqXQcuicGLuON/J DGTA== X-Received: by 10.152.115.134 with SMTP id jo6mr8017321lab.9.1370105677115; Sat, 01 Jun 2013 09:54:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.80.227 with HTTP; Sat, 1 Jun 2013 09:54:17 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> References: <51A8DCEB.2090401@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Sat, 1 Jun 2013 09:54:17 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl6ISFfO6kFM/XHk3Ra/6jNNGERGRy7mT7kDuUFuBKtyHKiipkpAJ2XciHJC4/ieY+9/1uIYzaLQio4tM8zXyxmF6nQB3OLF1u+1coMgLzWjiHOjPJzVjoxskMGHNmOsnkDJuPOHtZWfWIEw2umcPjUszdjwIQcmqnvyNziwxxAgKG6o78hCECvFHxiiTbZUCi1sWCi Cc: Fernando Gont , "tcpm@ietf.org Extensions" , Tim Shepard , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:54:43 -0000 On Sat, Jun 1, 2013 at 6:57 AM, Scheffenegger, Richard wrot= e: > Hi Tim, > > I agree with your reasoning, and think that IF Tsopt was established, und= er the current semantics, subsequent segments without Tsopt MUST not be acc= epted. > > Sending an ACK for the last in-sequence segment MAY be allowed (but a rec= eiver should not keep sending such an ACK excessively - if it would, and th= e reason for the non-TSopt segments is a path change where TSopt is being s= tripped, it could result in a permanent exchange of data/ack, without any f= orward progress... Although the sender would continuously shrink the cwnd, = and limit the wasted bandwidth.) > > Olivier remarked, that sometimes a sender might push out the TSopt in fav= or of other options (MPTCP, SACK). While I believe that even then a segment= should not be accepted, if it lacks TSopt, I was wondering if there is any= benefit to be had, to allow a fully in-sequence packet to be accepted then= (shinking the acceptance window basically to one particular sequence numbe= r). > > OTOH, the point of SACK is that it being sent during reorder / loss event= s, so a rule like above wouldn't be all that helpful really... > > Does anyone know why Linux does accept non TSopt segments at any time? quoting Olivier """ Dropping segments that do not contain the TSopt is excessive. There are on the Internet middleboxes that coalesce or split segments. While doing that, they may remove options. Dropping a segment because it does not contain the TSopt which is only informative appears overkill to me. Dropping a segment that does not contain the negotiated TCP-AO option makes sens, but not for the TSopt. """ Real implementations need to handle things that purists don't like. > > > In any case, the only proper way for PAWS would be to not accept non-TSop= t segments after TSopt has been negotiated. > > Regards, > > > Richard Scheffenegger > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >> Tim Shepard >> Sent: Freitag, 31. Mai 2013 20:48 >> To: Joe Touch >> Cc: Fernando Gont; tcpm@ietf.org Extensions >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt >> >> >> >> If a TCP connection has succesfully negotiated timestamp option on, and = a >> segment shows up with no timestamp option, I can think of only two reaso= ns >> for this: >> >> 1. The other TCP is buggy in some way. (Or maybe *this* >> TCP implementation is buggy in some way and corrupted >> the TCB block variable that remembers whether we've got >> timestamp options on or off. In any case, there is a >> bug.) >> >> 2. The segment that arrived is from some old TCP connection, >> probably to or from some previous user of a reused IP >> address. >> >> (The MSL is a pure myth. There's no way to guarantee any >> upper bound for how long some packet may be delayed in >> transit. 15+ years ago I did a trivially easy >> demonstration that delayed several ping packets for over >> an hour (over lunch), with no Internet routers involved, >> on a LAN using hardware that was in widespread use at the >> time. E.g. Someone trips over a cable which slightly >> dislodges it, then hours or days later, someone later >> notices and pushes it back in.) >> >> >> So, you can either accept the packet (A) or drop the packet (B). >> >> 1. (A) hmm... other end is buggy, *maybe* accepting the packet >> would be the right thing. >> >> 1. (B) other end is buggy, dropping the packet *might* cause a >> TCP connection to get stuck that otherwise would not >> have gotten stuck. (Hard to say... the other end is buggy!= ) >> >> >> 2. (A) data corruption (if the packet is otherwise acceptable) >> >> 2. (B) clearly the right thing to do. >> >> >> With no reliable way to distinguish case 1 from case 2 at the receiver, = my >> gut is to prefer option B and live with the possible downside of the 1= . >> (B) situation. >> >> >> I also think letting the connection get stuck in the 1. (B) situation ha= s >> an upside... it might draw attention to the bug and cause the bug to get >> fixed. >> >> ... as long as there is no ambiguity on which of the two TCP >> implementations is buggy. (If we have this problem, then we have a much >> bigger problem.) >> >> >> -Tim Shepard >> shep@alum.mit.edu >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From jakob.heitz@ericsson.com Sat Jun 1 10:38:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D152121F9D39 for ; Sat, 1 Jun 2013 10:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCelAcob5shK for ; Sat, 1 Jun 2013 10:37:51 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 732C321F9D51 for ; Sat, 1 Jun 2013 10:37:51 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-d4-51aa316e549b Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9B.A3.17537.E613AA15; Sat, 1 Jun 2013 19:37:50 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Sat, 1 Jun 2013 13:37:50 -0400 From: Jakob Heitz To: Andre Oppermann Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: AQHOXi9R07IGxOen60eVrUN5k0w47JkhJqGAgAAwwwD//8m2Qw== Date: Sat, 1 Jun 2013 17:37:50 +0000 Message-ID: <67A4B8BE-96C7-4547-80B6-40CBB4B1DEA0@ericsson.com> References: Your message of Fri, 31 May 2013 10:24:59 -0700. <51A8DCEB.2090401@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com>, <51AA26B8.7080700@freebsd.org> In-Reply-To: <51AA26B8.7080700@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPgm6e4apAg097rCxubKi0eLLqDZvF yn9n2C0uNn9itNh2cj6Txbo/c1kc2Dz+vv/A5DHj03wWjyVLfjJ57H6/lQXI/cLm8eFQD3sA WxSXTUpqTmZZapG+XQJXxpWXm1gKdjNVLD1wlL2B8StjFyMnh4SAiUTP9o/MELaYxIV769m6 GLk4hASOMkos3nAcylnGKLFpxmVWkCo2AR2Jb9e7wDpEBNQljvyeyQJSxCxwkFFi24Nj7CAJ YQE7iZ2nmlkgiuwl9m67xgRhO0lcmNgJNohFQEXi75QrYDW8QDXruu+wQGx7yihxZOl+sCJO AW2J69/fgN3KCHTf91NrwAYxC4hL3HoynwnibgGJJXvOQ/0gKvHy8T9WiBodiQW7P7FB2NoS yxa+ZoZYJihxcuYTlgmMorOQjJqFpGUWkpZZSFoWMLKsYuQoLU4ty003MtjECIywYxJsujsY 97y0PMQozcGiJM6rxrs4UEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjZtBnngfndsZtadkc UdL0RtHz+GTOKyfc5pvJ3bCQ/nj+fsWHNd9P7I7rmc7x5G6LxsI/hf8WlDbPLN0iuOfeKZVD 2bsaos4aCPkd3esZ6JD6xItP4T+XYunWtX4TF3sedUqW0wpSS+fpLzkldeZE4bep9TFuGc0b jI1cZjc/+fdPgqlcZp6tEktxRqKhFnNRcSIAMFE9Tn4CAAA= Cc: Joe Touch , "tcpm@ietf.org Extensions" , Tim Shepard , Fernando Gont Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 17:38:05 -0000 On Jun 1, 2013, at 9:52 AM, "Andre Oppermann" wrote: > For a) a missing TSopt on a segment wouldn't be fatal, however which > timestamp shall the receiver reflect from now on? =20 Zero > The last one seen? > That would lead to a rapid inflation in apparent RTT seen on the sender. From nishida@sfc.wide.ad.jp Sun Jun 2 07:02:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8873C21F8605 for ; Sun, 2 Jun 2013 07:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZdvmdLSDIwP for ; Sun, 2 Jun 2013 07:02:28 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 6664221F859D for ; Sun, 2 Jun 2013 07:02:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 75B1F27808B for ; Sun, 2 Jun 2013 23:02:10 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id p10so3017925lbi.17 for ; Sun, 02 Jun 2013 07:02:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oNnqmNBsOE1Gl/hIOVh3UAMczRZVAMjKkye26PgeTRk=; b=QB/JEacCQnBNkmIqpXgFOVPw1dcBknRues+tTMwUw0VzW3b95p21V2E5AG+sDmbJM5 DbCrVQ64KXBrJwKgVbO7dXe/LOYh8czUOi/m8hWR6XGw+kaqhu72wrqwH0XPieMPTT/g w7jl1ZnUl7YWFsb3kZa07fj+yoRRPlUIEc0nFNSjQS4FPizWQKUm6dkceBNzOLwDR3xX HwIZEvSdfywvnfctZjgcr5xlxszA/hmjqOz/Hvnbi2jGTRPQo77uM/s4uQfponzGNvVv mUiS51sRCxPoNk+XjGG+9NJ5FIkq0zI0z747n8OYCnr5ZeACHi0tBeimDNdApnpA0aKX s8Eg== MIME-Version: 1.0 X-Received: by 10.112.141.40 with SMTP id rl8mr9003262lbb.111.1370181727861; Sun, 02 Jun 2013 07:02:07 -0700 (PDT) Received: by 10.114.1.12 with HTTP; Sun, 2 Jun 2013 07:02:07 -0700 (PDT) Date: Sun, 2 Jun 2013 07:02:07 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 14:02:28 -0000 Hi, I start wondering the following points on PAWS. Please let me know if I miss something. 1: Do we always need PAWS check? If TCP uses enough length of MSL and it hasn't sent 2**32 data yet, I personally don't see strong reason to drop the packet without TS-opt. Also, when TCP has sent more than 2**32 data and if it has good knowledge that more than MSL time has passed since a packet with the seqno has sent, do we really need to perform PAWS check? 2: Do we always need to enable both RTTM and PAWS when TS is negotiated? I'm wondering there might be cases where sender only wants RTTM or PAWS. Since the sender's choice doesn't affect the receiver's logic, implementing a simple parameter at the sender might be enough for this. Or, does it cause serious problems? 3: Action for ACK without TS-opt I'm guessing we don't need to send an ACK for the last in-sequence segment when a packet without TS-opt is ACK. But, I think the draft is not very clear on this point. Thanks, -- Yoshifumi From jakob.heitz@ericsson.com Sun Jun 2 10:00:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1250221F919D for ; Sun, 2 Jun 2013 10:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boevb0eeIJDd for ; Sun, 2 Jun 2013 10:00:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 561E521F90EE for ; Sun, 2 Jun 2013 10:00:05 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-cb-51ab7a147094 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8A.0D.05617.41A7BA15; Sun, 2 Jun 2013 19:00:04 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 13:00:03 -0400 From: Jakob Heitz To: Yoshifumi Nishida , "tcpm@ietf.org" Thread-Topic: [tcpm] some questions related to PAWS Thread-Index: AQHOX5njigrtd12l/EaV7yw/BprbUZkiowBlgAADDss= Date: Sun, 2 Jun 2013 17:00:02 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E2332E3@eusaamb109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E2332E3eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPuK5I1epAg1VPlCw2LrnBZrHt5Hwm ByaPJUt+MnlcfH2dOYApissmJTUnsyy1SN8ugSuj//4h1oKpKhU7doo0MC6T62Lk5JAQMJGY OuUGI4QtJnHh3nq2LkYuDiGBo4wSx6ccYIVwljFKnHn0lAmkik1AR+Lb9S5mEFtEIFBi6+85 YLawgJHEr63fGCHixhL7nuxgh7CtJJ63NwHVcHCwCKhINJ5nAQnzCnhLfDi8gBXEFhIIkJh6 dyobiM0JNPLhhDVgNYxAB30/tQZsLbOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP1YI21Ti14YP UM8oS3yf84gFojdfYtvircwQewUlTs58wjKBUXQWkrGzkJTNQlIGEdeTuDF1ChuErS2xbOFr ZghbV2LGv0NQNdYSSyZuQVGzgJFjFSNHaXFqWW66keEmRmCsHZNgc9zBuOCT5SFGaQ4WJXFe Hd7FgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYJ2/8KivMq3fFcqOva4zUhqTv72f9PxS8 X2JGVXvvOy/teZut+yt7vxwOjr+y+0m02vvj4X86XoZfuHiD0+I979SNhnuCgp88sr287Nus 9nPKorsexpw/mcbec1X3ieunA2z7HNjaZIJDQnd/vdZa5HI/8PrTh29NlvJ/lLe5UtCc4aLm 41T3QYmlOCPRUIu5qDgRAItyAxGDAgAA Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 17:00:15 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E2332E3eusaamb109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone have statistics to show how many packets PAWS has dropped? -- Jakob Heitz. ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Yoshifumi = Nishida [nishida@sfc.wide.ad.jp] Sent: Sunday, 02 June 2013 7:02 AM To: tcpm@ietf.org Subject: [tcpm] some questions related to PAWS Hi, I start wondering the following points on PAWS. Please let me know if I miss something. 1: Do we always need PAWS check? If TCP uses enough length of MSL and it hasn't sent 2**32 data yet, I personally don't see strong reason to drop the packet without TS-opt. Also, when TCP has sent more than 2**32 data and if it has good knowledge that more than MSL time has passed since a packet with the seqno has sent, do we really need to perform PAWS check? 2: Do we always need to enable both RTTM and PAWS when TS is negotiated? I'm wondering there might be cases where sender only wants RTTM or PAWS= . Since the sender's choice doesn't affect the receiver's logic, implementing a simple parameter at the sender might be enough for this. Or, does it cause serious problems? 3: Action for ACK without TS-opt I'm guessing we don't need to send an ACK for the last in-sequence segment when a packet without TS-opt is ACK. But, I think the draft is not very clear on this point. Thanks, -- Yoshifumi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E2332E3eusaamb109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Does anyone have statistics to show how many packets PAWS has dropped?

 

--

Jakob Heitz.

From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of= Yoshifumi Nishida [nishida@sfc.wide.ad.jp]
Sent: Sunday, 02 June 2013 7:02 AM
To: tcpm@ietf.org
Subject: [tcpm] some questions related to PAWS

Hi,
I start wondering the following points on PAWS.
Please let me know if I miss something.

1: Do we always need PAWS check?
    If TCP uses enough length of MSL and it hasn't sent 2**3= 2 data
yet,  I personally don't see strong reason to drop the packet without<= br> TS-opt.

   Also,  when TCP has sent more than 2**32 data and if it h= as good
knowledge that more than MSL time has passed since a packet with the
seqno has sent, do we really need to perform PAWS check?

2: Do we always need to enable both RTTM and PAWS when TS is negotiated?     I'm wondering there might be cases where sender only wan= ts RTTM or PAWS.
   Since the sender's choice doesn't affect the receiver's logic,=
implementing a simple parameter at the sender might be enough for
this. Or, does it cause serious problems?

3: Action for ACK without TS-opt
    I'm guessing we don't need to send an ACK for the last i= n-sequence
segment when a packet without TS-opt is ACK. But, I think the draft is
not very clear on this point.

Thanks,
--
Yoshifumi
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E2332E3eusaamb109ericsso_-- From rs@netapp.com Sun Jun 2 14:16:42 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A019C21F901F for ; Sun, 2 Jun 2013 14:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iquaEYJnsMG6 for ; Sun, 2 Jun 2013 14:16:38 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 59FFB21F8C08 for ; Sun, 2 Jun 2013 14:16:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,790,1363158000"; d="scan'208";a="60811205" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 02 Jun 2013 14:16:37 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r52LGaw0010521; Sun, 2 Jun 2013 14:16:37 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Sun, 2 Jun 2013 14:16:36 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida , "tcpm@ietf.org" Thread-Topic: [tcpm] some questions related to PAWS Thread-Index: AQHOX5nlI6SiHSreO0iaNFSHTu3955ki6zhQ Date: Sun, 2 Jun 2013 21:16:36 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 21:16:42 -0000 Hi Yoshifumi, ad 1) - I would think that PAWS is not only about correct, cooperative impl= ementations; it is also about protecting the session from outside interfere= nce. With WS, the window could be up to 2^30 bytes in size. So, if a segmen= t without (proper) TSopt or no TSopt may be accepted, a malicious interfere= r can have a chance of up to 1 in 4 to corrupt the data stream, just knowin= g (guessing) the 4-tuple. Requiring that acceptable packets always have an = acceptable TSopt reduces this again to sane levels. (Blind in-window attack= ). However, as the timestamp clock is shared between sessions in may implem= entations, the attacker only needs to find out the TSopt of the sender, to = bypass this. There is some small text in the examples, asking for a TSoffse= t that is destination-specific (only shared among sessions towards the same= destination), to avoid this issue. But it's not mentioned very prominent e= ither. Ad 2) PAWS is receiver-only, while RTTM is sender side; A TSopt enabled sen= der has currently (1323 / 1323bis) no way of signaling the receiver, that t= he TSopt should NOT be used for PAWS (because, for example, it may sporadic= ally stop sending TSopt). The sender has to assume, that a receiver will al= ways enable PAWS (even if it doesn't) once TSopt was negotiated. Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Yoshifumi Nishida > Sent: Sonntag, 02. Juni 2013 16:02 > To: tcpm@ietf.org > Subject: [tcpm] some questions related to PAWS >=20 > Hi, > I start wondering the following points on PAWS. > Please let me know if I miss something. >=20 > 1: Do we always need PAWS check? > If TCP uses enough length of MSL and it hasn't sent 2**32 data yet, = I > personally don't see strong reason to drop the packet without TS-opt. >=20 > Also, when TCP has sent more than 2**32 data and if it has good > knowledge that more than MSL time has passed since a packet with the seqn= o > has sent, do we really need to perform PAWS check? >=20 > 2: Do we always need to enable both RTTM and PAWS when TS is negotiated? > I'm wondering there might be cases where sender only wants RTTM or > PAWS. > Since the sender's choice doesn't affect the receiver's logic, > implementing a simple parameter at the sender might be enough for this. > Or, does it cause serious problems? >=20 > 3: Action for ACK without TS-opt > I'm guessing we don't need to send an ACK for the last in-sequence > segment when a packet without TS-opt is ACK. But, I think the draft is no= t > very clear on this point. >=20 > Thanks, > -- > Yoshifumi > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From shep@xplot.org Sun Jun 2 15:21:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEC321F90EF for ; Sun, 2 Jun 2013 15:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A5fY0hSQJZX for ; Sun, 2 Jun 2013 15:21:02 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id A13E221F90EE for ; Sun, 2 Jun 2013 15:21:02 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1UjGdy-0007JR-00; Sun, 02 Jun 2013 18:20:54 -0400 From: Tim Shepard To: "Scheffenegger, Richard" In-reply-to: Your message of Sun, 02 Jun 2013 21:16:36 -0000. <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> Date: Sun, 02 Jun 2013 18:20:54 -0400 Message-Id: Sender: Tim Shepard Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 22:21:08 -0000 > Ad 2) PAWS is receiver-only, while RTTM is sender side; A TSopt > enabled sender has currently (1323 / 1323bis) no way of signaling > the receiver, that the TSopt should NOT be used for PAWS (because, > for example, it may sporadically stop sending TSopt). I don't believe sporadically stop sending TSopt is ever allowed (by either the current spec, or future spec). Also another thought... PAWS protects not only TCP connections which send more than 2^32 bytes in one TCP connection, but also protects against the case where the initial sequence number selection wraps the sequence space and multiple TCP connections use the same IP addresses and port numbers over time. You don't have to be sending a lot of data to need PAWS. To not need PAWS, you have to know there has not been a previous TCP connection using the same port numbers between the same IP address that might still have some packets stuck somewhere in the net. As for whether PAWS is doing any good... a linux machine of mine at home from which I do many things but probably mostly web browsing (using both a mozilla-based web browser and a chromium-based browser) that has been up 147 days shows this: $ netstat -s | egrep -e 'segments received|timestamp' 367985020 segments received 0 bad segments received. 1375 packets rejects in established connections because of timestamp I was a little surprised by how high that timestamp rejects number is, but not very surprised that number is non-zero. Wondering if this was an unusual quirk of my situation, I just checked on the group git/track/web server of a project and it has been up 67 days and shows this: $ netstat -s | egrep -e 'segments received|timestamp' 751477138 segments received 326 bad segments received. 49130 packets rejects in established connections because of timestamp Anyone have any idea why these numbers are as high as they are? Even my Linux laptop with an uptime of 15 days shows this: $ netstat -s | egrep -e 'segments received|timestamp' 2083891 segments received 352 bad segments received. 54 packets rejects in established connections because of timestamp I haven't audited the linux code to verify what exactly these counters are counting, but I assume the "bad segments received" is due to TCP checksum errors, and the "rejects in established connections because of timestamp" is due to PAWS. I am surprised that in the first two cases above rejects because of timestamp were significantly more common than "bad segments received". I went looking for those numbers hoping that non-zero counts there would help illustrate that needing timestamp option turned on to provide PAWS was not merely theoretical. But the counts I found are so high that now I wonder what is really going on. What counts do you see on your machines? -Tim Shepard shep@alum.mit.edu From perfgeek@mac.com Sun Jun 2 15:51:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9E121F925A for ; Sun, 2 Jun 2013 15:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsM3BvoleZan for ; Sun, 2 Jun 2013 15:51:15 -0700 (PDT) Received: from st11p05mm-asmtp001.mac.com (st11p05mm-asmtp001.mac.com [17.172.108.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3866221F9246 for ; Sun, 2 Jun 2013 15:51:14 -0700 (PDT) Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by st11p05mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MNS00HSIFH84PC0@st11p05mm-asmtp001.mac.com> for tcpm@ietf.org; Sun, 02 Jun 2013 22:51:14 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-02_07:2013-05-31, 2013-06-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1306020281 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Rick Jones In-reply-to: Date: Sun, 02 Jun 2013 15:51:06 -0700 Content-transfer-encoding: 7bit Message-id: <428E97B4-ECCE-483F-B25C-DD7388D87B90@mac.com> References: To: Tim Shepard X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 22:51:20 -0000 On Jun 2, 2013, at 3:20 PM, Tim Shepard wrote: > netstat -s | egrep -e 'segments received|timestamp' for netperf.org: $ netstat -s | egrep -e 'segments received|timestamp' timestamp request: 1 timestamp replies: 1 2304112 segments received 47 bad segments received. 2333 packets rejects in established connections because of timestamp uptime of 16 days, 5:18 rick jones From jakob.heitz@ericsson.com Sun Jun 2 17:14:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F186321F894E for ; Sun, 2 Jun 2013 17:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-jkaMVS1lvI for ; Sun, 2 Jun 2013 17:14:20 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAB521F89A6 for ; Sun, 2 Jun 2013 17:14:18 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-45-51abdfd982c4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 00.51.17537.9DFDBA15; Mon, 3 Jun 2013 02:14:18 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 20:14:17 -0400 From: Jakob Heitz To: Tim Shepard , "Scheffenegger, Richard" Thread-Topic: [tcpm] some questions related to PAWS Thread-Index: AQHOX99yigrtd12l/EaV7yw/BprbUZkjDYoxgAARSYA= Date: Mon, 3 Jun 2013 00:14:16 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E233470@eusaamb109.ericsson.se> References: Your message of Sun, 02 Jun 2013 21:16:36 -0000. <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E233470eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonSvfW/dWBBr8uCFis/HeG3eJi8ydG i20n5zM5MHv8ff+ByWPJkp9MHjM+fWELYI7isklJzcksSy3St0vgypje08BScKObsWLWkQ0s DYzPirsYOTkkBEwkWl7OYYSwxSQu3FvP1sXIxSEkcJRRYtalX4wQzjJGiTuPLjCDVLEJ6Eh8 u94FZosI+Eo82LGdCcRmFlCWWH5sOjuILSxgJPFr6zdGiBpjiX1PdrBD2FYSa682s4HYLAIq Eg3377OC2LwC3hKnT09khli2klFi4vGPYAlOAT2Jdx/+gy1gBDrv+6k1UMvEJW49mc8EcbaA xJI955khbFGJl4//sULYphK/NnyAek1Z4vucRywQvfkSG6fdYodYLChxcuYTlgmMYrOQjJ2F pGwWkjKIuJ7EjalT2CBsbYllC18zQ9i6EjP+HYKqsZaYtnQyI7KaBYwcqxg5SotTy3LTjQw2 MQLj85gEm+4Oxj0vLQ8xSnOwKInzqvEuDhQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyG5+ 8s6nvd0hu/ik046Gx9tP1+iuMdHZLrH4QV7u4qBnjxdUbop/3usxaeHFutYvGc9W3Vk/87W2 4rmKDm8Bn6miQi7fdU6t5Hy+fjVDuvln0/iKwu2dd4sXrl+7M/lzmaDqDp1p9wrdS2t2fZww 30NnZyvLp+38UW+9T/vVedh8u7ZE75NHpxJLcUaioRZzUXEiAGCaw7OdAgAA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 00:14:27 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E233470eusaamb109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe the statistic "packets rejects in established connections because of timestamp' is LINUX_MIB_PAWSESTABREJECTED. This will increment if the received segment is disordered, but !tcp_disorde= red_ack. This is apparently quite common, but not a PAWS error: would be caught in s= equence number check. Here is the code from tcp_input.c static inline int tcp_paws_check(const struct tcp_options_received *rx_opt, int paws_win) { if ((s32)(rx_opt->ts_recent - rx_opt->rcv_tsval) <=3D paws_win) return 1; if (unlikely(get_seconds() >=3D rx_opt->ts_recent_stamp + TCP_PAWS_24DAYS)= ) return 1; /* * Some OSes send SYN and SYNACK messages with tsval=3D0 tsecr=3D0, * then following tcp messages have valid values. Ignore 0 value, * or else 'negative' tsval might forbid us to accept their packets. */ if (!rx_opt->ts_recent) return 1; return 0; } ... /* Sorry, PAWS as specified is broken wrt. pure-ACKs -DaveM * * It is not fatal. If this ACK does _not_ change critical state (seqs, win= dow) * it can pass through stack. So, the following predicate verifies that * this segment is not used for anything but congestion avoidance or * fast retransmit. Moreover, we even are able to eliminate most of such * second order effects, if we apply some small "replay" window (~RTO) * to timestamp space. * * All these measures still do not guarantee that we reject wrapped ACKs * on networks with high bandwidth, when sequence space is recycled fastly, * but it guarantees that such events will be very rare and do not affect * connection seriously. This doesn't look nice, but alas, PAWS is really * buggy extension. * * [ Later note. Even worse! It is buggy for segments _with_ data. RFC * states that events when retransmit arrives after original data are rare. * It is a blatant lie. VJ forgot about fast retransmit! 8)8) It is * the biggest problem on large power networks even with minor reordering. * OK, let's give it small replay window. If peer clock is even 1hz, it is = safe * up to bandwidth of 18Gigabit/sec. 8) ] */ static int tcp_disordered_ack(const struct sock *sk, const struct sk_buff *= skb) { struct tcp_sock *tp =3D tcp_sk(sk); struct tcphdr *th =3D tcp_hdr(skb); u32 seq =3D TCP_SKB_CB(skb)->seq; u32 ack =3D TCP_SKB_CB(skb)->ack_seq; return (/* 1. Pure ACK with correct sequence number. */ (th->ack && seq =3D=3D TCP_SKB_CB(skb)->end_seq && seq =3D=3D tp->rcv_nxt= ) && /* 2. ... and duplicate ACK. */ ack =3D=3D tp->snd_una && /* 3. ... and does not update window. */ !tcp_may_update_window(tp, ack, seq, ntohs(th->window) << tp->rx_opt.snd_= wscale) && /* 4. ... and sits in replay window. */ (s32)(tp->rx_opt.ts_recent - tp->rx_opt.rcv_tsval) <=3D (inet_csk(sk)->ic= sk_rto * 1024) / HZ); } static inline int tcp_paws_discard(const struct sock *sk, const struct sk_buff *skb) { const struct tcp_sock *tp =3D tcp_sk(sk); return !tcp_paws_check(&tp->rx_opt, TCP_PAWS_WINDOW) && !tcp_disordered_ack(sk, skb); } ... static int tcp_validate_incoming(struct sock *sk, struct sk_buff *skb, struct tcphdr *th, int syn_inerr) { u8 *hash_location; struct tcp_sock *tp =3D tcp_sk(sk); /* RFC1323: H1. Apply PAWS check first. */ if (tcp_fast_parse_options(skb, th, tp, &hash_location) && tp->rx_opt.saw_tstamp && tcp_paws_discard(sk, skb)) { if (!th->rst) { NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSESTABREJECTED); tcp_send_dupack(sk, skb); goto discard; } /* Reset is accepted even if it did not pass PAWS. */ } /* Step 1: check sequence number */ if (!tcp_sequence(tp, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq)) { ... -- Jakob Heitz. ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Tim Shepar= d [shep@alum.mit.edu] Sent: Sunday, 02 June 2013 3:20 PM To: Scheffenegger, Richard Cc: tcpm@ietf.org Subject: Re: [tcpm] some questions related to PAWS > Ad 2) PAWS is receiver-only, while RTTM is sender side; A TSopt > enabled sender has currently (1323 / 1323bis) no way of signaling > the receiver, that the TSopt should NOT be used for PAWS (because, > for example, it may sporadically stop sending TSopt). I don't believe sporadically stop sending TSopt is ever allowed (by either the current spec, or future spec). Also another thought... PAWS protects not only TCP connections which send more than 2^32 bytes in one TCP connection, but also protects against the case where the initial sequence number selection wraps the sequence space and multiple TCP connections use the same IP addresses and port numbers over time. You don't have to be sending a lot of data to need PAWS. To not need PAWS, you have to know there has not been a previous TCP connection using the same port numbers between the same IP address that might still have some packets stuck somewhere in the net. As for whether PAWS is doing any good... a linux machine of mine at home from which I do many things but probably mostly web browsing (using both a mozilla-based web browser and a chromium-based browser) that has been up 147 days shows this: $ netstat -s | egrep -e 'segments received|timestamp' 367985020 segments received 0 bad segments received. 1375 packets rejects in established connections because of timestamp I was a little surprised by how high that timestamp rejects number is, but not very surprised that number is non-zero. Wondering if this was an unusual quirk of my situation, I just checked on the group git/track/web server of a project and it has been up 67 days and shows this: $ netstat -s | egrep -e 'segments received|timestamp' 751477138 segments received 326 bad segments received. 49130 packets rejects in established connections because of timestamp Anyone have any idea why these numbers are as high as they are? Even my Linux laptop with an uptime of 15 days shows this: $ netstat -s | egrep -e 'segments received|timestamp' 2083891 segments received 352 bad segments received. 54 packets rejects in established connections because of timestamp I haven't audited the linux code to verify what exactly these counters are counting, but I assume the "bad segments received" is due to TCP checksum errors, and the "rejects in established connections because of timestamp" is due to PAWS. I am surprised that in the first two cases above rejects because of timestamp were significantly more common than "bad segments received". I went looking for those numbers hoping that non-zero counts there would help illustrate that needing timestamp option turned on to provide PAWS was not merely theoretical. But the counts I found are so high that now I wonder what is really going on. What counts do you see on your machines? -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E233470eusaamb109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <32BD134F1FD9C2468A965C6C6A29D34D@ericsson.com> Content-Transfer-Encoding: quoted-printable

I believe the statistic

 "packets rejects in established connections because of timest= amp'

is LINUX_MIB_PAWSESTABREJECTED.

This will increment if the received segment is disordered, but !tcp_diso= rdered_ack.

 

This is apparently quite common, but not a PAWS error: would be caught i= n sequence number check.

 

Here is the code from tcp_input.c

 

static inline int tcp_paws_check(const struct tcp_options_received *rx_o= pt,
     int paws_win)
{
 if ((s32)(rx_opt->ts_recent - rx_opt->rcv_tsval) <=3D paws_w= in)
  return 1;
 if (unlikely(get_seconds() >=3D rx_opt->ts_recent_stamp + T= CP_PAWS_24DAYS))
  return 1;
 /*
  * Some OSes send SYN and SYNACK messages with tsval=3D0 tsecr=3D0,   * then following tcp messages have valid values. Ignore 0 value,
  * or else 'negative' tsval might forbid us to accept their packets.<= br>   */
 if (!rx_opt->ts_recent)
  return 1;
 return 0;
}

...

 

/* Sorry, PAWS as specified is broken wrt. pure-ACKs -DaveM
 *
 * It is not fatal. If this ACK does _not_ change critical state (seqs= , window)
 * it can pass through stack. So, the following predicate verifies tha= t
 * this segment is not used for anything but congestion avoidance or  * fast retransmit. Moreover, we even are able to eliminate most of su= ch
 * second order effects, if we apply some small "replay" win= dow (~RTO)
 * to timestamp space.
 *
 * All these measures still do not guarantee that we reject wrapped AC= Ks
 * on networks with high bandwidth, when sequence space is recycled fa= stly,
 * but it guarantees that such events will be very rare and do not aff= ect
 * connection seriously. This doesn't look nice, but alas, PAWS is rea= lly
 * buggy extension.
 *
 * [ Later note. Even worse! It is buggy for segments _with_ data. RFC=
 * states that events when retransmit arrives after original data are = rare.
 * It is a blatant lie. VJ forgot about fast retransmit! 8)8) It is  * the biggest problem on large power networks even with minor reorder= ing.
 * OK, let's give it small replay window. If peer clock is even 1hz, i= t is safe
 * up to bandwidth of 18Gigabit/sec. 8) ]
 */

static int tcp_disordered_ack(const struct sock *sk, const struct sk_buf= f *skb)
{
 struct tcp_sock *tp =3D tcp_sk(sk);
 struct tcphdr *th =3D tcp_hdr(skb);
 u32 seq =3D TCP_SKB_CB(skb)->seq;
 u32 ack =3D TCP_SKB_CB(skb)->ack_seq;

 return (/* 1. Pure ACK with correct sequence number. */
  (th->ack && seq =3D=3D TCP_SKB_CB(skb)->end_seq &= amp;& seq =3D=3D tp->rcv_nxt) &&

  /* 2. ... and duplicate ACK. */
  ack =3D=3D tp->snd_una &&

  /* 3. ... and does not update window. */
  !tcp_may_update_window(tp, ack, seq, ntohs(th->window) <&= lt; tp->rx_opt.snd_wscale) &&

  /* 4. ... and sits in replay window. */
  (s32)(tp->rx_opt.ts_recent - tp->rx_opt.rcv_tsval) <= =3D (inet_csk(sk)->icsk_rto * 1024) / HZ);
}

static inline int tcp_paws_discard(const struct sock *sk,
       const struct sk_buff *skb)
{
 const struct tcp_sock *tp =3D tcp_sk(sk);

 return !tcp_paws_check(&tp->rx_opt, TCP_PAWS_WINDOW) &&= amp;
        !tcp_disordered_ack(sk, skb); }

 

...

static int tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,          struct tcphdr *th, int syn= _inerr)
{
 u8 *hash_location;
 struct tcp_sock *tp =3D tcp_sk(sk);

 /* RFC1323: H1. Apply PAWS check first. */
 if (tcp_fast_parse_options(skb, th, tp, &hash_location) &&= ;
     tp->rx_opt.saw_tstamp &&
     tcp_paws_discard(sk, skb)) {
  if (!th->rst) {
   NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSESTABREJECTE= D);
   tcp_send_dupack(sk, skb);
   goto discard;
  }
  /* Reset is accepted even if it did not pass PAWS. */
 }

 /* Step 1: check sequence number */
 if (!tcp_sequence(tp, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->en= d_seq)) {
...

 

 

--

Jakob Heitz.

From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of= Tim Shepard [shep@alum.mit.edu]
Sent: Sunday, 02 June 2013 3:20 PM
To: Scheffenegger, Richard
Cc: tcpm@ietf.org
Subject: Re: [tcpm] some questions related to PAWS


> Ad 2) PAWS is receiver-only, while RTTM is sender side; A TSopt
> enabled sender has currently (1323 / 1323bis) no way of signaling
> the receiver, that the TSopt should NOT be used for PAWS (because,
> for example, it may sporadically stop sending TSopt).


I don't believe sporadically stop sending TSopt is ever allowed (by
either the current spec, or future spec).




Also another thought... PAWS protects not only TCP connections which
send more than 2^32 bytes in one TCP connection, but also protects
against the case where the initial sequence number selection wraps the
sequence space and multiple TCP connections use the same IP addresses
and port numbers over time.  You don't have to be sending a lot of
data to need PAWS.

To not need PAWS, you have to know there has not been a previous TCP
connection using the same port numbers between the same IP address
that might still have some packets stuck somewhere in the net.

As for whether PAWS is doing any good...    a linux machine = of mine at
home from which I do many things but probably mostly web browsing
(using both a mozilla-based web browser and a chromium-based browser)
that has been up 147 days shows this:

$ netstat -s | egrep -e 'segments received|timestamp'
    367985020 segments received
    0 bad segments received.
    1375 packets rejects in established connections because = of timestamp

I was a little surprised by how high that timestamp rejects number is,
but not very surprised that number is non-zero.

Wondering if this was an unusual quirk of my situation, I just checked
on the group git/track/web server of a project and it has been up 67
days and shows this:

$ netstat -s | egrep -e 'segments received|timestamp'
    751477138 segments received
    326 bad segments received.
    49130 packets rejects in established connections because= of timestamp

Anyone have any idea why these numbers are as high as they are?

Even my Linux laptop with an uptime of 15 days shows this:

$ netstat -s | egrep -e 'segments received|timestamp'
    2083891 segments received
    352 bad segments received.
    54 packets rejects in established connections because of= timestamp



I haven't audited the linux code to verify what exactly these counters
are counting, but I assume the "bad segments received" is due to = TCP
checksum errors, and the "rejects in established connections because o= f
timestamp" is due to PAWS.

I am surprised that in the first two cases above rejects because of
timestamp were significantly more common than "bad segments received&q= uot;.


I went looking for those numbers hoping that non-zero counts there
would help illustrate that needing timestamp option turned on to
provide PAWS was not merely theoretical.  But the counts I found are so high that now I wonder what is really going on.

What counts do you see on your machines?


            &nb= sp;           -Tim Shepar= d
            &nb= sp;            shep@= alum.mit.edu
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E233470eusaamb109ericsso_-- From pasi.sarolahti@iki.fi Mon Jun 3 03:19:03 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE55821F8F0C for ; Mon, 3 Jun 2013 03:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRa5bVsuu5zJ for ; Mon, 3 Jun 2013 03:18:57 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id EF2C521F909A for ; Mon, 3 Jun 2013 03:18:55 -0700 (PDT) Received: from pc123.tct.hut.fi (130.233.154.123) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163EC56039F122B; Mon, 3 Jun 2013 13:18:39 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <26227_1370095078_51A9FDE5_26227_5079_1_012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 3 Jun 2013 13:18:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: Your message of Fri, 31 May 2013 10:24:59 -0700. <51A8DCEB.2090401@isi.edu> <26227_1370095078_51A9FDE5_26227_5079_1_012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: Fernando Gont , "tcpm@ietf.org Extensions" , Tim Shepard , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:19:03 -0000 On Jun 1, 2013, at 4:57 PM, "Scheffenegger, Richard" = wrote: > I agree with your reasoning, and think that IF Tsopt was established, = under the current semantics, subsequent segments without Tsopt MUST not = be accepted. This is true for reliable operation of PAWS, but I did not find any = language in RFC 1323 that speaks about the situation when a segment is = received without timestamp. Instead, the way how R1 was written "if = there is a timestamp option and [...Ts conditions...] then treat the = arriving segment as not acceptable" easily leads to interpretation that = segment that arrives without timestamp is acceptable. So the = implementations that accept such segments are compliant with RFC 1323 in = my reading, even if it opens a window of possible failure to the PAWS = check. If we want reliable PAWS, I agree that "MUST not be accepted" is needed, = but it seems that practical deployments have opted for imperfect PAWS in = favor of being able to deal with problematic middleboxes in the network = (or whatever other reason), no matter how rare those might be. I guess = this is one of the principle vs. practice issues that implementations = need to face these days. If we include this as MUST, I think it would be = appropriate to note that many (or most?) current implementations do not = have it (i.e., we do not necessarily know about all the deployment = implications, referring to the discussion in middlebox part), and also = note the check wasn't required by RFC 1323 (but this might have been an = oversight). - Pasi From touch@isi.edu Mon Jun 3 09:48:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1A521F95DD for ; Mon, 3 Jun 2013 09:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBvgoos3l86n for ; Mon, 3 Jun 2013 09:47:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AD0F821F918F for ; Mon, 3 Jun 2013 09:47:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r53Gl96t015038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 09:47:09 -0700 (PDT) Message-ID: <51ACC889.1080807@isi.edu> Date: Mon, 03 Jun 2013 09:47:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yuchung Cheng References: <51A8DCEB.2090401@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" , Tim Shepard , Fernando Gont Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:48:01 -0000 On 6/1/2013 9:54 AM, Yuchung Cheng wrote: > On Sat, Jun 1, 2013 at 6:57 AM, Scheffenegger, Richard wrote: >> Hi Tim, >> >> I agree with your reasoning, and think that IF Tsopt was established, under the current semantics, subsequent segments without Tsopt MUST not be accepted. >> >> Sending an ACK for the last in-sequence segment MAY be allowed (but a receiver should not keep sending such an ACK excessively - if it would, and the reason for the non-TSopt segments is a path change where TSopt is being stripped, it could result in a permanent exchange of data/ack, without any forward progress... Although the sender would continuously shrink the cwnd, and limit the wasted bandwidth.) >> >> Olivier remarked, that sometimes a sender might push out the TSopt in favor of other options (MPTCP, SACK). While I believe that even then a segment should not be accepted, if it lacks TSopt, I was wondering if there is any benefit to be had, to allow a fully in-sequence packet to be accepted then (shinking the acceptance window basically to one particular sequence number). >> >> OTOH, the point of SACK is that it being sent during reorder / loss events, so a rule like above wouldn't be all that helpful really... >> >> Does anyone know why Linux does accept non TSopt segments at any time? > > quoting Olivier > """ > Dropping segments that do not contain the TSopt is excessive. There > are on the Internet middleboxes that coalesce or split segments. While > doing that, they may remove options. Dropping a segment because it > does not contain the TSopt which is only informative appears overkill > to me. Dropping a segment that does not contain the negotiated TCP-AO > option makes sens, but not for the TSopt. > """ > > Real implementations need to handle things that purists don't like. I completely agree. However, what you describe is a middlebox that allowed the TSopt in a SYN and then blocked it later. The middlebox made a decision that broke what the endpoints asked for. So whose intentions do we honor? Given this is the Internet, it seems clear to me that the endpoints are in control, and if the middlebox does something that breaks the negotiated connection semantics, then it is a real implementation that is broken. If you let the "real implementation" of the middlebox drive the solution here, you have just told all the endpoints that PAWS is no longer available. You cannot have it both ways. There are real implementations at the endpoints who care. Joe From touch@isi.edu Mon Jun 3 09:59:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A2521F9638 for ; Mon, 3 Jun 2013 09:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygHEblm2CLX4 for ; Mon, 3 Jun 2013 09:59:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 91DBC21F8F38 for ; Mon, 3 Jun 2013 09:59:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r53GwXrw017103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 09:58:33 -0700 (PDT) Message-ID: <51ACCB34.6010205@isi.edu> Date: Mon, 03 Jun 2013 09:58:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pasi Sarolahti References: Your message of Fri, 31 May 2013 10:24:59 -0700. <51A8DCEB.2090401@isi.edu> <26227_1370095078_51A9FDE5_26227_5079_1_012C3117EDDB3C4781FD802A8C27DD4F24BBF87A@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" , Tim Shepard , Fernando Gont Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:59:34 -0000 Hi, Pasi, On 6/3/2013 3:18 AM, Pasi Sarolahti wrote: > > On Jun 1, 2013, at 4:57 PM, "Scheffenegger, Richard" wrote: > >> I agree with your reasoning, and think that IF Tsopt was >> established, under the current semantics, subsequent segments >> without Tsopt MUST not be accepted. > > This is true for reliable operation of PAWS, but I did not find any > language in RFC 1323 that speaks about the situation when a segment > is received without timestamp. Instead, the way how R1 was written > "if there is a timestamp option and [...Ts conditions...] then treat > the arriving segment as not acceptable" easily leads to > interpretation that segment that arrives without timestamp is > acceptable. I disagree with your logic. On connections that successfully negotiate TSopt, a segment lacking TSopt has insufficient information to be considered "acceptable", which to me indicates that it is "not acceptable". I.e., we agree that a segment lacking TSopt has insufficient info; so do we assume that such a segment is in-window? or not? Assuming such a segment is acceptable effectively disables PAWS. > So the implementations that accept such segments are > compliant with RFC 1323 in my reading, even if it opens a window of > possible failure to the PAWS check. RFC1323 does not specifically address segments lacking TSopt in the PAWS section. IMO, you can't claim compliance, but you can claim it doesn't violate it if you want - but I don't see the point in that. > If we want reliable PAWS, I agree that "MUST not be accepted" is > needed, but it seems that practical deployments have opted for > imperfect PAWS in favor of being able to deal with problematic > middleboxes in the network (or whatever other reason), no matter how > rare those might be. I guess this is one of the principle vs. > practice issues that implementations need to face these days. If we > include this as MUST, I think it would be appropriate to note that > many (or most?) current implementations do not have it (i.e., we do > not necessarily know about all the deployment implications, referring > to the discussion in middlebox part), and also note the check wasn't > required by RFC 1323 (but this might have been an oversight). I agree that we should note that 1323 doesn't address the case of TSopt being dropped or selectively omitted after being negotiated, and that the current recommendation may cause some broken middlebox behavior to be detected. Joe From touch@isi.edu Mon Jun 3 10:37:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F288521F8B07 for ; Mon, 3 Jun 2013 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU1k95WRqq6f for ; Mon, 3 Jun 2013 10:36:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3C08021F8E37 for ; Mon, 3 Jun 2013 10:30:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r53HTp6J023238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 10:29:51 -0700 (PDT) Message-ID: <51ACD28A.4000507@isi.edu> Date: Mon, 03 Jun 2013 10:29:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yoshifumi Nishida References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:37:10 -0000 On 6/2/2013 7:02 AM, Yoshifumi Nishida wrote: > Hi, > I start wondering the following points on PAWS. > Please let me know if I miss something. > > 1: Do we always need PAWS check? > If TCP uses enough length of MSL and it hasn't sent 2**32 data > yet, I personally don't see strong reason to drop the packet without > TS-opt. > > Also, when TCP has sent more than 2**32 data and if it has good > knowledge that more than MSL time has passed since a packet with the > seqno has sent, do we really need to perform PAWS check? The trouble is that we don't have a way to say "use TSopt to measure RTT" vs. "use TSopt for PAWS". Right now, AFAICT it means "use TSopt for PAWS and to measure RTT". However, sending more than 4GB isn't as absurd or exceptional as it used to be, and lots of devices do lots of things with TCP packets that keep them around a while. It'd be nice if "MSL" was relevant here, but without TSopt, AFAICT MSL isn't involved except voluntarily at the source; if a source wants to send more than 4GB in 2 minutes (a transfer rate over 267Mbps, which is easy even on a laptop), then it can, will, and *does*. > 2: Do we always need to enable both RTTM and PAWS when TS is negotiated? > I'm wondering there might be cases where sender only wants RTTM or PAWS. > Since the sender's choice doesn't affect the receiver's logic, > implementing a simple parameter at the sender might be enough for > this. Or, does it cause serious problems? I'm not sure how to do that (see above). > 3: Action for ACK without TS-opt > I'm guessing we don't need to send an ACK for the last in-sequence > segment when a packet without TS-opt is ACK. But, I think the draft is > not very clear on this point. It should be more clear; IMO, all segments in a TSopt-negotiated session without TSopt should be silently ignored, but that's me ;-) Joe From nishida@sfc.wide.ad.jp Mon Jun 3 23:41:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB23021F96C2 for ; Mon, 3 Jun 2013 23:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+QddISzvrgb for ; Mon, 3 Jun 2013 23:41:06 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0CB21F9700 for ; Mon, 3 Jun 2013 22:35:34 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6F73F2780A0 for ; Tue, 4 Jun 2013 14:35:32 +0900 (JST) Received: by mail-lb0-f178.google.com with SMTP id w10so229413lbi.37 for ; Mon, 03 Jun 2013 22:35:29 -0700 (PDT) X-Google-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=5iU5IvuO+FwzsZknQ49nDLeehUgLiEI1UGQb20Nz9H4=; b=kJH4877lWF7C2pAFmvAxdWGErztyg7GcRBmp7c1MjHwOvcMM/Oz0M1vwFxuonyQuO+ 8rLYXsTMjrJhPlw/aZ7k98K1TsVRltS0oazjH+hij0tMr76goAe3vifTkkO/BdqCW0Na G7FCnBfPPPDERe4/plgCnUoFkVd2v3v3vOHXhHSrC20wU8BwsUi7SgLOC43gpulUDsTT +tVq9Fi3zTBw5hAzefijtdhRxKq25atgImCIjFzy4wPB0wYvkEarBtG+5+JRhAyp+l+F UW6LCASXjFJJoMhcZb+bLXJpcOIytUfhjuF4gWWrUNJ3MktzZGhIqb2fkJ31GReVs0Yr Th/Q== MIME-Version: 1.0 X-Received: by 10.112.7.4 with SMTP id f4mr12106959lba.132.1370324129876; Mon, 03 Jun 2013 22:35:29 -0700 (PDT) Received: by 10.114.1.12 with HTTP; Mon, 3 Jun 2013 22:35:29 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 3 Jun 2013 22:35:29 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=14dae93d968cfd159504de4d7201 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 06:41:16 -0000 --14dae93d968cfd159504de4d7201 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, On Sun, Jun 2, 2013 at 2:16 PM, Scheffenegger, Richard wrote: > ad 1) - I would think that PAWS is not only about correct, cooperative implementations; it is also about protecting the session from outside interference. With WS, the window could be up to 2^30 bytes in size. So, if a segment without (proper) TSopt or no TSopt may be accepted, a malicious interferer can have a chance of up to 1 in 4 to corrupt the data stream, just knowing (guessing) the 4-tuple. Requiring that acceptable packets always have an acceptable TSopt reduces this again to sane levels. (Blind in-window attack). However, as the timestamp clock is shared between sessions in may implementations, the attacker only needs to find out the TSopt of the sender, to bypass this. There is some small text in the examples, asking for a TSoffset that is destination-specific (only shared among sessions towards the same destination), to avoid this issue. But it's not mentioned very prominent either. I agree with that it can be used to protect the session from outside interference to some extents. But, I'm still wondering how it is effective. In my understanding, PAWS is checking if SEG.TSval < TS.Recent. Is it enough to protect from malicious users? > > Ad 2) PAWS is receiver-only, while RTTM is sender side; A TSopt enabled sender has currently (1323 / 1323bis) no way of signaling the receiver, that the TSopt should NOT be used for PAWS (because, for example, it may sporadically stop sending TSopt). The sender has to assume, that a receiver will always enable PAWS (even if it doesn't) once TSopt was negotiated. Sorry. As you mentioned, PAWS is receiver logic. What I meant was disabling PAWS check. Something like, "I want to have TS for RTTM, but I don't want to drop packets without TS unless the sender sends data 4GB in less than 2MSL". In this case, the node needs to measure receiving rate to check if PAWS check is required. It might be tricky, but I still think it's one possibility. one might prefer it rather than dropping packets without TS blindly. Thanks, -- Yoshifumi --14dae93d968cfd159504de4d7201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Sun, Jun 2, 2013 at 2:16 PM, Scheffe= negger, Richard <rs@netapp.com> = wrote:

> ad 1) - I would think that PAWS is not only about correc= t, cooperative implementations; it is also about protecting the session fro= m outside interference. With WS, the window could be up to 2^30 bytes in si= ze. So, if a segment without (proper) TSopt or no TSopt may be accepted, a = malicious interferer can have a chance of up to 1 in 4 to corrupt the data = stream, just knowing (guessing) the 4-tuple. Requiring that acceptable pack= ets always have an acceptable TSopt reduces this again to sane levels. (Bli= nd in-window attack). However, as the timestamp clock is shared between ses= sions in may implementations, the attacker only needs to find out the TSopt= of the sender, to bypass this. There is some small text in the examples, a= sking for a TSoffset that is destination-specific (only shared among sessio= ns towards the same destination), to avoid this issue. But it's not men= tioned very prominent either.


I agree with that it can be used to protect the session from outsid= e interference to some extents. But, I'm still wondering how it is effe= ctive.
In my understanding, PAWS is checking if SEG.TSval < TS.Recent= . Is it enough to protect from malicious users?
=A0
>
> Ad 2) PAWS is receiver-only, while RTTM is sender side;= A TSopt enabled sender has currently (1323 / 1323bis) no way of signaling = the receiver, that the TSopt should NOT be used for PAWS (because, for exam= ple, it may sporadically stop sending TSopt). The sender has to assume, tha= t a receiver will always enable PAWS (even if it doesn't) once TSopt wa= s negotiated.

Sorry. As you mentioned, PAWS is receiver logic. What I meant was disab= ling PAWS check.=A0
Something like, "I want to have TS for RTTM, b= ut I don't want to drop packets without TS unless the sender sends data= 4GB in less than 2MSL". In this case, the node needs to measure recei= ving rate to check if PAWS check is required.=A0
It might be tricky, but I still think it's one possibility. one mi= ght prefer it rather than dropping packets without TS blindly.

Thanks,
--
Yoshifumi
--14dae93d968cfd159504de4d7201-- From michael.scharf@alcatel-lucent.com Tue Jun 4 03:33:42 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B5421F9CC7 for ; Tue, 4 Jun 2013 03:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG0CckIRVM0g for ; Tue, 4 Jun 2013 03:33:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E429F21F9BF4 for ; Tue, 4 Jun 2013 02:28:55 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r549Ss1R011770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Jun 2013 04:28:55 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r549SrRZ032185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 05:28:54 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Jun 2013 05:28:53 -0400 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.15]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 4 Jun 2013 11:28:41 +0200 From: "Scharf, Michael (Michael)" To: Michael Welzl , "tcpm (tcpm@ietf.org)" Thread-Topic: [tcpm] Can't we use newcwv for IW too? Thread-Index: AQHOW3nummxKEx+yVkaL5lYdFt7yM5klTMGw Date: Tue, 4 Jun 2013 09:28:40 +0000 Message-ID: <655C07320163294895BBADA28372AF5D029467@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> In-Reply-To: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:33:42 -0000 (catching up...) > There really isn't much difference between newcwv restarting=20 > after an idle period and a new connection using an IW based=20 > on a previous connection's newcwv. > We may have a new port number (although we could also be=20 > extra restrictive here, if we really must), and we had the=20 > FIN + SYN handshakes. These things may lead to different=20 > treatment in middle-boxes and they may give us a new path,=20 > using ECMP, so yes, it's not exactly the same as restarting=20 > from idle, but then again, consider: > - it takes only 1 RTT to notice the mistake and react to it;=20 > this is quite close to the Jump Start idea (=20 > http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf ),=20 > but backed by prior knowledge about the path whenever stuff=20 > like ECMP didn't kick in > - we do this only for one connection following a previously=20 > terminated one (sure, if N just terminated, we could do it N=20 > times, within a certain time frame...) Since you refer to Jump Start: I am not sure if Jump Start is really simila= r to these current discussions. As far as I recall, Jump Start had three interesting components: 1. Playing out the data that is available from the app in the first RTT (mo= re precisely: the minimum of the available data and RWND) 2. Use of rate pacing in that first RTT 3. Use of a non-5681/non-6675 cwnd calculation if packet loss occurs during= that inital burst I think all three components are orthogonal to each other. Using path knowl= edge is probably a forth dimension. Out of my head, my experience with the three components of Jumpstart were (= I had a Linux patch for it): 1. This can be complex in practice. Apps such as Web servers don't necessar= ily write data in a single write() socket call. In 2008/2009, it was not si= mple to set cwnd during subsequent write() calls as required by Jump Start.= Also, it could depend on the use case whether the server knows the data si= ze in advance and could signal it to the TCP stack in kernel, e.g., by a so= cket option. 2. Rate pacing results were really mixed - IW10 had a pretty decent perform= ance without pacing 3. The equation in the paper Section II ("(D-R)/2") does not always work - = R can be larger than D in case of heavy loss. I run out of time to fully in= vestigate the design space for loss recovery algorithms for Jump Start. In = general, I am not sure if we have really well explored whether an increased= aggressiveness and burstiness of TCP (IW10, etc.) could be combined with a= modified loss recovery. Michael (community member) From rs@netapp.com Tue Jun 4 06:37:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1288221F9DDD for ; Tue, 4 Jun 2013 06:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNm9DIibqGQJ for ; Tue, 4 Jun 2013 06:36:48 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A165221F966B for ; Tue, 4 Jun 2013 05:05:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,799,1363158000"; d="scan'208";a="21925573" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx11-out.netapp.com with ESMTP; 04 Jun 2013 05:05:08 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r54C57So011104; Tue, 4 Jun 2013 05:05:08 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Tue, 4 Jun 2013 05:05:07 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] some questions related to PAWS Thread-Index: AQHOX5nlI6SiHSreO0iaNFSHTu3955ki6zhQgAKVkoD///RoIA== Date: Tue, 4 Jun 2013 12:05:06 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:37:02 -0000 Hi Yoshifumi, > I agree with that it can be used to protect the session=20 > from outside interference to some extents. But, I'm still=20 > wondering how it is effective. > > In my understanding, PAWS is checking if SEG.TSval <=20 > TS.Recent. Is it enough to protect from malicious users? It at least increases the bar for a successful data injection (corruption),= while Window Scale lowers the bar. Provided that the sender is using diffe= rent timestamp clock offsets to different clients (destination IP addresses= ), of course, if this is to be seen as a security mechanism (deliberate dat= a corruption) But in the current implementations, by allowing a receiver to simply accept= non-TSopt data packets (which are otherwise in window), data corruption or= malicious interference can happen much more easily. =A0 >> >> Ad 2) PAWS is receiver-only, while RTTM is sender side; A=20 >> TSopt enabled sender has currently (1323 / 1323bis) no way=20 >> of signaling the receiver, that the TSopt should NOT be=20 >> used for PAWS (because, for example, it may sporadically=20 >> stop sending TSopt). The sender has to assume, that a=20 >> receiver will always enable PAWS (even if it doesn't) once >> TSopt was negotiated. > > Sorry. As you mentioned, PAWS is receiver logic. What=20 > I meant was disabling PAWS check.=A0Something like, "I want=20 > to have TS for RTTM, but I don't want to drop packets > without TS unless the sender sends data 4GB in less than > 2MSL". In this case, the node needs to measure receiving > rate to check if PAWS check is required.=A0 > > It might be tricky, but I still think it's one possibility. > one might prefer it rather than dropping packets without > TS blindly. Probably. The sender MUST still provide a TSopt in every segment, assuming = that the receiver is strictly enforcing PAWS. If a receiver chooses to open= a broader window for misuse (as apparently two dominant stacks currently d= o), that's their business. Specifying a resiliency mechanism and then stipu= lating it is completely optional to use it, is not the best approach for an= RFC IMHO. That's an implementers choice. I need to find some time to summarize the discussion around this topic that= the WG had in the last few days, and pour it into some text for the 1323bi= s draft. (I'm always happy if someone want's to donate text..:) Best regards, Richard From pasi.sarolahti@iki.fi Tue Jun 4 10:40:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5673B21F8415 for ; Tue, 4 Jun 2013 10:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss0hHABGHLin for ; Tue, 4 Jun 2013 10:40:52 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8200F21F9C11 for ; Tue, 4 Jun 2013 09:28:20 -0700 (PDT) Received: from [10.52.67.185] (77.86.210.20) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F203BBCB21; Tue, 4 Jun 2013 19:28:13 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 4 Jun 2013 19:27:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:40:59 -0000 On Jun 4, 2013, at 3:05 PM, "Scheffenegger, Richard" = wrote: >> It might be tricky, but I still think it's one possibility. >> one might prefer it rather than dropping packets without >> TS blindly. >=20 > Probably. The sender MUST still provide a TSopt in every segment, = assuming that the receiver is strictly enforcing PAWS. If a receiver = chooses to open a broader window for misuse (as apparently two dominant = stacks currently do), that's their business. Specifying a resiliency = mechanism and then stipulating it is completely optional to use it, is = not the best approach for an RFC IMHO. That's an implementers choice. Right. But we should also remember PAWS failure should be very rare = case, where two uncommon events coincide: * there is a old segment with wrapped sequence number that happens to = hit the window * the segment has timestamps option removed for some reason > I need to find some time to summarize the discussion around this topic = that the WG had in the last few days, and pour it into some text for the = 1323bis draft. (I'm always happy if someone want's to donate text..:) I don't think there has been much disagreement about the fact that to = ensure reliable operation of PAWS, all segments must have timestamps. I = tend to agree with you that standardizing an algorithm that works = unreliably is not elegant, and majority of mailing list feedback seems = to support this, so this seems clear. The trickier thing is, what language to add about the current state, but = I think we should point out what we know: there are implementations that = accept segments without timestamp after its successful negotiation (in = fact no one so far has reported implementation that would discard = segments without timestamps), and changing to follow the "MUST discard" = rule may bring up some communication problems as a result of faulty = network behavior (and there was some reported evidence of this actually = happening). I'm not suggesting this as a text to be used, but hopefully = it is an acceptable summary to everyone. Not to be said in the document, but just wanted to say it out: even if = segments without timestamps were accepted, PAWS could still be able to = detect most cases of sequence wrapping, assuming that timestamps removal = is a rare case. If user runs into communication problems that can be = solved by turning timestamps off entirely, the natural reaction is to do = so. After that there is no PAWS protection at all. - Pasi From internet-drafts@ietf.org Tue Jun 4 11:32:03 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057A521F99C9; Tue, 4 Jun 2013 11:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-eyUqeCi9+Z; Tue, 4 Jun 2013 11:32:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FF921F9AAE; Tue, 4 Jun 2013 11:03:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130604180356.20916.32395.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 11:03:56 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:32:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Shared Use of Experimental TCP Options Author(s) : Joe Touch Filename : draft-ietf-tcpm-experimental-options-06.txt Pages : 12 Date : 2013-06-04 Abstract: This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection. It uses a new IANA TCP experiment identifier, and is also robust to experiments that are not registered and those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Tue Jun 4 11:44:18 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DC721F9926; Tue, 4 Jun 2013 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.321 X-Spam-Level: X-Spam-Status: No, score=-103.321 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ong6SoJfmxxi; Tue, 4 Jun 2013 11:44:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E821F96F2; Tue, 4 Jun 2013 11:41:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r54IeC6S021941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Jun 2013 11:40:15 -0700 (PDT) Message-ID: <51AE3486.7060006@isi.edu> Date: Tue, 04 Jun 2013 11:40:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20130604180356.20916.32395.idtracker@ietfa.amsl.com> In-Reply-To: <20130604180356.20916.32395.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:44:18 -0000 Hi, all, FYI, this version addresses IESG feedback, notably: - recommending a preference towards a shorter ExID to conserve space unless needed for specific reasons, as listed - removes old text referring to a case no longer relevant - clarifies that registered ExIDs apply to both experimental option codepoints Joe On 6/4/2013 11:03 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : Shared Use of Experimental TCP Options > Author(s) : Joe Touch > Filename : draft-ietf-tcpm-experimental-options-06.txt > Pages : 12 > Date : 2013-06-04 > > Abstract: > This document describes how the experimental TCP option codepoints > can concurrently support multiple TCP extensions, even within the > same connection. It uses a new IANA TCP experiment identifier, and > is also robust to experiments that are not registered and those that > do not use this sharing mechanism. It is recommended for all new TCP > options that use these codepoints. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michael.scharf@alcatel-lucent.com Tue Jun 4 14:39:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACEC21F99D4 for ; Tue, 4 Jun 2013 14:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djF0pcobk62D for ; Tue, 4 Jun 2013 14:39:24 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C516021F9B3D for ; Tue, 4 Jun 2013 13:50:41 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r54KodQx023510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Jun 2013 15:50:39 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r54KoSUQ008644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 16:50:36 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Jun 2013 16:50:35 -0400 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.15]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 4 Jun 2013 22:50:32 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WGLC for update of draft-ietf-tcpm-experimental-options Thread-Index: AQHOYWUnrI9F40ythEmbqeMUTvpD6Q== Date: Tue, 4 Jun 2013 20:50:32 +0000 Message-ID: <655C07320163294895BBADA28372AF5D029B3C@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: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ted.lemon@nominum.com" Subject: [tcpm] WGLC for update of draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:39:30 -0000 Hi all,=0A= =0A= Because of IESG feedback, a new version (-06) has been submitted for draft-= ietf-tcpm-experimental-options. The update is mainly about a stronger recom= mendation of the 16bit experimental ID:=0A= =0A= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options-06= =0A= =0A= It is still allowed to use the 32bit variant.=0A= =0A= I'd like to confirm that the TCPM community agrees to this update. Because = the changed text just provides stronger guidance but doesn't affect the pro= tocol, this new WGLC runs only for one week.=0A= =0A= If you have any comments or concerns regarding this update, please let us k= now until Tuesday June 11.=0A= =0A= Thanks=0A= =0A= Michael (TCPM co-chair)=0A= =0A= =0A= ________________________________________=0A= Von: internet-drafts@ietf.org [internet-drafts@ietf.org]=0A= Gesendet: Dienstag, 4. Juni 2013 20:03=0A= An: tcpm-chairs@tools.ietf.org; draft-ietf-tcpm-experimental-options@tools.= ietf.org; martin.stiemerling@neclab.eu; ted.lemon@nominum.com=0A= Betreff: New Version Notification - draft-ietf-tcpm-experimental-options-06= .txt=0A= =0A= A new version (-06) has been submitted for draft-ietf-tcpm-experimental-opt= ions:=0A= http://www.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-06= .txt=0A= =0A= Sub state has been changed to AD Followup from Revised ID Needed=0A= =0A= =0A= The IETF datatracker page for this Internet-Draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/=0A= =0A= Diff from previous version:=0A= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options-06= =0A= =0A= IETF Secretariat.=0A= =0A= From ycheng@google.com Tue Jun 4 14:45:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0814421F990D for ; Tue, 4 Jun 2013 14:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQgJmh2o03rL for ; Tue, 4 Jun 2013 14:45:43 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19021F90AC for ; Tue, 4 Jun 2013 14:43:43 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so1189204lbi.5 for ; Tue, 04 Jun 2013 14:43:42 -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=VKU1cGeKMzYshF3kdr4YHw/ryNDIwIbnO4HnELNi1hM=; b=TN/c/JHXA84cEE03FzxIKiu2TF56vNxFtId/JT0E4YkjNfXJA6icj6WUYmQYV0/Php JUmcRxNhdfaj6GtxffPj9vKJ0fhwpGRSITo5nhFL+SXdciP+C8/AHOU48+SXS8dt1ilH S7fuvWttsYEch6ippNRK14mt8qio4LvbSoW6nCG9ODIVFD1gmRJcvarGy5AAV62gLRv2 uS/0LMmt4OTXHpBH2i2D9k/ef1gCLwn3ImWoGn1M1eokmfIoZTICe8rq9Mzt7MGI8ydE 6LpG+FzCRxDtPR56e/Y9nhEIb3xaziEggWuq7G45zuNIB+ghizefxUlAvDVTU1Ulw0xc bfKQ== X-Google-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:x-gm-message-state; bh=VKU1cGeKMzYshF3kdr4YHw/ryNDIwIbnO4HnELNi1hM=; b=pn6189ha8BHFoZpxJ6ceb5tnO0LMfwdYqIH+JxHywrhDHfxI1GyAnP9KFnaSZykVbq LK/utXOtpbd1H2twruZHGi8fTo9CN8kG5fTgYM7RxAb66YwYyRMynCZ4zmyrRb3yBZvf nXrB+7vSo7f23rxXJwawA4o76afg8LwUaSLykUrE9fTmvDA2Ue2Nn+HWvwJiRlelsx9Z 31PWnSV7AuZ3bfdEfpny5RrTeLRFZey7ADL3k/FNJtxVy2p6Qfm3g9ljGOXSI05r9k25 4UCbenon9Om6z41yjay3AYYcLXkVFH/ISlb8Xh3FC0MSOUTGmzp/kKdtcyeneUagQZ1i dJUg== X-Received: by 10.112.136.6 with SMTP id pw6mr7793465lbb.58.1370382222215; Tue, 04 Jun 2013 14:43:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.80.227 with HTTP; Tue, 4 Jun 2013 14:43:22 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D029B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D029B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Tue, 4 Jun 2013 14:43:22 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkCyy2VrUWbKWe8O0i/ZmdmxpPy3q6chlRbBrxMA4t90F6VaM+zR2uDGLKsxwuolyEg1ifAStbtb+4i0zq598TaJipOzK4402mZIBJ8x/QZ+Fi+flX+77MH7nIsTL95e1zwUqFOEljtRNJO1TgONdWFXtQ2kdfyniQvehTnjQIvBkkR20Kwnwfjf+Ri4JYaFhm/dSS8 Cc: "tcpm@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [tcpm] WGLC for update of draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:45:48 -0000 On Tue, Jun 4, 2013 at 1:50 PM, Scharf, Michael (Michael) wrote: > Hi all, > > Because of IESG feedback, a new version (-06) has been submitted for draft-ietf-tcpm-experimental-options. The update is mainly about a stronger recommendation of the 16bit experimental ID: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-06 > > It is still allowed to use the 32bit variant. +1 on -06 > > I'd like to confirm that the TCPM community agrees to this update. Because the changed text just provides stronger guidance but doesn't affect the protocol, this new WGLC runs only for one week. > > If you have any comments or concerns regarding this update, please let us know until Tuesday June 11. > > Thanks > > Michael (TCPM co-chair) > > > ________________________________________ > Von: internet-drafts@ietf.org [internet-drafts@ietf.org] > Gesendet: Dienstag, 4. Juni 2013 20:03 > An: tcpm-chairs@tools.ietf.org; draft-ietf-tcpm-experimental-options@tools.ietf.org; martin.stiemerling@neclab.eu; ted.lemon@nominum.com > Betreff: New Version Notification - draft-ietf-tcpm-experimental-options-06.txt > > A new version (-06) has been submitted for draft-ietf-tcpm-experimental-options: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-06.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-06 > > IETF Secretariat. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wes@mti-systems.com Tue Jun 4 19:34:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9F21F8D90 for ; Tue, 4 Jun 2013 19:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbec6hj4sWPw for ; Tue, 4 Jun 2013 19:34:34 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6611F21F9A98 for ; Tue, 4 Jun 2013 19:32:48 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.209]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r552Wl3Q002205 for ; Tue, 4 Jun 2013 22:32:47 -0400 Received: (qmail 25835 invoked by uid 0); 5 Jun 2013 02:32:47 -0000 Received: from unknown (HELO ?192.168.1.136?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 5 Jun 2013 02:32:47 -0000 Message-ID: <51AEA343.4040601@mti-systems.com> Date: Tue, 04 Jun 2013 22:32:35 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D029B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D029B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [tcpm] WGLC for update of draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:34:40 -0000 On 6/4/2013 4:50 PM, Scharf, Michael (Michael) wrote: > > I'd like to confirm that the TCPM community agrees to this update. It looks good to me. -- Wes Eddy MTI Systems From iesg-secretary@ietf.org Wed Jun 12 07:18:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3541421F9970; Wed, 12 Jun 2013 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G69uErFQnyAp; Wed, 12 Jun 2013 07:18:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E2421F99C9; Wed, 12 Jun 2013 07:18:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130612141822.24686.77077.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 07:18:22 -0700 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Protocol Action: 'Shared Use of Experimental TCP Options' to Proposed Standard (draft-ietf-tcpm-experimental-options-06.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:18:24 -0000 The IESG has approved the following document: - 'Shared Use of Experimental TCP Options' (draft-ietf-tcpm-experimental-options-06.txt) as Proposed Standard 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-experimental-options/ Technical Summary This document describes how TCP option codepoints can support concurrent experiments using a magic number field. It extends the option structure for experimental codepoints (253, 254) with a magic number, which is used to differentiate different experiments. This mechanism avoids the need for a coordinated registry, and is backward-compatible with currently known uses. It is recommended for all new experimental RFCs that require TCP option codepoints. Working Group Summary The document was accepted by the TCPM working group with support from a significant number of participants. It was discussed in several meetings and on the mailing list. Given that the mechanism proposed by the document is technically simple, the TCPM discussion mainly focused on process questions and a clear description of the normative parts of the document. There was only one clarification question during the working group last call. In summary, it is strong consensus in the TCPM working group that the document describes the best solution to deal with shared use of experimental TCP option codepoints. Document Quality Several implementations of experimental protocols have already documented the use of the magic numbers as specified in this document. The document is a short and technically straightforward and does not require extensive technical review. Personnel The document sheperd is Michael Scharf . The responsible Area Director is Martin Stiemerling . From michael.scharf@alcatel-lucent.com Tue Jun 18 01:08:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD521F9D15 for ; Tue, 18 Jun 2013 01:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejhXUkMzdHAG for ; Tue, 18 Jun 2013 01:08:38 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABF221F9D0B for ; Tue, 18 Jun 2013 01:08:38 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r5I88Zek003633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Jun 2013 03:08:35 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5I88SEg020878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 04:08:32 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 18 Jun 2013 04:08:02 -0400 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 18 Jun 2013 10:07:49 +0200 From: "Scharf, Michael (Michael)" To: "tcpm (tcpm@ietf.org)" Thread-Topic: Agenda preparation for IETF 87 (Berlin) Thread-Index: Ac5r+uyeHiNbWdMkTRytlZ+iRxk5bg== Date: Tue, 18 Jun 2013 08:07:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D04C46E@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Agenda preparation for IETF 87 (Berlin) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:08:45 -0000 Hi all, If you plan to present at the planned TCPM meeting in Berlin, please let th= e chairs know: * Presentation title / draft * Presenter * Presentation time The deadline for time slot requests is July 15. Thanks Michael, Pasi, Yoshifumi= From internet-drafts@ietf.org Wed Jun 19 11:45:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5F21F9E0F; Wed, 19 Jun 2013 11:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh+hYh-v7v6E; Wed, 19 Jun 2013 11:45:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAE321F9DC8; Wed, 19 Jun 2013 11:45:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619184531.14348.77568.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 11:45:31 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:45:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Author(s) : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-01.txt Pages : 19 Date : 2013-06-19 Abstract: This document proposes an update to RFC 5681 to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It updates TCP to allow a TCP sender to restart quickly following either an idle or rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. NOTE: The standards status of this WG document is under review for consideration as either Experimental (EXP) or Proposed Standard (PS). This decision will be made later as the document is finalised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hkchu@google.com Wed Jun 19 11:58:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D3721F9DFA for ; Wed, 19 Jun 2013 11:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY1uwbAYm2Ae for ; Wed, 19 Jun 2013 11:58:16 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 474C521F9DFF for ; Wed, 19 Jun 2013 11:58:14 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id v20so5135946lbc.31 for ; Wed, 19 Jun 2013 11:58:13 -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=JryBzWkIjVN91/XisbALwUqNudsC5BX+s4TVxZYU/08=; b=XOdh0rO8DysX1PBLKOcvwxGlyWlxJ7BGGmv5ix0uXHLn3NZuA+HvnNDu1lkVr28oB9 bIS7mnKPUmaRWmlaj4Jp+3ADUsCjR75m16M0bam54tQyYBb4+zKmB6BVWa4zKx72Z2aw fZ1o9zDuByI3SzSHGxRadG7CSu3Zr1T9vq1csQW9zk71/okQJjN1pcS7k6pihGl7YN61 GHtQzfgWsiUayAk07TPg4U5rQeXDMtz2CFQQfK4n0oLyRGlhBEsXkdO62TnaOdMFlFIw HEKiC1ayTZCBT+X531J2eRzr1Rd0Qg8funZhDkSzoTnKYgDziwn8b1Cvxml+f3FZooFe ValQ== X-Google-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:x-gm-message-state; bh=JryBzWkIjVN91/XisbALwUqNudsC5BX+s4TVxZYU/08=; b=bVlhRUFgZLQoTwQ0QBRyNt1TpoXaQvFMqGKl2YeQKf4CoK8tH4BLtaW8ojEj9Tu5hz e9uNhdl1BLla+ehY4rf5CchIApJSgmJtm6kB/UJuj0NJJAbOR3B113qmT7Wnr+MgZS2n 5kJ6Xg4dTPgs5aFg095M+JebGYCI9GStTU3Vh60WVbGm1mVezoTe99UW9t0Q6JlZOXj9 VrfbqJpod3tSAqI9V6DlR1NhetC5ElozW93VxnTIpzTU9Bn9G2v+Vz38emYsGw3/JAJ0 mJwicYfUX5NUNeYstZPmK8E1Gk+1ORdnMIF0FcBkR1Xk8yPodEwVSajpR9wMN9XLWNQj zj2Q== MIME-Version: 1.0 X-Received: by 10.152.170.162 with SMTP id an2mr1989310lac.3.1371668293031; Wed, 19 Jun 2013 11:58:13 -0700 (PDT) Received: by 10.112.0.200 with HTTP; Wed, 19 Jun 2013 11:58:12 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D04C46E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D04C46E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 19 Jun 2013 11:58:12 -0700 Message-ID: From: Jerry Chu To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnXR/CU2flyiBWo+6dQ18E1sFS+kixWnWmQdwoqCivTa8Xf+jo/UHopUDgxn8DPbC/Ob9EkCQdMwOvts1ys971ZcoVyC9UW/aLpgAviQQQoTV3ioRSt6ohIz07HoLWX1TBqKODa9CNYkYoYqSpaLyXWIh+4sacgZk2yjfItb77d2rivFyRZ0s8Y9Xh8J7fvDl++vqgN Cc: "tcpm-chairs@tools.ietf.org" , "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Agenda preparation for IETF 87 (Berlin) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:58:20 -0000 Hi Michael, On Tue, Jun 18, 2013 at 1:07 AM, Scharf, Michael (Michael) wrote: > Hi all, > > If you plan to present at the planned TCPM meeting in Berlin, please let the chairs know: > > * Presentation title / draft TCP Fast Open Draft Update (-04) > * Presenter Jerry/Yuchung > * Presentation time 15 mins Best, Jerry > > The deadline for time slot requests is July 15. > > Thanks > > Michael, Pasi, Yoshifumi > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From brandon.williams@akamai.com Wed Jun 19 12:46:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1FF21F9C51; Wed, 19 Jun 2013 12:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1olBNH8GBPR; Wed, 19 Jun 2013 12:46:43 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 71FCD21F9ECF; Wed, 19 Jun 2013 12:46:43 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C4181D1073; Wed, 19 Jun 2013 19:46:42 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id AC488D0CDC; Wed, 19 Jun 2013 19:46:42 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A185B1FF9; Wed, 19 Jun 2013 19:46:42 +0000 (GMT) Message-ID: <51C20AA1.3090604@akamai.com> Date: Wed, 19 Jun 2013 15:46:41 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "tcpm@ietf.org" , "int-area@ietf.org" References: <20130619193032.15613.81616.idtracker@ietfa.amsl.com> In-Reply-To: <20130619193032.15613.81616.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130619193032.15613.81616.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] Fwd: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 19:46:47 -0000 Dear all, A new version of this draft has been submitted. The changes is the version are: o Clarify public overlay network use case regarding NAT. o Add some discussion regarding use of option space and packet fragmentation. Comments are welcome. Cheers, --Brandon PS: Please note, I have cross posted to tcpm and int-area because the draft describes both a TCP option and IP options for v4 and v6. -------- Original Message -------- Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-04.txt Date: Wed, 19 Jun 2013 15:30:32 -0400 From: internet-drafts@ietf.org To: Williams, Brandon A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-04.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Filename: draft-williams-overlaypath-ip-tcp-rfc Revision: 04 Title: Overlay Path Option for IP and TCP Creation date: 2013-06-19 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-04.txt Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-04 Abstract: Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. The IETF Secretariat From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jun 26 04:27:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B327511E81A3 for ; Wed, 26 Jun 2013 04:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZAnWgOykxTG for ; Wed, 26 Jun 2013 04:27:45 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 784F721E813C for ; Wed, 26 Jun 2013 04:27:41 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 597D16020E; Wed, 26 Jun 2013 13:27:40 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 460D36020D; Wed, 26 Jun 2013 13:27:40 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org Date: Wed, 26 Jun 2013 13:27:40 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201306261327.40162.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-accurate-ecn-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 11:27:48 -0000 Hi, we updated our proposal for a more accurate ECN feedback. We now propose on= e=20 solution using codepoints and the Urgent Pointer if the URG flag is not set= =20 to increase the robustness. =46eedback would be very welcome! Thanks, Richard and Mirja =2D--------- Forwarded Message ---------- Subject: New Version Notification for=20 draft-kuehlewind-tcpm-accurate-ecn-02.txt Date: Thursday 20 June 2013, 16:36:55 =46rom: internet-drafts@ietf.org To: Richard Scheffenegger , Mirja Kuehlewind=20 A new version of I-D, draft-kuehlewind-tcpm-accurate-ecn-02.txt has been successfully submitted by Mirja Kuehlewind and posted to the IETF repository. =46ilename: draft-kuehlewind-tcpm-accurate-ecn Revision: 02 Title: More Accurate ECN Feedback in TCP Creation date: 2013-06-20 Group: Individual Submission Number of pages: 14 URL: =20 http://www.ietf.org/internet-drafts/draft-kuehlewind-tcpm-accurate-ecn-02.t= xt Status: =20 http://datatracker.ietf.org/doc/draft-kuehlewind-tcpm-accurate-ecn Htmlized: =20 http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-02 Diff: =20 http://www.ietf.org/rfcdiff?url2=3Ddraft-kuehlewind-tcpm-accurate-ecn-02 Abstract: Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. ECN-capable receivers will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently, new TCP mechanisms like ConEx or DCTCP need more accurate ECN feedback information in the case where more than one marking is received in one RTT. This document specifies a different scheme for the ECN feedback in the TCP header to provide more than one feedback signal per RTT. Furthermore this document specifies a re-use of the Urgent Pointer in the TCP header if the URG flag is not set to increase the robustness of the proposed ECN feedback scheme. = =20 The IETF Secretariat =2D------------------------------------------------------ =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From ycheng@google.com Wed Jun 26 08:32:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEB011E81C4 for ; Wed, 26 Jun 2013 08:32:46 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJdmYea5cBwb for ; Wed, 26 Jun 2013 08:32:46 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFAC11E81C5 for ; Wed, 26 Jun 2013 08:32:42 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eg20so13954589lab.19 for ; Wed, 26 Jun 2013 08:32:42 -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=9P34GmI4BPq68HuYEcLYZ5AfxGohPO4pvMw8dg9lBQw=; b=Zk0LGpntilEJOVuyLEg5VOkXpSQUxodZlXGO09wSulHOrTPjsrHZ2H341Ckx9QwPG1 GU497ERG1VIao6V5YDj7bKREty6HO5bv2iHn82FCHTDLVlNk+XzGibuyfX67hQ5gs8oj 23YY8mP67bsCGu9aSOJD0ckBv6X0STVDOFMLCk2efTduEIoYHxM8VytF0y5eTkuCgifg kleTZvCdfjYO9SwMyGyqkN2terA0Oq4Io6dtnN9NR+0tqya/TEpgjQhIJe+Huh8X2kAo ownyu3tQF9A36N7Y4Impb2tisY78Id7ILai57SpvVQM7tPUDC0wHcklBYhJBdaoyXf5x lSdQ== X-Google-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:x-gm-message-state; bh=9P34GmI4BPq68HuYEcLYZ5AfxGohPO4pvMw8dg9lBQw=; b=BTFsxab5xOZpjIr3qlcblHZTknbA1yS2XGb4oJBAFl0LbF7RkMkawXjwXD8O7pq7YA PnKTGeOMSXqM0u6fHN4gu3YfFB+7tSkdeC1ikyZRrbNkKK2PcsrjaYTIoo/oYA301P09 P4k8HD2BYX9LJb2507ZjYOHM60vxiCob6XTzViQnE+CJbQwIu0VBoKdg9ER2gEx6vbsZ mKUNB2GV15nTSrv7XvcdJH4+fYNz/jvXlkTxmwx4k/Ibpr0FCFnWYmfyq+NLzPajxaAo RPwwVelsAk15wAhzle5g/w+Iqcrw3yYEVd/7CvMg8274bZgsaLwQP04pVr8wCvKr+uX0 JfnA== X-Received: by 10.112.167.136 with SMTP id zo8mr2332838lbb.33.1372260762045; Wed, 26 Jun 2013 08:32:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Wed, 26 Jun 2013 08:32:22 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D04C46E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D04C46E@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Wed, 26 Jun 2013 08:32:22 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlNtDCdLZUdNUilKOxoQHpc6kh8J2F3gN5m96qYQ8cVSysJW86QDav9TUtNYvQpbKgS1+vW7NciQDmo0S8fmzkxwxWMGWVcR7WeHtST/zKEr3HCmS1QPV3C//iwRDOxFL9zZNaaMocoWG7aWYBhrwA5bDZgkb2rYX9Zd5zUHcUtxjvNKgOK1zHq9n17ORuKzis7GO3v Cc: "tcpm-chairs@tools.ietf.org" , "tcpm \(tcpm@ietf.org\)" , Matthew Mathis Subject: Re: [tcpm] Agenda preparation for IETF 87 (Berlin) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:32:48 -0000 On Tue, Jun 18, 2013 at 1:07 AM, Scharf, Michael (Michael) wrote: > > Hi all, > > If you plan to present at the planned TCPM meeting in Berlin, please let the chairs know: > > * Presentation title / draft Update of tail loss probe > * Presenter Yuchung Cheng > * Presentation time 5m > > The deadline for time slot requests is July 15. > > Thanks > > Michael, Pasi, Yoshifumi > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Thu Jun 27 06:28:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAD921F9D90 for ; Thu, 27 Jun 2013 06:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAcjGXOfBTeJ for ; Thu, 27 Jun 2013 06:28:18 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id F200B21F9D8E for ; Thu, 27 Jun 2013 06:28:01 -0700 (PDT) Received: from [172.20.10.3] (188.238.31.117) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163EC560585DA91 for tcpm@ietf.org; Thu, 27 Jun 2013 16:28:00 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3E564B47-814D-4B9C-AD1C-688E2B315A7E@iki.fi> Date: Thu, 27 Jun 2013 16:28:03 +0300 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [tcpm] TCPM status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:28:23 -0000 Hi, Here is the chairs' understanding of the current WG status. Let us know = of any corrections or other remarks. Recent RFCs ----------- Proportional Rate Reduction for TCP (draft-ietf-tcpm-proportional-rate-reduction) * Milestone Target: Experimental in May 2012 * Status: RFC 6937 (May 2013) Increasing the Initial Window (draft-ietf-tcpm-initcwnd) * Milestone Target: Experimental in September 2011 * Status: RFC 6928 (April 2013) WG Items Nearing RFC Publication -------------------------------- Shared Use of Experimental TCP Options (draft-ietf-tcpm-experimental-options) * Milestone Target: PS in Sept. 2012 * Status: RFC Editor's queue, new IANA registry for Experimental Option IDs is opened at = http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-ex= ids WG Items in WGLC or being revised after WGLC -------------------------------------------- TCP Extensions for High Performance (draft-ietf-tcpm-1323bis) * Milestone Target: Proposed Standard in July 2009 * Status: WGLC over, most WGLC comments addressed in subsequent update * Action: Update pending from Richard, to be discussed in Berlin meeting Active WG Items --------------- TCP Fast Open (draft-ietf-tcpm-fastopen) * Milestone Target: Experimental in Sept. 2012 * Status: No update since last meeting Updating TCP to support Variable-Rate Traffic (draft-ietf-tcpm-newcwv) * Status: Recently updated * Action: Intended status of the document to be decided Problem Statement and Requirements for a More Accurate ECN Feedback (draft-ietf-tcpm-accecn-reqs) * Status: No update since last meeting TCP and SCTP RTO Restart (draft-ietf-tcpm-rtorestart) * Status: No update since last meeting Active Individual Internet-Drafts --------------------------------- A Roadmap for TCP Specification Documents (draft-zimmermann-tcpm-tcp-rfc4614bis) * Status: Recently updated * Action: To be discussed at IETF-87 TCP Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses (draft-dukkipati-tcpm-tcp-loss-probe) * Status: No updates since IETF-86 On the Validation of TCP Sequence Numbers (draft-gont-tcpm-tcp-seq-validation) * Status: No updates since IETF-86 * Action: To be discussed at IETF-87 More Accurate ECN Feedback in TCP (draft-kuehlewind-tcpm-accurate-ecn) * Status: Recently updated A TCP Authentication Option NAT Extension (draft-touch-tcp-ao-nat) * Status: At RFC editor, submitted through individual track Shared Memory Communications over RDMA (draft-fox-tcpm-shared-memory-rdma) * Status: Recently updated