From ycheng@google.com Thu Nov 1 09:19:45 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7677421F8FA1 for ; Thu, 1 Nov 2012 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.727 X-Spam-Level: X-Spam-Status: No, score=-101.727 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbc9nOc0NgHK for ; Thu, 1 Nov 2012 09:19:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACEF21F8F9F for ; Thu, 1 Nov 2012 09:19:44 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2932476obq.31 for ; Thu, 01 Nov 2012 09:19:44 -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:x-system-of-record; bh=FPeYs9GP2+1A/ZlenYMSVcWORgZqIpmOXGmnaX/OurY=; b=AcKkdyldmciFEkm0ZVVuNHpgbk9PBmok/4+leUVnmL7rv9FIjp5p9nviGATh1LZlYo qzIeraKTD8SvR3hbwhFTcv0Yx2gWnzjAoyqPtkR5Jw55qHN62VhkJ9qPFPTpx12LOcuJ uiQKqVrUVGuK8qc8cRrbIZQwQbUDgtJ3hhqw4CY+rmcEcAtjXDXt+XKHfsc4lqv605BZ pho2t3zNtJYQOCKGC1Co92ecN057xzLZdmu9vyvAccM7D+rO6eW3CaVg0uDjSuT0+ycV /HsM2Tcc1mJ7nHA5WKdFITkCJZWOTXcHMEQ9CQDRIWAM9f0GzP4PJz2L2d79vYCW/pMZ T2oA== 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-system-of-record:x-gm-message-state; bh=FPeYs9GP2+1A/ZlenYMSVcWORgZqIpmOXGmnaX/OurY=; b=dUElBe4BY1G5BW0LTs70X6RPdYIm0BhretPCVPTe9yzkcBeMVzkQ+28SUFOtkpa0pT 1Ajs8dPGQRUWehnPS2bGocb71jYAsGgk+n3E8Q8vga+emZ3/Ak2xfB0QHTArblTAVURL 6L8j7D2Hyf42vkTQRMH76Thmf3yrGzEy5w4eQ5+YORj48ETCeEbZ3qchX0HOdNAqJydP 7mx4QpMRoZUOANwBupSchkoitGJjsn5unRf5wFPLegLqQLUoUy3bcEzoiZbAGYW7hdMe p0grsrq1P+1sN3IosI4IF66dqz6AudxHdvKFkzAiWsuf5GKq1nhxMU07yagYEIiIyoAm ttJw== Received: by 10.60.36.73 with SMTP id o9mr505546oej.23.1351786784159; Thu, 01 Nov 2012 09:19:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.41 with HTTP; Thu, 1 Nov 2012 09:19:23 -0700 (PDT) In-Reply-To: References: <20121022185739.7534.69954.idtracker@ietfa.amsl.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A61B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39987@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Thu, 1 Nov 2012 09:19:23 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQldnyXo3XgFt9QCkqrvo6LQDlk7eFv7QpWYDrlD1ty1Jp7Cl7N9uhJoYVdlRQB+4mVXx2jgAnx/GyhEio2fVp6e4SyvxAMY1fyK6eptFAKUQAeE6xmbi6UJ/ifTkIwbFsiBBAh6InWYe8Tl7Mr6UMzyqaZZ1VvdJqJc7ioCPFMnpEmCLMktATHM9hBrD2rVAACTJD3c Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-fastopen-02 vs. congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 Nov 2012 16:19:45 -0000 On Wed, Oct 31, 2012 at 12:45 PM, Yoshifumi Nishida wrote: > Hi Yuchung, > > On Tue, Oct 30, 2012 at 2:42 PM, Yuchung Cheng wrote: >> >> >> >> On Sun, Oct 28, 2012 at 1:14 PM, Scharf, Michael (Michael) >> wrote: >>> >>> Yuchung, >>> >>> I did not suggest that the draft must update RFC 5681. >>> >>> My proposal is that the draft discusses more explicitly what the >>> different sending behavior implies to a (congested) network. Right now, the >>> draft mainly stresses the performance benefit for applications. Well >>> understood. But it seems to me a valid question whether this benefit comes >>> at some cost for the network, at least in corner cases. >>> >>> I think that some text on that would be good to complete the document. >>> This could be a short paragraph e. g. in Section 5. This is a quite >>> low-hanging fruit. It could basically be a better phrasing of our discussion >>> here. >> >> How about this >> "If SYNACK is lost during handshake, in Fast Open the server may send up >> to an initial window of data because the loss is detected afterwards. But in >> regular handshake, the server detects the loss first and reduces the initial >> congestion window according to RFC". > > > I'm wondering it might be advisable to have a mechanism which can invalidate > the cookie for lossy destinations. > Or, it could be a job for the drafts like IW10 to recommend to set > appropriate IW size for lossy destinations. Any thoughts on this? The server can ack only SYN/initial sequence or send less data if it does not want (e.g., based on some history of the destination). I will modify step 4 in "Server: Receiving SYN and responding with SYN-ACK" to make this option more explicit. Thanks for pointing that out. > > Thanks, > -- > Yoshifumi > >>> >>> ________________________________________ >>> Von: Yuchung Cheng [ycheng@google.com] >>> Gesendet: Samstag, 27. Oktober 2012 22:03 >>> An: Scharf, Michael (Michael) >>> Cc: tcpm@ietf.org >>> Betreff: Re: draft-ietf-tcpm-fastopen-02 vs. congestion control >>> >>> On Fri, Oct 26, 2012 at 12:57 PM, Scharf, Michael (Michael) >>> wrote: >>> > Yuchung, >>> > >>> > You state that fast open does not change the congestion control, but I >>> > am still wondering whether this is actually true. My impression is that fast >>> > open can have side effects that affect congestion control, at least in >>> > corner cases. But please correct me if I am wrong. >>> >>> Which part in RFC5681 needs to be updated by Fast Open if you don't >>> think it's true? >>> >>> > >>> > Let's assume that the downlink between a HTTP server and a HTTP client >>> > is severely congested. >>> > >>> > With current TCP, the client will send a SYN, and the server will >>> > respond by SYN-ACK. Even if the SYN carries data, the server cannot respond. >>> > That implies that the server sends one packet to a congested downlink. If it >>> > gets dropped, the whole connection backs off for a moment. That may help to >>> > reduce the congestion. >>> > >>> > With fast open, the client will send SYN+data, and the server will >>> > potentially respond by a series of packets as allowed by the initial >>> > congestion window. According to RFC 3390, this implies sending 3 packets to >>> > the severely congested downlink. That is apparently worse... >>> > >>> > Thus, unless I miss something here, the amount of data that a server >>> > could send to a severely congested link can be significantly larger with >>> > fast open. Fast open may thus cause self-congestion in such a scenario. >>> > Theoretically it could maybe also harm other traffic (fairness...). >>> >>> What if the handshakes finish smoothly in current TCP, but the network >>> becomes congested as you sketched by the time server is ready to send? >>> and many servers today do not change cwnd after idle. It's certainly >>> not a corner case then. How about changing the scenarios with >>> syn-cookies? >>> >>> We appreciate you scrutinizing the draft. but I suggest you experts >>> look congestion control on at higher level. How about loss-based >>> algorithm causing huge queues with BB. Ok I am deviating now ... >>> >>> > >>> > It is not entirely clear to me whether that difference indeed matters >>> > in reality with RFC 3390, since fast open mostly affects *when* data is >>> > sent. Maybe this is a corner case only. But at least it might be worthwile >>> > to mention that side-effect in the draft. That might also help to understand >>> > what would happen if fast open and IW10 are used at the same time. That >>> > question was raised several times already. >>> > >>> As I said, IW10 is part of RFC5681. TFO does not update RFC5681 >>> currently. Should I mention TCP-SACK in TFO too? >>> >>> >>> > Thanks >>> > >>> > Michael (as individual) >>> > >>> > >>> >> -----Original Message----- >>> >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >>> >> Behalf Of Yuchung Cheng >>> >> Sent: Tuesday, October 23, 2012 12:22 AM >>> >> To: tcpm@ietf.org >>> >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-02.txt >>> >> >>> >> On Mon, Oct 22, 2012 at 11:57 AM, wrote: >>> >> > >>> >> > A New Internet-Draft is available from the on-line >>> >> Internet-Drafts directories. >>> >> > This draft is a work item of the TCP Maintenance and Minor >>> >> Extensions Working Group of the IETF. >>> >> > >>> >> > Title : TCP Fast Open >>> >> > Author(s) : Yuchung Cheng >>> >> > Jerry Chu >>> >> > Sivasankar Radhakrishnan >>> >> > Arvind Jain >>> >> > Filename : draft-ietf-tcpm-fastopen-02.txt >>> >> > Pages : 22 >>> >> > Date : 2012-10-22 >>> >> > >>> >> > Abstract: >>> >> > TCP Fast Open (TFO) allows data to be carried in the SYN >>> >> and SYN-ACK >>> >> > packets and consumed by the receiving end during the initial >>> >> > connection handshake, thus saving up to one full round trip time >>> >> > (RTT) compared to standard TCP which requires a >>> >> three-way handshake >>> >> > (3WHS) to complete before data can be exchanged. >>> >> ChangeLog since 01: >>> >> >>> >> - elaborate more on the issue of duplicate SYN-data (sec 2.1) >>> >> >>> >> - use draft-tcpm-experimental-options (sec 10) >>> >> >>> >> - add a new subsection about attacks from behind NAT (sec 6.3) >>> >> and discuss Bob Briscoe's idea on defending with TCP-TS and >>> >> cookies >>> >> >>> >> - use null cookie (end of sec 4.1.2) (courtesy of Bob Briscoe) >>> >> >>> >> - explain the problem of cookie option in FIN (end of 4.2.1) >>> >> >>> >> - re-emphasize other than including data in SYN packet. TFO >>> >> draft does not change any part of congestion control, and >>> >> the transmission MUST be governed by CC (sec 4.2.2) >>> >> >>> >> - a bunch of minor edits >>> >> >>> >> > >>> >> > Terminology >>> >> > >>> >> > The IETF datatracker status page for this draft is: >>> >> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen >>> >> > >>> >> > There's also a htmlized version available at: >>> >> > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 >>> >> > >>> >> > A diff from the previous version is available at: >>> >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-02 >>> >> > >>> >> > >>> >> > Internet-Drafts are also available by anonymous FTP at: >>> >> > ftp://ftp.ietf.org/internet-drafts/ >>> >> > >>> >> > _______________________________________________ >>> >> > tcpm mailing list >>> >> > tcpm@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >>> >> tcpm mailing list >>> >> tcpm@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/tcpm >>> >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From per.hurtig@gmail.com Thu Nov 1 13:18:32 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0921A21F9305 for ; Thu, 1 Nov 2012 13:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kMdJDyaDEDF for ; Thu, 1 Nov 2012 13:18:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B657121F92D3 for ; Thu, 1 Nov 2012 13:18:28 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3189089obq.31 for ; Thu, 01 Nov 2012 13:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nBsNI8gkEMspweNREPFnlBLDhEFvfoZMwwWGa9PICJE=; b=lOmra4kN1c11IYJbYbznUZvN17iUj3KwxdRRQ8MnUiix7udF+IU0R3HS4gtGgJfFw2 zwlkcpXb5YWF+dNJfKKotl7wTepNGip9ZC/63A77Wst4HbUIbyIgCvAus2y2Q4ez2Z9G E1PcfOwcV/BFQoi6tn8CgOkQv2kwSOMnbelnhmVm4QpSOGT3wTpbRgDIdsrCDRDP4RSY cpB5+LXQw1YmWUiIzQgM6JL0PuXcbWxVwEkp+36OCp55/LjVYs5QsPWtqAsIBBdBk3/r sIgEQryNvELKj+yDo04i7s8jpYCHLFIHshlASnAOuOIguuCMBsoOBFaFMdDDr0SKXjxg k2Iw== MIME-Version: 1.0 Received: by 10.60.13.198 with SMTP id j6mr35160796oec.51.1351801108399; Thu, 01 Nov 2012 13:18:28 -0700 (PDT) Sender: per.hurtig@gmail.com Received: by 10.182.8.200 with HTTP; Thu, 1 Nov 2012 13:18:27 -0700 (PDT) In-Reply-To: <20120710151352.A743D22F931F@lawyers.icir.org> References: <20120710151352.A743D22F931F@lawyers.icir.org> Date: Thu, 1 Nov 2012 21:18:27 +0100 X-Google-Sender-Auth: lYUvOeXwRaSwgnDsAhT5ysS9ooQ Message-ID: From: Per Hurtig To: "mallman@icir.org" Content-Type: multipart/alternative; boundary=e89a8ff253d2df884b04cd74b8ae Cc: tcpm , Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Thu, 01 Nov 2012 20:18:32 -0000 --e89a8ff253d2df884b04cd74b8ae Content-Type: text/plain; charset=ISO-8859-1 Hi, We've run experiments (using Linux TCP) to determine whether our restart approach is more likely to cause spurious retransmissions in a burst transmission scenario as suggested by Yuchung. In the experiments 30 packets are transmitted in total. At first there is a very low initial delay, but from packet 11 and onward the bandwidth is restricted so that the spacing between packets become 200 ms. Given an initial window of 10 and that Linux ACKs each packet in the initial window the scenario creates a burst transmission of 20 packets as suggested in Yuchung's example. In our experiments we see the "balloon effect" that Mark predicted very clearly (the RTO becomes extremely inflated due to the variation). There is no risk that the modified RTO approach causes spurious retransmissions. Furthermore, possible problems in burst scenarios are quite unlikely, as spurious retransmissions would only affect the transmission if a new large burst of data is to be sent after the RTO timer spuriously expires (otherwise the spurious retransmission is just a wasted packet in the end of a short flow), but before an RTO worth of time has elapsed (otherwise cwnd is reset to the restart window). Per On Tue, Jul 10, 2012 at 5:13 PM, Mark Allman wrote: > > > I am concerned about this following hypothetical scenario: > > > > t0.0s: bursts packets 1-20, mount RTO to 2second > > t1.8s: gets ack of packets 2,4,6,8,10,12,14,16, 18 every 200ms. > > Ack of 18 arrives at 1.8s > > > > This draft will mount an RTO of 200ms for packet 19 on ack18, which > > is likely to be spurious. The problem is that T_earliest could be > > starting from large send a while back even when current FlightSize > > is small. > > I hear you. But, I don't buy your framing. You keep the RTO at a > constant throughout the process. But, with a variance like you describe > above it certainly seems plausible that the RTO will balloon. And, the > way the document is framed when 18 arrives we restart the timer with > RTO-T_earliest. But, if RTO is > 2sec then the timeout will be > > 200ms. > > So, I don't think it is as easy as you have portrayed it. > > allman > > > > --e89a8ff253d2df884b04cd74b8ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,


We've run experiments (using Linux TCP) to determine whether our rest= art approach is more likely to cause spurious retransmissions in a burst tr= ansmission scenario as suggested by Yuchung.


In the experiments 30 packets are transmitted in total. At first there is= a very low initial delay, but from packet 11 and onward the bandwidth is r= estricted so that the spacing between packets become 200 ms. Given an initi= al window of 10 and that Linux ACKs each packet in the initial window the s= cenario creates a burst transmission of 20 packets as suggested in Yuchung&= #39;s example. In our experiments we see the "balloon effect" tha= t Mark predicted very clearly (the RTO becomes extremely inflated due to th= e variation). There is no risk that the modified RTO approach causes spurio= us retransmissions.


Furthermore, possible problems in burst scenarios are quite unlikely, as = spurious retransmissions would only affect the transmission if a new large = burst of data is to be sent after the RTO timer spuriously expires (otherwi= se the spurious retransmission is just a wasted packet in the end of a shor= t flow), but before an RTO worth of time has elapsed (otherwise cwnd is res= et to the restart window).




Per

On Tue, Jul 10, 2012 at 5:13 PM, Mark Allman <mallman@icir.org> wrote:

> I am concerned about this following hypothetical scenario:
>
> t0.0s: bursts packets 1-20, mount RTO to 2second
> t1.8s: gets ack of packets 2,4,6,8,10,12,14,16, 18 every 200ms.
> =A0 =A0 =A0 =A0Ack of 18 arrives at 1.8s
>
> This draft will mount an RTO of 200ms for packet 19 on ack18, which > is likely to be spurious. The problem is that T_earliest could be
> starting from large send a while back even when current FlightSize
> is small.

I hear you. =A0But, I don't buy your framing. =A0You keep the RTO= at a
constant throughout the process. =A0But, with a variance like you describe<= br> above it certainly seems plausible that the RTO will balloon. =A0And, the way the document is framed when 18 arrives we restart the timer with
RTO-T_earliest. =A0But, if RTO is > 2sec then the timeout will be > 200ms.

So, I don't think it is as easy as you have portrayed it.

allman




--e89a8ff253d2df884b04cd74b8ae-- From Michael.Tuexen@lurchi.franken.de Thu Nov 1 13:59:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFBB21F9641 for ; Thu, 1 Nov 2012 13:59:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJjOjpn5ZmpD for ; Thu, 1 Nov 2012 13:59:01 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1091A21F9611 for ; Thu, 1 Nov 2012 13:59:00 -0700 (PDT) Received: from [192.168.1.103] (p5481BC4A.dip.t-dialin.net [84.129.188.74]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C5E221C0C0692; Thu, 1 Nov 2012 21:58:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Thu, 1 Nov 2012 21:58:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120710151352.A743D22F931F@lawyers.icir.org> To: Per Hurtig X-Mailer: Apple Mail (2.1283) Cc: tcpm , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Thu, 01 Nov 2012 20:59:02 -0000 On Nov 1, 2012, at 9:18 PM, Per Hurtig wrote: > Hi, >=20 > We've run experiments (using Linux TCP) to determine whether our = restart approach is more likely to cause spurious retransmissions in a = burst transmission scenario as suggested by Yuchung. >=20 > In the experiments 30 packets are transmitted in total. At first there = is a very low initial delay, but from packet 11 and onward the bandwidth = is restricted so that the spacing between packets become 200 ms. Given = an initial window of 10 and that Linux ACKs each packet in the initial = window the scenario creates a burst transmission of 20 packets as = suggested in Yuchung's=20 Just curios: How does the receiver know what the sender uses as its = initial window? Best regards Michael > example. In our experiments we see the "balloon effect" that Mark = predicted very clearly (the RTO becomes extremely inflated due to the = variation). There is no risk that the modified RTO approach causes = spurious retransmissions. >=20 > Furthermore, possible problems in burst scenarios are quite unlikely, = as spurious retransmissions would only affect the transmission if a new = large burst of data is to be sent after the RTO timer spuriously expires = (otherwise the spurious retransmission is just a wasted packet in the = end of a short flow), but before an RTO worth of time has elapsed = (otherwise cwnd is reset to the restart window). >=20 >=20 >=20 > Per >=20 > On Tue, Jul 10, 2012 at 5:13 PM, Mark Allman wrote: >=20 > > I am concerned about this following hypothetical scenario: > > > > t0.0s: bursts packets 1-20, mount RTO to 2second > > t1.8s: gets ack of packets 2,4,6,8,10,12,14,16, 18 every 200ms. > > Ack of 18 arrives at 1.8s > > > > This draft will mount an RTO of 200ms for packet 19 on ack18, which > > is likely to be spurious. The problem is that T_earliest could be > > starting from large send a while back even when current FlightSize > > is small. >=20 > I hear you. But, I don't buy your framing. You keep the RTO at a > constant throughout the process. But, with a variance like you = describe > above it certainly seems plausible that the RTO will balloon. And, = the > way the document is framed when 18 arrives we restart the timer with > RTO-T_earliest. But, if RTO is > 2sec then the timeout will be > > 200ms. >=20 > So, I don't think it is as easy as you have portrayed it. >=20 > allman >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Thu Nov 1 14:06:01 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7692421F9750 for ; Thu, 1 Nov 2012 14:06:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpW8rZVCahrO for ; Thu, 1 Nov 2012 14:06:00 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 3019721F9756 for ; Thu, 1 Nov 2012 14:06:00 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TU1xd-0007ej-3v; Thu, 01 Nov 2012 22:05:57 +0100 Received: from [12.231.120.253] (helo=[10.19.0.50]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TU1xc-00054M-1m; Thu, 01 Nov 2012 22:05:56 +0100 Message-Id: <7CB75818-5C61-49DA-9729-741AA7DA7078@ifi.uio.no> From: Michael Welzl To: Michael Tuexen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Nov 2012 22:05:51 +0100 References: <20120710151352.A743D22F931F@lawyers.icir.org> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 11 sum msgs/h 4 total rcpts 25202 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A9FE99945BDF4046437E74FED251A73F157E8460 X-UiO-SPAM-Test: remote_host: 12.231.120.253 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 34 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Thu, 01 Nov 2012 21:06:01 -0000 On Nov 1, 2012, at 9:58 PM, Michael Tuexen wrote: > On Nov 1, 2012, at 9:18 PM, Per Hurtig wrote: > >> Hi, >> >> We've run experiments (using Linux TCP) to determine whether our >> restart approach is more likely to cause spurious retransmissions >> in a burst transmission scenario as suggested by Yuchung. >> >> In the experiments 30 packets are transmitted in total. At first >> there is a very low initial delay, but from packet 11 and onward >> the bandwidth is restricted so that the spacing between packets >> become 200 ms. Given an initial window of 10 and that Linux ACKs >> each packet in the initial window the scenario creates a burst >> transmission of 20 packets as suggested in Yuchung's > Just curios: How does the receiver know what the sender uses as its > initial window? RTO Restart is a sender-side only change. Neither this draft nor the scenario that Yuchung described (his concern that we're trying to address here) requires the receiver to know the sender's IW. If you're wondering where the bandwidth restriction from packet 11 and onward comes from: we made this, artificially, to recreate the scenario of Yuchung's concern. Cheers, Michael From Michael.Tuexen@lurchi.franken.de Thu Nov 1 14:10:14 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C23321F8634 for ; Thu, 1 Nov 2012 14:10:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjAxu9zFvgBp for ; Thu, 1 Nov 2012 14:10:13 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 15EC421F89FF for ; Thu, 1 Nov 2012 14:10:13 -0700 (PDT) Received: from [192.168.1.103] (p5481BC4A.dip.t-dialin.net [84.129.188.74]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 29F661C0C0BC5; Thu, 1 Nov 2012 22:10:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <7CB75818-5C61-49DA-9729-741AA7DA7078@ifi.uio.no> Date: Thu, 1 Nov 2012 22:10:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120710151352.A743D22F931F@lawyers.icir.org> <7CB75818-5C61-49DA-9729-741AA7DA7078@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1283) Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Thu, 01 Nov 2012 21:10:14 -0000 On Nov 1, 2012, at 10:05 PM, Michael Welzl wrote: >=20 > On Nov 1, 2012, at 9:58 PM, Michael Tuexen wrote: >=20 >> On Nov 1, 2012, at 9:18 PM, Per Hurtig wrote: >>=20 >>> Hi, >>>=20 >>> We've run experiments (using Linux TCP) to determine whether our = restart approach is more likely to cause spurious retransmissions in a = burst transmission scenario as suggested by Yuchung. >>>=20 >>> In the experiments 30 packets are transmitted in total. At first = there is a very low initial delay, but from packet 11 and onward the = bandwidth is restricted so that the spacing between packets become 200 = ms. Given an initial window of 10 and that Linux ACKs each packet in the = initial window the scenario creates a burst transmission of 20 packets = as suggested in Yuchung's >> Just curios: How does the receiver know what the sender uses as its = initial window? >=20 > RTO Restart is a sender-side only change. Neither this draft nor the = scenario that Yuchung described (his concern that we're trying to = address here) requires the receiver to know the sender's IW. > If you're wondering where the bandwidth restriction from packet 11 and = onward comes from: we made this, artificially, to recreate the scenario = of Yuchung's concern. I was wondering how the receiver can ack each packet in the senders = initial window? Does the receiver assume that the sender's initial window is the same is = the initial window the receiver would use? Best regards Michael > Cheers, > Michael >=20 >=20 From pasi.sarolahti@iki.fi Fri Nov 2 01:31:37 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DEF21F998D for ; Fri, 2 Nov 2012 01:31:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcgjSdbPqiZ0 for ; Fri, 2 Nov 2012 01:31:37 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id A556221F9985 for ; Fri, 2 Nov 2012 01:31:35 -0700 (PDT) Received: from [192.168.251.149] (83.150.112.184) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508714160021D43C; Fri, 2 Nov 2012 10:31:32 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <12426_1351804225_5092E541_12426_876_1_E1C8AE27-E4CC-46D8-B1EB-2BD866437061@lurchi.franken.de> Date: Fri, 2 Nov 2012 10:31:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B60FA7F-E937-4391-985F-F621B70B1CF5@iki.fi> References: <20120710151352.A743D22F931F@lawyers.icir.org> <7CB75818-5C61-49DA-9729-741AA7DA7078@ifi.uio.no> <12426_1351804225_5092E541_12426_876_1_E1C8AE27-E4CC-46D8-B1EB-2BD866437061@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1283) Cc: tcpm , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Fri, 02 Nov 2012 08:31:37 -0000 On Nov 1, 2012, at 11:10 PM, Michael Tuexen wrote: >>>> In the experiments 30 packets are transmitted in total. At first = there is a very low initial delay, but from packet 11 and onward the = bandwidth is restricted so that the spacing between packets become 200 = ms. Given an initial window of 10 and that Linux ACKs each packet in the = initial window the scenario creates a burst transmission of 20 packets = as suggested in Yuchung's >>> Just curios: How does the receiver know what the sender uses as its = initial window? >>=20 >> RTO Restart is a sender-side only change. Neither this draft nor the = scenario that Yuchung described (his concern that we're trying to = address here) requires the receiver to know the sender's IW. >> If you're wondering where the bandwidth restriction from packet 11 = and onward comes from: we made this, artificially, to recreate the = scenario of Yuchung's concern. > I was wondering how the receiver can ack each packet in the senders = initial window? > Does the receiver assume that the sender's initial window is the same = is the initial > window the receiver would use? I believe this refers to the quick ack mechanism Linux applies in the = beginning of connection. If I recall it right, the number of packets to = quick-ack was some fraction of the initial receiver window. - Pasi From Michael.Tuexen@lurchi.franken.de Fri Nov 2 02:23:04 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1F621F999E for ; Fri, 2 Nov 2012 02:23: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo+Im0WiGgBb for ; Fri, 2 Nov 2012 02:23:03 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 6E78921F95DD for ; Fri, 2 Nov 2012 02:23:03 -0700 (PDT) Received: from [10.53.145.86] (unknown [80.187.201.11]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 783621C0C069E; Fri, 2 Nov 2012 10:23:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <3B60FA7F-E937-4391-985F-F621B70B1CF5@iki.fi> Date: Fri, 2 Nov 2012 10:22:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B2AF49C-C7A9-4885-AE36-EA84D20EF080@lurchi.franken.de> References: <20120710151352.A743D22F931F@lawyers.icir.org> <7CB75818-5C61-49DA-9729-741AA7DA7078@ifi.uio.no> <12426_1351804225_5092E541_12426_876_1_E1C8AE27-E4CC-46D8-B1EB-2BD866437061@lurchi.franken.de> <3B60FA7F-E937-4391-985F-F621B70B1CF5@iki.fi> To: Pasi Sarolahti X-Mailer: Apple Mail (2.1283) Cc: tcpm , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Fri, 02 Nov 2012 09:23:04 -0000 On Nov 2, 2012, at 9:31 AM, Pasi Sarolahti wrote: > On Nov 1, 2012, at 11:10 PM, Michael Tuexen wrote: >=20 >>>>> In the experiments 30 packets are transmitted in total. At first = there is a very low initial delay, but from packet 11 and onward the = bandwidth is restricted so that the spacing between packets become 200 = ms. Given an initial window of 10 and that Linux ACKs each packet in the = initial window the scenario creates a burst transmission of 20 packets = as suggested in Yuchung's >>>> Just curios: How does the receiver know what the sender uses as its = initial window? >>>=20 >>> RTO Restart is a sender-side only change. Neither this draft nor the = scenario that Yuchung described (his concern that we're trying to = address here) requires the receiver to know the sender's IW. >>> If you're wondering where the bandwidth restriction from packet 11 = and onward comes from: we made this, artificially, to recreate the = scenario of Yuchung's concern. >> I was wondering how the receiver can ack each packet in the senders = initial window? >> Does the receiver assume that the sender's initial window is the same = is the initial >> window the receiver would use? >=20 > I believe this refers to the quick ack mechanism Linux applies in the = beginning of connection. If I recall it right, the number of packets to = quick-ack was some fraction of the initial receiver window. Ahh, I see. Thanks for the clarification. This is something Linux = specific, right? Best regards Michael >=20 > - Pasi >=20 >=20 From pasi.sarolahti@iki.fi Fri Nov 2 03:18:19 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5986921F872D for ; Fri, 2 Nov 2012 03:18:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 770y4009OnWH for ; Fri, 2 Nov 2012 03:18:18 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 896EE21F8724 for ; Fri, 2 Nov 2012 03:18:18 -0700 (PDT) Received: from pc122.netlab.hut.fi (130.233.154.122) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087141600223A4E; Fri, 2 Nov 2012 12:18:04 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Pasi Sarolahti In-Reply-To: <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> Date: Fri, 2 Nov 2012 12:18:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> References: <20120710151352.A743D22F931F@lawyers.icir.org> <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> To: Per Hurtig X-Mailer: Apple Mail (2.1283) Cc: tcpm , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Fri, 02 Nov 2012 10:18:19 -0000 On Nov 1, 2012, at 10:18 PM, Per Hurtig wrote: > In the experiments 30 packets are transmitted in total. At first there = is a very low initial delay, but from packet 11 and onward the bandwidth = is restricted so that the spacing between packets become 200 ms. Given = an initial window of 10 and that Linux ACKs each packet in the initial = window the scenario creates a burst transmission of 20 packets as = suggested in Yuchung's example. In our experiments we see the "balloon = effect" that Mark predicted very clearly (the RTO becomes extremely = inflated due to the variation). There is no risk that the modified RTO = approach causes spurious retransmissions. An additional complication is that not all RTO implementations are = similar. The risk of spurious RTO depends on minimum RTO and the development of = the variance component in the RTO computation. With RFC 6298 - compliant = implementation the minimum RTO is 1 second, so I wouldn't be so worried = about spurious timeouts, because the RTTs are typically much smaller. On = the other hand, the relative benefit of rtorestart might also be more = modest then. But there are implementations (such as Linux) with smaller minimum RTO = and possibly some other tweaks on the RTO computation algorithm. It is = harder to see how different scenarios play out in such cases, for = example after a longer period of steady RTTs followed by a tiny delay = spike. Perhaps the draft should discuss the factors affecting the likelihood of = spurious timeouts in different implementations. A strawman mitigation = that comes to mind could be to ensure that the variance component also = has a reasonable minimum bound, if a non-RFC 6298 compliant = implementation with RTO less than one second is used together with = rtorestart. (There is 'G' in RFC 6298, but clock granularity can also be = quite fine in some systems) - Pasi From nishida@sfc.wide.ad.jp Fri Nov 2 03:21:47 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AA221F99DE for ; Fri, 2 Nov 2012 03:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.373 X-Spam-Level: X-Spam-Status: No, score=-98.373 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8sHLbDqx8tG for ; Fri, 2 Nov 2012 03:21:46 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 91E8421F8746 for ; Fri, 2 Nov 2012 03:21:46 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6A1332780DD for ; Fri, 2 Nov 2012 19:21:32 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id b11so2705586lam.31 for ; Fri, 02 Nov 2012 03:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.37.41 with SMTP id v9mr548369lbj.97.1351851689027; Fri, 02 Nov 2012 03:21:29 -0700 (PDT) Received: by 10.112.103.193 with HTTP; Fri, 2 Nov 2012 03:21:29 -0700 (PDT) Date: Fri, 2 Nov 2012 03:21:29 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: multipart/alternative; boundary=e0cb4efe322ab6a7f004cd807f49 Subject: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:21:47 -0000 --e0cb4efe322ab6a7f004cd807f49 Content-Type: text/plain; charset=ISO-8859-1 Hello, I'm reading the draft and I still need more time to think about this, but I have one question to proceed.. It seems to me that TLP requires FACK-based recovery logic. if RFC6675 is used instead, I'm guessing TLP probably won't be so useful since it cannot recover all lost packets in some situations. AFAIK we don't have a concrete specification for FACK. Hence, I have a little concern that we cannot think about detailed corner cases for this approach. Any thoughts on this? Thanks, -- Yoshifumi Nishida --e0cb4efe322ab6a7f004cd807f49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I'm reading the draft and I still need more time to think= about this, but I have one question to proceed..

It seems to me tha= t TLP requires FACK-based recovery logic.
if RFC6675 is used instead, I= 'm guessing TLP probably won't be so useful since it cannot recover= all lost packets in some situations.
AFAIK we don't have a concrete specification for FACK. Hence, I have a = little concern that we cannot think about detailed corner cases for this ap= proach.
Any thoughts on this?

Thanks,
--
Yoshifumi Nishid= a
--e0cb4efe322ab6a7f004cd807f49-- From michawe@ifi.uio.no Fri Nov 2 04:27:34 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5F21F99BA for ; Fri, 2 Nov 2012 04:27:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYdLY2tyx64G for ; Fri, 2 Nov 2012 04:27:33 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 19A6021F99B8 for ; Fri, 2 Nov 2012 04:27:32 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TUFPP-0006s0-9j; Fri, 02 Nov 2012 12:27:31 +0100 Received: from [12.231.120.253] (helo=[10.19.40.27]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TUFPO-0002jG-D5; Fri, 02 Nov 2012 12:27:31 +0100 Message-Id: <4790AE07-46C0-4974-BEBA-EB07FDA59F31@ifi.uio.no> From: Michael Welzl To: Pasi Sarolahti In-Reply-To: <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Nov 2012 12:27:26 +0100 References: <20120710151352.A743D22F931F@lawyers.icir.org> <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 11 sum msgs/h 4 total rcpts 25219 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8AAFD77441C03F3CFF9BCBBF21DB8F5082D500A2 X-UiO-SPAM-Test: remote_host: 12.231.120.253 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 44 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Fri, 02 Nov 2012 11:27:34 -0000 On Nov 2, 2012, at 11:18 AM, Pasi Sarolahti wrote: > > On Nov 1, 2012, at 10:18 PM, Per Hurtig wrote: > >> In the experiments 30 packets are transmitted in total. At first >> there is a very low initial delay, but from packet 11 and onward >> the bandwidth is restricted so that the spacing between packets >> become 200 ms. Given an initial window of 10 and that Linux ACKs >> each packet in the initial window the scenario creates a burst >> transmission of 20 packets as suggested in Yuchung's example. In >> our experiments we see the "balloon effect" that Mark predicted >> very clearly (the RTO becomes extremely inflated due to the >> variation). There is no risk that the modified RTO approach causes >> spurious retransmissions. > > An additional complication is that not all RTO implementations are > similar. > > The risk of spurious RTO depends on minimum RTO and the development > of the variance component in the RTO computation. With RFC 6298 - > compliant implementation the minimum RTO is 1 second, so I wouldn't > be so worried about spurious timeouts, because the RTTs are > typically much smaller. On the other hand, the relative benefit of > rtorestart might also be more modest then. > > But there are implementations (such as Linux) with smaller minimum > RTO and possibly some other tweaks on the RTO computation algorithm. > It is harder to see how different scenarios play out in such cases, > for example after a longer period of steady RTTs followed by a tiny > delay spike. > > Perhaps the draft should discuss the factors affecting the > likelihood of spurious timeouts in different implementations. A > strawman mitigation that comes to mind could be to ensure that the > variance component also has a reasonable minimum bound, if a non-RFC > 6298 compliant implementation with RTO less than one second is used > together with rtorestart. (There is 'G' in RFC 6298, but clock > granularity can also be quite fine in some systems) I see your point; that can be done. Note however this paragraph from Per's email, which describes a further limitation of the possible effect of spurious timeouts: ** Furthermore, possible problems in burst scenarios are quite unlikely, as spurious retransmissions would only affect the transmission if a new large burst of data is to be sent after the RTO timer spuriously expires (otherwise the spurious retransmission is just a wasted packet in the end of a short flow), but before an RTO worth of time has elapsed (otherwise cwnd is reset to the restart window). ** To give an example: The TCP sender transmits 10 packets in one go, transmitted at times t1, t2, t3... t10, and then stops because the application doesn't have any more data to send. As per RFC 5681, cwnd SHOULD be set to RW after t10+RTO (or even less if congestion is detected). To avoid that this happens, the application has to start sending again before t10+RTO. The earliest spurious RTO that could occur because of our draft is the RTO for packet 8 which was transmitted at t8. As a result, a spurious timeout from our draft would only have an effect if the application sends data again within the time window [t8+RTO, t10+RTO] Scenarios can probably be constructed where this can play out worse, but it's an additional limitation worth noting, I think, on top of what we're discussing above. Cheers, Michael From pasi.sarolahti@iki.fi Fri Nov 2 05:32:34 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44D021F8958 for ; Fri, 2 Nov 2012 05:32:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-qHP9lfKJ31 for ; Fri, 2 Nov 2012 05:32:34 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 187EB21F867B for ; Fri, 2 Nov 2012 05:32:32 -0700 (PDT) Received: from pc122.netlab.hut.fi (130.233.154.122) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508714160022B3E8; Fri, 2 Nov 2012 14:32:19 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <4790AE07-46C0-4974-BEBA-EB07FDA59F31@ifi.uio.no> Date: Fri, 2 Nov 2012 14:32:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120710151352.A743D22F931F@lawyers.icir.org> <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> <4790AE07-46C0-4974-BEBA-EB07FDA59F31@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1283) Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Fri, 02 Nov 2012 12:32:35 -0000 On Nov 2, 2012, at 1:27 PM, Michael Welzl wrote: > To give an example: > The TCP sender transmits 10 packets in one go, transmitted at times = t1, t2, t3... t10, and then stops because the application doesn't have = any more data to send. As per RFC 5681, cwnd SHOULD be set to RW after = t10+RTO (or even less if congestion is detected). To avoid that this = happens, the application has to start sending again before t10+RTO. The = earliest spurious RTO that could occur because of our draft is the RTO = for packet 8 which was transmitted at t8. As a result, a spurious = timeout from our draft would only have an effect if the application = sends data again within the time window [t8+RTO, t10+RTO] I guess the hypothetical problem cases are such where the computed RTO = is close to RTT, and for that reason the timer would be at some sort of = risk of expiring spuriously even without RTO-restart. Then RTO-restart = adds to this risk by some factor, that probably depends on the bandwidth = and delay characteristics on the path. I wonder if it was possible to give a rough guideline on when = RTO-restart is at spurious timeout risk zone, without taking position on = how likely or unlikely that might be. When RTO < 2*RTT, perhaps? - Pasi From nanditad@google.com Fri Nov 2 07:03:26 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540E921F8889 for ; Fri, 2 Nov 2012 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2zCrNo7yZ5M for ; Fri, 2 Nov 2012 07:03:25 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2A0C21F858B for ; Fri, 2 Nov 2012 07:03:25 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3957335oag.31 for ; Fri, 02 Nov 2012 07:03:25 -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:x-system-of-record; bh=qNldpKGj3j/ybB6ii97HMH/2iWhCs9mOoqnSHLIyMSE=; b=VmPEbQMepRox3fqNOcQ9M5RyotaVbAqhLA60FUl0ywUEsrCN7xTvIraX1KG9wudIg7 iLhYAc9RAwAFR1rILHyTbeEcVTvoiLczmMFVLXzCOMDE8VVxa3CWuMa5MjC4QfE/UdgC Di1x5kQ6mP5tgFYSK5TZL2C12Tt8vkA8w850d5qt5nkP9KQmer0+/kPbAJqCnw/CL/O/ BhAyHmi+TQkQ71A5Y1eDA2yuMcNB+9saKI5Zcbv3zb2gdSuD6wIqO3pTVh76Pk69fqX4 N/KXt4IQ9t7n6HjmdoZwfj6Wt5I9BJbdWNH4UXv9+wkmEJddHaFym917Otm/B2ogKllX 3+3w== 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-system-of-record:x-gm-message-state; bh=qNldpKGj3j/ybB6ii97HMH/2iWhCs9mOoqnSHLIyMSE=; b=N4vgd+WtfZAZkR53WJT+HGrR20kh/HztCrkm5Emw6DQ5IYHnpD5bAibLvcjmOSwtjR 12MinuvyXek/zME1wRQaedxeG3tmJjLV19Uu2/ui4cR3nMHyfjkotwtvo9nfwldp0gW8 4wwvOpP2iaxKHm4ZixCyBfhrX7FDYOGSIEvI9Fqv4Jmxz3m13c9l5wpsZMERQwUik4dy G7D7FqFQpTVQvhwnGk5Ae9VdlAyS7D7MFLYR7bRRkjDYmjxorbbqGNY+zqgrgJhcuN2K /2/Lvn1xVBOuZNrvbsVhsKE3534El3Pu7C5n5f1MtBm9Zt99jU4DFpGVx8D0vqfjg1XK GTWg== MIME-Version: 1.0 Received: by 10.182.146.46 with SMTP id sz14mr1374119obb.76.1351865004902; Fri, 02 Nov 2012 07:03:24 -0700 (PDT) Received: by 10.182.40.234 with HTTP; Fri, 2 Nov 2012 07:03:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Nov 2012 19:33:24 +0530 Message-ID: From: Nandita Dukkipati To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkavtybJHQ+oaI5VijUIYX5GYotCG/iDTniyl7vzz4v+d7AF4rrBJ6hCixObh0YXYeFosi0K5/g3ntWhTYBKrKrxO+CCpTs8jlx9tXrOJ3MWabFpTJ9qfTXeAjXh28UCpdp/UZ/DoUce0qeQAamQbat9DpgbcdxbH1TvSGSjgt4Mm5lmqTTBRVaWhQ6c12+R0nV9ZJT Cc: "tcpm@ietf.org" Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:03:26 -0000 You are right that TLP as specified requires FACK based recovery. FACK is actually one of the most effective algorithms for loss recovery in our experiments and it's worthwhile having (reviving?) a concrete specification for FACK. Are there particular corner cases that you are concerned about? Nandita On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida wrote: > Hello, > > I'm reading the draft and I still need more time to think about this, but I > have one question to proceed.. > > It seems to me that TLP requires FACK-based recovery logic. > if RFC6675 is used instead, I'm guessing TLP probably won't be so useful > since it cannot recover all lost packets in some situations. > AFAIK we don't have a concrete specification for FACK. Hence, I have a > little concern that we cannot think about detailed corner cases for this > approach. > Any thoughts on this? > > Thanks, > -- > Yoshifumi Nishida > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From prvs=0653d0b073=Anna.Brunstrom@kau.se Fri Nov 2 08:41:10 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AD11F0C42 for ; Fri, 2 Nov 2012 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an3NcQ72jaYV for ; Fri, 2 Nov 2012 08:41:09 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) by ietfa.amsl.com (Postfix) with ESMTP id 44F811F0C3A for ; Fri, 2 Nov 2012 08:41:09 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 02 Nov 2012 16:40:49 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 127.0.0.1 X-Return-Path: Anna.Brunstrom@kau.se X-Envelope-From: Anna.Brunstrom@kau.se Date: Fri, 02 Nov 2012 16:40:45 +0100 From: "Anna =?iso-8859-1?Q?Brunstr=F6m?=" To: "Pasi Sarolahti" , "Michael Welzl" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: WorldClient 13.0.2 In-Reply-To: References: <20120710151352.A743D22F931F@lawyers.icir.org> <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> <4790AE07-46C0-4974-BEBA-EB07FDA59F31@ifi.uio.no> Cc: tcpm , mallman@icir.org Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Fri, 02 Nov 2012 15:41:10 -0000 -----Original Message----- From: Pasi Sarolahti To: Michael Welzl Cc: tcpm , "mallman@icir.org" Date: Fri, 2 Nov 2012 14:32:19 +0200 Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-02.txt > On Nov 2, 2012, at 1:27 PM, Michael Welzl wrote: > > > To give an example: > > The TCP sender transmits 10 packets in one go, transmitted at times > t1, t2, t3... t10, and then stops because the application doesn't have > any more data to send. As per RFC 5681, cwnd SHOULD be set to RW after > t10+RTO (or even less if congestion is detected). To avoid that this > happens, the application has to start sending again before t10+RTO. The > earliest spurious RTO that could occur because of our draft is the RTO > for packet 8 which was transmitted at t8. As a result, a spurious > timeout from our draft would only have an effect if the application > sends data again within the time window [t8+RTO, t10+RTO] > > I guess the hypothetical problem cases are such where the computed RTO > is close to RTT, and for that reason the timer would be at some sort of > risk of expiring spuriously even without RTO-restart. Then RTO-restart > adds to this risk by some factor, that probably depends on the > bandwidth and delay characteristics on the path. The problem cases should indeed be very similar. If a new burst is transmitted in Michael's example above, packet 11 will have the same RTO as packet 8 (assuming the RTO itself has not changed). So in cases where spurious retransmissions cause problems, any mitigations should be useful also when you do not use RTO-restart. BR, Anna From ycheng@google.com Fri Nov 2 10:12:23 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCFF11E80D1 for ; Fri, 2 Nov 2012 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4vRfHvMAAk9 for ; Fri, 2 Nov 2012 10:12:22 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B309211E80CC for ; Fri, 2 Nov 2012 10:12:22 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so4157312oag.31 for ; Fri, 02 Nov 2012 10:12:22 -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:x-system-of-record; bh=22cQ51Qp/XFPUv5ry5xJFSfIYTQPa9wdDOW8Hf4+YQA=; b=XgZBYxUyO6nN6jDu+pipx9J1SJENoMnusaUST6PfB4nQWEqqlZa1iLZiB+tOXNP1Di ng2dcqvMede6mnmv9NAQCcfUDxZ/lWwNb/PL1BNtpdyUYzv0FrJz8codCgw8Gw7z54sR 8RTfLufrIURa0EIFZCOPIQaTrS0pHsG0L3VDva+3XmvhTTznmNhm3nqShCFa26Lmxg4S BUaKnAVLscnL30HK2tD/Y9CbfMPaW+klhhfneCJk4OPNRDO6J03J6fUIJWo9Kzr1G9ft +ZW98nh2RIJak0HzpR0NqdLaUrnuaLJ69PPU7LZRUhG0z3oKjZyhaMHpGY1GpQ2YiZ4U TYng== 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-system-of-record:x-gm-message-state; bh=22cQ51Qp/XFPUv5ry5xJFSfIYTQPa9wdDOW8Hf4+YQA=; b=hRUb9TORLDmOioILsjuq47RdmeCOGPTEbPQSE+G/GPTNZrPguKwyUMbXS3fWzHdYdQ o6amguj4Pi5wkmZa+d1IVtf9Gtje9qSN9EMH4nl9+yHVv28AH1MZtJou4xSiYtfe0TcR HIdOfoRjfbKOY/tTaK8zCdStndA1yAf+wQ0trwWYOVzYxMdQ5qmI9VBOBQfJIqeHIOBe t9zmFLoxdT4HDvzWAJUYAjLHZ+QPfAp4Tz92V1k5b5Io6XDmj9sd58ui7BhsfQ3DazGN 96UofMGq0tsETrojpYkgY0s7A7V6TW27uoHDq+EYkfCMmVit5TvZGhVJmm/fHLwzu3So 3lYQ== Received: by 10.60.18.110 with SMTP id v14mr1826555oed.135.1351876342220; Fri, 02 Nov 2012 10:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.41 with HTTP; Fri, 2 Nov 2012 10:12:00 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Fri, 2 Nov 2012 10:12:00 -0700 Message-ID: To: Nandita Dukkipati Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk9nNq83/+d1Yiip4FXYPNzileyUqBIpifE5tAX+gcnkO8rujQezK7JlAS99RwflKAzzOI4Az5F9sTTEebs8wCtF5v6eG4Q1y+zUTnb9V3KTIraBeAkAIeG/AIvL/Mrrshc69wxNtxwVathAXjFgXGMC8umCqWwEDBdDeumru4oSZTMQiBQ0GZ3yrngZ4v+A8FpTF+H Cc: "tcpm@ietf.org" Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:12:23 -0000 On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkipati wrote: > You are right that TLP as specified requires FACK based recovery. FACK > is actually one of the most effective algorithms for loss recovery in > our experiments and it's worthwhile having (reviving?) a concrete +1 on reviving FACK loss detection algorithm in "M. Mathis, J. Mahdavi, "Forward Acknowledgement: Refining TCP Congestion Control," SIGCOMM 96, August 1996": trigger FR if the highest sack sequence > dupthresh. It's not very complicated and can be a revision to RFC6675? The sender can fall back to current scheme if it detects high reordering based on (D)SACK or TS. Linux by default uses this strategy (since 2006?) but supports RFC6675 as an option. I experimented both on Google web servers and FACK recovery is about 10% faster for connection experiencing losses. But Matt Mathis is not too interested in on reviving ancient proposals... > specification for FACK. Are there particular corner cases that you are > concerned about? > > Nandita > > On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida > wrote: >> Hello, >> >> I'm reading the draft and I still need more time to think about this, but I >> have one question to proceed.. >> >> It seems to me that TLP requires FACK-based recovery logic. >> if RFC6675 is used instead, I'm guessing TLP probably won't be so useful >> since it cannot recover all lost packets in some situations. >> AFAIK we don't have a concrete specification for FACK. Hence, I have a >> little concern that we cannot think about detailed corner cases for this >> approach. >> Any thoughts on this? >> >> Thanks, >> -- >> Yoshifumi Nishida >> >> _______________________________________________ >> 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 nishida@sfc.wide.ad.jp Fri Nov 2 10:58:16 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8411F0C60 for ; Fri, 2 Nov 2012 10:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.398 X-Spam-Level: X-Spam-Status: No, score=-98.398 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIszJpvZBNOG for ; Fri, 2 Nov 2012 10:58:15 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 69E9D1F0C44 for ; Fri, 2 Nov 2012 10:58:10 -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 B60FD2780D7 for ; Sat, 3 Nov 2012 02:58:02 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id k13so3041192lbo.31 for ; Fri, 02 Nov 2012 10:58:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.105.68 with SMTP id gk4mr2296173lab.48.1351879080242; Fri, 02 Nov 2012 10:58:00 -0700 (PDT) Received: by 10.112.103.193 with HTTP; Fri, 2 Nov 2012 10:58:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Nov 2012 10:58:00 -0700 Message-ID: From: Yoshifumi Nishida To: Nandita Dukkipati Content-Type: multipart/alternative; boundary=f46d040714af5b6f0904cd86e0c9 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:58:16 -0000 --f46d040714af5b6f0904cd86e0c9 Content-Type: text/plain; charset=ISO-8859-1 Hi Nandita, I don't have specific scenarios in my mind yet. But, I personally would like to support the idea for having a spec of FACK. I think FACK is a worthy idea for the efforts and we can eliminate some ambiguity from the TLP draft. On the other hand, I have another comment on the draft. I'm assuming the draft is focusing on "probing" rather than "recovering". So, I'm wondering that even retransmitting small bytes (e.g. 1 byte) can be useful for this purpose, although I might miss something. One tricky thing in TLP is you need to identify if packet loss is recovered by only TLP. But, I guess there will be false positive cases in some situations. If you retransmit small amount of data, I guess we can avoid this and hence we can at least simplify the logic in the proposal. Thanks, -- Yoshifumi Nishida On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkipati wrote: > You are right that TLP as specified requires FACK based recovery. FACK > is actually one of the most effective algorithms for loss recovery in > our experiments and it's worthwhile having (reviving?) a concrete > specification for FACK. Are there particular corner cases that you are > concerned about? > > Nandita > > On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida > wrote: > > Hello, > > > > I'm reading the draft and I still need more time to think about this, > but I > > have one question to proceed.. > > > > It seems to me that TLP requires FACK-based recovery logic. > > if RFC6675 is used instead, I'm guessing TLP probably won't be so useful > > since it cannot recover all lost packets in some situations. > > AFAIK we don't have a concrete specification for FACK. Hence, I have a > > little concern that we cannot think about detailed corner cases for this > > approach. > > Any thoughts on this? > > > > Thanks, > > -- > > Yoshifumi Nishida > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > --f46d040714af5b6f0904cd86e0c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nandita,

I don't have specific scenarios in my mind yet. But,= I personally would like to support the idea for having a spec of FACK. I t= hink FACK is a worthy idea for the efforts and we can eliminate some ambigu= ity from the TLP draft.

On the other hand, I have another comment on the draft.
I'm assu= ming the draft is focusing on "probing" rather than "recover= ing".
So, I'm wondering that even retransmitting small bytes (e= .g. 1 byte) can be useful for this purpose, although I might miss something= .

One tricky thing in TLP is you need to identify if packet loss is recov= ered by only TLP. But, I guess there will be false positive cases in some s= ituations. If you retransmit small amount of data, I guess we can avoid thi= s and hence we can at least simplify the logic in the proposal.

Thanks,
--
Yoshifumi Nishida
=A0


On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkipati <nanditad@g= oogle.com> wrote:
You are right that TLP as specified requires= FACK based recovery. FACK
is actually one of the most effective algorithms for loss recovery in
our experiments and it's worthwhile having (reviving?) a concrete
specification for FACK. Are there particular corner cases that you are
concerned about?

Nandita

On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida
<nishida@sfc.wide.ad.jp>= ; wrote:
> Hello,
>
> I'm reading the draft and I still need more time to think about th= is, but I
> have one question to proceed..
>
> It seems to me that TLP requires FACK-based recovery logic.
> if RFC6675 is used instead, I'm guessing TLP probably won't be= so useful
> since it cannot recover all lost packets in some situations.
> AFAIK we don't have a concrete specification for FACK. Hence, I ha= ve a
> little concern that we cannot think about detailed corner cases for th= is
> approach.
> Any thoughts on this?
>
> Thanks,
> --
> Yoshifumi Nishida
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--f46d040714af5b6f0904cd86e0c9-- From rs@netapp.com Sat Nov 3 04:16:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B756F21F9C51 for ; Sat, 3 Nov 2012 04:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1ejai5ad9JO for ; Sat, 3 Nov 2012 04:16:02 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7321F9C48 for ; Sat, 3 Nov 2012 04:16:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,705,1344236400"; d="scan'208,217";a="222830124" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 03 Nov 2012 04:16:00 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qA3BFx2f022056; Sat, 3 Nov 2012 04:15:59 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.165]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 04:15:58 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 Thread-Index: AQHNuOPqBSXu52Pc8k6FEUHAnfX8SpfXCTYAgABBjACAARSAAA== Date: Sat, 3 Nov 2012 11:15:58 +0000 Message-ID: <07586C31-CBA1-4C32-BCB9-A7BB06362A10@netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_07586C31CBA14C32BCB9A7BB06362A10netappcom_" MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 11:16:02 -0000 --_000_07586C31CBA14C32BCB9A7BB06362A10netappcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGlmdW1pLA0KDQpJIGFncmVlIHRoYXQgd2l0aG91dCB1c2luZyBUUyBvciBTQUNLLCBw cm9iYWJseSB0aGUgb25seSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGluIHNvbWUgY2Fz ZXMgYmV0d2VlbiB0aGUgZGVsYXllZCBvcmlnaW5hbCBhbmQgdGhlIHRscCBwYWNrZXQgd291bGQg YmUgdG8gbW9kaWZ5IHRoZSBzaXplIG9mIHRoZSBUTFAuDQoNCkhvd2V2ZXIsIGkgd29uZGVyIGlm IHRoYXQgY29tcGxleGl0eSBpcyByZWFsbHkgd29ydGh3aGlsZS4gSXQgd291bGQgYmUgbXVjaCBl YXNpZXIgYW5kIGVmZmljaWVudCB0byBlbmFibGUgVFMgYW5kIFNBQ0sgb24gbGlua3MgcHJvbmUg dG8gdGFpbCBkcm9wcyBhbmQgcmVvcmRlcmluZyAtIGFuZCBub3Qgb25seSBmb3IgYSBxdWlja2Vy IHRhaWwgbG9zcyByZWNvdmVyeS4uLg0KDQpCZXN0IHJlZ2FyZHMsDQogICBSaWNoYXJkDQoNClZv biBtZWluZW0gaVBob25lIGdlc2VuZGV0DQoNCkFtIDAyLjExLjIwMTIgdW0gMTM6NTggc2Nocmll YiAiWW9zaGlmdW1pIE5pc2hpZGEiIDxuaXNoaWRhQHNmYy53aWRlLmFkLmpwPG1haWx0bzpuaXNo aWRhQHNmYy53aWRlLmFkLmpwPj46DQoNCkhpIE5hbmRpdGEsDQoNCkkgZG9uJ3QgaGF2ZSBzcGVj aWZpYyBzY2VuYXJpb3MgaW4gbXkgbWluZCB5ZXQuIEJ1dCwgSSBwZXJzb25hbGx5IHdvdWxkIGxp a2UgdG8gc3VwcG9ydCB0aGUgaWRlYSBmb3IgaGF2aW5nIGEgc3BlYyBvZiBGQUNLLiBJIHRoaW5r IEZBQ0sgaXMgYSB3b3J0aHkgaWRlYSBmb3IgdGhlIGVmZm9ydHMgYW5kIHdlIGNhbiBlbGltaW5h dGUgc29tZSBhbWJpZ3VpdHkgZnJvbSB0aGUgVExQIGRyYWZ0Lg0KDQpPbiB0aGUgb3RoZXIgaGFu ZCwgSSBoYXZlIGFub3RoZXIgY29tbWVudCBvbiB0aGUgZHJhZnQuDQpJJ20gYXNzdW1pbmcgdGhl IGRyYWZ0IGlzIGZvY3VzaW5nIG9uICJwcm9iaW5nIiByYXRoZXIgdGhhbiAicmVjb3ZlcmluZyIu DQpTbywgSSdtIHdvbmRlcmluZyB0aGF0IGV2ZW4gcmV0cmFuc21pdHRpbmcgc21hbGwgYnl0ZXMg KGUuZy4gMSBieXRlKSBjYW4gYmUgdXNlZnVsIGZvciB0aGlzIHB1cnBvc2UsIGFsdGhvdWdoIEkg bWlnaHQgbWlzcyBzb21ldGhpbmcuDQoNCk9uZSB0cmlja3kgdGhpbmcgaW4gVExQIGlzIHlvdSBu ZWVkIHRvIGlkZW50aWZ5IGlmIHBhY2tldCBsb3NzIGlzIHJlY292ZXJlZCBieSBvbmx5IFRMUC4g QnV0LCBJIGd1ZXNzIHRoZXJlIHdpbGwgYmUgZmFsc2UgcG9zaXRpdmUgY2FzZXMgaW4gc29tZSBz aXR1YXRpb25zLiBJZiB5b3UgcmV0cmFuc21pdCBzbWFsbCBhbW91bnQgb2YgZGF0YSwgSSBndWVz cyB3ZSBjYW4gYXZvaWQgdGhpcyBhbmQgaGVuY2Ugd2UgY2FuIGF0IGxlYXN0IHNpbXBsaWZ5IHRo ZSBsb2dpYyBpbiB0aGUgcHJvcG9zYWwuDQoNClRoYW5rcywNCi0tDQpZb3NoaWZ1bWkgTmlzaGlk YQ0KDQoNCg0KT24gRnJpLCBOb3YgMiwgMjAxMiBhdCA3OjAzIEFNLCBOYW5kaXRhIER1a2tpcGF0 aSA8bmFuZGl0YWRAZ29vZ2xlLmNvbTxtYWlsdG86bmFuZGl0YWRAZ29vZ2xlLmNvbT4+IHdyb3Rl Og0KWW91IGFyZSByaWdodCB0aGF0IFRMUCBhcyBzcGVjaWZpZWQgcmVxdWlyZXMgRkFDSyBiYXNl ZCByZWNvdmVyeS4gRkFDSw0KaXMgYWN0dWFsbHkgb25lIG9mIHRoZSBtb3N0IGVmZmVjdGl2ZSBh bGdvcml0aG1zIGZvciBsb3NzIHJlY292ZXJ5IGluDQpvdXIgZXhwZXJpbWVudHMgYW5kIGl0J3Mg d29ydGh3aGlsZSBoYXZpbmcgKHJldml2aW5nPykgYSBjb25jcmV0ZQ0Kc3BlY2lmaWNhdGlvbiBm b3IgRkFDSy4gQXJlIHRoZXJlIHBhcnRpY3VsYXIgY29ybmVyIGNhc2VzIHRoYXQgeW91IGFyZQ0K Y29uY2VybmVkIGFib3V0Pw0KDQpOYW5kaXRhDQoNCk9uIEZyaSwgTm92IDIsIDIwMTIgYXQgMzo1 MSBQTSwgWW9zaGlmdW1pIE5pc2hpZGENCjxuaXNoaWRhQHNmYy53aWRlLmFkLmpwPG1haWx0bzpu aXNoaWRhQHNmYy53aWRlLmFkLmpwPj4gd3JvdGU6DQo+IEhlbGxvLA0KPg0KPiBJJ20gcmVhZGlu ZyB0aGUgZHJhZnQgYW5kIEkgc3RpbGwgbmVlZCBtb3JlIHRpbWUgdG8gdGhpbmsgYWJvdXQgdGhp cywgYnV0IEkNCj4gaGF2ZSBvbmUgcXVlc3Rpb24gdG8gcHJvY2VlZC4uDQo+DQo+IEl0IHNlZW1z IHRvIG1lIHRoYXQgVExQIHJlcXVpcmVzIEZBQ0stYmFzZWQgcmVjb3ZlcnkgbG9naWMuDQo+IGlm IFJGQzY2NzUgaXMgdXNlZCBpbnN0ZWFkLCBJJ20gZ3Vlc3NpbmcgVExQIHByb2JhYmx5IHdvbid0 IGJlIHNvIHVzZWZ1bA0KPiBzaW5jZSBpdCBjYW5ub3QgcmVjb3ZlciBhbGwgbG9zdCBwYWNrZXRz IGluIHNvbWUgc2l0dWF0aW9ucy4NCj4gQUZBSUsgd2UgZG9uJ3QgaGF2ZSBhIGNvbmNyZXRlIHNw ZWNpZmljYXRpb24gZm9yIEZBQ0suIEhlbmNlLCBJIGhhdmUgYQ0KPiBsaXR0bGUgY29uY2VybiB0 aGF0IHdlIGNhbm5vdCB0aGluayBhYm91dCBkZXRhaWxlZCBjb3JuZXIgY2FzZXMgZm9yIHRoaXMN Cj4gYXBwcm9hY2guDQo+IEFueSB0aG91Z2h0cyBvbiB0aGlzPw0KPg0KPiBUaGFua3MsDQo+IC0t DQo+IFlvc2hpZnVtaSBOaXNoaWRhDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmc8 bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbQ0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg== --_000_07586C31CBA14C32BCB9A7BB06362A10netappcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiPg0KPGRpdj5IaSBZb3NoaWZ1bWksPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J IGFncmVlIHRoYXQgd2l0aG91dCB1c2luZyBUUyBvciBTQUNLLCBwcm9iYWJseSB0aGUgb25seSB3 YXkgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGluIHNvbWUgY2FzZXMgYmV0d2VlbiB0aGUgZGVs YXllZCBvcmlnaW5hbCBhbmQgdGhlIHRscCBwYWNrZXQgd291bGQgYmUgdG8gbW9kaWZ5IHRoZSBz aXplIG9mIHRoZSBUTFAuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ib3dldmVyLCBp IHdvbmRlciBpZiB0aGF0IGNvbXBsZXhpdHkgaXMgcmVhbGx5IHdvcnRod2hpbGUuIEl0IHdvdWxk IGJlIG11Y2ggZWFzaWVyIGFuZCBlZmZpY2llbnQgdG8gZW5hYmxlIFRTIGFuZCBTQUNLIG9uIGxp bmtzIHByb25lIHRvIHRhaWwgZHJvcHMgYW5kIHJlb3JkZXJpbmcgLSBhbmQgbm90IG9ubHkgZm9y IGEgcXVpY2tlciB0YWlsIGxvc3MgcmVjb3ZlcnkuLi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO1JpY2hhcmQ8YnI+ DQo8YnI+DQpWb24gbWVpbmVtIGlQaG9uZSBnZXNlbmRldDwvZGl2Pg0KPGRpdj48YnI+DQpBbSAw Mi4xMS4yMDEyIHVtIDEzOjU4IHNjaHJpZWIgJnF1b3Q7WW9zaGlmdW1pIE5pc2hpZGEmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpuaXNoaWRhQHNmYy53aWRlLmFkLmpwIj5uaXNoaWRhQHNmYy53 aWRlLmFkLmpwPC9hPiZndDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PkhpIE5hbmRpdGEsPGJyPg0KPGJyPg0KSSBkb24ndCBo YXZlIHNwZWNpZmljIHNjZW5hcmlvcyBpbiBteSBtaW5kIHlldC4gQnV0LCBJIHBlcnNvbmFsbHkg d291bGQgbGlrZSB0byBzdXBwb3J0IHRoZSBpZGVhIGZvciBoYXZpbmcgYSBzcGVjIG9mIEZBQ0su IEkgdGhpbmsgRkFDSyBpcyBhIHdvcnRoeSBpZGVhIGZvciB0aGUgZWZmb3J0cyBhbmQgd2UgY2Fu IGVsaW1pbmF0ZSBzb21lIGFtYmlndWl0eSBmcm9tIHRoZSBUTFAgZHJhZnQuPGJyPg0KPGJyPg0K T24gdGhlIG90aGVyIGhhbmQsIEkgaGF2ZSBhbm90aGVyIGNvbW1lbnQgb24gdGhlIGRyYWZ0Ljxi cj4NCkknbSBhc3N1bWluZyB0aGUgZHJhZnQgaXMgZm9jdXNpbmcgb24gJnF1b3Q7cHJvYmluZyZx dW90OyByYXRoZXIgdGhhbiAmcXVvdDtyZWNvdmVyaW5nJnF1b3Q7Ljxicj4NClNvLCBJJ20gd29u ZGVyaW5nIHRoYXQgZXZlbiByZXRyYW5zbWl0dGluZyBzbWFsbCBieXRlcyAoZS5nLiAxIGJ5dGUp IGNhbiBiZSB1c2VmdWwgZm9yIHRoaXMgcHVycG9zZSwgYWx0aG91Z2ggSSBtaWdodCBtaXNzIHNv bWV0aGluZy48YnI+DQo8YnI+DQpPbmUgdHJpY2t5IHRoaW5nIGluIFRMUCBpcyB5b3UgbmVlZCB0 byBpZGVudGlmeSBpZiBwYWNrZXQgbG9zcyBpcyByZWNvdmVyZWQgYnkgb25seSBUTFAuIEJ1dCwg SSBndWVzcyB0aGVyZSB3aWxsIGJlIGZhbHNlIHBvc2l0aXZlIGNhc2VzIGluIHNvbWUgc2l0dWF0 aW9ucy4gSWYgeW91IHJldHJhbnNtaXQgc21hbGwgYW1vdW50IG9mIGRhdGEsIEkgZ3Vlc3Mgd2Ug Y2FuIGF2b2lkIHRoaXMgYW5kIGhlbmNlIHdlIGNhbiBhdCBsZWFzdCBzaW1wbGlmeQ0KIHRoZSBs b2dpYyBpbiB0aGUgcHJvcG9zYWwuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCi0tPGJyPg0KWW9z aGlmdW1pIE5pc2hpZGEgPGJyPg0KJm5ic3A7IDxicj4NCjxicj4NCjxicj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBGcmksIE5vdiAyLCAyMDEyIGF0IDc6MDMgQU0sIE5hbmRpdGEgRHVr a2lwYXRpIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86bmFuZGl0YWRAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5hbmRpdGFkQGdvb2dsZS5jb208L2E+Jmd0Ozwvc3Bh bj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQpZb3UgYXJlIHJpZ2h0IHRoYXQgVExQIGFzIHNwZWNpZmllZCByZXF1aXJlcyBGQUNLIGJh c2VkIHJlY292ZXJ5LiBGQUNLPGJyPg0KaXMgYWN0dWFsbHkgb25lIG9mIHRoZSBtb3N0IGVmZmVj dGl2ZSBhbGdvcml0aG1zIGZvciBsb3NzIHJlY292ZXJ5IGluPGJyPg0Kb3VyIGV4cGVyaW1lbnRz IGFuZCBpdCdzIHdvcnRod2hpbGUgaGF2aW5nIChyZXZpdmluZz8pIGEgY29uY3JldGU8YnI+DQpz cGVjaWZpY2F0aW9uIGZvciBGQUNLLiBBcmUgdGhlcmUgcGFydGljdWxhciBjb3JuZXIgY2FzZXMg dGhhdCB5b3UgYXJlPGJyPg0KY29uY2VybmVkIGFib3V0Pzxicj4NCjxicj4NCk5hbmRpdGE8YnI+ DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPjxicj4NCk9uIEZyaSwgTm92IDIsIDIwMTIgYXQgMzo1 MSBQTSwgWW9zaGlmdW1pIE5pc2hpZGE8YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm5pc2hpZGFA c2ZjLndpZGUuYWQuanAiPm5pc2hpZGFAc2ZjLndpZGUuYWQuanA8L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7IEhlbGxvLDxicj4NCiZndDs8YnI+DQomZ3Q7IEknbSByZWFkaW5nIHRoZSBkcmFmdCBh bmQgSSBzdGlsbCBuZWVkIG1vcmUgdGltZSB0byB0aGluayBhYm91dCB0aGlzLCBidXQgSTxicj4N CiZndDsgaGF2ZSBvbmUgcXVlc3Rpb24gdG8gcHJvY2VlZC4uPGJyPg0KJmd0Ozxicj4NCiZndDsg SXQgc2VlbXMgdG8gbWUgdGhhdCBUTFAgcmVxdWlyZXMgRkFDSy1iYXNlZCByZWNvdmVyeSBsb2dp Yy48YnI+DQomZ3Q7IGlmIFJGQzY2NzUgaXMgdXNlZCBpbnN0ZWFkLCBJJ20gZ3Vlc3NpbmcgVExQ IHByb2JhYmx5IHdvbid0IGJlIHNvIHVzZWZ1bDxicj4NCiZndDsgc2luY2UgaXQgY2Fubm90IHJl Y292ZXIgYWxsIGxvc3QgcGFja2V0cyBpbiBzb21lIHNpdHVhdGlvbnMuPGJyPg0KJmd0OyBBRkFJ SyB3ZSBkb24ndCBoYXZlIGEgY29uY3JldGUgc3BlY2lmaWNhdGlvbiBmb3IgRkFDSy4gSGVuY2Us IEkgaGF2ZSBhPGJyPg0KJmd0OyBsaXR0bGUgY29uY2VybiB0aGF0IHdlIGNhbm5vdCB0aGluayBh Ym91dCBkZXRhaWxlZCBjb3JuZXIgY2FzZXMgZm9yIHRoaXM8YnI+DQomZ3Q7IGFwcHJvYWNoLjxi cj4NCiZndDsgQW55IHRob3VnaHRzIG9uIHRoaXM/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtz LDxicj4NCiZndDsgLS08YnI+DQomZ3Q7IFlvc2hpZnVtaSBOaXNoaWRhPGJyPg0KJmd0Ozxicj4N CjwvZGl2Pg0KPC9kaXY+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyB0Y3BtIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJl Zj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L2E+PGJy Pg0KJmd0Ozxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+dGNw bSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0 Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_07586C31CBA14C32BCB9A7BB06362A10netappcom_-- From ycheng@google.com Sat Nov 3 15:41:42 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57521F95B8 for ; Sat, 3 Nov 2012 15:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e53X1Jsj4+Hf for ; Sat, 3 Nov 2012 15:41:41 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A246F21F9A35 for ; Sat, 3 Nov 2012 15:41:41 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4994350obq.31 for ; Sat, 03 Nov 2012 15:41:41 -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:x-system-of-record; bh=Pov02ApVB1svL+R32D5BPZUM4tqWiR5npT++o4xTiCU=; b=Jts3LdTwUQF2vDTgXVW78bL1+1DoPGnC2GjLMMCyioNbEFxcARYHhIpUAxAKUawfly Z41djQAgoyX0iG1ssEDvumk643eaMWMnWpb4M8AiAruU7iN/9EzZWaUMSK8i40mJHGGx 4Wpr9rqDnPDIMHrwYz4/qe7PfRFO7270jLC6WKm4BZvpQ356Khz9I2RfyPnZAn406ruO hzbmkQF123DpPUKja1PPiHGEXIscV7o4vQQJJM0iidXyGCYKJm4emjo4nd96Ax0BxElK rHDq7cwusw+2Ag92ddubPuM/fL1eaw0dtkOfQ5GKScrwVd9xNhgMYLUmxul+781uJgfu 6mhA== 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-system-of-record:x-gm-message-state; bh=Pov02ApVB1svL+R32D5BPZUM4tqWiR5npT++o4xTiCU=; b=Yzy1eARTvtklKaKLUaCPJcxKUm5Ij9O8nySiz/q+ICOhMpHc2vNi4n4y3pOA6H9wKD 58sScybTjkf7ckfzBtTVBJh39zPM3uhMgiOuxyQKyhUxXC9IuEHl/g5suNdfb23jdNaQ 3HPIbOxA9MNjGJj6kkSsflbECdT/BWB6n2UIv69V6CfTV+7NTS1YG9nPdAApo7AcMIKs m8VA4RQcdPb9h0UroVOU/D4zgFV0TVOrRx/Pqzu+1PCRTZLP2rDdZaRJwpOjRJ9qVIZB ZvsFvuF1OKCWnhN44P/6rOhzteJo7eWKHtAQXPvEI/f6lhrkeLgMI4UgYvKjrzwV5sm6 NKXQ== Received: by 10.60.3.69 with SMTP id a5mr4638758oea.117.1351982501017; Sat, 03 Nov 2012 15:41:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.41 with HTTP; Sat, 3 Nov 2012 15:41:20 -0700 (PDT) In-Reply-To: <07586C31-CBA1-4C32-BCB9-A7BB06362A10@netapp.com> References: <07586C31-CBA1-4C32-BCB9-A7BB06362A10@netapp.com> From: Yuchung Cheng Date: Sat, 3 Nov 2012 15:41:20 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkGIRQpSIgZal/imkh+kdSECCxKnrZKttJzJHWs42HVaSpnumCwxbOh7i/lP4S2QhsnyO0gB5MnswZJXbk7+7/rdtEe+HGNmlPCojqwqa8U6z7b37ahiicKHaQgxJwiMqguNBWyX0q1wfp1AqQO7mMnHE90kX3AZqsvieE+PrghR/HPCEqDeSWx+hXnjvwDlOODpduw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:41:42 -0000 On Sat, Nov 3, 2012 at 4:15 AM, Scheffenegger, Richard wrote: > > Hi Yoshifumi, > > I agree that without using TS or SACK, probably the only way to > differentiate between in some cases between the delayed original and the tlp > packet would be to modify the size of the TLP. > > However, i wonder if that complexity is really worthwhile. It would be > much easier and efficient to enable TS and SACK on links prone to tail drops > and reordering - and not only for a quicker tail loss recovery... > > Best regards, > Richard Both Yoshifumi and Richard have very good points. I am leaning toward re-sending original last packet. The focus of TLP is latency on short transfers experiencing losses. It's not probing nor converting timeout to recovery etc. After all it's just retransmitting stuff earlier or later. 1-byte probe eases the complexity of detecting single (>1 byte) packet drop when DSACK or TS is not supported. But it costs one more RTT to recover! that is detrimental for short transfer latency. We are experimenting both ideas on Google Web servers to get more data. > > Von meinem iPhone gesendet > > Am 02.11.2012 um 13:58 schrieb "Yoshifumi Nishida" > : > > Hi Nandita, > > I don't have specific scenarios in my mind yet. But, I personally would > like to support the idea for having a spec of FACK. I think FACK is a worthy > idea for the efforts and we can eliminate some ambiguity from the TLP draft. > > On the other hand, I have another comment on the draft. > I'm assuming the draft is focusing on "probing" rather than "recovering". > So, I'm wondering that even retransmitting small bytes (e.g. 1 byte) can > be useful for this purpose, although I might miss something. > > One tricky thing in TLP is you need to identify if packet loss is > recovered by only TLP. But, I guess there will be false positive cases in > some situations. If you retransmit small amount of data, I guess we can > avoid this and hence we can at least simplify the logic in the proposal. > > Thanks, > -- > Yoshifumi Nishida > > > > On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkipati > wrote: >> >> You are right that TLP as specified requires FACK based recovery. FACK >> is actually one of the most effective algorithms for loss recovery in >> our experiments and it's worthwhile having (reviving?) a concrete >> specification for FACK. Are there particular corner cases that you are >> concerned about? >> >> Nandita >> >> On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida >> wrote: >> > Hello, >> > >> > I'm reading the draft and I still need more time to think about this, >> > but I >> > have one question to proceed.. >> > >> > It seems to me that TLP requires FACK-based recovery logic. >> > if RFC6675 is used instead, I'm guessing TLP probably won't be so >> > useful >> > since it cannot recover all lost packets in some situations. >> > AFAIK we don't have a concrete specification for FACK. Hence, I have a >> > little concern that we cannot think about detailed corner cases for >> > this >> > approach. >> > Any thoughts on this? >> > >> > Thanks, >> > -- >> > Yoshifumi Nishida >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ycheng@google.com Sat Nov 3 17:33:37 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB0E21F86C9 for ; Sat, 3 Nov 2012 17:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tiuq8AWaKma1 for ; Sat, 3 Nov 2012 17:33:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0988A21F86B9 for ; Sat, 3 Nov 2012 17:33:36 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so5034635obq.31 for ; Sat, 03 Nov 2012 17:33:36 -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:x-system-of-record; bh=cKYaXMCsbhh5/W0mYhxqfw5tXro39EWi8X88PrZwhow=; b=LIH6tpM6uOybz2hR8W5PbJcoqS0AHD+qhII+mR3rUMDlSeTXUu+jbBaToKble21QQ0 P7My56O3qeIslXczPQDfiD3x/woxsCga6mEYfa2aLo8DBqq3hsXp06SAM/V9QX+WVTsG kXX10HzTkG3S3A6fwouPtlhjPIm6dn7FdwIFlB4pKfhSvmsMaA2ugEz2YwqXI626yAOD 4Fh0HypQ9cPbPIw0gIp0H6R2/4oFqAgu/V0vKB+5pcPScNghsjI+lhUBSjahh1RsaPtI ri3B9piNNGyc32SOqijwuhV95b9fK4N7X0aAZbZ6Fep4wrqmPKdeU4s+gESBcIcQWSIj u5gQ== 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-system-of-record:x-gm-message-state; bh=cKYaXMCsbhh5/W0mYhxqfw5tXro39EWi8X88PrZwhow=; b=m8eVEzZafhz8oKlauffvdcvb+E1liUNMRb8aI0oZX1KFnM0lmYZoy0VvzMVqCqdzJN ql9gid2C0OImEk7hJ9FtiA+mugpOOY8rAuTZ7VFWXvZSSB+lpTWaFmA8xlRXdoobmJjo dfg4UDnEDHOZR/kuKXKusgSnPPvINcJ5B7X61wXjVDKa9UJmMUmk8TL9N4qKYJKQXG6M e66UiIzmVBkOf7skTwnHMukfVO+3kcGyaAbDtZcHPOluaOckczp4nqifnVQ6lA5YODLK Zyn8tJeXXqco8U+ak/kLZEKOZXDmdNOKOTyuD3dfHwb59kFjjbGO/G6jd2vl7Do3kmXZ +wNQ== Received: by 10.182.54.103 with SMTP id i7mr4632679obp.62.1351989216551; Sat, 03 Nov 2012 17:33:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.41 with HTTP; Sat, 3 Nov 2012 17:33:16 -0700 (PDT) In-Reply-To: References: <20120710151352.A743D22F931F@lawyers.icir.org> From: Yuchung Cheng Date: Sat, 3 Nov 2012 17:33:16 -0700 Message-ID: To: Per Hurtig Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlTrMnwSrZReZ+1z+bQfYKnBAbY6GyPb2hT9TyMcZIW7OYZbxmJu0UifOfNG8Yx/DXlVtSLiqEnx/COMIRqJV0ez2XYtnuoYl9sjOo5MNJJsOzfHRYq+u9nman4uzd08onwmOV43VAjo29/ScRgPKdmsHhbQ0j13ym2qiqdJJYncPglWiKBW218MfGfrjvjWsXUgMHJ Cc: tcpm , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 00:33:37 -0000 On Thu, Nov 1, 2012 at 1:18 PM, Per Hurtig wrote: > Hi, > > > We've run experiments (using Linux TCP) to determine whether our restart > approach is more likely to cause spurious retransmissions in a burst > transmission scenario as suggested by Yuchung. > > > In the experiments 30 packets are transmitted in total. At first there is a > very low initial delay, but from packet 11 and onward the bandwidth is > restricted so that the spacing between packets become 200 ms. Given an > initial window of 10 and that Linux ACKs each packet in the initial window > the scenario creates a burst transmission of 20 packets as suggested in > Yuchung's example. In our experiments we see the "balloon effect" that Mark > predicted very clearly (the RTO becomes extremely inflated due to the > variation). There is no risk that the modified RTO approach causes spurious > retransmissions. Thanks for the experiment. Per-packet RTT sampling is critical to "ballon" the RTO on a window worth of burst. I wonder if you can share the Linux patch with me. I am interested to experiment more. > > > Furthermore, possible problems in burst scenarios are quite unlikely, as > spurious retransmissions would only affect the transmission if a new large > burst of data is to be sent after the RTO timer spuriously expires > (otherwise the spurious retransmission is just a wasted packet in the end of > a short flow), but before an RTO worth of time has elapsed (otherwise cwnd > is reset to the restart window). I am puzzled by this part: if there is no risk to trigger spurious RTO like you said why bother its effects anyways? Off-topic but web servers don't restart cwnd after idle, at least I know several ones that we probably all visit everyday. > > > > > Per > > > On Tue, Jul 10, 2012 at 5:13 PM, Mark Allman wrote: >> >> >> > I am concerned about this following hypothetical scenario: >> > >> > t0.0s: bursts packets 1-20, mount RTO to 2second >> > t1.8s: gets ack of packets 2,4,6,8,10,12,14,16, 18 every 200ms. >> > Ack of 18 arrives at 1.8s >> > >> > This draft will mount an RTO of 200ms for packet 19 on ack18, which >> > is likely to be spurious. The problem is that T_earliest could be >> > starting from large send a while back even when current FlightSize >> > is small. >> >> I hear you. But, I don't buy your framing. You keep the RTO at a >> constant throughout the process. But, with a variance like you describe >> above it certainly seems plausible that the RTO will balloon. And, the >> way the document is framed when 18 arrives we restart the timer with >> RTO-T_earliest. But, if RTO is > 2sec then the timeout will be > >> 200ms. >> >> So, I don't think it is as easy as you have portrayed it. >> >> allman >> >> >> > From gorry@erg.abdn.ac.uk Sun Nov 4 04:09:07 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE84021F8462 for ; Sun, 4 Nov 2012 04:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.464 X-Spam-Level: X-Spam-Status: No, score=-101.464 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw+kVVbtSuYp for ; Sun, 4 Nov 2012 04:09:07 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 416EA21F845E for ; Sun, 4 Nov 2012 04:09:07 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 1DA2D2B45EE; Sun, 4 Nov 2012 12:09:06 +0000 (GMT) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0C38C2B43C1; Sun, 4 Nov 2012 12:09:04 +0000 (GMT) Message-ID: <50958DB8.3060400@erg.abdn.ac.uk> Date: Sat, 03 Nov 2012 17:33:44 -0400 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] TFO fastopen-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:09:08 -0000 4.1.3 requires servers to cache cookies, but does not mandate anything about negative responses. 4.2.1 contains a "RECOMMEND", similar statements are made in various places in non-standards language. It seems to me that the robustness of the method actually relies on a history cache of unsuccessful attempts to deal with paths/servers that do not support the new mechanism. Therefore the caching functions seem under-specified. I have concerns that this could result in additional useless retransmission of SYNs - noting that other protocol entities may also be responding to/interpretting retransmissions (e.g. ECN, ICE, or IPv4 fall-back from IPv6), I think we should seek to avoid such persistent SYN retransmission. I therefore think we require failures to be cached by a client and we should also specify a minimum time that an endpoint should cache an unsuccessful TFO exchange - hosts that can not maintain this cache (e.g. due to memory constraints) could entirely suspend new (uncached) use of TFO for the interface for the period. To me, this would be much more robust to problems with hosts that find themselves on paths that do not support TFO (including middleboxes that do not have this support). I wonder if using the PMTU cache also implies that the first SYN may fail when there is a path change? I did not see a discussion of the RTT cache - what are the unwanted implications of caching this value? It seems the path characteristic that is most likely to change with time. Presumably one implication is that clients behind a varying RTT paths may find themselves unable to use TFO (because of spurious SYN+TFO timeout). I also agree with Michael Scharf that allowing the server to send initial window segments in response to Fastopen, does have congestion implications, perhaps these are small with typical up/downlinks but I do not yet see this as inconsequential in other cases (and TCP is a general purpose protocol). This would seem not to be an issue if the server sent 1 or 2 segments... but that's not what the draft allows (e.g. IW=10). At first sight this seems an unreasonable increase in aggressiveness, and would I suggest require some normative text. Gorry ---- PS, possible NiT?: The first MUST in 4,2,2, does not appear to be a protocol requirement. From rs@netapp.com Sun Nov 4 05:23:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A554B21F84A4 for ; Sun, 4 Nov 2012 05:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lsHIC9qLiye for ; Sun, 4 Nov 2012 05:23:37 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C9F2521F8475 for ; Sun, 4 Nov 2012 05:23:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,710,1344236400"; d="scan'208";a="706872660" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 04 Nov 2012 05:23:36 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qA4DNaO0008815; Sun, 4 Nov 2012 05:23:36 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.165]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 05:23:36 -0800 From: "Scheffenegger, Richard" To: David Malone , Pasi Sarolahti Thread-Topic: [tcpm] Please review RFC 1323bis Thread-Index: AQHNrT6PEdxq9Hj7Jka5D+UMWSeRQpe/p3sAgBoYkIA= Date: Sun, 4 Nov 2012 13:23:35 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D73D873@SACEXCMBX02-PRD.hq.netapp.com> References: <20121018153616.GA77317@marble.hamilton.local> In-Reply-To: <20121018153616.GA77317@marble.hamilton.local> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Please review RFC 1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:23:38 -0000 Hi David, thank you for your comment. As far as I can see, receivers modifying the timestamps as their usage is d= efined in RFC1323(bis) can really only affect their RTO; either decrease th= e effective RTO time - leading to increased spurious retransmission timeout= s, thus a performance penalty to themselves, or increase the effective RTO = time - leading to less timely retransmissions for last resort recovery, aga= in leading to a performance penalty to themselves (assuming the RTTM / RTO = mechanism is not severely broken in the sender). >From what I learned, the linux code switched to internal bookkeeping when C= UBIC was developed, because TS got repurposed to provide the Cubic epoch ti= me; by modifying the TSecr values, the receiver could modify the epoch time= , which in turn resulted in a much faster ramp-up of the senders cwnd than = intended. Thus a receiver could actually gain from that modification. However, RFC1323(bis) defines timestamps only for two purposes (PAWS, RTTM = for RTO).=20 So, I agree that there exists an attack vector to the RTTM part of RFC1323,= but the outcome will be detrimential to the attacker.=20 We do have other drafts in the WG, that deal with timestamps and additional= mechanisms using those (draft-scheffenegger-tcpm-timestamp-negotiation and= draft-trammell-tcpm-timestamp-interval). I think your concerns are valid, = and are discussed in those documents, specifically when timestamps are to b= e used for mechanisms outside RFC1323 (such as Cubic; Chirp, Ledbat,...). But perhaps some of the text in those drafts should become part of 1323bis = at this time? Any opinions? Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > David Malone > Sent: Donnerstag, 18. Oktober 2012 17:36 > To: Pasi Sarolahti > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Please review RFC 1323bis >=20 > I wonder if the text in Section 4.3 needs modification: >=20 > It is vitally important to use the RTTM mechanism with big windows; > otherwise, the door is opened to some dangerous instabilities due to > aliasing. Furthermore, the option is probably useful for all TCP's, > since it simplifies the sender. >=20 > I believe that Linux hasn't used the echoed timestamp to calculate RTTs > for some years (though I haven't looked at the code recently, Matt Mathis > could probably say). I believe the book-keeping is just done internally, > as much as possible. >=20 > I also wonder if it is worth mentioning the issue of a reciever who echos > modified timestamps? If the timestamps are used without sanity checking, > then the timeout can be controlled by the reciever (without changing the > actual RTT). >=20 > The security section has some comments on middle boxes that remove > timestamp options. I don't know if we need to offer any advice on > scrubbing timestamp options? I haven't heard any problems being caused by > this, so maybe there is nothing to be said. >=20 > David. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Sun Nov 4 05:29:42 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EE721F8503 for ; Sun, 4 Nov 2012 05:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHTJEDTpJQAk for ; Sun, 4 Nov 2012 05:29:41 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id EE2B721F8526 for ; Sun, 4 Nov 2012 05:29:30 -0800 (PST) Received: from [10.252.1.106] (213.174.124.178) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087141600284BE3; Sun, 4 Nov 2012 15:29:18 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Pasi Sarolahti In-Reply-To: Date: Sun, 4 Nov 2012 14:29:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120710151352.A743D22F931F@lawyers.icir.org> <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> <4790AE07-46C0-4974-BEBA-EB07FDA59F31@ifi.uio.no> To: =?iso-8859-1?Q?Anna_Brunstr=F6m?= X-Mailer: Apple Mail (2.1283) Cc: tcpm , Michael Welzl , mallman@icir.org Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 13:29:42 -0000 On Nov 2, 2012, at 4:40 PM, Anna Brunstr=F6m wrote: >> I guess the hypothetical problem cases are such where the computed = RTO >> is close to RTT, and for that reason the timer would be at some sort = of >> risk of expiring spuriously even without RTO-restart. Then = RTO-restart >> adds to this risk by some factor, that probably depends on the >> bandwidth and delay characteristics on the path. >=20 > The problem cases should indeed be very similar. If a new burst is > transmitted in Michael's example above, packet 11 will have the same = RTO > as packet 8 (assuming the RTO itself has not changed). =20 >=20 > So in cases where spurious retransmissions cause problems, any = mitigations > should be useful also when you do not use RTO-restart.=20 I'm not so sure about the mitigations when we are at the end of the send = window. Different scenarios aside, I understand that we are only talking about = few packets, so erring on one side or another may not be a big issue in = practice, but as a design point: It seems possible that under some circumstances RTO could get values = close to SRTT. It seems possible that under some conditions T_earliest could be almost = one RTT away. So in principle, isn't it possible that RTO - T_earliest could get = values close to 0? Would it make sense to add some low bound to RTO = restart, for example max(RTO - T_earliest, SRTT)? - Pasi From michawe@ifi.uio.no Sun Nov 4 12:36:56 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75EB21F889A for ; Sun, 4 Nov 2012 12:36:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRQLkuhYAjdK for ; Sun, 4 Nov 2012 12:36:56 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id E1B5621F887D for ; Sun, 4 Nov 2012 12:36:55 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TV6wA-0003Io-1E; Sun, 04 Nov 2012 21:36:54 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TV6w9-0006ER-6T; Sun, 04 Nov 2012 21:36:53 +0100 Message-Id: From: Michael Welzl To: Yuchung Cheng In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 4 Nov 2012 21:36:50 +0100 References: <20120710151352.A743D22F931F@lawyers.icir.org> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 19 msgs/h 9 sum rcpts/h 20 sum msgs/h 10 total rcpts 25272 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 039BBF8F143C2CB80B515435947519D45B130A71 X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 8 total 8 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 20:36:56 -0000 On Nov 4, 2012, at 1:33 AM, Yuchung Cheng wrote: > On Thu, Nov 1, 2012 at 1:18 PM, Per Hurtig wrote: >> Hi, >> >> >> We've run experiments (using Linux TCP) to determine whether our >> restart >> approach is more likely to cause spurious retransmissions in a burst >> transmission scenario as suggested by Yuchung. >> >> >> In the experiments 30 packets are transmitted in total. At first >> there is a >> very low initial delay, but from packet 11 and onward the bandwidth >> is >> restricted so that the spacing between packets become 200 ms. Given >> an >> initial window of 10 and that Linux ACKs each packet in the initial >> window >> the scenario creates a burst transmission of 20 packets as >> suggested in >> Yuchung's example. In our experiments we see the "balloon effect" >> that Mark >> predicted very clearly (the RTO becomes extremely inflated due to the >> variation). There is no risk that the modified RTO approach causes >> spurious >> retransmissions. > Thanks for the experiment. Per-packet RTT sampling is critical to > "ballon" the > RTO on a window worth of burst. > > I wonder if you can share the Linux patch with me. I am interested to > experiment more. Sure! (stay tuned..) >> Furthermore, possible problems in burst scenarios are quite >> unlikely, as >> spurious retransmissions would only affect the transmission if a >> new large >> burst of data is to be sent after the RTO timer spuriously expires >> (otherwise the spurious retransmission is just a wasted packet in >> the end of >> a short flow), but before an RTO worth of time has elapsed >> (otherwise cwnd >> is reset to the restart window). > I am puzzled by this part: if there is no risk to trigger spurious RTO > like you said why bother its effects anyways? The point is not that there is no risk, but little risk. Cheers, Michael > Off-topic but web servers don't restart cwnd after idle, at least I > know > several ones that we probably all visit everyday. > >> >> >> >> >> Per >> >> >> On Tue, Jul 10, 2012 at 5:13 PM, Mark Allman >> wrote: >>> >>> >>>> I am concerned about this following hypothetical scenario: >>>> >>>> t0.0s: bursts packets 1-20, mount RTO to 2second >>>> t1.8s: gets ack of packets 2,4,6,8,10,12,14,16, 18 every 200ms. >>>> Ack of 18 arrives at 1.8s >>>> >>>> This draft will mount an RTO of 200ms for packet 19 on ack18, which >>>> is likely to be spurious. The problem is that T_earliest could be >>>> starting from large send a while back even when current FlightSize >>>> is small. >>> >>> I hear you. But, I don't buy your framing. You keep the RTO at a >>> constant throughout the process. But, with a variance like you >>> describe >>> above it certainly seems plausible that the RTO will balloon. >>> And, the >>> way the document is framed when 18 arrives we restart the timer with >>> RTO-T_earliest. But, if RTO is > 2sec then the timeout will be > >>> 200ms. >>> >>> So, I don't think it is as easy as you have portrayed it. >>> >>> allman >>> >>> >>> >> From michawe@ifi.uio.no Sun Nov 4 12:58:50 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3FE21F87BA for ; Sun, 4 Nov 2012 12:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzxepnkqCZOr for ; Sun, 4 Nov 2012 12:58:49 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 82F8721F87B8 for ; Sun, 4 Nov 2012 12:58:49 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TV7HM-0008AT-Sk; Sun, 04 Nov 2012 21:58:48 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TV7HM-0002sN-4w; Sun, 04 Nov 2012 21:58:48 +0100 Message-Id: From: Michael Welzl To: Pasi Sarolahti In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 4 Nov 2012 21:58:45 +0100 References: <20120710151352.A743D22F931F@lawyers.icir.org> <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> <4790AE07-46C0-4974-BEBA-EB07FDA59F31@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 23 msgs/h 10 sum rcpts/h 24 sum msgs/h 11 total rcpts 25276 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E7BD4AE1A825E45440904D2B0D096050435DC337 X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 9 total 9 max/h 9 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , mallman@icir.org Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 20:58:50 -0000 Hi, On Nov 4, 2012, at 2:29 PM, Pasi Sarolahti wrote: > On Nov 2, 2012, at 4:40 PM, Anna Brunstr=F6m wrote: >>> I guess the hypothetical problem cases are such where the computed =20= >>> RTO >>> is close to RTT, and for that reason the timer would be at some =20 >>> sort of >>> risk of expiring spuriously even without RTO-restart. Then RTO-=20 >>> restart >>> adds to this risk by some factor, that probably depends on the >>> bandwidth and delay characteristics on the path. >> >> The problem cases should indeed be very similar. If a new burst is >> transmitted in Michael's example above, packet 11 will have the =20 >> same RTO >> as packet 8 (assuming the RTO itself has not changed). >> >> So in cases where spurious retransmissions cause problems, any =20 >> mitigations >> should be useful also when you do not use RTO-restart. > > I'm not so sure about the mitigations when we are at the end of the =20= > send window. > > Different scenarios aside, I understand that we are only talking =20 > about few packets, so erring on one side or another may not be a big =20= > issue in practice, but as a design point: > > It seems possible that under some circumstances RTO could get values =20= > close to SRTT. > > It seems possible that under some conditions T_earliest could be =20 > almost one RTT away. I think we assume that T_earliest is always at least an RTT. > So in principle, isn't it possible that RTO - T_earliest could get =20 > values close to 0? Would it make sense to add some low bound to RTO =20= > restart, for example > max(RTO - T_earliest, SRTT)? Yes, very valid point, the draft doesn't discuss the <=3D 0 case; but I =20= think this should then be max(RTO - T_earliest, 0). (It's about firing the timer (RTO-T_earliest) seconds *after* the ACK =20= comes in) Cheers, Michael From michael.scharf@alcatel-lucent.com Sun Nov 4 13:05:34 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C48721F889A for ; Sun, 4 Nov 2012 13:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCQUHq5z1E9I for ; Sun, 4 Nov 2012 13:05:33 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6253E21F887D for ; Sun, 4 Nov 2012 13:05:33 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA4L5Run032046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 4 Nov 2012 22:05:27 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 4 Nov 2012 22:05:27 +0100 From: "Scharf, Michael (Michael)" To: Michael Welzl , Yuchung Cheng Date: Sun, 4 Nov 2012 22:05:26 +0100 Thread-Topic: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-02.txt Thread-Index: Ac26zCU16zfM1RRURXqCkP6CVsaQnwAArC7w Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39992@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20120710151352.A743D22F931F@lawyers.icir.org> , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 21:05:34 -0000 One random community member question inline ([MS])... >> Furthermore, possible problems in burst scenarios are quite >> unlikely, as >> spurious retransmissions would only affect the transmission if a >> new large >> burst of data is to be sent after the RTO timer spuriously expires >> (otherwise the spurious retransmission is just a wasted packet in >> the end of >> a short flow), but before an RTO worth of time has elapsed >> (otherwise cwnd >> is reset to the restart window). > I am puzzled by this part: if there is no risk to trigger spurious RTO > like you said why bother its effects anyways? The point is not that there is no risk, but little risk. [MS] Maybe I am lost here. But in case of a spurious timeout, TCP uses the = loss window, whereas after an idle timeout it would use the restart window,= right? With IW10, this is one order of magnitude, and for standards-track,= it is still factor 3. Does this not result in a somehow relevant risk of r= to restart? > Off-topic but web servers don't restart cwnd after idle, at least I > know > several ones that we probably all visit everyday. [MS] I would indeed be interested to see real data on the risk/benefit trad= eoff of draft-hurtig-tcpm-rtorestart for HTTP traffic, before deciding whet= her to go down that road. Michael= From michawe@ifi.uio.no Sun Nov 4 13:26:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545EC21F8613 for ; Sun, 4 Nov 2012 13:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgxyvNi+B7oX for ; Sun, 4 Nov 2012 13:26:08 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 781B821F84F3 for ; Sun, 4 Nov 2012 13:26:08 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TV7hn-0002Uc-7c; Sun, 04 Nov 2012 22:26:07 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TV7hm-0007HX-DL; Sun, 04 Nov 2012 22:26:07 +0100 Message-Id: <5707BA05-CE6F-48EB-A45A-0FDB4741F2FF@ifi.uio.no> From: Michael Welzl To: "Scharf, Michael (Michael)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39992@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 4 Nov 2012 22:26:03 +0100 References: <20120710151352.A743D22F931F@lawyers.icir.org> , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39992@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 20 sum msgs/h 7 total rcpts 25286 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8174C12BC1E6E6BE81B8F0E4F58A06F267D43690 X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 21:26:09 -0000 On Nov 4, 2012, at 10:05 PM, Scharf, Michael (Michael) wrote: > One random community member question inline ([MS])... > >>> Furthermore, possible problems in burst scenarios are quite >>> unlikely, as >>> spurious retransmissions would only affect the transmission if a >>> new large >>> burst of data is to be sent after the RTO timer spuriously expires >>> (otherwise the spurious retransmission is just a wasted packet in >>> the end of >>> a short flow), but before an RTO worth of time has elapsed >>> (otherwise cwnd >>> is reset to the restart window). >> I am puzzled by this part: if there is no risk to trigger spurious >> RTO >> like you said why bother its effects anyways? > > The point is not that there is no risk, but little risk. > > [MS] Maybe I am lost here. But in case of a spurious timeout, TCP > uses the loss window, whereas after an idle timeout it would use the > restart window, right? With IW10, this is one order of magnitude, > and for standards-track, it is still factor 3. Does this not result > in a somehow relevant risk of rto restart? Yes. That diminishes the value of the problem case restriction described above. (Note: I'm using this complicated phrase because all of this only applies if a spurious RTO is caused, the chance of which we still have to check some more. But so far, it doesn't seem to be very likely. >> Off-topic but web servers don't restart cwnd after idle, at least I >> know >> several ones that we probably all visit everyday. > > [MS] I would indeed be interested to see real data on the risk/ > benefit tradeoff of draft-hurtig-tcpm-rtorestart for HTTP traffic, > before deciding whether to go down that road. We have shown some data on the benefit side. Per has done a test, described on the list, to evaluate the risk, but yes, we can go further in risk evaluation. Cheers, Michael From michael.scharf@alcatel-lucent.com Sun Nov 4 13:53:27 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542A421F85CF for ; Sun, 4 Nov 2012 13:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxSvOYvmZrTd for ; Sun, 4 Nov 2012 13:53:26 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D24B21F84B3 for ; Sun, 4 Nov 2012 13:53:26 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA4LrLgN027205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 4 Nov 2012 22:53:21 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 4 Nov 2012 22:53:21 +0100 From: "Scharf, Michael (Michael)" To: Michael Welzl Date: Sun, 4 Nov 2012 22:53:19 +0100 Thread-Topic: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-02.txt Thread-Index: Ac260wZR5RCr1cO1ToKYdzJpynY08wAAS9wy Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39993@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20120710151352.A743D22F931F@lawyers.icir.org> , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39992@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, <5707BA05-CE6F-48EB-A45A-0FDB4741F2FF@ifi.uio.no> In-Reply-To: <5707BA05-CE6F-48EB-A45A-0FDB4741F2FF@ifi.uio.no> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 21:53:27 -0000 As far as I (chair hat off) understand the data presented in the last meeti= ng, this is for thin stream gaming applications, right? I guess I understan= d the impact for that class of applications. But I am interested in the ben= efit/risk for typical Web traffic. Technically, I also wonder about the difference to the "noRestart" approach= . I think there was some valuable discussion on the pros and cons of that. = Unfortunately, I don't recall the exact difference ;) Would it make sense t= o discuss this in the draft? Thanks Michael ________________________________________ Von: Michael Welzl [michawe@ifi.uio.no] Gesendet: Sonntag, 4. November 2012 22:26 An: Scharf, Michael (Michael) Cc: Yuchung Cheng; tcpm; mallman@icir.org Betreff: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtoresta= rt-02.txt On Nov 4, 2012, at 10:05 PM, Scharf, Michael (Michael) wrote: > One random community member question inline ([MS])... > >>> Furthermore, possible problems in burst scenarios are quite >>> unlikely, as >>> spurious retransmissions would only affect the transmission if a >>> new large >>> burst of data is to be sent after the RTO timer spuriously expires >>> (otherwise the spurious retransmission is just a wasted packet in >>> the end of >>> a short flow), but before an RTO worth of time has elapsed >>> (otherwise cwnd >>> is reset to the restart window). >> I am puzzled by this part: if there is no risk to trigger spurious >> RTO >> like you said why bother its effects anyways? > > The point is not that there is no risk, but little risk. > > [MS] Maybe I am lost here. But in case of a spurious timeout, TCP > uses the loss window, whereas after an idle timeout it would use the > restart window, right? With IW10, this is one order of magnitude, > and for standards-track, it is still factor 3. Does this not result > in a somehow relevant risk of rto restart? Yes. That diminishes the value of the problem case restriction described above. (Note: I'm using this complicated phrase because all of this only applies if a spurious RTO is caused, the chance of which we still have to check some more. But so far, it doesn't seem to be very likely. >> Off-topic but web servers don't restart cwnd after idle, at least I >> know >> several ones that we probably all visit everyday. > > [MS] I would indeed be interested to see real data on the risk/ > benefit tradeoff of draft-hurtig-tcpm-rtorestart for HTTP traffic, > before deciding whether to go down that road. We have shown some data on the benefit side. Per has done a test, described on the list, to evaluate the risk, but yes, we can go further in risk evaluation. Cheers, Michael= From anna.brunstrom@kau.se Sun Nov 4 14:21:30 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A91421F8780 for ; Sun, 4 Nov 2012 14:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdybSLXZ6qWg for ; Sun, 4 Nov 2012 14:21:30 -0800 (PST) Received: from smtprelay-b21.telenor.se (smtprelay-b21.telenor.se [195.54.99.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD7121F8493 for ; Sun, 4 Nov 2012 14:21:25 -0800 (PST) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-b21.telenor.se (Postfix) with ESMTP id 0E064EBA8B for ; Sun, 4 Nov 2012 23:21:24 +0100 (CET) X-SENDER-IP: [85.231.110.210] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0qAO7pllBV527SOWdsb2JhbAANN4pRtRqDZQEBAQEhF4JSAQEBAQIBMgEFPwEBEAsOCgkWDwkDAgECARsWFAYNAQcBAYgAphKSUYwBhjwDqS8 X-IronPort-AV: E=Sophos;i="4.80,712,1344204000"; d="scan'208";a="219279763" Received: from c-d26ee755.06-34-6b736411.cust.bredbandsbolaget.se (HELO [192.168.1.101]) ([85.231.110.210]) by ipb5.telenor.se with ESMTP; 04 Nov 2012 23:21:24 +0100 Message-ID: <5096EA66.2090301@kau.se> Date: Sun, 04 Nov 2012 23:21:26 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Michael Welzl References: <20120710151352.A743D22F931F@lawyers.icir.org> <6420_1351801125_5092D924_6420_149_1_CAC2J6umwoGAF_vd8eEBoa-9V39OAyV4xXcJbmNUfratorE=99A@mail.gmail.com> <18BA726E-B072-43AC-BE5F-8B196F0BB5CD@iki.fi> <4790AE07-46C0-4974-BEBA-EB07FDA59F31@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: tcpm , mallman@icir.org Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 22:21:30 -0000 On 2012-11-04 21:58, Michael Welzl wrote: > Hi, > > On Nov 4, 2012, at 2:29 PM, Pasi Sarolahti wrote: > >> On Nov 2, 2012, at 4:40 PM, Anna Brunström wrote: >>>> I guess the hypothetical problem cases are such where the computed RTO >>>> is close to RTT, and for that reason the timer would be at some sort of >>>> risk of expiring spuriously even without RTO-restart. Then RTO-restart >>>> adds to this risk by some factor, that probably depends on the >>>> bandwidth and delay characteristics on the path. >>> >>> The problem cases should indeed be very similar. If a new burst is >>> transmitted in Michael's example above, packet 11 will have the same RTO >>> as packet 8 (assuming the RTO itself has not changed). >>> >>> So in cases where spurious retransmissions cause problems, any >>> mitigations >>> should be useful also when you do not use RTO-restart. >> >> I'm not so sure about the mitigations when we are at the end of the >> send window. >> >> Different scenarios aside, I understand that we are only talking about >> few packets, so erring on one side or another may not be a big issue >> in practice, but as a design point: >> >> It seems possible that under some circumstances RTO could get values >> close to SRTT. >> >> It seems possible that under some conditions T_earliest could be >> almost one RTT away. > > I think we assume that T_earliest is always at least an RTT. I do not think this is true. As the application may send data at any time I do not think that there is any assumption on T_earliest. It could be close to zero or it could be almost an RTT away. >> So in principle, isn't it possible that RTO - T_earliest could get >> values close to 0? Would it make sense to add some low bound to RTO >> restart, for example >> max(RTO - T_earliest, SRTT)? > > Yes, very valid point, the draft doesn't discuss the <= 0 case; but I > think this should then be max(RTO - T_earliest, 0). > > (It's about firing the timer (RTO-T_earliest) seconds *after* the ACK > comes in) Maybe if the RTO is decreasing, the <= 0 case can happen. Having some check seems good. BR, Anna From anna.brunstrom@kau.se Sun Nov 4 15:06:53 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3870821F87B8 for ; Sun, 4 Nov 2012 15:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4DXSizV-IEn for ; Sun, 4 Nov 2012 15:06:52 -0800 (PST) Received: from smtprelay-b22.telenor.se (smtprelay-b22.telenor.se [195.54.99.213]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAFF21F87A6 for ; Sun, 4 Nov 2012 15:06:46 -0800 (PST) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-b22.telenor.se (Postfix) with ESMTP id 3106FEB66A for ; Mon, 5 Nov 2012 00:06:44 +0100 (CET) X-SENDER-IP: [85.231.110.210] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMqAJ/0llBV527SOWdsb2JhbAANN4pRtRqDYQQBAQEBIReCTgQBAQEBAgE4PwEBEAsOExYPCQMCAQIBGxYUBg0BBwEBhUWCJRamE5JOkj0DqS8 X-IronPort-AV: E=Sophos;i="4.80,712,1344204000"; d="scan'208";a="219285705" Received: from c-d26ee755.06-34-6b736411.cust.bredbandsbolaget.se (HELO [192.168.1.101]) ([85.231.110.210]) by ipb5.telenor.se with ESMTP; 05 Nov 2012 00:06:44 +0100 Message-ID: <5096F507.8010601@kau.se> Date: Mon, 05 Nov 2012 00:06:47 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Yuchung Cheng References: <20120710151352.A743D22F931F@lawyers.icir.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 23:06:53 -0000 Hi On 2012-11-04 01:33, Yuchung Cheng wrote: >> Furthermore, possible problems in burst scenarios are quite unlikely, as >> spurious retransmissions would only affect the transmission if a new large >> burst of data is to be sent after the RTO timer spuriously expires >> (otherwise the spurious retransmission is just a wasted packet in the end of >> a short flow), but before an RTO worth of time has elapsed (otherwise cwnd >> is reset to the restart window). > I am puzzled by this part: if there is no risk to trigger spurious RTO > like you said why bother its effects anyways? > > Off-topic but web servers don't restart cwnd after idle, at least I know > several ones that we probably all visit everyday. To continue off topic, just a thought on this scenario. Isn't the first packet in a new burst the packet to worry about the most with regards to a spurious retransmit? If the idle time is long I guess the likelihood of the path characteristics having changed could be larger than for packets sent in the same burst. As there is no data sent, the RTO will also not adapt to the changes. Assuming the new burst is not to small (i.e > 4), increasing the RTO after idle may be beneficial as we want a fast retransmit anyway in case a packet is lost. Hence we do not run the same risk of delaying loss recovery as we do in the end of a burst. BR, Anna From michawe@ifi.uio.no Sun Nov 4 15:12:55 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8D621F87BD for ; Sun, 4 Nov 2012 15:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKZ4+FJH+O4p for ; Sun, 4 Nov 2012 15:12:54 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id CDB0F21F87B8 for ; Sun, 4 Nov 2012 15:12:53 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TV9N6-0004fP-Ow; Mon, 05 Nov 2012 00:12:52 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TV9N6-0003mi-10; Mon, 05 Nov 2012 00:12:52 +0100 Message-Id: From: Michael Welzl To: "Scharf, Michael (Michael)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39993@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Nov 2012 00:12:47 +0100 References: <20120710151352.A743D22F931F@lawyers.icir.org> , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39992@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, <5707BA05-CE6F-48EB-A45A-0FDB4741F2FF@ifi.uio.no> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F39993@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 10 sum msgs/h 3 total rcpts 25296 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E6D1326733D560B98B9F679F2DCC24C69BD97518 X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 16 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , "mallman@icir.org" Subject: Re: [tcpm] New Version Notification for draft-hurtig-tcpm-rtorestart-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: Sun, 04 Nov 2012 23:12:55 -0000 Hi, On Nov 4, 2012, at 10:53 PM, Scharf, Michael (Michael) wrote: > As far as I (chair hat off) understand the data presented in the > last meeting, this is for thin stream gaming applications, right? I > guess I understand the impact for that class of applications. But I > am interested in the benefit/risk for typical Web traffic. Yes, it was. About web traffic, sure, I agree. > Technically, I also wonder about the difference to the "noRestart" > approach. I think there was some valuable discussion on the pros and > cons of that. Unfortunately, I don't recall the exact difference ;) > Would it make sense to discuss this in the draft? We have found that the mechanism doesn't work. It was a nice idea, but led to problems with thin streams (greater potential for spurious timeouts, with the benefit of a slightly simpler implementation). We can discuss why we didn't pick it, but personally I think it's not worth it (not helping the reader much). But no problem, can be done if you guys feel otherwise... Cheers, Michael From bob.briscoe@bt.com Mon Nov 5 06:37:08 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28F621F8615 for ; Mon, 5 Nov 2012 06:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-nWLH99IiMp for ; Mon, 5 Nov 2012 06:37:08 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6721F8596 for ; Mon, 5 Nov 2012 06:37:07 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 5 Nov 2012 14:37:05 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 5 Nov 2012 14:37:05 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Mon, 5 Nov 2012 14:37:00 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1352126219272; Mon, 5 Nov 2012 14:36:59 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.2.27]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qA5Eau5P025919; Mon, 5 Nov 2012 14:36:57 GMT Message-ID: <201211051436.qA5Eau5P025919@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 4 Nov 2012 22:07:50 +0000 To: Mirja KUEHLEWIND , "Richard Scheffenegger" From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tcpm IETF list Subject: [tcpm] Review: draft-kuehlewind-tcpm-accecn-reqs-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:37:08 -0000 Mirja & Richard, Thanks for this draft. I hope the following will help the IETF process to efficiently choose between the proposed solutions to these requirements: Suggested New Abstract: This document gives requirements for an ECN feedback mechanism within TCP that continually feeds back the extent of congestion, not merely its existence. Explicit congestion notification (ECN) is an IP/TCP mechanism in which network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. ECN is specified for TCP in such a way that the receiver can only feed back one signal per round-trip time (RTT). Recently, both ConEx and DCTCP have made different local changes to TCP to feed back how many ECN markings have been received in a round trip. It would be desirable to standardise how TCP feeds back this extra information, which might also lead it to be exploited in other ways yet to be invented. Rationale for my numerous changes to the abstract: * First sentence summarises what the doc does, for those who already know what ECN is. * ConEx doesn't /need/ accurate ECN - it's an optimisation * DCTCP isn't an IETF activity, so it's not relevant that DCTCP /needs/ this. It's relevant to the IETF that multiple incompatible TCP wire protocols are appearing on the Internet. * Want to highlight up front that this could be generally useful in the future. 1. Introduction First para: [Suggest the first para adopts similar changes to those proposed in abstract above. Then, add the following:] If it is possible to make TCP's ECN feedback accurate without extra header space or complexity, the aim is that this should become the only way TCP ECN feedback is done, whether or not the sender needs the accuracy. Then future sender algorithms can evolve to exploit this richer information, without facing the deployment challenge of getting receivers upgraded first. [I suggest, in the same way that the Intro explains briefly what ECN is, it also explains what CoNEx is, and what DCTCP is, before talking about them... Suggested text follows:] Congestion Exposure (ConEx) is a (currently experimental) modification to an IP sender so that it signals its knowledge of congestion to the network, in order that networks can offer better, application-neutral traffic management. The idea is that ConEx signals can inform an operator's traffic management function at the network ingress (in advance of encountering the congestion). ConEx signals are immutable end-to-end, so further into the network, at or beyond where congestion is experienced, the operator can audit the ConEx signals by comparing them with the actual congestion experienced. In the case of TCP, a ConEx sender uses SACK feedback to signal each loss it sees. However, with standard ECN [RFC3168] enabled, the receiver does not give sufficient feedback for the sender to signal the extent of congestion, so modifications to the TCP receiver have been proposed to feed back every congestion notification [I-D.kuehlewind-tcpm-accurate-ecn]. Data Centre TCP (DCTCP) is a change to the TCP sender, the TCP receiver and to all the queues in between. It is confined to deployments where everything is controlled by the same administration (e.g. in data centres). It was released in the recent beta of Windows 8 Server Edition. A DCTCP sender responds a small amount to each and every ECN congestion marking. This contrasts with a traditional TCP sender, which halves its rate in response to the first loss or ECN in a round trip, but then does not respond any more for the rest of the round trip. This is why a DCTCP receiver has been altered to feed back the extent of ECN marking, not just its existence. Section 2. 2nd para: OLD: In the TCP header the first two bits in byte 14 are defined for the use of ECN. The TCP mechanism for signaling the reception of a congestion mark uses the ECN-Echo (ECE) flag in the TCP header. To enable the TCP receiver to determine when to stop setting the ECN-Echo flag, the CWR flag is set by the sender upon reception of the feedback signal. NEW: In the TCP header the first two bits in byte 14 are defined for the use of ECN. Each half-connection works separately. The TCP receiver signals the reception of a congestion mark by setting the ECN-Echo (ECE) flag in the TCP header repeatedly on every subsequent ACK. It does this for reliability, because TCP does not deliver pure ACKs reliably. When the TCP sender sees the first ECE flag, it sets the CWR flag once on the next packet it sends. When the receiver sees this CWR flag, it stops setting the ECE flag on subsequent ACKs. Thus, any congestion event always leads to a full RTT of ACKs with ECE set. Therefore the receiver cannot signal feedback of any additional CE markings arriving at the receiver within the same RTT. Section 3. [I suggest the resilience bullet is split into two: * resilience * sufficient precision because the delayed ack stuff (all but the first & last sentence in this bullet) isn't about resilience, it's saying you can't rely on having as many ACKs to carry feedback as there are data packets that could be marked. ] * Resilience: s/TCP ACKS can get lost/ /Pure TCP ACKs can be silently and permanently lost/ * Sufficient Precision: We should require that the design should work for ACKs delayed by n where n>2. [This then needs to be merged with the Accuracy requirement bullet.] * Timely: s/Timely/Timeliness/ s/small number of ACK/small number of ACKs/ s/out dated/outdated/ s/high dynamic/high dynamics/ s/should be delivered timely (within one RTT)./should be delivered within about one RTT./ [Timely is an adjective not an adverb] * Integrity Delete or reword: /As this accurate ECN feedback is reusing the NS bit, / because this is now the reqs doc, not the protocol proposal. Ive said this before but I'll say it again: the nonce would only have assured integrity if it was made mandatory for all ECN receiver implementations. Once ECN implementations were deployed without it, it becames useless. Reasoning: a receiver who wants to cheat just claims it hasn't implemented the nonce, and it looks just like all the other implementations that haven't. So senders can never punish receivers for non-cooperation, when they can hide in the crowd of all the non-deployers. So, we shouldn't talk about supporting the nonce any more, unless we can reverse time (or an equivalent trick). * Accuracy: s/as this is supposed to be used for TCP congestion control which reduces/ /which is sufficient for a TCP congestion control that reduces/ Additional requirements: * Middlebox traversal * Avoid a fork in TCP ECN specifications Section 4. Design Approaches. I suggest this whole section is deleted. Instead, replace it with references to the candidate proposals and a suggestion for the process to follow to choose between them. For example: Table of each proposal vs the requirements with ticks or smileys or something to show which ones satisfy which requirements. Then: "Discussion is encouraged on the tcpm mailing list followed by a decision on which one to choose to go forward." Instead of S.4.2, "Using the reserved bits" could then be one of the proposals (with probable consequent middlebox traversal problems but greater accruacy). HTH Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From nishida@sfc.wide.ad.jp Mon Nov 5 15:43:43 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C6421F850E for ; Mon, 5 Nov 2012 15:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.258 X-Spam-Level: X-Spam-Status: No, score=-98.258 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPYlQerhwD5t for ; Mon, 5 Nov 2012 15:43:43 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id E7F9A21F845E for ; Mon, 5 Nov 2012 15:43:42 -0800 (PST) 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 91BC12780E8 for ; Tue, 6 Nov 2012 08:43:36 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id k13so4906967lbo.31 for ; Mon, 05 Nov 2012 15:43:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.106.171 with SMTP id gv11mr10793074lab.26.1352159013779; Mon, 05 Nov 2012 15:43:33 -0800 (PST) Received: by 10.112.103.193 with HTTP; Mon, 5 Nov 2012 15:43:33 -0800 (PST) Date: Mon, 5 Nov 2012 18:43:33 -0500 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] notetaker and jabber volunteer? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Nov 2012 23:43:43 -0000 Hello folks, We appreciate if someone help us with notetaking or jabber for the wg meeting tomorrow. Please let us know if you're interested. Regards, -- tcpm co-chairs From ycheng@google.com Mon Nov 5 21:04:04 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE13521F877C for ; Mon, 5 Nov 2012 21:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnQFuwVHxfK3 for ; Mon, 5 Nov 2012 21:04:04 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46B9B21F87B8 for ; Mon, 5 Nov 2012 21:04:04 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so43767obq.31 for ; Mon, 05 Nov 2012 21:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PYKop3xTTRCL3nhTE30FHln3y/IaHNjM5zRFV7HpKPI=; b=gxWh+RmfZkDBe8e7r28hC11TxWU5/eCpxHXasLcgQHCZZj+B+iXilVxgSyAJpp9mOW ekYIhdxfJcm5zjbzjDdAaKZgzvkpu5zDNDv5RLks7NlpJbR7QAmdYqI7FjKg2IDK4539 b+aHCANDjDBfDZxknnYXypvxt8jfAwC+HCeewfkJuwV+0Z++YNAsV4H3GoD5a9xhnfEF 5kA4Qdmlr4Jj8JThx+zRVUOs7YJkzVk94fEzSOrt7/GOarlcYyEsLCPhdZ0ZvaZbeGzp u8EZ9hBXPDp9gpjB+M6DHR4VOa/6UINYpeqrRexVEeAecvxiUNfPWkYjVHctf/dxQ6JI JrTA== 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=PYKop3xTTRCL3nhTE30FHln3y/IaHNjM5zRFV7HpKPI=; b=emWEHtlLt7J9AMVUZQ+ZUf9QDu2nOtAxrip61q1AShVHtrpB3kAqyjLj8jUaqKdTpk M99vGoLzqkvhLHp90GO7b+bSgisKD5p5tIm9/976CUeTbt4AVeC3u9bEzR+WZJ3IVIRA tI7qSl2pB5J+jd9WYfXBbWA0Py2GT6YJahpF/xPEFTTRjIJaxKKZe+aLb/buRe3P8iQC gNqgnv9fO4rbTnUCpc7G7f47YkD6IebDDXVCYUi6SLhVA3HWEH8mO/JTwdQSRzfZhPhE rnY3Nw2LZNuxMPWz9H1gGrnCC/QvIKfWjqXKebEaDu4G2oqfE3XrFcv5B09iMF0ChJF/ Ct7A== Received: by 10.60.3.69 with SMTP id a5mr9938001oea.117.1352178243718; Mon, 05 Nov 2012 21:04:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.99.41 with HTTP; Mon, 5 Nov 2012 21:03:43 -0800 (PST) In-Reply-To: <50958DB8.3060400@erg.abdn.ac.uk> References: <50958DB8.3060400@erg.abdn.ac.uk> From: Yuchung Cheng Date: Tue, 6 Nov 2012 00:03:43 -0500 Message-ID: To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmv40IXSXKgyVMLRZvAMfFdZYmfJlFL4ejTg0FsAR6wJ3RX1UgUoPEB6fiMR0LwkZAGV4NDrj8cDvPXsZI7iBVIe85iDfz72SfNY3E7y7Qq8Y6g33R05ylORbaAWSow9mw8/5mJ6Wsdz0VfIMD5YkXo95eh2hfbNPXLYe+1oZBZCk5Bn65Pu/tqayTl1Qd+Tqiam8nJ Cc: tcpm@ietf.org Subject: Re: [tcpm] TFO fastopen-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Nov 2012 05:04:05 -0000 First of all. Thanks for reviewing the draft! On Sat, Nov 3, 2012 at 5:33 PM, Gorry Fairhurst wrote: > 4.1.3 requires servers to cache cookies, but does not mandate anything about > negative responses. 4.2.1 contains a "RECOMMEND", similar statements are > made in various places in non-standards language. We will update these wordings. Thanks for catching that. > > It seems to me that the robustness of the method actually relies on a > history cache of unsuccessful attempts to deal with paths/servers that do > not support the new mechanism. Therefore the caching functions seem > under-specified. I have concerns that this could result in additional > useless retransmission of SYNs - noting that other protocol entities may > also be responding to/interpretting retransmissions (e.g. ECN, ICE, or IPv4 > fall-back from IPv6), I think we should seek to avoid such persistent SYN > retransmission. Let's define robustness first: it's robust as long as the client can finish connect operation. TFO client always retries a regular SYN. If that is not working then even regular TCP is failing. We do advise using negative caching in the end of 4.1.3. The reason we don't specify details are 1) the details of negative caching is not critical, as long as the client or server retransmits regular SYN which we do specify. 2) it's about working around broken middle-boxes. It should not be part of a TCP protocol. But I am happy to talk our implementation in Linux tomorrow :) > > I therefore think we require failures to be cached by a client and we should > also specify a minimum time that an endpoint should cache an unsuccessful > TFO exchange - hosts that can not maintain this cache (e.g. due to memory > constraints) could entirely suspend new (uncached) use of TFO for the > interface for the period. To me, this would be much more robust to problems > with hosts that find themselves on paths that do not support TFO (including > middleboxes that do not have this support). > > I wonder if using the PMTU cache also implies that the first SYN may fail > when there is a path change? path can change any time and fail any packet. PMTU (or rather MSS) caching does not imply that. It's certainly possible getting an ICMP message too big on SYN-data. In this case, the TCP should just cache the new MSS indicated in the ICMP. The draft isn't clear but our implementation does do that. I'll update the draft about this. Thanks. > > I did not see a discussion of the RTT cache - what are the unwanted > implications of caching this value? It seems the path characteristic that is > most likely to change with time. Presumably one implication is that clients > behind a varying RTT paths may find themselves unable to use TFO (because of > spurious SYN+TFO timeout). The reason about RTT cache is to speed up the SYN retransmission in case of the middle-box issue above. Cached RTT can be wrong, with or without having payload in SYN, and causes spurious SYN retransmission. The data in SYN is still delivered, but we send an extra SYN. > > I also agree with Michael Scharf that allowing the server to send initial > window segments in response to Fastopen, does have congestion implications, > perhaps these are small with typical up/downlinks but I do not yet see this > as inconsequential in other cases (and TCP is a general purpose protocol). > This would seem not to be an issue if the server sent 1 or 2 segments... but > that's not what the draft allows (e.g. IW=10). At first sight this seems an > unreasonable increase in aggressiveness, and would I suggest require some > normative text. We will add text about this case. I'd like to remind that TFO is about SYN-data plus some basic defense for simple attacks. data in SYN is in RFC793. The congestion control should have incorporated that. If middleboxes don't operate we may send some extra SYNs, but the sky is not falling. The browsers you are using are "speculatively" opening (idle) connections before they know what requests to send. These connections are thrown away if the resources are locally cached. The amount of unneeded SYNs are hundreds if not thousands orders of magnitude larger. This is all because apps working around handshake latency. > > Gorry > > ---- > > > PS, possible NiT?: The first MUST in 4,2,2, does not appear to be a protocol > requirement. agreed. will update. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Tue Nov 6 06:00:27 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386DC21F882F for ; Tue, 6 Nov 2012 06:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgbBeahsbaUt for ; Tue, 6 Nov 2012 06:00:26 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 3755D21F8784 for ; Tue, 6 Nov 2012 06:00:26 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TVjhY-0003Qx-Vk; Tue, 06 Nov 2012 15:00:24 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TVjhY-0000qR-Eb; Tue, 06 Nov 2012 15:00:24 +0100 Message-Id: From: Michael Welzl To: iccrg list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Nov 2012 15:00:22 +0100 X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 25340 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 95063B3CBB6255114E1716AB6D1D2FA5EEB3092B X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 34 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm Subject: [tcpm] draft-fairhurst-tcpm-newcwv-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Nov 2012 14:00:27 -0000 Hi, (ICCRG chair hat off) In his presentation yesterday, Gorry said that he'd like to get more comments. I have also read this draft, and had the overall impression that it has significantly improved since the first version. In particular, I like the way the non-validated phase is used. Given the trade-off between: 1) systems that collapse cwnd (do they exist? :-) ) 2) systems that simply maintain cwnd 3) old cwv which noone uses because it doesn't perform well enough ...this proposal strikes me as quite a reasonable trade-off. In other words: I'd prefer seeing this deployed and used over the current state of things. Cheers, Michael From nanditad@google.com Tue Nov 6 06:29:01 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F1821F88F5 for ; Tue, 6 Nov 2012 06:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NawB3xqyQ3Fy for ; Tue, 6 Nov 2012 06:29:00 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 916ED21F8468 for ; Tue, 6 Nov 2012 06:29:00 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so522420oag.31 for ; Tue, 06 Nov 2012 06:29:00 -0800 (PST) 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=bLdW3BOkUeiX3EXkPE94VJ4ZDK7I5TZT/7fiduaLkVY=; b=WfGpBE3IUWbIyOn8t0lFgueUQS8JQmBoYLO/aCK3Jswcjbs3hkvwMM2vWkJg6vlgGy ssHgjU4vW50UPDRPaxHoBNfM4UNWX1uF2Qbd4UTzAaJJYcjDfJArdQBiWX+OUkijhzav T74N7I0oce8F2sc24LeLxjRS7rrL3lQXaIoI7/BfoNIGbiG8hVsfyNZBPWqsWWEiD/l8 EZfRDwMJkhqgpzL6B8ZADD1HELXFI4V7TfhAs+tayd76Yp+4uHrodCx3OY8wvrYrRmJF PpW8HWUAMmif3lofbJXvEIdoNe7URHDoMqZ+MMRm24Bq5vPSU1M+Xj08WQrOysAMg4qF xFXA== 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=bLdW3BOkUeiX3EXkPE94VJ4ZDK7I5TZT/7fiduaLkVY=; b=SvehXiQXmPF1gM/21Ydv3Yq/5RcLVjZ6NHN5QDmmQWA3e2PB7kTJ2r4Qwbt2d10bXG KlcLo0qdJV9K6SUvkFCfMctLp+0w2rUub2JDaNpZg6DQ5jmGLIClmCcptboJJiDEaGsB sZYvZDtH2YDpqM2L5J40CrpcS1vCD6EWwyMn/JOWviDy0U+3EeNaa7FewOmqJ+UFi/a2 o9j5JiLrY2AS01xF2r9x9tLsP9yTUp8/qIA7o6Wh5IFq5gsfvft8LXqBM3QUOOBT4qdv 6IfCjTIZErFX2Pokff+a5REtvhnypP6SUj/yZkJ7/bKU/aNbopHz1hz0ebUxARekSeRo qNGg== MIME-Version: 1.0 Received: by 10.60.11.68 with SMTP id o4mr945564oeb.89.1352212139989; Tue, 06 Nov 2012 06:28:59 -0800 (PST) Received: by 10.182.40.234 with HTTP; Tue, 6 Nov 2012 06:28:59 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 19:58:59 +0530 Message-ID: From: Nandita Dukkipati To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=e89a8fb2069c43da0604cdd46ca6 X-Gm-Message-State: ALoCoQlssGbVIQgdnENADNOkYpLvtUYSAKNTX7pq68EyNR3Bcuy6VH5suVPd9VZsihjaaHee/pQAXN4g8k7/SYE8mmL2ZMjJuiDUHmqp0IEcEQKYDAiAbRXS8eFGyGr3xp+lTK7iDw7HQXcCvgHQmZuMhoxF9vwsYXH6JbKGI+wAPe2ItHsrOaYogD2JfEla7XjQqvnoDyJK Cc: "tcpm@ietf.org" Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:29:01 -0000 --e89a8fb2069c43da0604cdd46ca6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 2, 2012 at 11:28 PM, Yoshifumi Nishida wrote: > Hi Nandita, > > I don't have specific scenarios in my mind yet. But, I personally would > like to support the idea for having a spec of FACK. I think FACK is a > worthy idea for the efforts and we can eliminate some ambiguity from the > TLP draft. > > On the other hand, I have another comment on the draft. > I'm assuming the draft is focusing on "probing" rather than "recovering". > Yes, probing is one of the main goals - to be able to elicit some ACKs from the receiver in the event of long silence periods. If the ACKs trigger recovery, that's good. > So, I'm wondering that even retransmitting small bytes (e.g. 1 byte) can > be useful for this purpose, although I might miss something. > You are spot on! In fact, this is one of the experiments we'll be trying out in next few days. I have checked that receiving SACK for 1-byte retransmission can also trigger FACK based fast recovery (or early retransmit depending on FlightSize) at least in Linux, so that's good. > > One tricky thing in TLP is you need to identify if packet loss is > recovered by only TLP. But, I guess there will be false positive cases in > some situations. If you retransmit small amount of data, I guess we can > avoid this and hence we can at least simplify the logic in the proposal. > Correct, this logic can be greatly simplified if we limit TLP retransmissions to 1-byte. As Yuchung also noted in his response, we are experimenting with both approaches: 1) loss detection using the dupack counting that the draft outlines; 2) limiting TLP retransmissions to 1-byte, in which case there's no extra logic needed to identify if TLP masked loss. An argument against 2) is that for short flows (extreme case FlightSize==1) it unnecessarily takes one extra RTT to retrans. the remainder of the segment. But I think the critical part is saving an RTO versus saving an RTT. Thanks! Nandita > > Thanks, > -- > Yoshifumi Nishida > > > > On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkipati wrote: > >> You are right that TLP as specified requires FACK based recovery. FACK >> is actually one of the most effective algorithms for loss recovery in >> our experiments and it's worthwhile having (reviving?) a concrete >> specification for FACK. Are there particular corner cases that you are >> concerned about? >> >> Nandita >> >> On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida >> wrote: >> > Hello, >> > >> > I'm reading the draft and I still need more time to think about this, >> but I >> > have one question to proceed.. >> > >> > It seems to me that TLP requires FACK-based recovery logic. >> > if RFC6675 is used instead, I'm guessing TLP probably won't be so useful >> > since it cannot recover all lost packets in some situations. >> > AFAIK we don't have a concrete specification for FACK. Hence, I have a >> > little concern that we cannot think about detailed corner cases for this >> > approach. >> > Any thoughts on this? >> > >> > Thanks, >> > -- >> > Yoshifumi Nishida >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> > >> > > --e89a8fb2069c43da0604cdd46ca6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= br>
On Fri, Nov 2, 2012 at 11:28 PM, Yoshifumi Ni= shida <nishida@sfc.wide.ad.jp> wrote:
Hi Nandita,
I don't have specific scenarios in my mind yet. But, I personally wou= ld like to support the idea for having a spec of FACK. I think FACK is a wo= rthy idea for the efforts and we can eliminate some ambiguity from the TLP = draft.

On the other hand, I have another comment on the draft.
I'm assu= ming the draft is focusing on "probing" rather than "recover= ing".
Yes, probing is one of the main goals - to = be able to elicit some ACKs from the receiver in the event of long silence = periods. If the ACKs trigger recovery, that's good.
=A0
So, I'm wondering that eve= n retransmitting small bytes (e.g. 1 byte) can be useful for this purpose, = although I might miss something.

You are spot on! In fact, this is one of t= he experiments we'll be trying out in next few days. I have checked tha= t receiving SACK for 1-byte retransmission can also trigger FACK based fast= recovery (or early retransmit depending on FlightSize) at least in Linux, = so that's good.
=A0

One tricky thing in TLP is you need to identify if packet loss is recov= ered by only TLP. But, I guess there will be false positive cases in some s= ituations. If you retransmit small amount of data, I guess we can avoid thi= s and hence we can at least simplify the logic in the proposal.

Correct, this logic can be greatly simplif= ied if we limit TLP retransmissions to 1-byte.

As = Yuchung also noted in his response, we are experimenting with both approach= es: 1) loss detection using the dupack counting that the draft outlines; 2)= limiting TLP retransmissions to 1-byte, in which case there's no extra= logic needed to identify if TLP masked loss.=A0

An argument against 2) is that for short flows (extreme= case FlightSize=3D=3D1) it unnecessarily takes one extra RTT to retrans. t= he remainder of the segment. But I think the critical part is saving an RTO= versus saving an RTT.

Thanks!
Nandita
=A0

Thanks,
--
Yoshifumi Nishida
=A0


On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkip= ati <nanditad@google.com> wrote:
You are right t= hat TLP as specified requires FACK based recovery. FACK
is actually one of the most effective algorithms for loss recovery in
our experiments and it's worthwhile having (reviving?) a concrete
specification for FACK. Are there particular corner cases that you are
concerned about?

Nandita

On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida
<nishida@sfc= .wide.ad.jp> wrote:
> Hello,
>
> I'm reading the draft and I still need more time to think about th= is, but I
> have one question to proceed..
>
> It seems to me that TLP requires FACK-based recovery logic.
> if RFC6675 is used instead, I'm guessing TLP probably won't be= so useful
> since it cannot recover all lost packets in some situations.
> AFAIK we don't have a concrete specification for FACK. Hence, I ha= ve a
> little concern that we cannot think about detailed corner cases for th= is
> approach.
> Any thoughts on this?
>
> Thanks,
> --
> Yoshifumi Nishida
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>


--e89a8fb2069c43da0604cdd46ca6-- From rs@netapp.com Tue Nov 6 10:26:47 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9994821F8A85 for ; Tue, 6 Nov 2012 10:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVuPZtG8fKrC for ; Tue, 6 Nov 2012 10:26:44 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id DA54921F8A6E for ; Tue, 6 Nov 2012 10:26:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,722,1344236400"; d="scan'208,217";a="707549360" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Nov 2012 10:26:43 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qA6IQhR1012569; Tue, 6 Nov 2012 10:26:43 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.165]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 10:26:43 -0800 From: "Scheffenegger, Richard" To: Nandita Dukkipati , Yuchung Cheng , "Matthew Mathis (mattmathis@google.com)" Thread-Topic: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 Thread-Index: AQHNuOPqBSXu52Pc8k6FEUHAnfX8SpfXCTYAgABBjACABh+xgP//ttZw Date: Tue, 6 Nov 2012 18:26:42 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D742921@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.114] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F0D742921SACEXCMBX02PRDh_" MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:26:47 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F0D742921SACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nandita, Yuchung, Matt, just to keep a record of the discussion around FACK on list. TLP refers to FACK for loss recovery. Matt mentioned on the microphone, tha= t RFC6675 does address FACK. Following the session, there were some discuss= ions around that comment. Even when RFC6675 (SACK) is combined with RFC5827 (Early Retransmit), there= are scenarios - and I think the more interesting ones - that are NOT trigg= ering loss recovery. RFC6675 has this text: (2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true -- indicating at least three segments have arrived above the current cumulative acknowledgment point, which is taken to indicate loss -- go to step (4). [loss recovery] IsLost (SeqNum): This routine returns whether the given sequence number is considered to be lost. The routine returns true when either DupThresh discontiguous SACKed sequences have arrived above 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence numbers greater than 'SeqNum' have been SACKed. Otherwise, the routine returns false. RFC5827 has this text: (2.a) The amount of outstanding data (ownd) -- data sent but not yet acknowledged -- is less than 4*SMSS bytes (as defined in [RFC5681]). [..] (2.b) There is either no unsent data ready for transmission at the sender, or the advertised receive window does not permit new segments to be transmitted. [..] When conditions (2.a) and (2.b) hold and a TCP connection does support SACK or SCTP is in use, Early Retransmit MUST be used only when "ownd - SMSS" bytes have been SACKed. With TLP, and a tail drop of a higher number of packets, loss recovery is n= ot entered, based on this. In the example given on the slides: 1 2 3 4 5 x x x x x, the number of outs= tanding segments (5) is larger than where Early Retransmit allows reducing = DupThresh. TLP resending segment 10 would trigger a single SACK packet, but= that wouldn't suffice to enter loss recovery. So, the draft would need to either define FACK, or have some text that afte= r TLP sends out a "rescue" retransmission, DupThresh has to be reduced to 1= temporarily, so that RFC6675 loss recovery triggers. Best regards, Richard Scheffenegger From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Nan= dita Dukkipati Sent: Dienstag, 06. November 2012 15:29 To: Yoshifumi Nishida Cc: tcpm@ietf.org Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00 On Fri, Nov 2, 2012 at 11:28 PM, Yoshifumi Nishida > wrote: Hi Nandita, I don't have specific scenarios in my mind yet. But, I personally would lik= e to support the idea for having a spec of FACK. I think FACK is a worthy i= dea for the efforts and we can eliminate some ambiguity from the TLP draft. On the other hand, I have another comment on the draft. I'm assuming the draft is focusing on "probing" rather than "recovering". Yes, probing is one of the main goals - to be able to elicit some ACKs from= the receiver in the event of long silence periods. If the ACKs trigger rec= overy, that's good. So, I'm wondering that even retransmitting small bytes (e.g. 1 byte) can be= useful for this purpose, although I might miss something. You are spot on! In fact, this is one of the experiments we'll be trying ou= t in next few days. I have checked that receiving SACK for 1-byte retransmi= ssion can also trigger FACK based fast recovery (or early retransmit depend= ing on FlightSize) at least in Linux, so that's good. One tricky thing in TLP is you need to identify if packet loss is recovered= by only TLP. But, I guess there will be false positive cases in some situa= tions. If you retransmit small amount of data, I guess we can avoid this an= d hence we can at least simplify the logic in the proposal. Correct, this logic can be greatly simplified if we limit TLP retransmissio= ns to 1-byte. As Yuchung also noted in his response, we are experimenting with both appro= aches: 1) loss detection using the dupack counting that the draft outlines;= 2) limiting TLP retransmissions to 1-byte, in which case there's no extra = logic needed to identify if TLP masked loss. An argument against 2) is that for short flows (extreme case FlightSize=3D= =3D1) it unnecessarily takes one extra RTT to retrans. the remainder of the= segment. But I think the critical part is saving an RTO versus saving an R= TT. Thanks! Nandita Thanks, -- Yoshifumi Nishida On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkipati > wrote: You are right that TLP as specified requires FACK based recovery. FACK is actually one of the most effective algorithms for loss recovery in our experiments and it's worthwhile having (reviving?) a concrete specification for FACK. Are there particular corner cases that you are concerned about? Nandita On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida > wrote: > Hello, > > I'm reading the draft and I still need more time to think about this, but= I > have one question to proceed.. > > It seems to me that TLP requires FACK-based recovery logic. > if RFC6675 is used instead, I'm guessing TLP probably won't be so useful > since it cannot recover all lost packets in some situations. > AFAIK we don't have a concrete specification for FACK. Hence, I have a > little concern that we cannot think about detailed corner cases for this > approach. > Any thoughts on this? > > Thanks, > -- > Yoshifumi Nishida > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --_000_012C3117EDDB3C4781FD802A8C27DD4F0D742921SACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

Hi Nandita= , Yuchung, Matt,

 = ;

just to ke= ep a record of the discussion around FACK on list.

 = ;

 = ;

TLP refers= to FACK for loss recovery. Matt mentioned on the microphone, that RFC6675 = does address FACK. Following the session, there were some discussions around that comment.

 = ;

Even when = RFC6675 (SACK) is combined with RFC5827 (Early Retransmit), there are scena= rios – and I think the more interesting ones – that are NOT triggering loss recovery.

 = ;

RFC6675 ha= s this text:

 = ;

(2) If DupAcks < DupThresh&n= bsp;but IsLost (HighACK + 1) returns true=  --
       indicating at least&nbs= p;three segments have arrived above the curre= nt
       cumulative acknowledgment&nb= sp;point, which is taken to indicate loss
       -- go to step = ;(4). [loss recovery]

 = ;

IsLost (SeqNum):

      This routi= ne returns whether the given sequence number&= nbsp;is
      considered to be lost.&n= bsp; The routine returns true when either
      DupThresh discontiguous SACKe= d sequences have arrived above
      'SeqNum' or more than&nb= sp;(DupThresh - 1) * SMSS bytes with seq= uence
      numbers greater than 'Se= qNum' have been SACKed.  Otherwise, th= e
      routine returns false.

 

 

RFC5827 ha= s this text:

 = ;

(2.a) The amount of outstanding data (ownd)= -- data sent but not yet

       &= nbsp; acknowledged -- is less than 4*SMSS bytes (as defined in

       &= nbsp; [RFC5681]).

[..]<= /o:p>

(2.b) There is either no unsent data ready for tr=
ansmission at the
         =
sender, or the advertised receive window does not permit new
         =
segments to be transmitted.

[..]<= /o:p>

When conditions (2.a) and (2.b) hold and a TCP co=
nnection does
   support SACK or SCTP is in use, Earl=
y Retransmit MUST be used only
   when "ownd - SMSS" bytes h=
ave been SACKed.

 = ;

 = ;

With TLP, = and a tail drop of a higher number of packets, loss recovery is not entered= , based on this.

 = ;

In the exa= mple given on the slides: 1 2 3 4 5 x x x x x, the number of outstanding se= gments (5) is larger than where Early Retransmit allows reducing DupThresh. TLP resending segment 10 would trigger a single SACK packet, bu= t that wouldn’t suffice to enter loss recovery.

 = ;

So, the dr= aft would need to either define FACK, or have some text that after TLP send= s out a “rescue” retransmission, DupThresh has to be reduced to 1 temporarily, so that RFC6675 loss recovery triggers.

 = ;

Best regar= ds,

 = ;

Richard Scheffenegger

 <= /p>

From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Nandita Dukkipati
Sent: Dienstag, 06. November 2012 15:29
To: Yoshifumi Nishida
Cc: tcpm@ietf.org
Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00

 

 

On Fri, Nov 2, 2012 at 11:28 PM, Yoshifum= i Nishida <n= ishida@sfc.wide.ad.jp> wrote:

Hi Nandita,

I don't have specific scenarios in my mind yet. But, I personally would lik= e to support the idea for having a spec of FACK. I think FACK is a worthy i= dea for the efforts and we can eliminate some ambiguity from the TLP draft.=

On the other hand, I have another comment on the draft.
I'm assuming the draft is focusing on "probing" rather than "= ;recovering".

Yes, probing is one of the main goals - t= o be able to elicit some ACKs from the receiver in the event of long silenc= e periods. If the ACKs trigger recovery, that's good.

 

So, I'm wondering that even retransmittin= g small bytes (e.g. 1 byte) can be useful for this purpose, although I migh= t miss something.

 

You are spot on! In fact, this is one of = the experiments we'll be trying out in next few days. I have checked that r= eceiving SACK for 1-byte retransmission can also trigger FACK based fast recovery (or early retransmit depending on FlightSize) at = least in Linux, so that's good.

 


One tricky thing in TLP is you need to identify if packet loss is recovered= by only TLP. But, I guess there will be false positive cases in some situa= tions. If you retransmit small amount of data, I guess we can avoid this an= d hence we can at least simplify the logic in the proposal.

 

Correct, this logic can be greatly simpli= fied if we limit TLP retransmissions to 1-byte.

 

As Yuchung also noted in his response, we= are experimenting with both approaches: 1) loss detection using the dupack= counting that the draft outlines; 2) limiting TLP retransmissions to 1-byte, in which case there's no extra logic needed to identify if TLP = masked loss. 

 

An argument against 2) is that for short = flows (extreme case FlightSize=3D=3D1) it unnecessarily takes one extra RTT= to retrans. the remainder of the segment. But I think the critical part is saving an RTO versus saving an RTT.

 

Thanks!

Nandita

 


Thanks,
--
Yoshifumi Nishida
 

On Fri, Nov 2, 2012 at 7:03 AM, Nandita D= ukkipati <nandi= tad@google.com> wrote:

You are right that TLP as specified requi= res FACK based recovery. FACK
is actually one of the most effective algorithms for loss recovery in
our experiments and it's worthwhile having (reviving?) a concrete
specification for FACK. Are there particular corner cases that you are
concerned about?

Nandita


On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida
<nishida@sfc= .wide.ad.jp> wrote:
> Hello,
>
> I'm reading the draft and I still need more time to think about this, = but I
> have one question to proceed..
>
> It seems to me that TLP requires FACK-based recovery logic.
> if RFC6675 is used instead, I'm guessing TLP probably won't be so usef= ul
> since it cannot recover all lost packets in some situations.
> AFAIK we don't have a concrete specification for FACK. Hence, I have a=
> little concern that we cannot think about detailed corner cases for th= is
> approach.
> Any thoughts on this?
>
> Thanks,
> --
> Yoshifumi Nishida
>

> ____________________________________= ___________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>

 

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F0D742921SACEXCMBX02PRDh_-- From rs@netapp.com Wed Nov 7 05:10:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B6D21F8B32 for ; Wed, 7 Nov 2012 05:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnPH28DxR7+n for ; Wed, 7 Nov 2012 05:10:23 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7000D21F8B26 for ; Wed, 7 Nov 2012 05:10:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,730,1344236400"; d="scan'208,217";a="707802406" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Nov 2012 05:10:23 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qA7DAMmd012562; Wed, 7 Nov 2012 05:10:23 -0800 (PST) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 7 Nov 2012 05:10:22 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.165]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 05:10:22 -0800 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" , "iccrg@cs.ucl.ac.uk" Thread-Topic: ECN feedback discussion Thread-Index: Ac2856olwNIvlhLtTBm8IfAfhj0+sQ== Date: Wed, 7 Nov 2012 13:10:21 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F0D7446A5SACEXCMBX02PRDh_" MIME-Version: 1.0 Subject: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Nov 2012 13:10:25 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F0D7446A5SACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just wanted to keep a record of these interesting remarks on the list, fo= r further discussion. We discussed ECN both in TCPM and ICCRG, and this post is to start the disc= ussion on the working group lists. During the TCPM session, Matt Mathis made an interesting remark on the micr= ophone. To paraphrase (my understanding), current marking schemes (RED, CoD= el, PIE,...) assume that ECN marks get treated like loss by the end systems= . Therefore, they employ a "low density" marking scheme, with marks expect= ed at an (average) rate of around 3% or so at maximum. Alternative schemes, that start getting deployed at this time, have very si= mple marking schemes in the network, and give more information to the end s= ystems for processing and reaction there. As a side effect, these newer sch= emes may run as high as 100% marking for certain periods (longer than a sin= gle flows RTT), so they could be classified as "high density" marking schem= e. Later on, Bob noted, that since ECN Nonce is virtually nonexistent (I know = only one stack with partial support), why not re-define ECT(1) to be used b= y high density marking schemes, keeping ECT(0) for low density schemes (as = deployed today). For newer stacks, this would allow an even more fine grain= ed reaction to ECN marking levels... However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the same = meaning for existing ECN stacks as ECT(0)) would not be addressed, but then= again, current ECN is also virtually not deployed, according to recent stu= dies. Of course, such a shift in the semantics of ECT(0) vs ECT(1) would also nee= d to have an impact on the future signaling / feedback scheme used for TCP= (DCCP and SCTP would be able to cope already, afaik). Best regards, Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F0D7446A5SACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I just wanted to keep a record of these interesting remarks on the lis= t, for further discussion.
 
We discussed ECN both in TCPM and ICCRG, and this post is to start the= discussion on the working group lists.
 
During the TCPM session, Matt Mathis made an interesting remark on the= microphone. To paraphrase (my understanding), current marking schemes (RED= , CoDel, PIE,…) assume that ECN marks get treated like loss by the en= d systems.  Therefore, they employ a “low density” marking scheme, with marks expected at an (average) rate of = around 3% or so at maximum.
 
Alternative schemes, that start getting deployed at this time, have ve= ry simple marking schemes in the network, and give more information to the = end systems for processing and reaction there. As a side effect, these newe= r schemes may run as high as 100% marking for certain periods (longer than a single flows RTT), so they could= be classified as “high density” marking scheme.
 
 
Later on, Bob noted, that since ECN Nonce is virtually nonexistent (I = know only one stack with partial support), why not re-define ECT(1) to be u= sed by high density marking schemes, keeping ECT(0) for low density schemes= (as deployed today). For newer stacks, this would allow an even more fine grained reaction to ECN marking = levels…
 
However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the = same meaning for existing ECN stacks as ECT(0)) would not be addressed, but= then again, current ECN is also virtually not deployed, according to recen= t studies.
 
Of course, such a shift in the semantics of ECT(0) vs ECT(1) would als= o need to have an impact on the future signaling  / feedback scheme us= ed for TCP (DCCP and SCTP would be able to cope already, afaik).
 
Best regards,
 
Richard Scheffenegger
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F0D7446A5SACEXCMBX02PRDh_-- From michawe@ifi.uio.no Wed Nov 7 05:14:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FAB21F8B4F for ; Wed, 7 Nov 2012 05:14:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XMrWkh0Xq-x for ; Wed, 7 Nov 2012 05:14:13 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id A481021F8B4D for ; Wed, 7 Nov 2012 05:14:12 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TW5SN-0003eH-Ij; Wed, 07 Nov 2012 14:14:11 +0100 Received: from vpn-client386.uio.no ([193.157.137.133] helo=[10.71.12.152]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TW5SM-0001Bm-QC; Wed, 07 Nov 2012 14:14:11 +0100 Message-Id: From: Michael Welzl To: "Scheffenegger, Richard" In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Nov 2012 14:14:06 +0100 References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 5 sum rcpts/h 9 sum msgs/h 6 total rcpts 25403 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.608, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EA65AF23BC352FACE4F381187BD10A4FF53D32F7 X-UiO-SPAM-Test: remote_host: 193.157.137.133 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 635 max/h 14 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Nov 2012 13:14:13 -0000 Great idea, I'd love for this semantic shift to happen! On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: > Hi, > > I just wanted to keep a record of these interesting remarks on the =20 > list, for further discussion. > > We discussed ECN both in TCPM and ICCRG, and this post is to start =20 > the discussion on the working group lists. > > During the TCPM session, Matt Mathis made an interesting remark on =20 > the microphone. To paraphrase (my understanding), current marking =20 > schemes (RED, CoDel, PIE,=85) assume that ECN marks get treated like =20= > loss by the end systems. Therefore, they employ a =93low density=94 =20= > marking scheme, with marks expected at an (average) rate of around =20 > 3% or so at maximum. > > Alternative schemes, that start getting deployed at this time, have =20= > very simple marking schemes in the network, and give more =20 > information to the end systems for processing and reaction there. As =20= > a side effect, these newer schemes may run as high as 100% marking =20 > for certain periods (longer than a single flows RTT), so they could =20= > be classified as =93high density=94 marking scheme. > > > Later on, Bob noted, that since ECN Nonce is virtually nonexistent =20 > (I know only one stack with partial support), why not re-define =20 > ECT(1) to be used by high density marking schemes, keeping ECT(0) =20 > for low density schemes (as deployed today). For newer stacks, this =20= > would allow an even more fine grained reaction to ECN marking levels=85 > > However, ECN security aspects (Nonce) and legacy uses (ECT(1) has =20 > the same meaning for existing ECN stacks as ECT(0)) would not be =20 > addressed, but then again, current ECN is also virtually not =20 > deployed, according to recent studies. > > Of course, such a shift in the semantics of ECT(0) vs ECT(1) would =20 > also need to have an impact on the future signaling / feedback =20 > scheme used for TCP (DCCP and SCTP would be able to cope already, =20 > afaik). > > Best regards, > > Richard Scheffenegger > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Wed Nov 7 09:16:21 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC2021F88EA for ; Wed, 7 Nov 2012 09:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0l9bfG5sjL2 for ; Wed, 7 Nov 2012 09:16:20 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id F2C0121F87E3 for ; Wed, 7 Nov 2012 09:16:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,730,1344236400"; d="scan'208,217";a="707885824" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Nov 2012 09:16:19 -0800 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qA7HGITO010701; Wed, 7 Nov 2012 09:16:18 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.165]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 09:16:18 -0800 From: "Scheffenegger, Richard" To: "Matthew Mathis (mattmathis@google.com)" , "Mirja Kuehlewind" , Mark Allman Thread-Topic: 1323bis Thread-Index: Ac29CUh07utru2dyQX2IAPkjxClUBQ== Date: Wed, 7 Nov 2012 17:16:18 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D745B07@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F0D745B07SACEXCMBX02PRDh_" MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] 1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:16:21 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F0D745B07SACEXCMBX02PRDh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Matt, Mirja, Kevin, Michael Welzl just mentioned one old paper where this was looked into, and = also I believe Mark Allman brought this up... With 1323 TS, timing every packet changes the dynamics (in the time domain)= how fast sRTT / sRTTvar converge... With only one sample per RTT, the convergence time is measured in a couple = of RTTs up to a dozend of RTTs; however, with per-packet RTT sampling, and = the same static weight factors, the effective convergence time of sRTT / sR= TTvar get mich faster than this - with large windows even shorter than a si= ngle RTT... Should 1323bis give some definitive guidance to make the weight factors, an= d thus the convergence time, dynamic (something proportional to cwnd/SMSS p= erhaps), so that RTT convergence (more importantly, RTO) is somewhat slower= ? Right now, the wording is rather vague in this aspect in 1323bis: Implementors should note that with Timestamps multiple RTTMs can be taken per RTT. Many RTO estimators have a weighting factor based on an implicit assumption that at most one RTTM will be gotten per RTT. When using multiple RTTMs per RTT to update the RTO estimator, the weighting factor needs to be decreased to take into account the more frequent RTTMs. For example, an implementation could choose to just use one sample per RTT to update the RTO estimator, or vary the gain based on the congestion window, or take an average of all the RTTM measurements received over one RTT, and then use that value to update the RTO estimator. This document does not prescribe any particular method for modifying the RTO estimator, the important point is that the implementation should do something more than just feeding additional RTTM samples from one RTT into the RTO estimator. (unless a definitive new default is prescribed, an implementer will propabl= y "do nothing", ie. continue use the static weight factor.) Also, would that section of text (since it's probably an important aspect) = warrant to be promoted to its own subsection (4.x)? Best regards, Richard Scheffenegger NetApp rs@netapp.com +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com EURO PLAZA Geb=E4ude G, Stiege 7, 3.OG Am Euro Platz 2 A-1120 Wien --_000_012C3117EDDB3C4781FD802A8C27DD4F0D745B07SACEXCMBX02PRDh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Matt, Mirja, Kevin,
 
Michael Welzl just mentioned one old paper where this was looked into,= and also I believe Mark Allman brought this up...
 
With 1323 TS, timing every packet changes the dynamics (in the time do= main) how fast sRTT / sRTTvar converge…
 
With only one sample per RTT, the convergence time is measured in a co= uple of RTTs up to a dozend of RTTs; however, with per-packet RTT sampling,= and the same static weight factors, the effective convergence time of sRTT= / sRTTvar get mich faster than this – with large windows even shorter than a single RTT…
 
Should 1323bis give some definitive guidance to make the weight factor= s, and thus the convergence time, dynamic (something proportional to cwnd/S= MSS perhaps), so that RTT convergence (more importantly, RTO) is somewhat s= lower?
 
Right now, the wording is rather vague in this aspect in 1323bis:
 
=    Implementors should note that with Timestamps multiple RTTMs c= an be
=    taken per RTT.  Many RTO estimators have a weighting fact= or based on
=    an implicit assumption that at most one RTTM will be gotten pe= r RTT.
=    When using multiple RTTMs per RTT to update the RTO estimator,= the
=    weighting factor needs to be decreased to take into account th= e more
=    frequent RTTMs.  For example, an implementation could cho= ose to just
=    use one sample per RTT to update the RTO estimator, or vary th= e gain
=    based on the congestion window, or take an average of all the = RTTM
=    measurements received over one RTT, and then use that value to= update
=    the RTO estimator.  This document does not prescribe any = particular
=    method for modifying the RTO estimator, the important point is= that
=    the implementation should do something more than just feeding<= /span>
=    additional RTTM samples from one RTT into the RTO estimator.
 
(unless a definitive new default is prescribed, an implementer will pr= opably “do nothing”, ie. continue use the static weight factor.= )
 
Also, would that section of text (since it’s probably an importa= nt aspect) warrant to be promoted to its own subsection (4.x)?
 
Best regards,
 
Richard Scheffenegger

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

EURO PLAZA
Geb=E4ude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien
 
 
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F0D745B07SACEXCMBX02PRDh_-- From michael.scharf@alcatel-lucent.com Wed Nov 7 09:31:00 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0694721F8C57 for ; Wed, 7 Nov 2012 09:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQxzL4qcf69A for ; Wed, 7 Nov 2012 09:30:59 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id BD51621F8C50 for ; Wed, 7 Nov 2012 09:30:58 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA7HRLsA015557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Nov 2012 18:30:51 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 7 Nov 2012 18:30:43 +0100 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "Matthew Mathis (mattmathis@google.com)" , "Mirja Kuehlewind" , Mark Allman Date: Wed, 7 Nov 2012 18:30:42 +0100 Thread-Topic: 1323bis Thread-Index: Ac29CUh07utru2dyQX2IAPkjxClUBQAA3QJQ Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A7E4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D745B07@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D745B07@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] 1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:31:00 -0000 Richard, > Should 1323bis give some definitive guidance to make the=20 > weight factors, and thus the convergence time, dynamic=20 > (something proportional to cwnd/SMSS perhaps), so that RTT=20 > convergence (more importantly, RTO) is somewhat slower? As a researcher who looked into this question some 10 years ago (Linux alre= ady used a different estimator with other weight factors those days), I thi= nk that RTO estimator details don't really belong into 1323bis. Specificall= y, I doubt that we we should define specific weight factors in 1323bis. My take is that the filter design is mostly orthogonal to the measurement m= ethod - except that a warning sign for users of timestamps is clearly neede= d. Michael From john@jlc.net Wed Nov 7 09:59:19 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09AE21F8C59 for ; Wed, 7 Nov 2012 09:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7GDOY2T9myr for ; Wed, 7 Nov 2012 09:59:19 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 32AF721F8C50 for ; Wed, 7 Nov 2012 09:59:19 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D517733ED1; Wed, 7 Nov 2012 12:59:18 -0500 (EST) Date: Wed, 7 Nov 2012 12:59:18 -0500 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20121107175918.GC78300@verdi> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Nov 2012 17:59:19 -0000 Scheffenegger, Richard wrote: > > During the TCPM session, Matt Mathis made an interesting remark on the > microphone. To paraphrase (my understanding), current marking schemes > (RED, CoDel, PIE,...) assume that ECN marks get treated like loss by > the end systems. Therefore, they employ a "low density" marking scheme, > with marks expected at an (average) rate of around 3% or so at maximum. Actually, 3% loss is pretty bad, and 3% ECN-marking would be very much worth avoiding. Nonetheless, "low-density" can rise that high without seriously damaging the transport. > Alternative schemes, that start getting deployed at this time, have > very simple marking schemes in the network, and give more information > to the end systems for processing and reaction there. As a side effect, > these newer schemes may run as high as 100% marking for certain periods > (longer than a single flows RTT), so they could be classified as > "high density" marking scheme. DCTCP fits this model. Alas, I don't think we all understand it... > Later on, Bob noted, that since ECN Nonce is virtually nonexistent > (I know only one stack with partial support), why not re-define ECT(1) > to be used by high density marking schemes, keeping ECT(0) for low > density schemes (as deployed today). This would have been a much better initial design! > For newer stacks, this would allow an even more fine grained reaction > to ECN marking levels... With 100% deployment, yes... > However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the > same meaning for existing ECN stacks as ECT(0)) would not be addressed, It might be possible to define a protocol for sender and receiver to agree to treat ECT(1) this way; but I'm not optimistic about adoption. It should be workable for research, though... > but then again, current ECN is also virtually not deployed, according > to recent studies. There's quite a bit of "deployed but disabled" AFAICT. > Of course, such a shift in the semantics of ECT(0) vs ECT(1) would > also need to have an impact on the future signaling / feedback scheme > used for TCP (DCCP and SCTP would be able to cope already, afaik). I believe SCTP could, with near-trivial changes, get both ends to agree on this difference for ECT(1). I'm not familiar enough with DCCP to say for sure, but at first blush it appears there are enough reserved bits to adapt. (It looks non-trivial, though.) Looking ahead, I doubt that two flavors of ECN will be sufficient for all needs. Getting beyond one flavor is _very_ much worth doing; but I think we need a final target of at least eight flavors. -- John Leslie From mattmathis@google.com Wed Nov 7 10:59:14 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A143821F8A7E for ; Wed, 7 Nov 2012 10:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwhgBc6jIMfc for ; Wed, 7 Nov 2012 10:59:14 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E464321F86DE for ; Wed, 7 Nov 2012 10:59:13 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id fm10so3241991wgb.1 for ; Wed, 07 Nov 2012 10:59:13 -0800 (PST) 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:content-transfer-encoding; bh=XiBh94ZT9vms4zB41Amy8av1rFOUU9XttNd0PAg6KrM=; b=S0cJ/wlBaoXlaKEiVVSTUXVXDJ3c9cg7D57vjIXgLU3Hzzs9Ovl9UDVBZzhFxotBa7 4KidNMISh6pTYAmMj4KjMpkAcWbzFRYUNTuxqMjU2qaKxDOie248t1JYYZZlqdFZ9F2q XTYhZbgiw5gZM7ODVzwMI6l+tUb9uHdacfLsXmwGoIE6D6r1GlypXJikSc7mv/fatLUY ZJB/VwG1FgNfYilvquLMVbb6qxvBFVKAcBbRVkRqItAfDhUghe24iEggdZ9MPfihdgpx NhjSI9aP3cRIgPXFhDrqDMycQln2Wg9yN2WEdBlJatkW/Xf1nWhJ4T+WEEWKknnezDX4 lvsw== 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:content-transfer-encoding:x-gm-message-state; bh=XiBh94ZT9vms4zB41Amy8av1rFOUU9XttNd0PAg6KrM=; b=OYtSbTJHs/jM1IWj71dlttZtFpwnK2Kl9vs2drvWJY72UYq7jRpmU0L4meuwj8pqyQ iKV9XblwSm2e+4LHOkg3I763Ae8TierbkZyQ2FiMufJL3mx5KHYRfii6wMZum/Q39bGA jFRQ2TUeHPMM58en0L/90exU7Xatxpu3x7Ze6oAOIAGCYV8EXHZo0aDnWniyNuWj8o+e 9xlafXKSFzPeQ+3m4uvIHiMy0QdNe/lxSuud66IDipjYZtmnLmy04nztFn5UYuu1ZkNG Re3CUmhaPN4P5/tOPeYZmMQViJew5jjO2jgViWbLK2GLbZ0tY43Srm5X0mp15mb410IM dQnQ== MIME-Version: 1.0 Received: by 10.216.217.38 with SMTP id h38mr2121661wep.82.1352314753013; Wed, 07 Nov 2012 10:59:13 -0800 (PST) Received: by 10.194.56.133 with HTTP; Wed, 7 Nov 2012 10:59:12 -0800 (PST) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A7E4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D745B07@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A7E4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Wed, 7 Nov 2012 10:59:12 -0800 Message-ID: From: Matt Mathis To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn2D0tIUyHc3pL6CM8lKTkvAqA44nJqQQG3QpNxc4+XtHPuOdYbYNWYkKopEsN31XNes2DnRNQkTEEDHmtcsjQMEFCxpovP0GmRuxAMpDbdhah8s50HqKuwHG+7YSGGHw8iQhlZRl1OEqbgzWBBdbEuEpx8AVOxSxqHOr4tgqA+DS1eZkK1VIcw0mlHqO/Sw4C/8Yby Cc: "tcpm \(tcpm@ietf.org\)" , Mark Allman Subject: Re: [tcpm] 1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:59:14 -0000 I like your answer a lot. "In absence of other recommendations refer to the (not fully deprecated) text in RFC1323". As a general principle lets crisp up document scopes! Thank,s --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Wed, Nov 7, 2012 at 9:30 AM, Scharf, Michael (Michael) wrote: > Richard, > >> Should 1323bis give some definitive guidance to make the >> weight factors, and thus the convergence time, dynamic >> (something proportional to cwnd/SMSS perhaps), so that RTT >> convergence (more importantly, RTO) is somewhat slower? > > As a researcher who looked into this question some 10 years ago (Linux al= ready used a different estimator with other weight factors those days), I t= hink that RTO estimator details don't really belong into 1323bis. Specifica= lly, I doubt that we we should define specific weight factors in 1323bis. > > My take is that the filter design is mostly orthogonal to the measurement= method - except that a warning sign for users of timestamps is clearly nee= ded. > > Michael > From michael.scharf@alcatel-lucent.com Wed Nov 7 11:06:36 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867E221F8CA2 for ; Wed, 7 Nov 2012 11:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.578 X-Spam-Level: X-Spam-Status: No, score=-7.578 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMjGX5E+-ge0 for ; Wed, 7 Nov 2012 11:06:36 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id C631021F8C61 for ; Wed, 7 Nov 2012 11:06:35 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA7J5stQ013228 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Nov 2012 20:06:31 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 7 Nov 2012 20:06:10 +0100 From: "Scharf, Michael (Michael)" To: Matt Mathis Date: Wed, 7 Nov 2012 20:06:10 +0100 Thread-Topic: 1323bis Thread-Index: Ac29Gf0YWaubt4LMS+2A1ox++iI+YAAAKWOw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A7EE@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D745B07@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A7E4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm \(tcpm@ietf.org\)" , Mark Allman Subject: Re: [tcpm] 1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:06:36 -0000 For what it is worth: IMHO the paragraph (or a variant thereof) should be i= n 1323bis, too. Implementors should find the warning sign easily. Michael=20 > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com]=20 > Sent: Wednesday, November 07, 2012 7:59 PM > To: Scharf, Michael (Michael) > Cc: Scheffenegger, Richard; Mirja Kuehlewind; Mark Allman;=20 > tcpm (tcpm@ietf.org) > Subject: Re: 1323bis >=20 > I like your answer a lot. "In absence of other recommendations > refer to the (not fully deprecated) text in RFC1323". >=20 > As a general principle lets crisp up document scopes! >=20 > Thank,s > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because=20 > for some users, they are. >=20 >=20 > On Wed, Nov 7, 2012 at 9:30 AM, Scharf, Michael (Michael)=20 > wrote: > > Richard, > > > >> Should 1323bis give some definitive guidance to make the weight=20 > >> factors, and thus the convergence time, dynamic (something=20 > >> proportional to cwnd/SMSS perhaps), so that RTT convergence (more=20 > >> importantly, RTO) is somewhat slower? > > > > As a researcher who looked into this question some 10 years=20 > ago (Linux already used a different estimator with other=20 > weight factors those days), I think that RTO estimator=20 > details don't really belong into 1323bis. Specifically, I=20 > doubt that we we should define specific weight factors in 1323bis. > > > > My take is that the filter design is mostly orthogonal to=20 > the measurement method - except that a warning sign for users=20 > of timestamps is clearly needed. > > > > Michael > > > = From michael.scharf@alcatel-lucent.com Wed Nov 7 11:23:36 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36D121F87E7; Wed, 7 Nov 2012 11:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.636 X-Spam-Level: X-Spam-Status: No, score=-7.636 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI5bEruzfnJH; Wed, 7 Nov 2012 11:23:35 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 622CA21F8B7A; Wed, 7 Nov 2012 11:23:34 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA7JNUaW019438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Nov 2012 20:23:30 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 7 Nov 2012 20:23:30 +0100 From: "Scharf, Michael (Michael)" To: "iesg-secretary@ietf.org" , "tcpm-ads@tools.ietf.org" Date: Wed, 7 Nov 2012 20:23:31 +0100 Thread-Topic: Publication request for draft-ietf-tcpm-experimental-options-02 Thread-Index: Ac29HV8b/A+3e+QcR3+1OcttB0HWlA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A7EF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] Publication request for draft-ietf-tcpm-experimental-options-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Nov 2012 19:23:37 -0000 The TCPM working group requests publication of draft-ietf-tcpm-experimental= -options-02 as Proposed Standard RFC. The Document Shepherd is Michael Scharf = . The write-up is attached below. Thanks Michael (TCPM co-chair) ****************************** Writeup for draft-ietf-tcpm-experimental-options-02 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is requested for publication as Proposed Standard, as indicated on the title page. =20 Early individual versions of the document were heading towards Informational status, but community feedback suggested that a target status of Proposed Standard would be more appropriate, given that the protocol specification is expected to be used by running applications. The document was accepted by the TCPM working group as a standards track document. There was a brief discussion whether the status could be BCP, but the document contains a technical protocol specification that could be updated in future. In summary, Proposed Standard seems the proper type. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document 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=20 require extensive technical review. Personnel The document sheperd is Michael Scharf . The responsible Area Director is Wesley Eddy . (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document sheperd has reviewed the latest version of the document, as well as previous versions. He has also reviewed the single last call comment, which did not require a document update. The document is therefore considered ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? =20 No. =20 (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. =20 (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. In the document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. =20 A reader of the document was apparently confused by that markers, probably because he skipped Section 2, where this notation is explained. The document sheperd believes that it is up to the RFC editor to decide whether to use those markers in the final RFC text, and possibly to remove them. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. The author has confirmed that he is not aware of any IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure has been filed. (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20 The document was reviewed and explicitly supported by multiple key contributors to the TCPM working group. There was no objection. The chairs therefore conclude that there is strong working group consensus that this document should be published. In addition, first implementions of new experimental protocols already use the mechanism. This confirms that the mechanism is accepted by the TCP implementation community. =20 The document explicitly allows use of existing, accepted IETF processes to obtain a dedicated TCP option codepoint for a new protocol. Feedback in the TCPM working group indicates that this process continues to make sense in selected cases for experimental protocols (a recent example is MPTCP), possibly after careful analysis. Such cases are in line with what this document describes. =20 As mentioned in the document, certain TCP options are known to be used by protocols without or with only limited involvment of the IETF and, most notably, the TCPM working group. This document enables a much simpler use of the existing experimental codepoints for such protocols. It remains to be seen whether unauthorized use of TCP option codepoints in deployed code will migrate towards the mechanism specified in this document. Users of unauthorized TCP option codepoints are often silent in the TCPM working group. =20 (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No issues found in the document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published. =20 (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in=20 the Last Call procedure. No. =20 (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document does not change the status of any existing RFC. It describes an additional mechanism to facilitate shared use of the codepoints definied in RFC 4727. But given that RFC 4727 is not modified, no update is required. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The key objective of this document is to enable experimental use of TCP options without any new IANA registry. The TCPM working group has discussed use of IANA registries for the experimental magic numbers and concluded that a mechanism with less overhead would be preferable. It is expected that sufficiently stable protocols will request a dedicated TCP option codepoint via the existing IETF process (e. g., Standard Track document or IESG action) and use the existing IANA registry. For other protocols, it is difficult to track the actual use of magic numbers. Therefore, the document permits experiments to use an experimental magic number without IANA involvement. =20 It is suggested that Internet Drafts documenting an experimental procotol specify the magic number in their document. Given that the value is not managed by IANA, such documentation can be anywhere in a draft, i. e., it does not have to be in the IANA section. It is up to the experiment to use a magic number with low risk of collissions. It has been recommended that magic numbers are posted for information to the TCPM mailing list, and this mechanism has already been used by all known users of this specification. It is expected that the collision probability for experiments resulting from that process is extremely small. Protocols can be expected to migrate to a dedicated TCP option codepoint managed by the existing IANA process prior to Internet-scale deployment. =20 In summary, this document does inherently not require any IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The objective of this document is to avoid new IANA registries, because it is impossible to track the use of TCP extensions used by certain experiments. The existing IANA registry for TCP option codepoints is not affected by this document, since the process for allocating a dedicated TCP option codepoint does not change. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document does not contain such sections. From gorry@erg.abdn.ac.uk Thu Nov 8 04:30:26 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8557F21F880F for ; Thu, 8 Nov 2012 04:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPLn5GpdUfU5 for ; Thu, 8 Nov 2012 04:30:26 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id AE7A321F8802 for ; Thu, 8 Nov 2012 04:30:25 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 168352B43B2; Thu, 8 Nov 2012 12:30:24 +0000 (GMT) Received: from 2001:df8:0:64:5ab0:35ff:fe7b:b828 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 8 Nov 2012 12:30:24 -0000 Message-ID: In-Reply-To: References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 8 Nov 2012 12:30:24 -0000 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 12:30:26 -0000 I'm also really interested in doing better than current ECN. ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the reaction is defined in the (still) experimental RFC 3540. The ECN nonce can detect remarking NON-ECT packets to ECT and can also detect misbehaving transport receivers hiding CE from the transport sender. My own opinion is that if we do see more deployment of ECN (I do hope so) - we do need this sort of mechanism, not to verify every segment, but at least to be able to detect paths/endpoints where the ACK information is simply invalid. DCCP was mentioned in the thread, RFC 4340, took the view that ECN nonce needed to be supported and the ECN Nonce Echo field is encoded in acknowledgement options. "Each DCCP sender SHOULD set ECN Nonces on its packets and remember which packets had nonces." Gorry P.S. Also note, if we do get to plans for new use of ECN this is likely to be a TSVWG item - since it effects much more than TCP. > Great idea, I'd love for this semantic shift to happen! > > > On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: > >> Hi, >> >> I just wanted to keep a record of these interesting remarks on the >> list, for further discussion. >> >> We discussed ECN both in TCPM and ICCRG, and this post is to start >> the discussion on the working group lists. >> >> During the TCPM session, Matt Mathis made an interesting remark on >> the microphone. To paraphrase (my understanding), current marking >> schemes (RED, CoDel, PIE,…) assume that ECN marks get treated like >> loss by the end systems. Therefore, they employ a “low density” >> marking scheme, with marks expected at an (average) rate of around >> 3% or so at maximum. >> >> Alternative schemes, that start getting deployed at this time, have >> very simple marking schemes in the network, and give more >> information to the end systems for processing and reaction there. As >> a side effect, these newer schemes may run as high as 100% marking >> for certain periods (longer than a single flows RTT), so they could >> be classified as “high density” marking scheme. >> >> >> Later on, Bob noted, that since ECN Nonce is virtually nonexistent >> (I know only one stack with partial support), why not re-define >> ECT(1) to be used by high density marking schemes, keeping ECT(0) >> for low density schemes (as deployed today). For newer stacks, this >> would allow an even more fine grained reaction to ECN marking levels… >> >> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has >> the same meaning for existing ECN stacks as ECT(0)) would not be >> addressed, but then again, current ECN is also virtually not >> deployed, according to recent studies. >> >> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would >> also need to have an impact on the future signaling / feedback >> scheme used for TCP (DCCP and SCTP would be able to cope already, >> afaik). >> >> Best regards, >> >> Richard Scheffenegger >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michawe@ifi.uio.no Thu Nov 8 04:59:22 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0FD21F8793 for ; Thu, 8 Nov 2012 04:59:22 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEXYi3aulAFv for ; Thu, 8 Nov 2012 04:59:21 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E720521F84B9 for ; Thu, 8 Nov 2012 04:59:20 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TWRhW-0002sB-Gw; Thu, 08 Nov 2012 13:59:18 +0100 Received: from vpn-client041.uio.no ([193.157.136.42] helo=[10.71.12.152]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TWRhU-0002mq-Gz; Thu, 08 Nov 2012 13:59:18 +0100 From: Michael Welzl To: gorry@erg.abdn.ac.uk In-Reply-To: X-Priority: 3 (Normal) References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> Message-Id: <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Nov 2012 13:59:09 +0100 X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 25459 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.212, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 609388F87B74EAEAA969B134FA25ACCEEB871997 X-UiO-SPAM-Test: remote_host: 193.157.136.42 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 863 max/h 22 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 12:59:22 -0000 ... but the nonce could still be used, somehow - it's just that you =20 risk more queue growth with every ECT(0) packet. So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s =20= and ECT(1)'s. In doing so, you risk some more queue growth - but this =20= tests the receiver and might be good enough in the long run, as the =20 notion is to stop believing the receiver once the receiver was found =20 to cheat. Cheers, Michael On Nov 8, 2012, at 1:30 PM, gorry@erg.abdn.ac.uk wrote: > I'm also really interested in doing better than current ECN. > > ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the =20 > reaction > is defined in the (still) experimental RFC 3540. > > The ECN nonce can detect remarking NON-ECT packets to ECT and can also > detect misbehaving transport receivers hiding CE from the transport > sender. My own opinion is that if we do see more deployment of ECN =20 > (I do > hope so) - we do need this sort of mechanism, not to verify every =20 > segment, > but at least to be able to detect paths/endpoints where the ACK > information is simply invalid. > > DCCP was mentioned in the thread, RFC 4340, took the view that ECN =20 > nonce > needed to be supported and the ECN Nonce Echo field is encoded in > acknowledgement options. "Each DCCP sender SHOULD set ECN Nonces on =20= > its > packets and remember which packets had nonces." > > > Gorry > > P.S. Also note, if we do get to plans for new use of ECN this is =20 > likely to > be a TSVWG item - since it effects much more than TCP. > >> Great idea, I'd love for this semantic shift to happen! >> >> >> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: >> >>> Hi, >>> >>> I just wanted to keep a record of these interesting remarks on the >>> list, for further discussion. >>> >>> We discussed ECN both in TCPM and ICCRG, and this post is to start >>> the discussion on the working group lists. >>> >>> During the TCPM session, Matt Mathis made an interesting remark on >>> the microphone. To paraphrase (my understanding), current marking >>> schemes (RED, CoDel, PIE,=85) assume that ECN marks get treated like >>> loss by the end systems. Therefore, they employ a =93low density=94 >>> marking scheme, with marks expected at an (average) rate of around >>> 3% or so at maximum. >>> >>> Alternative schemes, that start getting deployed at this time, have >>> very simple marking schemes in the network, and give more >>> information to the end systems for processing and reaction there. As >>> a side effect, these newer schemes may run as high as 100% marking >>> for certain periods (longer than a single flows RTT), so they could >>> be classified as =93high density=94 marking scheme. >>> >>> >>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent >>> (I know only one stack with partial support), why not re-define >>> ECT(1) to be used by high density marking schemes, keeping ECT(0) >>> for low density schemes (as deployed today). For newer stacks, this >>> would allow an even more fine grained reaction to ECN marking =20 >>> levels=85 >>> >>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has >>> the same meaning for existing ECN stacks as ECT(0)) would not be >>> addressed, but then again, current ECN is also virtually not >>> deployed, according to recent studies. >>> >>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would >>> also need to have an impact on the future signaling / feedback >>> scheme used for TCP (DCCP and SCTP would be able to cope already, >>> afaik). >>> >>> Best regards, >>> >>> Richard Scheffenegger >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > From rs@netapp.com Thu Nov 8 05:08:06 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1921F8B06 for ; Thu, 8 Nov 2012 05:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD01T4Wpx7CL for ; Thu, 8 Nov 2012 05:08:05 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 36A7421F8ADD for ; Thu, 8 Nov 2012 05:08:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,737,1344236400"; d="scan'208";a="708216342" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 08 Nov 2012 05:08:04 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qA8D84P8014832; Thu, 8 Nov 2012 05:08:04 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.165]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 05:08:03 -0800 From: "Scheffenegger, Richard" To: Michael Welzl Thread-Topic: [tcpm] ECN feedback discussion Thread-Index: Ac2856olwNIvlhLtTBm8IfAfhj0+sQARSesAADDD5QAAAQELgP//fGBl Date: Thu, 8 Nov 2012 13:08:03 +0000 Message-ID: <29D34BEC-318F-47A4-9A6B-D4F4FE3DAFF7@netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> , <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> In-Reply-To: <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 13:08:06 -0000 Hi Michael, If both ect1 and ce signify some kind of congestion, having the sender "pro= be" ect1 is a noisy business (in the sense that there is no guarantee that = the ect1 from the sender makes it all the way to the receiver. Hypothetical= ly, the first part of the path might "eat" ect1=20 And the 2nd half expirience congestion... (probing would mask true marks always. A mechanism to probabilistically tes= t this is still possible) Rgds Richard Von meinem iPhone gesendet Am 08.11.2012 um 07:59 schrieb "Michael Welzl" : > ... but the nonce could still be used, somehow - it's just that you risk = more queue growth with every ECT(0) packet. >=20 > So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s and= ECT(1)'s. In doing so, you risk some more queue growth - but this tests th= e receiver and might be good enough in the long run, as the notion is to st= op believing the receiver once the receiver was found to cheat. >=20 > Cheers, > Michael >=20 >=20 > On Nov 8, 2012, at 1:30 PM, gorry@erg.abdn.ac.uk wrote: >=20 >> I'm also really interested in doing better than current ECN. >>=20 >> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the reacti= on >> is defined in the (still) experimental RFC 3540. >>=20 >> The ECN nonce can detect remarking NON-ECT packets to ECT and can also >> detect misbehaving transport receivers hiding CE from the transport >> sender. My own opinion is that if we do see more deployment of ECN (I do >> hope so) - we do need this sort of mechanism, not to verify every segmen= t, >> but at least to be able to detect paths/endpoints where the ACK >> information is simply invalid. >>=20 >> DCCP was mentioned in the thread, RFC 4340, took the view that ECN nonce >> needed to be supported and the ECN Nonce Echo field is encoded in >> acknowledgement options. "Each DCCP sender SHOULD set ECN Nonces on its >> packets and remember which packets had nonces." >>=20 >>=20 >> Gorry >>=20 >> P.S. Also note, if we do get to plans for new use of ECN this is likely = to >> be a TSVWG item - since it effects much more than TCP. >>=20 >>> Great idea, I'd love for this semantic shift to happen! >>>=20 >>>=20 >>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I just wanted to keep a record of these interesting remarks on the >>>> list, for further discussion. >>>>=20 >>>> We discussed ECN both in TCPM and ICCRG, and this post is to start >>>> the discussion on the working group lists. >>>>=20 >>>> During the TCPM session, Matt Mathis made an interesting remark on >>>> the microphone. To paraphrase (my understanding), current marking >>>> schemes (RED, CoDel, PIE,=85) assume that ECN marks get treated like >>>> loss by the end systems. Therefore, they employ a =93low density=94 >>>> marking scheme, with marks expected at an (average) rate of around >>>> 3% or so at maximum. >>>>=20 >>>> Alternative schemes, that start getting deployed at this time, have >>>> very simple marking schemes in the network, and give more >>>> information to the end systems for processing and reaction there. As >>>> a side effect, these newer schemes may run as high as 100% marking >>>> for certain periods (longer than a single flows RTT), so they could >>>> be classified as =93high density=94 marking scheme. >>>>=20 >>>>=20 >>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent >>>> (I know only one stack with partial support), why not re-define >>>> ECT(1) to be used by high density marking schemes, keeping ECT(0) >>>> for low density schemes (as deployed today). For newer stacks, this >>>> would allow an even more fine grained reaction to ECN marking levels= =85 >>>>=20 >>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has >>>> the same meaning for existing ECN stacks as ECT(0)) would not be >>>> addressed, but then again, current ECN is also virtually not >>>> deployed, according to recent studies. >>>>=20 >>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would >>>> also need to have an impact on the future signaling / feedback >>>> scheme used for TCP (DCCP and SCTP would be able to cope already, >>>> afaik). >>>>=20 >>>> Best regards, >>>>=20 >>>> Richard Scheffenegger >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >>=20 >>=20 >=20 From michawe@ifi.uio.no Thu Nov 8 05:22:14 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1457221F8BB2 for ; Thu, 8 Nov 2012 05:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t74zkXcpIRwo for ; Thu, 8 Nov 2012 05:22:13 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id E543A21F8BAE for ; Thu, 8 Nov 2012 05:22:12 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TWS3g-0002Oe-8m; Thu, 08 Nov 2012 14:22:12 +0100 Received: from vpn-client041.uio.no ([193.157.136.42] helo=[10.71.12.152]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TWS3f-0000cf-5v; Thu, 08 Nov 2012 14:22:12 +0100 Message-Id: <6D0769DE-DAE0-4FE3-91CA-1B36AA2B5B72@ifi.uio.no> From: Michael Welzl To: "Scheffenegger, Richard" In-Reply-To: <29D34BEC-318F-47A4-9A6B-D4F4FE3DAFF7@netapp.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Nov 2012 14:22:08 +0100 References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> , <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <29D34BEC-318F-47A4-9A6B-D4F4FE3DAFF7@netapp.com> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 12 sum msgs/h 4 total rcpts 25468 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.212, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5B5E4051FB379684B937AAB8EA02D25966D2F4C5 X-UiO-SPAM-Test: remote_host: 193.157.136.42 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 867 max/h 22 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 13:22:14 -0000 Ah, Sorry, I had misunderstood Bob's proposal. My interpretation was: ECT1 tells routers to apply a high density marking scheme. Yes this leads to unexpected behavior for current ECN-capable end =20 systems, but given that nobody (except for you! :-))) ) uses ECN, =20= maybe we can just update that behavior and not worry about this =20 problem much? To have a better basis for such a decision, it could be useful to look =20= at some data from the backbone, or from popular servers, on how many =20 packets arrive with ECT0 or ECT1 set. We should agree to not worry =20 about it if the value is below a certain percentage :-) Cheers, Michael On Nov 8, 2012, at 2:08 PM, Scheffenegger, Richard wrote: > Hi Michael, > > If both ect1 and ce signify some kind of congestion, having the =20 > sender "probe" ect1 is a noisy business (in the sense that there is =20= > no guarantee that the ect1 from the sender makes it all the way to =20 > the receiver. Hypothetically, the first part of the path might "eat" =20= > ect1 > And the 2nd half expirience congestion... > > (probing would mask true marks always. A mechanism to =20 > probabilistically test this is still possible) > > Rgds > Richard > > Von meinem iPhone gesendet > > Am 08.11.2012 um 07:59 schrieb "Michael Welzl" : > >> ... but the nonce could still be used, somehow - it's just that you =20= >> risk more queue growth with every ECT(0) packet. >> >> So you could mostly use ECT(1)'s, but occasionally, use both =20 >> ECT(0)'s and ECT(1)'s. In doing so, you risk some more queue growth =20= >> - but this tests the receiver and might be good enough in the long =20= >> run, as the notion is to stop believing the receiver once the =20 >> receiver was found to cheat. >> >> Cheers, >> Michael >> >> >> On Nov 8, 2012, at 1:30 PM, gorry@erg.abdn.ac.uk wrote: >> >>> I'm also really interested in doing better than current ECN. >>> >>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the =20= >>> reaction >>> is defined in the (still) experimental RFC 3540. >>> >>> The ECN nonce can detect remarking NON-ECT packets to ECT and can =20= >>> also >>> detect misbehaving transport receivers hiding CE from the transport >>> sender. My own opinion is that if we do see more deployment of ECN =20= >>> (I do >>> hope so) - we do need this sort of mechanism, not to verify every =20= >>> segment, >>> but at least to be able to detect paths/endpoints where the ACK >>> information is simply invalid. >>> >>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN =20= >>> nonce >>> needed to be supported and the ECN Nonce Echo field is encoded in >>> acknowledgement options. "Each DCCP sender SHOULD set ECN Nonces =20= >>> on its >>> packets and remember which packets had nonces." >>> >>> >>> Gorry >>> >>> P.S. Also note, if we do get to plans for new use of ECN this is =20 >>> likely to >>> be a TSVWG item - since it effects much more than TCP. >>> >>>> Great idea, I'd love for this semantic shift to happen! >>>> >>>> >>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: >>>> >>>>> Hi, >>>>> >>>>> I just wanted to keep a record of these interesting remarks on the >>>>> list, for further discussion. >>>>> >>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start >>>>> the discussion on the working group lists. >>>>> >>>>> During the TCPM session, Matt Mathis made an interesting remark on >>>>> the microphone. To paraphrase (my understanding), current marking >>>>> schemes (RED, CoDel, PIE,=85) assume that ECN marks get treated = like >>>>> loss by the end systems. Therefore, they employ a =93low density=94= >>>>> marking scheme, with marks expected at an (average) rate of around >>>>> 3% or so at maximum. >>>>> >>>>> Alternative schemes, that start getting deployed at this time, =20 >>>>> have >>>>> very simple marking schemes in the network, and give more >>>>> information to the end systems for processing and reaction =20 >>>>> there. As >>>>> a side effect, these newer schemes may run as high as 100% marking >>>>> for certain periods (longer than a single flows RTT), so they =20 >>>>> could >>>>> be classified as =93high density=94 marking scheme. >>>>> >>>>> >>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent >>>>> (I know only one stack with partial support), why not re-define >>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0) >>>>> for low density schemes (as deployed today). For newer stacks, =20 >>>>> this >>>>> would allow an even more fine grained reaction to ECN marking =20 >>>>> levels=85 >>>>> >>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has >>>>> the same meaning for existing ECN stacks as ECT(0)) would not be >>>>> addressed, but then again, current ECN is also virtually not >>>>> deployed, according to recent studies. >>>>> >>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would >>>>> also need to have an impact on the future signaling / feedback >>>>> scheme used for TCP (DCCP and SCTP would be able to cope already, >>>>> afaik). >>>>> >>>>> Best regards, >>>>> >>>>> Richard Scheffenegger >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>> >>> >> From michawe@ifi.uio.no Thu Nov 8 06:05:46 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8A21F8B2F for ; Thu, 8 Nov 2012 06:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elRygn2SRjkB for ; Thu, 8 Nov 2012 06:05:45 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBF621F8AEF for ; Thu, 8 Nov 2012 06:05:39 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TWSji-0005Xa-Gp; Thu, 08 Nov 2012 15:05:38 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TWSjh-0003oU-Om; Thu, 08 Nov 2012 15:05:38 +0100 Message-Id: <6A77FDBD-58D3-4606-AE56-4383B72BA8B2@ifi.uio.no> From: Michael Welzl To: Steve Bauer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Nov 2012 15:05:33 +0100 References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <29D34BEC-318F-47A4-9A6B-D4F4FE3DAFF7@netapp.com> <6D0769DE-DAE0-4FE3-91CA-1B36AA2B5B72@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 12 sum msgs/h 4 total rcpts 25477 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5AE0E14538BD519D1A7080A098C8E51B43D1EE36 X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 79 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 14:05:46 -0000 On Nov 8, 2012, at 2:50 PM, Steve Bauer wrote: >> To have a better basis for such a decision, it could be useful to =20 >> look at some data from the backbone, or from popular servers, on =20 >> how many packets arrive with ECT0 or ECT1 set. > > In our IMC 2011 paper, > > Measuring the State of ECN Readiness in Servers, Clients, and Routers > http://rbeverly.net/research/papers/ecn-imc11.pdf > > We reported that "Across all of our data sets, we see no instances of > ECN nonce support. Manual inspection of arriving packets with ECT1 set > reveals that these =EF=AC=82ows always set ECT1, even when ECN is not > negotiated by TCP." I have read this paper, and also had it open while I wrote my previous =20= email :-) but I managed to miss that statement. > So any packets with ECT1 set are evidence of something broken along =20= > the path. Well... up to now, it is. I don't see how what you describe would =20 limit us to not have a sender set ECT1? It would break the nonce interpretation though. Tricky. But should we =20= design for such equipment faults? A quick look at your paper doesn't =20 reveal how often you saw that; maybe I'm missing it again... Another thought: in my previous email, addressing Richard, I wrote: "Yes this leads to unexpected behavior for current ECN-capable end =20 systems, but given that nobody (except for you! :-))) ) uses ECN, =20= maybe we can just update that behavior and not worry about this =20 problem much?" - this made me think: Richard would certainly not run an old kernel. =3D> given that ECN is probably not on by default in any system, isn't =20= it fair to assume that folks who'd turn it on would run an up-to-date =20= system? Sure, lots of assumptions, but we're talking of blowing life into a =20 dead corpse here! You can't do that without doing ugly stuff, such as =20= having a zombie bite it... Cheers, Michael From gorry@erg.abdn.ac.uk Thu Nov 8 06:06:55 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5115B21F8B06 for ; Thu, 8 Nov 2012 06:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZhJmiz6Rwge for ; Thu, 8 Nov 2012 06:06:54 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 050D421F8B1C for ; Thu, 8 Nov 2012 06:06:51 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 589342B4356; Thu, 8 Nov 2012 14:06:44 +0000 (GMT) Received: from 2001:df8:0:16:5ab0:35ff:fe7b:b828 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 8 Nov 2012 14:06:44 -0000 Message-ID: In-Reply-To: <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> Date: Thu, 8 Nov 2012 14:06:44 -0000 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 14:06:55 -0000 Yes - and I plan to write an I-D on this, because I think we could perhaps move forward with this discussion in parallel with the more accurate ECN. Gorry > ... but the nonce could still be used, somehow - it's just that you > risk more queue growth with every ECT(0) packet. > > So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s > and ECT(1)'s. In doing so, you risk some more queue growth - but this > tests the receiver and might be good enough in the long run, as the > notion is to stop believing the receiver once the receiver was found > to cheat. > > Cheers, > Michael > > > On Nov 8, 2012, at 1:30 PM, gorry@erg.abdn.ac.uk wrote: > >> I'm also really interested in doing better than current ECN. >> >> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the >> reaction >> is defined in the (still) experimental RFC 3540. >> >> The ECN nonce can detect remarking NON-ECT packets to ECT and can also >> detect misbehaving transport receivers hiding CE from the transport >> sender. My own opinion is that if we do see more deployment of ECN >> (I do >> hope so) - we do need this sort of mechanism, not to verify every >> segment, >> but at least to be able to detect paths/endpoints where the ACK >> information is simply invalid. >> >> DCCP was mentioned in the thread, RFC 4340, took the view that ECN >> nonce >> needed to be supported and the ECN Nonce Echo field is encoded in >> acknowledgement options. "Each DCCP sender SHOULD set ECN Nonces on >> its >> packets and remember which packets had nonces." >> >> >> Gorry >> >> P.S. Also note, if we do get to plans for new use of ECN this is >> likely to >> be a TSVWG item - since it effects much more than TCP. >> >>> Great idea, I'd love for this semantic shift to happen! >>> >>> >>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: >>> >>>> Hi, >>>> >>>> I just wanted to keep a record of these interesting remarks on the >>>> list, for further discussion. >>>> >>>> We discussed ECN both in TCPM and ICCRG, and this post is to start >>>> the discussion on the working group lists. >>>> >>>> During the TCPM session, Matt Mathis made an interesting remark on >>>> the microphone. To paraphrase (my understanding), current marking >>>> schemes (RED, CoDel, PIE,…) assume that ECN marks get treated like >>>> loss by the end systems. Therefore, they employ a “low density” >>>> marking scheme, with marks expected at an (average) rate of around >>>> 3% or so at maximum. >>>> >>>> Alternative schemes, that start getting deployed at this time, have >>>> very simple marking schemes in the network, and give more >>>> information to the end systems for processing and reaction there. As >>>> a side effect, these newer schemes may run as high as 100% marking >>>> for certain periods (longer than a single flows RTT), so they could >>>> be classified as “high density” marking scheme. >>>> >>>> >>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent >>>> (I know only one stack with partial support), why not re-define >>>> ECT(1) to be used by high density marking schemes, keeping ECT(0) >>>> for low density schemes (as deployed today). For newer stacks, this >>>> would allow an even more fine grained reaction to ECN marking >>>> levels… >>>> >>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has >>>> the same meaning for existing ECN stacks as ECT(0)) would not be >>>> addressed, but then again, current ECN is also virtually not >>>> deployed, according to recent studies. >>>> >>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would >>>> also need to have an impact on the future signaling / feedback >>>> scheme used for TCP (DCCP and SCTP would be able to cope already, >>>> afaik). >>>> >>>> Best regards, >>>> >>>> Richard Scheffenegger >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> >> > From michawe@ifi.uio.no Thu Nov 8 06:12:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31021F8B57 for ; Thu, 8 Nov 2012 06:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7V1fnt2Rnsv for ; Thu, 8 Nov 2012 06:12:01 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id DDC9F21F8AEF for ; Thu, 8 Nov 2012 06:12:00 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TWSpr-0006mT-K2; Thu, 08 Nov 2012 15:11:59 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TWSpq-0002F5-Fu; Thu, 08 Nov 2012 15:11:59 +0100 From: Michael Welzl To: gorry@erg.abdn.ac.uk In-Reply-To: X-Priority: 3 (Normal) References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> Message-Id: <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Nov 2012 15:11:56 +0100 X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 3 sum rcpts/h 17 sum msgs/h 6 total rcpts 25482 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1AAAE1539F38D7F032F9D80D90250C664924A9EA X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 81 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 14:12:02 -0000 If your plan is to, in doing so, update RFC3540, I'd love to be a part =20= of it. If the ECN nonce is used, it's a low hanging fruit to also use =20= it to sometimes detect spurious loss events: http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html I have been thinking of writing a draft that updates RFC3540 to =20 incorporate this for many years now, but never seriously pursued it =20 because I thought it would be best to wait until Bob Briscoe is done =20 with all his bit thievery. But he will never stop, will he? :-) So, if possible, I'd love to be a part of this. Cheers, Michael On Nov 8, 2012, at 3:06 PM, gorry@erg.abdn.ac.uk wrote: > Yes - and I plan to write an I-D on this, because I think we could =20 > perhaps > move forward with this discussion in parallel with the more accurate =20= > ECN. > > Gorry > >> ... but the nonce could still be used, somehow - it's just that you >> risk more queue growth with every ECT(0) packet. >> >> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s >> and ECT(1)'s. In doing so, you risk some more queue growth - but this >> tests the receiver and might be good enough in the long run, as the >> notion is to stop believing the receiver once the receiver was found >> to cheat. >> >> Cheers, >> Michael >> >> >> On Nov 8, 2012, at 1:30 PM, gorry@erg.abdn.ac.uk wrote: >> >>> I'm also really interested in doing better than current ECN. >>> >>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the >>> reaction >>> is defined in the (still) experimental RFC 3540. >>> >>> The ECN nonce can detect remarking NON-ECT packets to ECT and can =20= >>> also >>> detect misbehaving transport receivers hiding CE from the transport >>> sender. My own opinion is that if we do see more deployment of ECN >>> (I do >>> hope so) - we do need this sort of mechanism, not to verify every >>> segment, >>> but at least to be able to detect paths/endpoints where the ACK >>> information is simply invalid. >>> >>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN >>> nonce >>> needed to be supported and the ECN Nonce Echo field is encoded in >>> acknowledgement options. "Each DCCP sender SHOULD set ECN Nonces on >>> its >>> packets and remember which packets had nonces." >>> >>> >>> Gorry >>> >>> P.S. Also note, if we do get to plans for new use of ECN this is >>> likely to >>> be a TSVWG item - since it effects much more than TCP. >>> >>>> Great idea, I'd love for this semantic shift to happen! >>>> >>>> >>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: >>>> >>>>> Hi, >>>>> >>>>> I just wanted to keep a record of these interesting remarks on the >>>>> list, for further discussion. >>>>> >>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start >>>>> the discussion on the working group lists. >>>>> >>>>> During the TCPM session, Matt Mathis made an interesting remark on >>>>> the microphone. To paraphrase (my understanding), current marking >>>>> schemes (RED, CoDel, PIE,=85) assume that ECN marks get treated = like >>>>> loss by the end systems. Therefore, they employ a =93low density=94= >>>>> marking scheme, with marks expected at an (average) rate of around >>>>> 3% or so at maximum. >>>>> >>>>> Alternative schemes, that start getting deployed at this time, =20 >>>>> have >>>>> very simple marking schemes in the network, and give more >>>>> information to the end systems for processing and reaction =20 >>>>> there. As >>>>> a side effect, these newer schemes may run as high as 100% marking >>>>> for certain periods (longer than a single flows RTT), so they =20 >>>>> could >>>>> be classified as =93high density=94 marking scheme. >>>>> >>>>> >>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent >>>>> (I know only one stack with partial support), why not re-define >>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0) >>>>> for low density schemes (as deployed today). For newer stacks, =20 >>>>> this >>>>> would allow an even more fine grained reaction to ECN marking >>>>> levels=85 >>>>> >>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has >>>>> the same meaning for existing ECN stacks as ECT(0)) would not be >>>>> addressed, but then again, current ECN is also virtually not >>>>> deployed, according to recent studies. >>>>> >>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would >>>>> also need to have an impact on the future signaling / feedback >>>>> scheme used for TCP (DCCP and SCTP would be able to cope already, >>>>> afaik). >>>>> >>>>> Best regards, >>>>> >>>>> Richard Scheffenegger >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>> >>> >> > > From gorry@erg.abdn.ac.uk Thu Nov 8 06:19:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3C21F85AE for ; Thu, 8 Nov 2012 06:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJeTwNqmhlsR for ; Thu, 8 Nov 2012 06:19:48 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id F25A621F85A1 for ; Thu, 8 Nov 2012 06:19:47 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E473C2B4356; Thu, 8 Nov 2012 14:19:46 +0000 (GMT) Received: from 2001:df8:0:16:5ab0:35ff:fe7b:b828 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 8 Nov 2012 14:19:47 -0000 Message-ID: <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> Date: Thu, 8 Nov 2012 14:19:47 -0000 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 14:19:49 -0000 Let's talk. I already have some text and we could maybe make a strawman quickly -if nothing more, this may help understand the background for quick moving forward with more accurate ECN... Gorry > If your plan is to, in doing so, update RFC3540, I'd love to be a part > of it. If the ECN nonce is used, it's a low hanging fruit to also use > it to sometimes detect spurious loss events: > http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html > > I have been thinking of writing a draft that updates RFC3540 to > incorporate this for many years now, but never seriously pursued it > because I thought it would be best to wait until Bob Briscoe is done > with all his bit thievery. But he will never stop, will he? :-) > > So, if possible, I'd love to be a part of this. > > Cheers, > Michael > > > On Nov 8, 2012, at 3:06 PM, gorry@erg.abdn.ac.uk wrote: > >> Yes - and I plan to write an I-D on this, because I think we could >> perhaps >> move forward with this discussion in parallel with the more accurate >> ECN. >> >> Gorry >> >>> ... but the nonce could still be used, somehow - it's just that you >>> risk more queue growth with every ECT(0) packet. >>> >>> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s >>> and ECT(1)'s. In doing so, you risk some more queue growth - but this >>> tests the receiver and might be good enough in the long run, as the >>> notion is to stop believing the receiver once the receiver was found >>> to cheat. >>> >>> Cheers, >>> Michael >>> >>> >>> On Nov 8, 2012, at 1:30 PM, gorry@erg.abdn.ac.uk wrote: >>> >>>> I'm also really interested in doing better than current ECN. >>>> >>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the >>>> reaction >>>> is defined in the (still) experimental RFC 3540. >>>> >>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can >>>> also >>>> detect misbehaving transport receivers hiding CE from the transport >>>> sender. My own opinion is that if we do see more deployment of ECN >>>> (I do >>>> hope so) - we do need this sort of mechanism, not to verify every >>>> segment, >>>> but at least to be able to detect paths/endpoints where the ACK >>>> information is simply invalid. >>>> >>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN >>>> nonce >>>> needed to be supported and the ECN Nonce Echo field is encoded in >>>> acknowledgement options. "Each DCCP sender SHOULD set ECN Nonces on >>>> its >>>> packets and remember which packets had nonces." >>>> >>>> >>>> Gorry >>>> >>>> P.S. Also note, if we do get to plans for new use of ECN this is >>>> likely to >>>> be a TSVWG item - since it effects much more than TCP. >>>> >>>>> Great idea, I'd love for this semantic shift to happen! >>>>> >>>>> >>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I just wanted to keep a record of these interesting remarks on the >>>>>> list, for further discussion. >>>>>> >>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start >>>>>> the discussion on the working group lists. >>>>>> >>>>>> During the TCPM session, Matt Mathis made an interesting remark on >>>>>> the microphone. To paraphrase (my understanding), current marking >>>>>> schemes (RED, CoDel, PIE,…) assume that ECN marks get treated like >>>>>> loss by the end systems. Therefore, they employ a “low density” >>>>>> marking scheme, with marks expected at an (average) rate of around >>>>>> 3% or so at maximum. >>>>>> >>>>>> Alternative schemes, that start getting deployed at this time, >>>>>> have >>>>>> very simple marking schemes in the network, and give more >>>>>> information to the end systems for processing and reaction >>>>>> there. As >>>>>> a side effect, these newer schemes may run as high as 100% marking >>>>>> for certain periods (longer than a single flows RTT), so they >>>>>> could >>>>>> be classified as “high density” marking scheme. >>>>>> >>>>>> >>>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent >>>>>> (I know only one stack with partial support), why not re-define >>>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0) >>>>>> for low density schemes (as deployed today). For newer stacks, >>>>>> this >>>>>> would allow an even more fine grained reaction to ECN marking >>>>>> levels… >>>>>> >>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has >>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be >>>>>> addressed, but then again, current ECN is also virtually not >>>>>> deployed, according to recent studies. >>>>>> >>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would >>>>>> also need to have an impact on the future signaling / feedback >>>>>> scheme used for TCP (DCCP and SCTP would be able to cope already, >>>>>> afaik). >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Richard Scheffenegger >>>>>> >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>>> >>>> >>> >> >> > From pasi.sarolahti@iki.fi Thu Nov 8 06:58:04 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A130821F890A for ; Thu, 8 Nov 2012 06:58:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH5wfkLR5AhV for ; Thu, 8 Nov 2012 06:58:04 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 19ECF21F8596 for ; Thu, 8 Nov 2012 06:58:03 -0800 (PST) Received: from dhcp-467e.meeting.ietf.org (130.129.70.126) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508714160037DB9E for tcpm@ietf.org; Thu, 8 Nov 2012 16:58:02 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 09:58:07 -0500 Message-Id: <4C0774EC-BD25-442E-B039-FDAB180495CF@iki.fi> To: tcpm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Draft TCPM minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:58:04 -0000 Hi, Draft TCPM minutes are available at = http://www.ietf.org/proceedings/85/minutes/minutes-85-tcpm . Please let = us chairs know about any possible corrections. Many thanks to Andrew and Gorry for taking the notes and taking care of = the jabber room! - Pasi From ycheng@google.com Thu Nov 8 07:44:56 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B06421F894E for ; Thu, 8 Nov 2012 07:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG1DEejJ1Jp3 for ; Thu, 8 Nov 2012 07:44:55 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 525D321F899B for ; Thu, 8 Nov 2012 07:44:55 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so3209717obq.31 for ; Thu, 08 Nov 2012 07:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Ol85dhhkkTK4Wy6SmbeqabSlhsnR+ytfNbcwDu5+jhg=; b=RBtv26i9iBigW7DQ9yHoB6/wKkuHneZFUyL6ybWsYmcy9fniLPM8sh5La4QuS9CzPL MSdQRwMJNVPU+Gt6M7zhnf2sdobovhc5204QR+RiAXVrZeqSFKU8UylKVG5pMcqtsojP KAuDAExjHaEAtkmrONAo0pdOR7gOZBue1JeYd1UPGhEoQbhqsboarLBm0YPXlzwP9h8a OoVfCYc6Pp8c1ylZLGWqE47iW+kfNDWrWbVbrSV3adIrvbS4cBp7tERRFBzEx7AF1WK6 K0zqbVH4Yk4RVebvS7HzDsoHnNgqHRLlXKVdX5VHNlpOVp/CRmaP1r6aMGKo0LPs9OfZ XJOg== 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=Ol85dhhkkTK4Wy6SmbeqabSlhsnR+ytfNbcwDu5+jhg=; b=emUnv2HLa/QnIh4LUwWIydGi/PORikFiP6QP7UbwF1waTCrKSLJoygyo89ULM4RUM0 +AdxXYIIGT6D3MKOrV2ijKPcibP09gfBWYMqgjbd1Mx3ZOEf5SHi56AwhlWwp7l27O5L D3XJWRMzpNJCJUhIcHLpQ+RWohiq2E46pwT7L8Nvm6m18jrVXKcSXu5+CBIuASeTconh py/mZ4i5Du884rpiYDyA0GguIeHKj6Oaz9TAvk+46FOplUaKNHsUCLhDw6/sTbdkKdJ7 8LRhd3hakwLw4kKCEq3BGzmHzIeGBGzf28drf77hiQ14LiLtmhyG683uhIyYVl8u4pXI BgxQ== Received: by 10.60.10.133 with SMTP id i5mr5162140oeb.11.1352389494877; Thu, 08 Nov 2012 07:44:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.95.73 with HTTP; Thu, 8 Nov 2012 07:44:34 -0800 (PST) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D745B07@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D745B07@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Thu, 8 Nov 2012 10:44:34 -0500 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkzbMQPBHCXahw1Xscr/ntwoz2jbrW1T2EvoVEbRaCAK/d1tWyzUp3ad1HsRUg0LPa/4wih9ASW/8kXKKVaE5DDooBBKeBzYZgI0NXYvurkPZKxEytXgF/x237caAfMmenYvAh6iGS/xljIUAtDh3Hm1/CP3lK2S0rZVLOFuWG3UpGyFlE5JJTev6XRJ6SSuTKo2CG2 Cc: "tcpm \(tcpm@ietf.org\)\"" Subject: Re: [tcpm] 1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:44:56 -0000 On Wed, Nov 7, 2012 at 12:16 PM, Scheffenegger, Richard wro= te: > Hi Matt, Mirja, Kevin, > > Michael Welzl just mentioned one old paper where this was looked into, an= d > also I believe Mark Allman brought this up... > > With 1323 TS, timing every packet changes the dynamics (in the time domai= n) > how fast sRTT / sRTTvar converge=85 > > With only one sample per RTT, the convergence time is measured in a coupl= e > of RTTs up to a dozend of RTTs; however, with per-packet RTT sampling, an= d > the same static weight factors, the effective convergence time of sRTT / > sRTTvar get mich faster than this =96 with large windows even shorter tha= n a > single RTT=85 > > Should 1323bis give some definitive guidance to make the weight factors, = and > thus the convergence time, dynamic (something proportional to cwnd/SMSS > perhaps), so that RTT convergence (more importantly, RTO) is somewhat > slower? -1. I agree w/ Michael's opinion. > > Right now, the wording is rather vague in this aspect in 1323bis: > > Implementors should note that with Timestamps multiple RTTMs can be > taken per RTT. Many RTO estimators have a weighting factor based on > an implicit assumption that at most one RTTM will be gotten per RTT. > When using multiple RTTMs per RTT to update the RTO estimator, the > weighting factor needs to be decreased to take into account the more > frequent RTTMs. For example, an implementation could choose to just > use one sample per RTT to update the RTO estimator, or vary the gain > based on the congestion window, or take an average of all the RTTM > measurements received over one RTT, and then use that value to update > the RTO estimator. This document does not prescribe any particular > method for modifying the RTO estimator, the important point is that > the implementation should do something more than just feeding > additional RTTM samples from one RTT into the RTO estimator. > > (unless a definitive new default is prescribed, an implementer will propa= bly > =93do nothing=94, ie. continue use the static weight factor.) +1 please remove this redundant sentence starting from "the important point= ..." > > Also, would that section of text (since it=92s probably an important aspe= ct) > warrant to be promoted to its own subsection (4.x)? > > Best regards, > > Richard Scheffenegger > > NetApp > rs@netapp.com > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > > EURO PLAZA > Geb=E4ude G, Stiege 7, 3.OG > Am Euro Platz 2 > A-1120 Wien > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From bauer@mit.edu Thu Nov 8 05:51:25 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB721F8B77 for ; Thu, 8 Nov 2012 05:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKSHg5TMho-X for ; Thu, 8 Nov 2012 05:51:25 -0800 (PST) Received: from outgoing.csail.mit.edu (outgoing-v6.csail.mit.edu [IPv6:2001:470:8b2d:7d2:ea9a:8fff:feb2:a9e4]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB9421F8B0C for ; Thu, 8 Nov 2012 05:51:25 -0800 (PST) Received: from mail-pa0-f44.google.com ([209.85.220.44]) by outgoing.csail.mit.edu with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1TWSVv-00015U-KU for tcpm@ietf.org; Thu, 08 Nov 2012 08:51:23 -0500 Received: by mail-pa0-f44.google.com with SMTP id fb11so2139251pad.31 for ; Thu, 08 Nov 2012 05:51:22 -0800 (PST) Received: by 10.68.234.201 with SMTP id ug9mr17545177pbc.63.1352382682602; Thu, 08 Nov 2012 05:51:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.241.7 with HTTP; Thu, 8 Nov 2012 05:50:52 -0800 (PST) In-Reply-To: <6D0769DE-DAE0-4FE3-91CA-1B36AA2B5B72@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <29D34BEC-318F-47A4-9A6B-D4F4FE3DAFF7@netapp.com> <6D0769DE-DAE0-4FE3-91CA-1B36AA2B5B72@ifi.uio.no> From: Steve Bauer Date: Thu, 8 Nov 2012 08:50:52 -0500 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 08 Nov 2012 08:10:09 -0800 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 13:51:26 -0000 > To have a better basis for such a decision, it could be useful to look at= some data from the backbone, or from popular servers, on how many packets = arrive with ECT0 or ECT1 set. In our IMC 2011 paper, Measuring the State of ECN Readiness in Servers, Clients, and Routers http://rbeverly.net/research/papers/ecn-imc11.pdf We reported that "Across all of our data sets, we see no instances of ECN nonce support. Manual inspection of arriving packets with ECT1 set reveals that these =EF=AC=82ows always set ECT1, even when ECN is not negotiated by TCP." So any packets with ECT1 set are evidence of something broken along the pat= h. Steven Bauer MIT From pasi.sarolahti@iki.fi Thu Nov 8 11:15:14 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBED21F86DB for ; Thu, 8 Nov 2012 11:15:14 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h53c59V4K0Ft for ; Thu, 8 Nov 2012 11:15:12 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 80F7321F86A1 for ; Thu, 8 Nov 2012 11:15:12 -0800 (PST) Received: from dhcp-50d3.meeting.ietf.org (130.129.80.211) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508714160038A793 for tcpm@ietf.org; Thu, 8 Nov 2012 21:15:11 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 14:15:19 -0500 Message-Id: <04611025-66BD-4AF8-A09B-37DA34D646E5@iki.fi> To: tcpm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Publication requested for Proportional Rate Reduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 19:15:14 -0000 For information: publication request for PRR has been sent. The write-up = is below. - Pasi -------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is requested for publication as Experimental RFC, as indicated on the title page. During the working group last call it was proposed that the document should be published as Proposed Standard, but after the mailing list discussion that followed the chairs concluded there is no strong consensus to change the status (but no strong opposition, either). Also the document authors supported keeping the document as Experimental. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes an algorithm to improve the accuracy of the amount of data sent by TCP during loss recovery. The existing TCP recovery algorithms can make excess window adjustments in some situations, such as in the presence of heavy losses, and may result in abrupt TCP behavior in the form of packet bursts or increased risk of timeouts. Proportional Rate Reduction aims to minimize the needed window adjustments, to result in more stable TCP congestion control behavior in the presence of losses. Working Group Summary The document was adopted as Experimental TCPM working group item by clear working group consensus, and no opinions against it have been raised during its progress or in the working group last call. Document Quality The algorithm specified in the document has been implemented in Linux and integrated to the main kernel distribution. The algorithm has also been evaluated through measurements, and the evaluation results reported in a paper published in the IMC'11 conference. Different versions of the document have been thoroughly reviewed by TCPM working group members. Personnel Document Shepherd is Pasi Sarolahti . Responsible Area Director is Wesley Eddy . (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Document Shepherd has reviewed the document, including the comments and the latest version, and thinks the document is ready for publication without further changes. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document was reviewed and supported by multiple individuals, and no one has raised opinions against it. The chairs concluded that there is a solid WG consensus behind the document. (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits produced two warnings, but these appear to be unnecessary. There are informative references to RFC 3517 that was recently obsoleted by RFC 6675, but these are justified, because they concern evaluations that were made prior to publication of RFC 6675. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews are required for this document. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in = the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not involve any IANA considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries are required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no sections that would require formal validation. From ycheng@google.com Thu Nov 8 13:11:00 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A6021F8B2B for ; Thu, 8 Nov 2012 13:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax726btIxNff for ; Thu, 8 Nov 2012 13:10:59 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9619E21F8ACA for ; Thu, 8 Nov 2012 13:10:59 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so3593580obq.31 for ; Thu, 08 Nov 2012 13:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=1fjyESviW532YtC2jN+19TiO5h5RdhLKWChCUErJMXE=; b=W3YlY32HudAcoZIt8ZdvDbFW/VNDBpg3hNeQBWVUwvPxYVD4mtVMndDsvZIED2TL+p +3Rssh7+kA/olK6PIHmzCiY3Bqa5JH1UPe8D0k+Wg6736WddonwuV7huC1KSLG3ajTWV 8CSJuEsyCpOXs/NtXFPMKonZ5xIe5PgIjtydGdsT6BFzG+DdumsluoGDCOeyNeBYHPcb aL4sa/8NsNhavoE6UciowM8EpDvL9CbYNfRwIvBbdKMzJN7DMCcb9EyHNjYyVarQJDkC 6yk0uDjbmlb+ffbwcyuqv5viegCSG2H6XEdLdqQuBj9fi4PTZBFzU+OOJnnmqq0w21WO FavA== 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 :content-type:x-gm-message-state; bh=1fjyESviW532YtC2jN+19TiO5h5RdhLKWChCUErJMXE=; b=E3PYWONXgybAADKC3d3JYU1hFDJmgm0Sog5wyLpTJ2NiH1xovcDXlXaW/idVxmoLWz NQ0hUt42lMRRooWQW97p6zpnonBmutIIPacva4szneiocQG81exnj9J1qaiWAbf+B+WA ofgLeJA8Wa3Rdo6ByVRgkSC8v5+F+n5KQU10E8Y+mOuBa5VdDI+AtuD8/yrvK9JcfDVC IAv8Nh0piU6MkQkN7IrGi1dpe9sm0JEqSj6XlcKBVIrmT/Yc6d7na6jgwZTuGMqet+AM W9hh0A4u9TTMlxesq/nM1YEdMIfEaJaep0ky0yY/RDu2ZmFDJca3ixGEc+7VhFfjWnhF DsIw== Received: by 10.60.32.176 with SMTP id k16mr5992575oei.130.1352409059071; Thu, 08 Nov 2012 13:10:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.95.73 with HTTP; Thu, 8 Nov 2012 13:10:38 -0800 (PST) In-Reply-To: <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> From: Yuchung Cheng Date: Thu, 8 Nov 2012 16:10:38 -0500 Message-ID: To: "tcpm (tcpm@ietf.org)" , "iccrg@cs.ucl.ac.uk list" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlUYp1f/TYi+Qzq6epEtsXbo0nUxok5X1jsyfz9jlZ83NFkVZk7oeh4MVl0R9A6V80NtlHDhOMFZjhFKjNZH8vF9Wqcf5t8lTQ2dDqhV7+GQbJtWJXDTbybvkdCBKh8okYe1jXfekpBoYmsM/MpiLeHDfqrcSNJREcg+PDp2Wzsx5iNFRlQNTHvXmeGHd0XKe6o/jZg Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 21:11:00 -0000 Playing devil's advocate: what's the goal of advanced ECN feedback? what and whose problems are we solving? My worries are that we can design fancier stuff, in the end if it does not matter for applications, it does not matter. Is today's basic ECN not being used b/c it's too basic? From michawe@ifi.uio.no Thu Nov 8 14:43:53 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55D21F8495 for ; Thu, 8 Nov 2012 14:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KorL739tkr6c for ; Thu, 8 Nov 2012 14:43:51 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 6037821F8B9C for ; Thu, 8 Nov 2012 14:43:51 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TWapB-0004iC-Dg; Thu, 08 Nov 2012 23:43:49 +0100 Received: from dhcp-12bc.meeting.ietf.org ([130.129.18.188]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TWapA-0000fU-SU; Thu, 08 Nov 2012 23:43:49 +0100 References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <88F49B9E-F311-405A-94D8-8D12DE089F64@ifi.uio.no> X-Mailer: iPhone Mail (9B206) From: Michael Welzl Date: Thu, 8 Nov 2012 17:43:46 -0500 To: Yuchung Cheng X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 4 sum msgs/h 2 total rcpts 4 max rcpts/h 4 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F8FF986C3BAF1EB7B1672101855544E6516FA610 X-UiO-SPAM-Test: remote_host: 130.129.18.188 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Nov 2012 22:43:53 -0000 We wanna have less delay, dude! Sent from my iPhone On 8. nov. 2012, at 16:10, Yuchung Cheng wrote: > Playing devil's advocate: what's the goal of advanced ECN feedback? > what and whose problems are we solving? > > My worries are that we can design fancier stuff, in the end if it does > not matter for applications, it does not matter. Is today's basic ECN > not being used b/c it's too basic? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From swmike@swm.pp.se Thu Nov 8 20:54:00 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D194C21F8552 for ; Thu, 8 Nov 2012 20:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdb6Pk9NTXvf for ; Thu, 8 Nov 2012 20:54:00 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 38CF21F0C59 for ; Thu, 8 Nov 2012 20:54:00 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 892799C; Fri, 9 Nov 2012 05:53:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 820DC9A for ; Fri, 9 Nov 2012 05:53:59 +0100 (CET) Date: Fri, 9 Nov 2012 05:49:48 +0100 (CET) From: Mikael Abrahamsson To: Yuchung Cheng In-Reply-To: Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Fri, 9 Nov 2012 05:53:50 +0100 (CET) ReSent-From: Mikael Abrahamsson ReSent-To: tcpm@ietf.org ReSent-Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 04:54:00 -0000 On Thu, 8 Nov 2012, Yuchung Cheng wrote: > My worries are that we can design fancier stuff, in the end if it does > not matter for applications, it does not matter. Is today's basic ECN > not being used b/c it's too basic? I'd imagine ECN isn't used today because nobody knows what it is and why it's good to use. It's like IPv6, it doesn't really solve anything for the individual entitiy (ISP|user|equipment vendor), but as a whole, it would be good if we had it. I would also venture to say that congestion used to happen in the core and distribution. This is not really the case anymore, now congestion happens much closer to the edge, which is also the place where there is least homogenous control and thus harder to coordinate any technology. I have been running with ECN on, on most my machines for years now, just to make sure it doesn't break anything. When it was first implemented in the Linux kernel, ECN broke a lot of things. PIX firewalls for instance, dropped ECN packets. This is not the case anymore as far as I can tell, I haven't noticed any ECN related problem at all since I re-enabled it, hm, 3-4 years ago perhaps. To get ECN (and other more advanced tech) into production networks, we need to be able to explain to users and manufacturers (and ISPs) what good it does, and how it can make their life metter. From the bufferbloat discussion, I'd say this is quite hard, since most don't even know how TCP works in conjunction with large buffers, much less the difference between different TCP algorithms. So teaching about benefits of ECN is quite hard. ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly) because IPv4 ran out. Nothing happened really for 5-10 years because IPv6 didn't really solve any problem people thought they had. ECN is the same thing. ECN makes the network more efficient, in that it doesn't drop the packet if there is congestion. But how does that help the individual end user? That's harder to explain. Sorry for not being able to give any constructive suggestions on how to solve the problem of lack of ECN support, but if we can get some consensus about why ECN hasn't been implemented, perhaps that helps us making future decisions? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 8 21:01:34 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6A221F85C5 for ; Thu, 8 Nov 2012 21:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fxaPnHDTFAo for ; Thu, 8 Nov 2012 21:01:33 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3F21F8536 for ; Thu, 8 Nov 2012 21:01:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7A5D99C; Fri, 9 Nov 2012 06:01:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 73A5B9A for ; Fri, 9 Nov 2012 06:01:31 +0100 (CET) Date: Fri, 9 Nov 2012 06:01:31 +0100 (CET) From: Mikael Abrahamsson To: tcpm@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [tcpm] host behaviour when connectivity is lost X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 05:01:34 -0000 Hello. I don't know if this is appropriate for this WG, please tell me if it's not. A while ago, I pitched an idea in the linux-netdev mailing list, regarding how a connection manager might hint the TCP stack of the host, to do things depending on network conditions. The post is here: Would what I am suggesting be appropriate to discuss here and perhaps even create a document giving guidance to TCP implementors about APIs that might be helpful, and how they should behave? I believe the problem I'm describing is real and it affects users all the time. Here is the text: ------------------------------------ I'm a network engineer, as in I work primarily with IP routing. Ever since I started running Linux back in the mid 90ties I've had a love/hate relationship with how Linux handles disappearing network connectivity or IP addresses. In my mind there are two ways to handle outage: 1. When a network connection (physical interface) goes down, keep everything as it is, it might come back up again shortly and then we can continue as if basically nothing happened. TCP was designed for this considering timeouts can be in hours. 2. When a network connection (physical interface) goes down, wait a few seconds, give up, reset all connectivity related to that connection, basically give up. Now to my question for the netdev people: Is there functionality in the kernel for a connection manager to easily accomplish 2, in that when it tries to deconfigure the IP address on the interface to also kill all TCP connections terminated at that IP? On my laptop, I regularily have to kill my ssh client after suspend/resume cycle, because it's been down for quite a while, and the ssh client doesn't know the TCP connection is now not functional anymore (TCP session is still up and retransmit won't happen for a while, so the TCP RST from the server (I use keepalives within SSH) isn't seen for a long time). Without knowing what's in place right now, I see some behaviours that I'd like to have: After resume (or otherwise network connectivity re-established), connection manager should be able to tell the kernel to: a) kill all TCP/UDP/other sessions existing which doesn't currently have an active IP address on the machine. This is for the sake of local clients. b) the TCP/SCTP sessions that *do* have an IP, should have their retransmit timers "reset", so that whatever needs to be sent, should be sent immediately (or shortly, within a few seconds). c) tell the kernel to kill all TCP sessions bound to a certain IP, because the connection manager is going to remove it shortly. Send TCP RSTs or whatever and close the TCP session, so both ends know that network connectivity is going down. This would mean that if I resume my laptop and it establishes network connectivity, I will then *know* within a few seconds what TCP sessions are still valid (the ones that aren't will be killed either because they're bound to an IP that is not available, or a TCP packet is sent out to which there will be a TCP RST reply from the other side if the TCP session is closed at that end). All of this also has implications on IPv6 and autoconfiguration, I don't know if currently we are closing TCP sessions bound to IPv6 addresses that are going away due to the RA the addresses were autoconfigured based on, now doesn't have a valid lifetime anymore and the kernel is going to remove them. It also applies to both DHCPv6 and DHCPv4 when a lease is expiring and the IPv4/IPv6 address is going to be removed. Right now I think the situation with a lot of "hanging" TCP sessions after connectivity is restored is suboptimal and negatively impacts user experience. Probably there should be knobs to turn for different user needs (server or desktop/laptop) because desired behaviour is different in different use cases. -- Mikael Abrahamsson email: swmike@swm.pp.se From michael.scharf@alcatel-lucent.com Fri Nov 9 00:33:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5163621F8427 for ; Fri, 9 Nov 2012 00:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.507 X-Spam-Level: X-Spam-Status: No, score=-9.507 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9McOaVxmHr5N for ; Fri, 9 Nov 2012 00:33:37 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3CF21F8422 for ; Fri, 9 Nov 2012 00:33:37 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA98NBpT017214 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Nov 2012 09:33:20 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 9 Nov 2012 09:32:58 +0100 From: "Scharf, Michael (Michael)" To: Michael Welzl , "gorry@erg.abdn.ac.uk" Date: Fri, 9 Nov 2012 09:32:56 +0100 Thread-Topic: [tcpm] ECN feedback discussion Thread-Index: Ac29uwowIBR7/C/iRZSes55ZB/2baQAl0BwA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A820@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> In-Reply-To: <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:33:38 -0000 > I have been thinking of writing a draft that updates RFC3540=20 > to incorporate this for many years now, but never seriously=20 > pursued it because I thought it would be best to wait until=20 > Bob Briscoe is done with all his bit thievery. But he will=20 > never stop, will he? :-) While I really enjoy the technical ideas in this discussion, I am somehow c= oncerned about the tone here... I think the community must really understan= d that *burglary* is not at all an appropriate approach for getting the bel= oved bits in the TCP header. Instead, quite obviously, the right thing to d= o is bribery of the TCPM chairs ;) Michael From emmanuel.lochin@gmail.com Fri Nov 9 02:27:07 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABA921F85C0 for ; Fri, 9 Nov 2012 02:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cti96Swj3mTj for ; Fri, 9 Nov 2012 02:27:06 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 999B621F8629 for ; Fri, 9 Nov 2012 02:27:06 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4089141vbb.31 for ; Fri, 09 Nov 2012 02:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e5PqpO6f3FvP40A3rNL3F5zmZ3dmrXokSmAtJ1ePVy0=; b=dMlACsuq2WUVqRSS1GFOIO2xuNaRl8D6gb+0ak5MZmRgKuhRbUPAb/U68JtUowPQCn 5RayzBmWZxKOIb2WJT1XvcJU8IZpRbqVmgIQGBd/lyCipeHQVJQIGIiOXoGmJTRZvxus 1KVd0HYQ7XhKtak0GQXS0HbXYojTvgTW631S3MNzVzXdJXCmOvnjebdbI95YILR7ivF1 VYVCWwtHIDi0m3+lSHOUaEV79y3NJJynYbGLZZ+h0oW+RZ6eO5Nqng8R6G1wJ0VG5Kmi mfPnJSTT0sQWU4t7d/InQvc37No/NMr+5LPJSfRyGb9rTG0ToxfIlWRVONqOdD0myB0G xi9g== MIME-Version: 1.0 Received: by 10.59.5.229 with SMTP id cp5mr4808804ved.32.1352456825860; Fri, 09 Nov 2012 02:27:05 -0800 (PST) Received: by 10.59.5.196 with HTTP; Fri, 9 Nov 2012 02:27:05 -0800 (PST) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A820@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A820@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Fri, 9 Nov 2012 11:27:05 +0100 Message-ID: From: Emmanuel Lochin To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=047d7b86e454adf33604ce0d64c5 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl , "iccrg@cs.ucl.ac.uk list" , Rem Rem Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 10:27:08 -0000 --047d7b86e454adf33604ce0d64c5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I wish to come back on the discussion concerning a "more accurate ECN feedback". I utterly support the following draft draft-kuehlewind-tcpm-accurate-ecn-option and the idea that this binary signal is not enough to clearly take an optimal decision concerning the sending rate. Two years ago, we drove a study to illustrate that the use of a simple ECN counter might open the door to several schemes and methods allowing to better assess the level of congestion and thus, react to losses in a consistent way. See : Diana, R=E9mi and Lochin, Emmanuel *ECN verbose mode:= a statistical method for network path congestion estimation.* (2011) Computer Networks, vol. 55 (n=B0 10). pp. 2380-2391. ISSN 1389-1286 available here : http://oatao.univ-toulouse.fr/4779/ Enhancing ECN feedback would greatly help us to collect statistical information in order to optimize the TCP reaction to this signal. Emmanuel On 9 November 2012 09:32, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > > I have been thinking of writing a draft that updates RFC3540 > > to incorporate this for many years now, but never seriously > > pursued it because I thought it would be best to wait until > > Bob Briscoe is done with all his bit thievery. But he will > > never stop, will he? :-) > > While I really enjoy the technical ideas in this discussion, I am somehow > concerned about the tone here... I think the community must really > understand that *burglary* is not at all an appropriate approach for > getting the beloved bits in the TCP header. Instead, quite obviously, the > right thing to do is bribery of the TCPM chairs ;) > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --047d7b86e454adf33604ce0d64c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I wish to come back on the discussion concerning a "mor= e accurate ECN feedback".
I utterly support the following draft dra= ft-kuehlewind-tcpm-accurate-ecn-option and the idea= that this binary signal is not enough to clearly take an optimal decision = concerning the sending rate.

Two years ago, we drove a study to illustrate that the use of a simple = ECN counter might open the door to several schemes and methods allowing to = better assess the level of congestion and thus, react to losses in a consis= tent way. See : Diana, R=E9mi and = Lochin, Emmanuel ECN verbose mode: a statistical method for netwo= rk path congestion estimation. (2011) Computer Networks, vol. 55 (n=B0 = 10). pp. 2380-2391. ISSN 1389-1286 available here : http://oatao.univ-toulouse.fr/4779/

Enhancing ECN feedback would greatly help us to collect statistical inf= ormation in order to optimize the TCP reaction to this signal.

Emman= uel




On 9 November 2012 09:32, Scharf, Michael (Michael) <<= a href=3D"mailto:michael.scharf@alcatel-lucent.com" target=3D"_blank">micha= el.scharf@alcatel-lucent.com> wrote:
> I have been thinking of writing a draft that updates= RFC3540
> to incorporate this for many years now, but never seriously
> pursued it because I thought it would be best to wait until
> Bob Briscoe is done with all his bit thievery. But he will
> never stop, will he? =A0:-)

While I really enjoy the technical ideas in this discussion, I am som= ehow concerned about the tone here... I think the community must really und= erstand that *burglary* is not at all an appropriate approach for getting t= he beloved bits in the TCP header. Instead, quite obviously, the right thin= g to do is bribery of the TCPM chairs ;)

Michael
___________________________= ____________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--047d7b86e454adf33604ce0d64c5-- From ycheng@google.com Fri Nov 9 07:06:30 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEC921F896F for ; Fri, 9 Nov 2012 07:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bFRocpT86zY for ; Fri, 9 Nov 2012 07:06:30 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF22E21F88F1 for ; Fri, 9 Nov 2012 07:06:29 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4423903oag.31 for ; Fri, 09 Nov 2012 07:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CV1oZD71uuLLaB1EZ8mhrVyY8oRGBDWemPOXywRD8uE=; b=HwyaELKKXJ3dZsUYn89dR07UBJj5PmpH0YOF5fA1ad+7HdFWuymvG7OuQeTlFyKCSf pnI0uy7U0QgMPOPtqwAIkbTL8bQvuVtJMgXaamGMLaD+/RiRUvft6lJkD6P2ySeLUDiq tAD+f9EYOdgZ5fWGUUPijSOvKKRh4SrkuB/srzgDl7Q/ECtwX56f1rSCmpFQmHabz37R ULNmFAq1UWrDEj5ncXH+fkBFO3huVV+IAtqrEEBpOKuxGVkgfzG+9M5PqReUISfnO5oq yMCrlHdlHDH5/Yl58ShbHcZah9Qou2+VOD6fjSPvKZUUCQbcTcEwEw0Jd9eqMC4ffTcS HAFQ== 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=CV1oZD71uuLLaB1EZ8mhrVyY8oRGBDWemPOXywRD8uE=; b=J9RypnXxsV2HZPadEHR/F3hZmf3mqAj0JX26xdC+HGv93WxxmIM5XL8LuCAoPXLiHc 7zItiHnbW72YOTxzp/0oDMX1ie12Sb0qVK3UZ7PBgy5v0TlxvtFVqWBDj2E/HYyaCj9j 08pSkizKLI9TNLFb/Mjbt7goZ/TmyxHjCnXtFXMgE1WINxs07njklail883NZOx/vw3c lsG/9Fn0wJQo9kY2MODJenSlyUVGOk8XbcQEFpRAS/rgXs7tCQQEqpN9iadu9KdDEzxN mYSLnd/19uiDIKseifyRbkTgWxBjwn86P9i+MouadTNHdAj20m029vfBr9gzSjagH9uW 0E4g== Received: by 10.60.27.166 with SMTP id u6mr7905857oeg.86.1352473589335; Fri, 09 Nov 2012 07:06:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.95.73 with HTTP; Fri, 9 Nov 2012 07:06:08 -0800 (PST) In-Reply-To: References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> From: Yuchung Cheng Date: Fri, 9 Nov 2012 10:06:08 -0500 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQleqviOTEc4c6NtATIyJ+KAkptbjQHinHmIqpdcqGopOkjfsIPYiNxS0DGLWNjLmVjUhyVHc4G/5Fv28Z8LfNqaMBD1aw1cXyEjeelQk+Eip0KSrdqTetK02nuEvxYgoBZvj4UoXQWJ0JP7LsRuCeNaZujtZFFXm9cw36PKVVwwE6yfCq0o/0ReKTOMoeeR/LZjC+P5 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:06:30 -0000 On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson wrote: > On Thu, 8 Nov 2012, Yuchung Cheng wrote: > >> My worries are that we can design fancier stuff, in the end if it does not >> matter for applications, it does not matter. Is today's basic ECN not being >> used b/c it's too basic? > > > I'd imagine ECN isn't used today because nobody knows what it is and why > it's good to use. It's like IPv6, it doesn't really solve anything for the > individual entitiy (ISP|user|equipment vendor), but as a whole, it would be > good if we had it. > > I would also venture to say that congestion used to happen in the core and > distribution. This is not really the case anymore, now congestion happens > much closer to the edge, which is also the place where there is least > homogenous control and thus harder to coordinate any technology. > > I have been running with ECN on, on most my machines for years now, just to > make sure it doesn't break anything. When it was first implemented in the > Linux kernel, ECN broke a lot of things. PIX firewalls for instance, dropped > ECN packets. This is not the case anymore as far as I can tell, I haven't > noticed any ECN related problem at all since I re-enabled it, hm, 3-4 years > ago perhaps. > > To get ECN (and other more advanced tech) into production networks, we need > to be able to explain to users and manufacturers (and ISPs) what good it > does, and how it can make their life metter. From the bufferbloat > discussion, I'd say this is quite hard, since most don't even know how TCP > works in conjunction with large buffers, much less the difference between > different TCP algorithms. So teaching about benefits of ECN is quite hard. > > ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly) > because IPv4 ran out. Nothing happened really for 5-10 years because IPv6 > didn't really solve any problem people thought they had. ECN is the same > thing. ECN makes the network more efficient, in that it doesn't drop the > packet if there is congestion. But how does that help the individual end > user? That's harder to explain. > > Sorry for not being able to give any constructive suggestions on how to > solve the problem of lack of ECN support, but if we can get some consensus > about why ECN hasn't been implemented, perhaps that helps us making future > decisions? +1 ECN has many good things but it's not used. If we are going to develop a "useful" ECN+ maybe we should ask why the operators don't use ECN. And I know many ops guy that know extremely well about TCP so maybe they have valid reasons. Thanks. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From michawe@ifi.uio.no Fri Nov 9 07:11:16 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6E221F86E2 for ; Fri, 9 Nov 2012 07:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqhEyn8A8SYk for ; Fri, 9 Nov 2012 07:11:16 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 958BF21F86F9 for ; Fri, 9 Nov 2012 07:11:15 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TWqEh-0004y7-Pl; Fri, 09 Nov 2012 16:11:11 +0100 Received: from dhcp-10f3.meeting.ietf.org ([130.129.16.243]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TWqEg-0007RI-VJ; Fri, 09 Nov 2012 16:11:11 +0100 Message-Id: <4F888FC7-BEF2-4562-9441-AE5599942215@ifi.uio.no> From: Michael Welzl To: Yuchung Cheng In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Nov 2012 16:11:08 +0100 References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 9 sum msgs/h 6 total rcpts 32 max rcpts/h 10 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E61205CAC5A59435B45F440F2CB10FC418EE20BA X-UiO-SPAM-Test: remote_host: 130.129.16.243 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:11:16 -0000 On Nov 9, 2012, at 4:06 PM, Yuchung Cheng wrote: > On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson > wrote: >> On Thu, 8 Nov 2012, Yuchung Cheng wrote: >> >>> My worries are that we can design fancier stuff, in the end if it >>> does not >>> matter for applications, it does not matter. Is today's basic ECN >>> not being >>> used b/c it's too basic? >> >> >> I'd imagine ECN isn't used today because nobody knows what it is >> and why >> it's good to use. It's like IPv6, it doesn't really solve anything >> for the >> individual entitiy (ISP|user|equipment vendor), but as a whole, it >> would be >> good if we had it. >> >> I would also venture to say that congestion used to happen in the >> core and >> distribution. This is not really the case anymore, now congestion >> happens >> much closer to the edge, which is also the place where there is least >> homogenous control and thus harder to coordinate any technology. >> >> I have been running with ECN on, on most my machines for years now, >> just to >> make sure it doesn't break anything. When it was first implemented >> in the >> Linux kernel, ECN broke a lot of things. PIX firewalls for >> instance, dropped >> ECN packets. This is not the case anymore as far as I can tell, I >> haven't >> noticed any ECN related problem at all since I re-enabled it, hm, >> 3-4 years >> ago perhaps. >> >> To get ECN (and other more advanced tech) into production networks, >> we need >> to be able to explain to users and manufacturers (and ISPs) what >> good it >> does, and how it can make their life metter. From the bufferbloat >> discussion, I'd say this is quite hard, since most don't even know >> how TCP >> works in conjunction with large buffers, much less the difference >> between >> different TCP algorithms. So teaching about benefits of ECN is >> quite hard. >> >> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening >> (slowly) >> because IPv4 ran out. Nothing happened really for 5-10 years >> because IPv6 >> didn't really solve any problem people thought they had. ECN is the >> same >> thing. ECN makes the network more efficient, in that it doesn't >> drop the >> packet if there is congestion. But how does that help the >> individual end >> user? That's harder to explain. >> >> Sorry for not being able to give any constructive suggestions on >> how to >> solve the problem of lack of ECN support, but if we can get some >> consensus >> about why ECN hasn't been implemented, perhaps that helps us making >> future >> decisions? > +1 > > ECN has many good things but it's not used. If we are going to develop > a "useful" ECN+ maybe we should ask why the operators don't use ECN. > And I know many ops guy that know extremely well about TCP so maybe > they have valid reasons. Chicken-egg, I suppose: why support something that noone uses? Cheers, Michael From emmanuel.lochin@gmail.com Fri Nov 9 08:54:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D06C21F8518 for ; Fri, 9 Nov 2012 08:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzbvPa8G74fA for ; Fri, 9 Nov 2012 08:54:32 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF921F8585 for ; Fri, 9 Nov 2012 08:54:31 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so4445875vcb.31 for ; Fri, 09 Nov 2012 08:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vMKwAa9OnXePJ7dlZM/BCkDMGh08kxAWJn9Hx86Dgbk=; b=pi/Nr71ju35gvjmwyxaNnDnH3XTD6N4EkeFIy7K3NAmIWzAKsQFN5jUunyCz57K34O ESoC7yoJkiOZxFIUReCRWAsHpesXTPx0+sG2e2cId0ZkSB60bX2uL0Wqy2jbNOBbquYn k8QnxREVRg9IWFy3k9qCZ6vjkT39wIynuhjnLojX5qann0YOvJ5YLS03l5s37G2Xc5b3 aflRlbfldUlM7RY+TrV4KFHfpKDPkh355e5XK03YbkXFEwPG1zveEW2uZg/RTisgSiU4 ObXb+LTZszETjM8t/igPhzL3Ne32E0desNoL1vcwFkaINhon/592CiNf3ZSBvPNCNr+g PMJA== MIME-Version: 1.0 Received: by 10.58.15.227 with SMTP id a3mr5821911ved.38.1352480071468; Fri, 09 Nov 2012 08:54:31 -0800 (PST) Received: by 10.59.5.196 with HTTP; Fri, 9 Nov 2012 08:54:31 -0800 (PST) In-Reply-To: <4F888FC7-BEF2-4562-9441-AE5599942215@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> <4F888FC7-BEF2-4562-9441-AE5599942215@ifi.uio.no> Date: Fri, 9 Nov 2012 17:54:31 +0100 Message-ID: From: Emmanuel Lochin To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:54:33 -0000 Sorry but "none" means TCP? Because I use ECN (I take my network engineer hat). And I am not the only one ... at least all my sys/network admin colleagues are using it too. I use it to take QoS decisions and to collect statistics on my network (the rationale of using a counter comes from this observation). Ok, ECN might be not used inside the whole network but who cares? All my core devices are ECN compliant so why not using inside my own network? We know, following "The power of explicit congestion notification", A. Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings out benefit for the end-user. My GNU/Linux stack does not react to ECN? Not a problem ... my access network does. On my side, I use specific mechanisms conjointly with ECN inherited from the QoS epoch. For instance, I can shape ECN feedbacks to slow down connexions or to give a delay penalty to a specific flow. Basically I use ECN like an "alert". The problem is that we do not propose the right tools to operate with ECN. ECN* was an attempt, Re-ECN is also a good example of a practical usage of ECN. Emmanuel On 9 November 2012 16:11, Michael Welzl wrote: > > On Nov 9, 2012, at 4:06 PM, Yuchung Cheng wrote: > >> On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson >> wrote: >>> >>> On Thu, 8 Nov 2012, Yuchung Cheng wrote: >>> >>>> My worries are that we can design fancier stuff, in the end if it does >>>> not >>>> matter for applications, it does not matter. Is today's basic ECN not >>>> being >>>> used b/c it's too basic? >>> >>> >>> >>> I'd imagine ECN isn't used today because nobody knows what it is and why >>> it's good to use. It's like IPv6, it doesn't really solve anything for >>> the >>> individual entitiy (ISP|user|equipment vendor), but as a whole, it would >>> be >>> good if we had it. >>> >>> I would also venture to say that congestion used to happen in the core >>> and >>> distribution. This is not really the case anymore, now congestion happens >>> much closer to the edge, which is also the place where there is least >>> homogenous control and thus harder to coordinate any technology. >>> >>> I have been running with ECN on, on most my machines for years now, just >>> to >>> make sure it doesn't break anything. When it was first implemented in the >>> Linux kernel, ECN broke a lot of things. PIX firewalls for instance, >>> dropped >>> ECN packets. This is not the case anymore as far as I can tell, I haven't >>> noticed any ECN related problem at all since I re-enabled it, hm, 3-4 >>> years >>> ago perhaps. >>> >>> To get ECN (and other more advanced tech) into production networks, we >>> need >>> to be able to explain to users and manufacturers (and ISPs) what good it >>> does, and how it can make their life metter. From the bufferbloat >>> discussion, I'd say this is quite hard, since most don't even know how >>> TCP >>> works in conjunction with large buffers, much less the difference between >>> different TCP algorithms. So teaching about benefits of ECN is quite >>> hard. >>> >>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly) >>> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6 >>> didn't really solve any problem people thought they had. ECN is the same >>> thing. ECN makes the network more efficient, in that it doesn't drop the >>> packet if there is congestion. But how does that help the individual end >>> user? That's harder to explain. >>> >>> Sorry for not being able to give any constructive suggestions on how to >>> solve the problem of lack of ECN support, but if we can get some >>> consensus >>> about why ECN hasn't been implemented, perhaps that helps us making >>> future >>> decisions? >> >> +1 >> >> ECN has many good things but it's not used. If we are going to develop >> a "useful" ECN+ maybe we should ask why the operators don't use ECN. >> And I know many ops guy that know extremely well about TCP so maybe >> they have valid reasons. > > > Chicken-egg, I suppose: why support something that noone uses? > > Cheers, > Michael > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Fri Nov 9 09:02:37 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9421F8759 for ; Fri, 9 Nov 2012 09:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPhaRSU4aSuN for ; Fri, 9 Nov 2012 09:02:36 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 1261B21F8752 for ; Fri, 9 Nov 2012 09:02:36 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TWryV-0007Fd-DU; Fri, 09 Nov 2012 18:02:35 +0100 Received: from dhcp-9332.meeting.ietf.org ([130.129.11.50]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TWryU-0000pS-AI; Fri, 09 Nov 2012 18:02:35 +0100 Message-Id: From: Michael Welzl To: Emmanuel Lochin In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Nov 2012 18:02:31 +0100 References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> <4F888FC7-BEF2-4562-9441-AE5599942215@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 38 max rcpts/h 10 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 381275BBBA8BB55807EC585BB69EC27BCE2CB947 X-UiO-SPAM-Test: remote_host: 130.129.11.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 16 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:02:37 -0000 Hi, Yes I meant TCP. Sorry if my message got across as meaning "ECN is useless". This is certainly not what I was trying to say: my point is, we're perhaps facing a chicken-egg problem where operators won't have much incentive to support ECN as they probably don't see many ECN- capable packets in their path. I'm all for changing that! From anecdotal evidence (including yours, based on the email below!) as well as the IMC'11 paper: Measuring the State of ECN Readiness in Servers, Clients, and Routers http://rbeverly.net/research/papers/ecn-imc11.pdf it seems to me that turning on ECN support in general won't cause you harm (although it's apparently common to have it disabled somewhere along the path). I think this was perhaps different in the past. Cheers, Michael On Nov 9, 2012, at 5:54 PM, Emmanuel Lochin wrote: > Sorry but "none" means TCP? Because I use ECN (I take my network > engineer hat). And I am not the only one ... at least all my > sys/network admin colleagues are using it too. I use it to take QoS > decisions and to collect statistics on my network (the rationale of > using a counter comes from this observation). > > Ok, ECN might be not used inside the whole network but who cares? All > my core devices are ECN compliant so why not using inside my own > network? > We know, following "The power of explicit congestion notification", A. > Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings > out benefit for the end-user. My GNU/Linux stack does not react to > ECN? Not a problem ... my access network does. > > On my side, I use specific mechanisms conjointly with ECN inherited > from the QoS epoch. For instance, I can shape ECN feedbacks to slow > down connexions or to give a delay penalty to a specific flow. > Basically I use ECN like an "alert". > > The problem is that we do not propose the right tools to operate with > ECN. ECN* was an attempt, Re-ECN is also a good example of a practical > usage of ECN. > > Emmanuel > > > > > > On 9 November 2012 16:11, Michael Welzl wrote: >> >> On Nov 9, 2012, at 4:06 PM, Yuchung Cheng wrote: >> >>> On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson >> > >>> wrote: >>>> >>>> On Thu, 8 Nov 2012, Yuchung Cheng wrote: >>>> >>>>> My worries are that we can design fancier stuff, in the end if >>>>> it does >>>>> not >>>>> matter for applications, it does not matter. Is today's basic >>>>> ECN not >>>>> being >>>>> used b/c it's too basic? >>>> >>>> >>>> >>>> I'd imagine ECN isn't used today because nobody knows what it is >>>> and why >>>> it's good to use. It's like IPv6, it doesn't really solve >>>> anything for >>>> the >>>> individual entitiy (ISP|user|equipment vendor), but as a whole, >>>> it would >>>> be >>>> good if we had it. >>>> >>>> I would also venture to say that congestion used to happen in the >>>> core >>>> and >>>> distribution. This is not really the case anymore, now congestion >>>> happens >>>> much closer to the edge, which is also the place where there is >>>> least >>>> homogenous control and thus harder to coordinate any technology. >>>> >>>> I have been running with ECN on, on most my machines for years >>>> now, just >>>> to >>>> make sure it doesn't break anything. When it was first >>>> implemented in the >>>> Linux kernel, ECN broke a lot of things. PIX firewalls for >>>> instance, >>>> dropped >>>> ECN packets. This is not the case anymore as far as I can tell, I >>>> haven't >>>> noticed any ECN related problem at all since I re-enabled it, hm, >>>> 3-4 >>>> years >>>> ago perhaps. >>>> >>>> To get ECN (and other more advanced tech) into production >>>> networks, we >>>> need >>>> to be able to explain to users and manufacturers (and ISPs) what >>>> good it >>>> does, and how it can make their life metter. From the bufferbloat >>>> discussion, I'd say this is quite hard, since most don't even >>>> know how >>>> TCP >>>> works in conjunction with large buffers, much less the difference >>>> between >>>> different TCP algorithms. So teaching about benefits of ECN is >>>> quite >>>> hard. >>>> >>>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening >>>> (slowly) >>>> because IPv4 ran out. Nothing happened really for 5-10 years >>>> because IPv6 >>>> didn't really solve any problem people thought they had. ECN is >>>> the same >>>> thing. ECN makes the network more efficient, in that it doesn't >>>> drop the >>>> packet if there is congestion. But how does that help the >>>> individual end >>>> user? That's harder to explain. >>>> >>>> Sorry for not being able to give any constructive suggestions on >>>> how to >>>> solve the problem of lack of ECN support, but if we can get some >>>> consensus >>>> about why ECN hasn't been implemented, perhaps that helps us making >>>> future >>>> decisions? >>> >>> +1 >>> >>> ECN has many good things but it's not used. If we are going to >>> develop >>> a "useful" ECN+ maybe we should ask why the operators don't use ECN. >>> And I know many ops guy that know extremely well about TCP so maybe >>> they have valid reasons. >> >> >> Chicken-egg, I suppose: why support something that noone uses? >> >> Cheers, >> Michael >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From swmike@swm.pp.se Fri Nov 9 09:56:52 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F0A21F8758 for ; Fri, 9 Nov 2012 09:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKAhr6P-8n2U for ; Fri, 9 Nov 2012 09:56:51 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 68EB421F8675 for ; Fri, 9 Nov 2012 09:56:51 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E7169C; Fri, 9 Nov 2012 18:56:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5843E9A; Fri, 9 Nov 2012 18:56:49 +0100 (CET) Date: Fri, 9 Nov 2012 18:56:49 +0100 (CET) From: Mikael Abrahamsson To: Emmanuel Lochin In-Reply-To: Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> <4F888FC7-BEF2-4562-9441-AE5599942215@ifi.uio.no> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" , Michael Welzl Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:56:52 -0000 On Fri, 9 Nov 2012, Emmanuel Lochin wrote: > Ok, ECN might be not used inside the whole network but who cares? All > my core devices are ECN compliant so why not using inside my own > network? What core devices are that? When I last looked at platforms such as Cisco CRS-1 / ASR9k, Juniper MX/P-series, Huawei 5000, none of them supported ECN. This was a few years ago, so I'd be happy to be enlightened about progress! The only platform I have encountered so far that does ECN are Cisco processor based platforms such as the 7200. > We know, following "The power of explicit congestion notification", A. > Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings > out benefit for the end-user. My GNU/Linux stack does not react to > ECN? Not a problem ... my access network does. What devices are those? > On my side, I use specific mechanisms conjointly with ECN inherited > from the QoS epoch. For instance, I can shape ECN feedbacks to slow > down connexions or to give a delay penalty to a specific flow. > Basically I use ECN like an "alert". But how many flows do you have that are ECN enabled? What host systems uses ECN by default? I have this on my linux boxes: $ grep -i ecn /etc/sysctl.conf net.ipv4.tcp_ecn = 1 net.ipv6.tcp_ecn = 1 (I believe the ipv6 line is redundant, just put it in there to be future proof). I do not believe this is the standard setting? Please correct me if I'm wrong. -- Mikael Abrahamsson email: swmike@swm.pp.se From emmanuel.lochin@gmail.com Fri Nov 9 11:00:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AEA21F845E for ; Fri, 9 Nov 2012 11:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Cynts4uiLL for ; Fri, 9 Nov 2012 11:00:08 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3651F21F845D for ; Fri, 9 Nov 2012 11:00:08 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so4586008vcb.31 for ; Fri, 09 Nov 2012 11:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=++GJ4dixnrM/8KH0k7qG7htUhhislhKlh1AtKaxn39c=; b=WVs4ajdv8raOwbrj60JtoJzfD482ObQIKMD3u08ecsFFru9O8lb6MloOkFhaeBOnrb haINejtLuTjT4gbT0BYkRKdE5ri/GrtZaF2G9JtzFRun6YQLTlwUvfJZE1FUYWcP45te dH6nr4w5zIm32oVhdjSd/Y5mS/vbFJNr/Mav75JLc5MdtwBxd7m6G3GVT79zLWgn+Z7i 4Ul9sba05fPP611Ncvgev8EoEMa6yO4UgI2BKj4AyA+cMmJXXbx4ZwB+6IwrW7Fgv4t2 Zj8OhMjcQIuApBnhFsy63EG30ajRbbXMu39zEijrYPpt0wEs+hAw84iaV6R8+cDncSG3 L67A== MIME-Version: 1.0 Received: by 10.58.15.227 with SMTP id a3mr6252669ved.38.1352487607504; Fri, 09 Nov 2012 11:00:07 -0800 (PST) Received: by 10.59.5.196 with HTTP; Fri, 9 Nov 2012 11:00:07 -0800 (PST) In-Reply-To: References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> <4F888FC7-BEF2-4562-9441-AE5599942215@ifi.uio.no> Date: Fri, 9 Nov 2012 20:00:07 +0100 Message-ID: From: Emmanuel Lochin To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" , Michael Welzl Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:00:09 -0000 On 9 November 2012 18:56, Mikael Abrahamsson wrote: > On Fri, 9 Nov 2012, Emmanuel Lochin wrote: > >> Ok, ECN might be not used inside the whole network but who cares? All >> my core devices are ECN compliant so why not using inside my own >> network? > > What core devices are that? When I last looked at platforms such as Cisco > CRS-1 / ASR9k, Juniper MX/P-series, Huawei 5000, none of them supported ECN. > This was a few years ago, so I'd be happy to be enlightened about progress! > The only platform I have encountered so far that does ECN are Cisco > processor based platforms such as the 7200. Hi Mikael Well ... I should precise that I use only GNU/Linux or *BSD. For ECN marking I use tc on GNU/Linux. >> We know, following "The power of explicit congestion notification", A. >> Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings >> out benefit for the end-user. My GNU/Linux stack does not react to >> ECN? Not a problem ... my access network does. > > > What devices are those? All my routers are Linux or BSD boxes (HP Proliant blades or simple PC), obvioulsy I need to tune both BSD or Linux kernels to be able to correctly manage the trafic. > >> On my side, I use specific mechanisms conjointly with ECN inherited >> from the QoS epoch. For instance, I can shape ECN feedbacks to slow >> down connexions or to give a delay penalty to a specific flow. >> Basically I use ECN like an "alert". > > > But how many flows do you have that are ECN enabled? What host systems uses > ECN by default? All are GNU/Linux boxes except some *BSD. Most of them are used by students/researchers that access to simulation servers or educational ressources. All my network is ECN-enabled. I have also used to enable an ECN path over a link between Reunion Island university and Paris VI university in 2004 and paced the traffic following the marking with a penalty box. > I have this on my linux boxes: > > $ grep -i ecn /etc/sysctl.conf > net.ipv4.tcp_ecn = 1 > net.ipv6.tcp_ecn = 1 > > (I believe the ipv6 line is redundant, just put it in there to be future > proof). I do not believe this is the standard setting? Please correct me if > I'm wrong. This is the standard setting. Today kernels enable CUBIC and ECN. But as far as I know, CUBIC does not react to ECN. Manu > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From rick.jones2@hp.com Fri Nov 9 12:54:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D121F84A5 for ; Fri, 9 Nov 2012 12:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3CN86075H80 for ; Fri, 9 Nov 2012 12:54:01 -0800 (PST) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id B0C8621F849A for ; Fri, 9 Nov 2012 12:54:01 -0800 (PST) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0006.atlanta.hp.com (Postfix) with ESMTP id F0AF2C175; Fri, 9 Nov 2012 20:54:00 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 17B8614092; Fri, 9 Nov 2012 20:53:59 +0000 (UTC) Message-ID: <509D6D66.8040701@hp.com> Date: Fri, 09 Nov 2012 12:53:58 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Emmanuel Lochin References: <012C3117EDDB3C4781FD802A8C27DD4F0D7446A5@SACEXCMBX02-PRD.hq.netapp.com> <145E236F-7E95-4943-A548-DFF563C3E1AB@ifi.uio.no> <2FAF37DF-F803-479B-BAFC-6DA75B817347@ifi.uio.no> <54d27ecd8587eea3bffb3cf810bf2440.squirrel@www.erg.abdn.ac.uk> <4F888FC7-BEF2-4562-9441-AE5599942215@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm \(tcpm@ietf.org\)" , "iccrg@cs.ucl.ac.uk list" , Michael Welzl Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:54:02 -0000 > This is the standard setting. Today kernels enable CUBIC and ECN. But > as far as I know, CUBIC does not react to ECN. It may not be "today's" Linux kernel, but I think the default setting for TCP's use of ECN is "Accept, but do not initiate" ubuntu@server-1351900909-az-3-region-a-geo-1:~$ sudo sysctl -a | grep ecn net.ipv4.tcp_ecn = 2 ubuntu@server-1351900909-az-3-region-a-geo-1:~$ uname -a Linux server-1351900909-az-3-region-a-geo-1 3.2.0-23-virtual #36-Ubuntu SMP Tue Apr 10 22:29:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Actually, I can get close to what I suppose in essence is "today's" linux kernel, at least as far as linux networking is concerned - a kernel from a davem net-next tree pulled somewhat recently (within the last week or so): raj@tardy-ubuntu-1204:~$ sudo sysctl -a | grep ecn error: permission denied on key 'net.ipv4.route.flush' net.ipv4.tcp_ecn = 2 raj@tardy-ubuntu-1204:~$ uname -a Linux tardy-ubuntu-1204 3.7.0-rc1+ #4 SMP Sat Nov 3 13:12:18 PDT 2012 x86_64 x86_64 x86_64 GNU/Linux Here is the description from Documentation/networking/ip-sysctl.txt in that net-next tree: tcp_ecn - INTEGER Enable Explicit Congestion Notification (ECN) in TCP. ECN is only used when both ends of the TCP flow support it. It is useful to avoid losses due to congestion (when the bottleneck router supports ECN). Possible values are: 0 disable ECN 1 ECN enabled 2 Only server-side ECN enabled. If the other end does not support ECN, behavior is like with ECN disabled. Default: 2 I suppose that could be worded a bit more explicitly though. happy benchmarking, rick jones From ingemar.s.johansson@ericsson.com Mon Nov 12 00:00:23 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27821F843E for ; Mon, 12 Nov 2012 00:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BneEWlk385PB for ; Mon, 12 Nov 2012 00:00:21 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 140F221F8462 for ; Mon, 12 Nov 2012 00:00:20 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-1b-50a0ac93e47f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DE.5E.11564.39CA0A05; Mon, 12 Nov 2012 09:00:20 +0100 (CET) Received: from ESESSHC005.ericsson.se (153.88.183.33) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 12 Nov 2012 09:00:18 +0100 Received: from ESESSMB205.ericsson.se ([169.254.5.129]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 09:00:18 +0100 From: Ingemar Johansson S To: "iccrg@cs.ucl.ac.uk" Thread-Topic: ECN feedback discussion Thread-Index: Ac3Ap6C8ufVNe52xT/mbM2eaxd1xvw== Date: Mon, 12 Nov 2012 08:00:17 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA03E8CC@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje6UNQsCDP62cVksvjKNyWLbyflM Dkwez46vZfJYsuQnUwBTFJdNSmpOZllqkb5dAlfGtx+PWQse6VTM/nyNvYFxlUoXIyeHhICJ xJ477WwQtpjEhXvrgWwuDiGBk4wSLadPsUI4Oxklprz+xQ5SJSSwhFHi3qcQEJtNwEZi5aHv jCC2iICuxIamZSwgNrOAssTyY9PB6oUFFCW2n1nNBFGjJvF31jJmCFtP4tyPY2A2i4CqxOTZ c8FqeAW8JeaebwSbySggK3H/+z2omeISt57MZ4K4VEBiyZ7zzBC2qMTLx/9YIWxFiY+v9jFC 1OtJ3Jg6hQ3C1pZYtvA1M8R8QYmTM5+wQPyiK7F+x1X2CYxis5CsmIWkfRaS9llI2hcwsqxi ZM9NzMxJLzfcxAiMkoNbfuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjKkvHK7qmVmlxZxkZ5/3ynnLx3ubp4pJXTrom+t5Vn97JtelEn3Lpe/s9mfz8f6b b7795Y55Jo/YeHZX97J9K3cyNTrcoZDWe+ezcv7n1mdefiHf0x1qt6z0W31hm1ljsNGFy1s4 Xxx912L/ItfTnZM7c/Ue9yXcnQ8bi402BKf/SQ+/MP1xvxJLcUaioRZzUXEiAIDtX8tgAgAA Cc: "tcpm@ietf.org" Subject: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 08:00:23 -0000 Hi A few comments on an interesting topic. =20 QoS dependent ECN marking:=20 I believe the idea to use different ECN marking strategies depending on QoS= (or perhaps QCI=3DQoS class identifier in LTE) has been discussed earlier.= =20 I am however pretty much in favor of having one strategy regardless of QoS,= mainly because of the relative simplicity compared to a special ECN treatm= ent depending on QCI. This may in the end mean that services with a higher = QoS will have a higher ECN marking rate than services with a lower QoS but= I don't really see a problem with that and long as it is allowed by operat= or policies. Also it blends well with the "weighted farness" ideas. In fact= ConEx (if it flies) is a good policing framework for this in the sense tha= t services with higher QoS can cause a higher congestion volume. High density vs Low Density ECN marking: I really like the idea as it can for instance enable a smoother rate adapta= tion for e.g video because of the higher number of congestion signals. Had a look into 3GPP TS36.300, no distinction is made between ECT(0) and EC= T(1) there. This means that additional specification is needed to specify t= hat ECT(1) means smomething like "apply high density ECN marking if impleme= nted". When 3GPP TS 26.114 was specified it was explicitly mentioned that E= CT(0) should be used, the idea behind was that at some stage there may pop = up some interesting use for ECT(1) so it is then best to avoid messing with= it. Low/High density ECN is a good cantidate. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "However beautiful the strategy,=20 you should occasionally look at the results"=20 Sir Winston Churchill =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------------- Message: 1 Date: Sat, 10 Nov 2012 16:35:12 +0000 From: "Scheffenegger, Richard" Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion To: Michael Welzl Cc: "iccrg@cs.ucl.ac.uk list" Message-ID: Content-Type: text/plain; charset=3D"utf-8" That would be my stance too... Imho, part of why ecn has failed to get traction was/is the complex and non= deterministic way in which the end systems and the network in between are s= upposed to run a distributed control loop that should keep congestion (stan= ding buffer queues/buffer overflows) at bay. Imho, dctcp has a very good point in keeping the control loop entirely in t= he end systems and have a very simple, straight forward and deterministic m= arking scheme in the network... I think we need first and foremost a signaling scheme that should lend itse= lf to the most broad applications. A counter (of some sort, however implemented) would be a huge step forward. I'm also wondering, if there is information to be had off the exact "patter= n" (in the time domain) from CE (or ECT1 too) marks... I.e. Is a sudden jump from no marks to all marks and then a slow drop of ma= rking probability - all in one RTT - different from a slow rise in markin p= robabiliy up to 100%, followed by a sudden drop to no marks? With the total= number of marks in one RTT equal in both cases? Can anyone think that such= a 2nd order signal might be useful, or does anyone know of research into s= uch aspects? Best regards, Richard Von meinem iPhone gesendet Am 09.11.2012 um 09:20 schrieb "Michael Welzl" : > Hi, >=20 > I'd prefer a simpler approach. We haven't seen ECN happen, and trying to = embed QoS in it isn't exactly going to improve the probability of success I= MO. >=20 > Cheers, > Michael >=20 >=20 > On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote: >=20 >> I think updating the behaviour of ECN would be a great idea - >>=20 >> We could have different behaviours for different types of=20 >> communication - for e.g. >>=20 >> (1) we could be less aggressive to emergency communications >> (2) We could be more aggressive to scavenger type traffic >> (3) We do the normal ecn behaviour inbetween >>=20 >> So probably we-ve got to map QoS behaviour to ECN I guess.. >>=20 >> Arjuna >>=20 >> On 9 November 2012 04:50, wrote: >>> Send Iccrg mailing list submissions to >>> iccrg@cs.ucl.ac.uk >>>=20 >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg >>> or, via email, send a message with subject or body 'help' to >>> iccrg-request@cs.ucl.ac.uk >>>=20 >>> You can reach the person managing the list at >>> iccrg-owner@cs.ucl.ac.uk >>>=20 >>> When replying, please edit your Subject line so it is more specific=20 >>> than "Re: Contents of Iccrg digest..." >>>=20 >>>=20 >>> Today's Topics: >>>=20 >>> 1. Re: [tcpm] ECN feedback discussion (Michael Welzl) 2. Re: New=20 >>> co-chair (Eggert, Lars) 3. Re: [tcpm] ECN feedback discussion=20 >>> (Yuchung Cheng) 4. Re: [tcpm] ECN feedback discussion (Michael=20 >>> Welzl) 5. Re: Re: [tcpm] ECN feedback discussion (Mikael=20 >>> Abrahamsson) >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> -- >>>=20 From rs@netapp.com Mon Nov 12 02:04:11 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2E521F84BB for ; Mon, 12 Nov 2012 02:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8zb+35a9wgm for ; Mon, 12 Nov 2012 02:04:10 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5DB21F84BA for ; Mon, 12 Nov 2012 02:04:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,761,1344236400"; d="scan'208";a="279956275" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 12 Nov 2012 02:04:08 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qACA466I016520; Mon, 12 Nov 2012 02:04:06 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.145]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 02:03:59 -0800 From: "Scheffenegger, Richard" To: Ingemar Johansson S Thread-Topic: [tcpm] ECN feedback discussion Thread-Index: Ac3Ap6C8ufVNe52xT/mbM2eaxd1xvwAFWdFU Date: Mon, 12 Nov 2012 10:03:58 +0000 Message-ID: <654636BB-AD42-42A1-8AAE-3837E9677325@netapp.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA03E8CC@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA03E8CC@ESESSMB205.ericsson.se> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 10:04:11 -0000 Alternative to using ect1 by the sender (allowing high density ecn marking)= , what about the sender continuing to use ect0, but high density ecn markin= g by routers changing that from ect0 to ect1 and ect1 to ce (or ect0 direct= l to ce on very high load)? Some papers claim that having an counter to allow multiple routers marking = the same packet enables better signal for cc... also, legacy receivers would only react to ce as usual and not fine grained= ... Best regards, richard Von meinem iPhone gesendet Am 12.11.2012 um 09:02 schrieb "Ingemar Johansson S" : > Hi >=20 > A few comments on an interesting topic. >=20 > QoS dependent ECN marking:=20 > I believe the idea to use different ECN marking strategies depending on Q= oS (or perhaps QCI=3DQoS class identifier in LTE) has been discussed earlie= r.=20 > I am however pretty much in favor of having one strategy regardless of Qo= S, mainly because of the relative simplicity compared to a special ECN trea= tment depending on QCI. This may in the end mean that services with a highe= r QoS will have a higher ECN marking rate than services with a lower QoS b= ut I don't really see a problem with that and long as it is allowed by oper= ator policies. Also it blends well with the "weighted farness" ideas. In fa= ct ConEx (if it flies) is a good policing framework for this in the sense t= hat services with higher QoS can cause a higher congestion volume. >=20 > High density vs Low Density ECN marking: > I really like the idea as it can for instance enable a smoother rate adap= tation for e.g video because of the higher number of congestion signals. > Had a look into 3GPP TS36.300, no distinction is made between ECT(0) and = ECT(1) there. This means that additional specification is needed to specify= that ECT(1) means smomething like "apply high density ECN marking if imple= mented". When 3GPP TS 26.114 was specified it was explicitly mentioned that= ECT(0) should be used, the idea behind was that at some stage there may po= p up some interesting use for ECT(1) so it is then best to avoid messing wi= th it. Low/High density ECN is a good cantidate. >=20 > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc.=20 > Senior Researcher >=20 > Ericsson AB > Wireless Access Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com >=20 > "However beautiful the strategy,=20 > you should occasionally look at the results"=20 > Sir Winston Churchill > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Sat, 10 Nov 2012 16:35:12 +0000 > From: "Scheffenegger, Richard" > Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion > To: Michael Welzl > Cc: "iccrg@cs.ucl.ac.uk list" > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" >=20 > That would be my stance too... >=20 > Imho, part of why ecn has failed to get traction was/is the complex and n= ondeterministic way in which the end systems and the network in between are= supposed to run a distributed control loop that should keep congestion (st= anding buffer queues/buffer overflows) at bay. >=20 > Imho, dctcp has a very good point in keeping the control loop entirely in= the end systems and have a very simple, straight forward and deterministic= marking scheme in the network... >=20 > I think we need first and foremost a signaling scheme that should lend it= self to the most broad applications. >=20 > A counter (of some sort, however implemented) would be a huge step forwar= d. >=20 > I'm also wondering, if there is information to be had off the exact "patt= ern" (in the time domain) from CE (or ECT1 too) marks... >=20 > I.e. Is a sudden jump from no marks to all marks and then a slow drop of = marking probability - all in one RTT - different from a slow rise in markin= probabiliy up to 100%, followed by a sudden drop to no marks? With the tot= al number of marks in one RTT equal in both cases? Can anyone think that su= ch a 2nd order signal might be useful, or does anyone know of research into= such aspects? >=20 >=20 > Best regards, > Richard >=20 > Von meinem iPhone gesendet >=20 > Am 09.11.2012 um 09:20 schrieb "Michael Welzl" : >=20 >> Hi, >>=20 >> I'd prefer a simpler approach. We haven't seen ECN happen, and trying to= embed QoS in it isn't exactly going to improve the probability of success = IMO. >>=20 >> Cheers, >> Michael >>=20 >>=20 >> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote: >>=20 >>> I think updating the behaviour of ECN would be a great idea - >>>=20 >>> We could have different behaviours for different types of=20 >>> communication - for e.g. >>>=20 >>> (1) we could be less aggressive to emergency communications >>> (2) We could be more aggressive to scavenger type traffic >>> (3) We do the normal ecn behaviour inbetween >>>=20 >>> So probably we-ve got to map QoS behaviour to ECN I guess.. >>>=20 >>> Arjuna >>>=20 >>> On 9 November 2012 04:50, wrote: >>>> Send Iccrg mailing list submissions to >>>> iccrg@cs.ucl.ac.uk >>>>=20 >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg >>>> or, via email, send a message with subject or body 'help' to >>>> iccrg-request@cs.ucl.ac.uk >>>>=20 >>>> You can reach the person managing the list at >>>> iccrg-owner@cs.ucl.ac.uk >>>>=20 >>>> When replying, please edit your Subject line so it is more specific=20 >>>> than "Re: Contents of Iccrg digest..." >>>>=20 >>>>=20 >>>> Today's Topics: >>>>=20 >>>> 1. Re: [tcpm] ECN feedback discussion (Michael Welzl) 2. Re: New=20 >>>> co-chair (Eggert, Lars) 3. Re: [tcpm] ECN feedback discussion=20 >>>> (Yuchung Cheng) 4. Re: [tcpm] ECN feedback discussion (Michael=20 >>>> Welzl) 5. Re: Re: [tcpm] ECN feedback discussion (Mikael=20 >>>> Abrahamsson) >>>>=20 >>>>=20 >>>> -------------------------------------------------------------------- >>>> -- >>>>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From john@jlc.net Mon Nov 12 05:48:28 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2099721F84DD for ; Mon, 12 Nov 2012 05:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRX8ieu+jIAf for ; Mon, 12 Nov 2012 05:48:26 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7521F81FE for ; Mon, 12 Nov 2012 05:48:26 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D750233C41; Mon, 12 Nov 2012 08:48:25 -0500 (EST) Date: Mon, 12 Nov 2012 08:48:25 -0500 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20121112134825.GJ78300@verdi> References: <81564C0D7D4D2A4B9A86C8C7404A13DA03E8CC@ESESSMB205.ericsson.se> <654636BB-AD42-42A1-8AAE-3837E9677325@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <654636BB-AD42-42A1-8AAE-3837E9677325@netapp.com> User-Agent: Mutt/1.4.1i Cc: Ingemar Johansson S , "tcpm@ietf.org" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 13:48:28 -0000 Scheffenegger, Richard wrote: > > Alternative to using ect1 by the sender (allowing high density ecn > marking), what about the sender continuing to use ect0, but high > density ecn marking by routers changing that from ect0 to ect1 andi > ect1 to ce (or ect0 directl to ce on very high load)? A truly interesting idea! Deployable... Of course, we'd need research to determine a good thresshold for marking ect0 to ect1. -- John Leslie From pasi.sarolahti@iki.fi Mon Nov 12 06:00:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D065521F85A2 for ; Mon, 12 Nov 2012 06:00:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGyYsNJOTmpc for ; Mon, 12 Nov 2012 06:00:48 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACEE21F8539 for ; Mon, 12 Nov 2012 06:00:47 -0800 (PST) Received: from pc122.netlab.hut.fi (130.233.154.122) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508714160044CE97 for tcpm@ietf.org; Mon, 12 Nov 2012 16:00:46 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 16:01:02 +0200 Message-Id: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> To: tcpm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 14:00:49 -0000 Hi, In the TCPM meeting last week there was a clear consensus for adopting = RTO restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, = targeted for Experimental RFC. Here is a proposal for a new milestone = item: Aug 2013 Submit document on restarting the RTO timer to the IESG for = publication as an Experimental RFC Any comments or objections about the milestone? We discussed the issue of Std Track vs. Experimental a bit during the = meeting, but did not have a clear consensus call on that. My reading of = the discussion is that there would be room for experimentation to = understand the effect that the proposed change might have on the = likelihood of spurious RTOs. Therefore the proposed milestone currently = is for Experimental. As discussed in the meeting, if during the progress = it turns out that more experimentation is not necessary, we may, by WG = consensus, change the intended status accordingly. Is this a fair plan = for people? - Pasi From rs@netapp.com Mon Nov 12 06:35:23 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C208921F85DF for ; Mon, 12 Nov 2012 06:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQGczN68ks8O for ; Mon, 12 Nov 2012 06:35:22 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id EA9A321F859E for ; Mon, 12 Nov 2012 06:35:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,762,1344236400"; d="scan'208";a="709425322" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Nov 2012 06:35:22 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qACEZLOP026241; Mon, 12 Nov 2012 06:35:22 -0800 (PST) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 12 Nov 2012 06:35:21 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.145]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 06:35:21 -0800 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [Iccrg] Re: [tcpm] ECN feedback discussion Thread-Index: Ac3Ap6C8ufVNe52xT/mbM2eaxd1xvwAFWdFUABiaSYAAELa/4A== Date: Mon, 12 Nov 2012 14:35:20 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D7835FC@SACEXCMBX02-PRD.hq.netapp.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA03E8CC@ESESSMB205.ericsson.se> <654636BB-AD42-42A1-8AAE-3837E9677325@netapp.com> <20121112134825.GJ78300@verdi> In-Reply-To: <20121112134825.GJ78300@verdi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ingemar Johansson S , "tcpm@ietf.org" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 14:35:23 -0000 I'm back at a decent computer; this is the paper which mentions how the hig= hest congestion rate on one of multiple congested routers can be determined= (needs to know the number of hops though; with L2-to-L3 mapping of marks, = simple TTL assumtions may not be enough). "ECN verbose mode: a statistical method for network path congestion estimat= ion", Remi Diana, Emmanuel Lochin, 2010 http://arxiv.org/pdf/0910.4455v2.pdf I think Emmanuel is listening on one of these groups; For the signaling aspect, using ECT1 as the initial signal of a high-densit= y marking scheme, and CE for both low-density and when two high-density sch= emes overlap (mark the same packet) would be an improvement along the lines= mentioned in that paper. However, even the current TCP ECN Nonce feedback wouldn't work properly, as= a feedback channel from the receiver to the sender. I'm deliberately exclu= ding other protocols for now... As Matt suggested, if such a scheme were to be standardized, the balance be= tween feedback for CE and ECT(1) would generally shift more to ECT(1); the = codepoint scheme described in draft-kuehlewind-tcpm-accurate-ecn could be a= dapted to that easily... Best regards, Richard Scheffenegger > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Montag, 12. November 2012 14:48 > To: Scheffenegger, Richard > Cc: Ingemar Johansson S; tcpm@ietf.org; iccrg@cs.ucl.ac.uk > Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion >=20 > Scheffenegger, Richard wrote: > > > > Alternative to using ect1 by the sender (allowing high density ecn > > marking), what about the sender continuing to use ect0, but high > > density ecn marking by routers changing that from ect0 to ect1 andi > > ect1 to ce (or ect0 directl to ce on very high load)? >=20 > A truly interesting idea! Deployable... >=20 > Of course, we'd need research to determine a good thresshold for > marking ect0 to ect1. >=20 > -- > John Leslie From rs@netapp.com Mon Nov 12 06:55:59 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7EB21F85B0 for ; Mon, 12 Nov 2012 06:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrqjQ3r4hSYM for ; Mon, 12 Nov 2012 06:55:59 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 15F1D21F85AC for ; Mon, 12 Nov 2012 06:55:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,762,1344236400"; d="scan'208";a="709432269" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 12 Nov 2012 06:55:59 -0800 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 qACEtwvR015574; Mon, 12 Nov 2012 06:55:58 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.145]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 06:55:57 -0800 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [Iccrg] Re: [tcpm] ECN feedback discussion Thread-Index: Ac3Ap6C8ufVNe52xT/mbM2eaxd1xvwAFWdFUABiaSYAADvA1kA== Date: Mon, 12 Nov 2012 14:55:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D7847CF@SACEXCMBX02-PRD.hq.netapp.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA03E8CC@ESESSMB205.ericsson.se> <654636BB-AD42-42A1-8AAE-3837E9677325@netapp.com> <20121112134825.GJ78300@verdi> In-Reply-To: <20121112134825.GJ78300@verdi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ingemar Johansson S , "tcpm@ietf.org" , "iccrg@cs.ucl.ac.uk" Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 14:55:59 -0000 Hi John, Assuming that the mechanisms of DCTCP get deployed, the threshold could be = a small static number of packets in queue (K ~=3D 0.17*C*d [pps] and [s]); = have you had a read of the analysis paper http://www.stanford.edu/~alizade/= Site/DCTCP_files/dctcp_analysis-full.pdf =20 If / how the simple dctcp queue marking could be modified with queue delay = (PIE, CoDel) instead of queue depth as signal is still open. But these two = algorithms currently assume a low density marking paradigm... Best regards,=20 Richard Scheffenegger > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Montag, 12. November 2012 14:48 > To: Scheffenegger, Richard > Cc: Ingemar Johansson S; tcpm@ietf.org; iccrg@cs.ucl.ac.uk > Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion >=20 > Scheffenegger, Richard wrote: > > > > Alternative to using ect1 by the sender (allowing high density ecn > > marking), what about the sender continuing to use ect0, but high > > density ecn marking by routers changing that from ect0 to ect1 andi > > ect1 to ce (or ect0 directl to ce on very high load)? >=20 > A truly interesting idea! Deployable... >=20 > Of course, we'd need research to determine a good thresshold for > marking ect0 to ect1. >=20 > -- > John Leslie From ycheng@google.com Mon Nov 12 08:58:29 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8B221F85C0 for ; Mon, 12 Nov 2012 08:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.722 X-Spam-Level: X-Spam-Status: No, score=-102.722 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf+IzyOVODQV for ; Mon, 12 Nov 2012 08:58:29 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E82B621F859C for ; Mon, 12 Nov 2012 08:58:28 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so6924655oag.31 for ; Mon, 12 Nov 2012 08:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=z1sKi7uett3TXSdnViOknpt7k1xiDmsy10FsTD7ANo4=; b=TO7wJvgm6T+x+AuhHBtRKzZfCvDqWr37Un2JoTc18I74kqiz1eriYpD3/gQz79eeOw KC41WR/SKzh9K3jmEvYsrZlQRN4UnVfn2TwS5uXMF5Xdt4+2ttsHNmr1Ed9EQgMaN3IC ePo1pRY1ttwhxyBF9yI90/OizP7pVRLVEThGK4yeP958QbXvttbcyuDds/uyHOcFZIZF MxWFiFvRwNZjlMMdINhvgAzaMcjn6WvzkrrSLGgRihSj48LdGj2ZchTLLLmyDX+LmZ9h eYxyfAYRGI77Z5Lu9O/eVPoRNRFJdU+R7U/F4eZu98ojuHhSO8WmzY74u2PSmf9w5Zyg 42qw== 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=z1sKi7uett3TXSdnViOknpt7k1xiDmsy10FsTD7ANo4=; b=Z2RGOHl/pCd4YTra4BZZbJlfIANQKm57TBJg62NmeJdX1fldc2Wajy9J8THLyh4yQ3 0NCEOGNMu4zzGs8CNdMDfZaTO//FnHLdKHUXZiZYtVtHUa3x6kBUkgpT2UOW2tpRzBvY yzvAZOSg63+yK6znxpVy9jr5SGg5K2MvAjNhcUZzMEF2YDpwrkgjyHPNGmxMsZTOcZGQ VjJR3EK8EQXxg2Pn+wGpzsDwfg/sGJFVs8sfo6BCJOipYLPWOxU70hkv7GUkxKP1oDdj haeMUnwo00LLDBfsm06FZ5Fp6q7O/OdMZdybZ1c3I1JdJ+oxzx8tAaf3xL6eqHAUaBc/ Xing== Received: by 10.60.32.241 with SMTP id m17mr15180099oei.50.1352739508470; Mon, 12 Nov 2012 08:58:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.95.73 with HTTP; Mon, 12 Nov 2012 08:58:08 -0800 (PST) In-Reply-To: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> References: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> From: Yuchung Cheng Date: Mon, 12 Nov 2012 08:58:08 -0800 Message-ID: To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnRHsvcjBK1TstUJ6bKKF6a8Xsm26r4pG4tBgdglh4bsR2FDMEs8WK0rf3NrewObl1weMaVPRc3deQdMi3vq44jYJR7J0RFy8izoDjixMiDd2Vy6aYrkYSN+96fAJavXmlic/+cqAeWQ5AJXv/HxP5sdldTLUbMweQ6hmDaN9T+orvOr/451U/F4P1x8p2aTNgGwF/D Cc: tcpm , Michael Welzl Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 16:58:29 -0000 On Mon, Nov 12, 2012 at 6:01 AM, Pasi Sarolahti wro= te: > Hi, > > In the TCPM meeting last week there was a clear consensus for adopting RT= O restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, target= ed for Experimental RFC. Here is a proposal for a new milestone item: > > Aug 2013 Submit document on restarting the RTO timer to the IESG for pub= lication as an Experimental RFC > > Any comments or objections about the milestone? Instead of another RFC, how about a bis of rfc6298? it seems a small modification on re-arming the RTO timer. > > We discussed the issue of Std Track vs. Experimental a bit during the mee= ting, but did not have a clear consensus call on that. My reading of the di= scussion is that there would be room for experimentation to understand the = effect that the proposed change might have on the likelihood of spurious RT= Os. Therefore the proposed milestone currently is for Experimental. As disc= ussed in the meeting, if during the progress it turns out that more experim= entation is not necessary, we may, by WG consensus, change the intended sta= tus accordingly. Is this a fair plan for people? > > - Pasi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Mon Nov 12 09:08:12 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F220921F8618 for ; Mon, 12 Nov 2012 09:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiCy798j5hT3 for ; Mon, 12 Nov 2012 09:08:10 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3B821F866B for ; Mon, 12 Nov 2012 09:08:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,764,1344236400"; d="scan'208";a="709479441" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Nov 2012 09:08:09 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qACH89Gm015027; Mon, 12 Nov 2012 09:08:09 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.145]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 09:08:09 -0800 From: "Scheffenegger, Richard" To: Yuchung Cheng , Pasi Sarolahti Thread-Topic: [tcpm] Adopting RTO Restart Thread-Index: AQHNwN40LWFA1aVngU2xTVMndSUCzZfm8icA//96bRA= Date: Mon, 12 Nov 2012 17:08:09 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D785F62@SACEXCMBX02-PRD.hq.netapp.com> References: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm , Michael Welzl Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 17:08:12 -0000 I'd be also interested as to why 6298 suggests the use of an even more cons= ervative RTO timer, by restarting not with the last sent (and unacknowledge= d) packet, but with the last received ACK... If the basis for using RTO was well funded, being more conservative than th= e necessary RTO shouldn't be necessary. If for some reason RTO is not calculated properly, or too short etc, IMHO t= hat needs addressing, rather than stipulating the RTO to start one RTT late= ... But RTTM hasn't been looked at in a long time, unfortunately... (I.e. to bu= ild better / more robust models that produce near an optimal RTO timer). So, I think a -bis (and standards track) may be more suited, too? Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Yuchung Cheng > Sent: Montag, 12. November 2012 17:58 > To: Pasi Sarolahti > Cc: tcpm; Michael Welzl > Subject: Re: [tcpm] Adopting RTO Restart >=20 > On Mon, Nov 12, 2012 at 6:01 AM, Pasi Sarolahti > wrote: > > Hi, > > > > In the TCPM meeting last week there was a clear consensus for adopting > RTO restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, > targeted for Experimental RFC. Here is a proposal for a new milestone > item: > > > > Aug 2013 Submit document on restarting the RTO timer to the IESG for > > publication as an Experimental RFC > > > > Any comments or objections about the milestone? > Instead of another RFC, how about a bis of rfc6298? it seems a small > modification on re-arming the RTO timer. >=20 > > > > We discussed the issue of Std Track vs. Experimental a bit during the > meeting, but did not have a clear consensus call on that. My reading of > the discussion is that there would be room for experimentation to > understand the effect that the proposed change might have on the > likelihood of spurious RTOs. Therefore the proposed milestone currently i= s > for Experimental. As discussed in the meeting, if during the progress it > turns out that more experimentation is not necessary, we may, by WG > consensus, change the intended status accordingly. Is this a fair plan fo= r > people? > > > > - Pasi > > > > _______________________________________________ > > 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 michawe@ifi.uio.no Mon Nov 12 10:05:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C854921F849A for ; Mon, 12 Nov 2012 10:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUU6hDeY-OSl for ; Mon, 12 Nov 2012 10:05:31 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id CE13F21F8472 for ; Mon, 12 Nov 2012 10:05:30 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TXyO0-0002u3-Sl for tcpm@ietf.org; Mon, 12 Nov 2012 19:05:28 +0100 Received: from [12.133.26.2] (helo=[172.20.16.218]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TXyO0-0007QY-40 for tcpm@ietf.org; Mon, 12 Nov 2012 19:05:28 +0100 Message-Id: <22FEC18A-C7E8-4C36-B98C-B9C1238C5328@ifi.uio.no> From: Michael Welzl To: "tcpm (tcpm@ietf.org)" In-Reply-To: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Nov 2012 19:05:16 +0100 References: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 3 total rcpts 90 max rcpts/h 11 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EA7D5660004CBD7D13ED0CF03ACBE6DD744796E4 X-UiO-SPAM-Test: remote_host: 12.133.26.2 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 18:05:31 -0000 Hi, We authors of draft-hurtig-tcpm-rtorestart-03 agree with that. Cheers, Michael On Nov 12, 2012, at 3:01 PM, Pasi Sarolahti wrote: > Hi, > > In the TCPM meeting last week there was a clear consensus for > adopting RTO restart (draft-hurtig-tcpm-rtorestart-03) as a working > group item, targeted for Experimental RFC. Here is a proposal for a > new milestone item: > > Aug 2013 Submit document on restarting the RTO timer to the IESG > for publication as an Experimental RFC > > Any comments or objections about the milestone? > > We discussed the issue of Std Track vs. Experimental a bit during > the meeting, but did not have a clear consensus call on that. My > reading of the discussion is that there would be room for > experimentation to understand the effect that the proposed change > might have on the likelihood of spurious RTOs. Therefore the > proposed milestone currently is for Experimental. As discussed in > the meeting, if during the progress it turns out that more > experimentation is not necessary, we may, by WG consensus, change > the intended status accordingly. Is this a fair plan for people? > > - Pasi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From john@jlc.net Mon Nov 12 14:48:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DF821F862E for ; Mon, 12 Nov 2012 14:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5Q0KvJnTBgB for ; Mon, 12 Nov 2012 14:48:30 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 62BD721F8626 for ; Mon, 12 Nov 2012 14:48:29 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7F75A33D46; Mon, 12 Nov 2012 17:48:29 -0500 (EST) Date: Mon, 12 Nov 2012 17:48:29 -0500 From: John Leslie To: "tcpm@ietf.org" Message-ID: <20121112224829.GL78300@verdi> References: <81564C0D7D4D2A4B9A86C8C7404A13DA03E8CC@ESESSMB205.ericsson.se> <654636BB-AD42-42A1-8AAE-3837E9677325@netapp.com> <20121112134825.GJ78300@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D7835FC@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D7835FC@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Subject: Re: [tcpm] [Iccrg] Re: ECN feedback discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Nov 2012 22:48:31 -0000 Scheffenegger, Richard wrote: > > "ECN verbose mode: a statistical method for network path congestion > estimation", Remi Diana, Emmanuel Lochin, 2010 > > http://arxiv.org/pdf/0910.4455v2.pdf I have replied to this in only -- IMHO the thread belongs there. -- John Leslie From mallman@icir.org Tue Nov 13 18:52:14 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A76721F86F8 for ; Tue, 13 Nov 2012 18:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1yXku2UvQt7 for ; Tue, 13 Nov 2012 18:52:13 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id B236921F86EC for ; Tue, 13 Nov 2012 18:52:12 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id qAE2q4We025748; Tue, 13 Nov 2012 18:52:04 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EB59D368D130; Tue, 13 Nov 2012 21:52:04 -0500 (EST) To: Pasi Sarolahti From: Mark Allman In-Reply-To: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Authority Song X-URL-0: http://www.icir.org/mallman-files/Document31328.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma1876-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 13 Nov 2012 21:52:04 -0500 Sender: mallman@icir.org Message-Id: <20121114025204.EB59D368D130@lawyers.icir.org> Cc: tcpm Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 02:52:14 -0000 ----------ma1876-1 Content-Type: text/plain Content-Disposition: inline > Aug 2013 Submit document on restarting the RTO timer to the IESG for > publication as an Experimental RFC > > Any comments or objections about the milestone? This seems like a good idea to me. allman ----------ma1876-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlCjB1QACgkQWyrrWs4yIs6HVQCggu8AI8iZA0p7+jrR0DS6Mvry qboAn37fdDmeSlJWUJyIdStaq1Lqx0gl =xrya -----END PGP SIGNATURE----- ----------ma1876-1-- From mallman@icir.org Tue Nov 13 18:58:42 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0928621F8769 for ; Tue, 13 Nov 2012 18:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cfAoqlZEJa6 for ; Tue, 13 Nov 2012 18:58:40 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id A5CE021F876A for ; Tue, 13 Nov 2012 18:58:40 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id qAE2wZ7B026159; Tue, 13 Nov 2012 18:58:36 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2D6B8368D27B; Tue, 13 Nov 2012 21:58:36 -0500 (EST) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D785F62@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Authority Song X-URL-0: http://www.icir.org/mallman-files/Document37911.jpg X-URL-1: http://www.icir.org/mallman-files/Document14896.doc X-URL-2: http://www.icir.org/mallman-files/Document17970.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2268-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 13 Nov 2012 21:58:36 -0500 Sender: mallman@icir.org Message-Id: <20121114025836.2D6B8368D27B@lawyers.icir.org> Cc: tcpm , Michael Welzl Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 02:58:42 -0000 ----------ma2268-1 Content-Type: text/plain Content-Disposition: inline > I'd be also interested as to why 6298 suggests the use of an even more > conservative RTO timer, by restarting not with the last sent (and > unacknowledged) packet, but with the last received ACK... I am not sure what your suggestion is here. The general idea behind restarting on an ACK of previously unACKed data is that the connection is making progress and so lets keep the RTO out of the way. More generally ... If the WG couldn't reach consensus on making this PS then I can't see rolling this into a 6298bis. That said, I would be fine with the tweak going PS. And, rolling it into a 6298bis seems OK in principle to me. And, even more generally ... We should *get out of this business* of trying to optimize the hell out of the RTO. I.e., http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-01.txt We can all imagine a bazillion different small tweaks. As long as the RTO adheres to some basic principles, none of these little things matters much. Maybe they help in some cases. They certainly do not hurt. allman ----------ma2268-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlCjCNwACgkQWyrrWs4yIs5xVwCcDJqAKwQDOON7jbc3AHbHYbic +jwAn1CApKEUnB0kZJ9InO/aqjwvkg+d =utO2 -----END PGP SIGNATURE----- ----------ma2268-1-- From ycheng@google.com Tue Nov 13 19:22:10 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524F521F865E for ; Tue, 13 Nov 2012 19:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.744 X-Spam-Level: X-Spam-Status: No, score=-102.744 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHmsV1pzxcBH for ; Tue, 13 Nov 2012 19:22:09 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B662F21F8654 for ; Tue, 13 Nov 2012 19:22:09 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so13082091iec.31 for ; Tue, 13 Nov 2012 19:22:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0LUF8w868PsdEEqxRgIrneakQmqSowCJfRUBz+A1N5Q=; b=oCEysvNSL7zNO5coIRpjPQFtIgnpcNQbhG5CmzO4NDUuzeM892GiYkD+xwEWn78b43 UJrS+Z8G4hzkdIZNNPqK67h6Mz3wd3i5XLMq/sAr3Elv5Etc+daLDRnv8mfjMwUuvehW Lza87dMg4YPRv8XwluoKLrueu2MwM/XoLJAfLnyTkn81f2XXtUTxiJOIKsm1CXwP6Fy5 p71/CAacvnICGJF0YUGlWRpSextx/f234CKliF7I7k4zeC+7YBDcbj2gVIAklKBkw3Pw /b3gVWzEOrqCrxrUo7np/cRPq2M1v0DmYDWy+AKUhf8aGHbfDSEUDC8+mrPucn1aq2Qz 4mUg== 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=0LUF8w868PsdEEqxRgIrneakQmqSowCJfRUBz+A1N5Q=; b=Yt5hQle2LAcC7HbWp7Nyqe5ZtwH4jPzEwBKN2SVLjoN9+ElNwIpVfNrH8Uzg0kSwp6 Ll2cN5PqSrZ6Oy4K319FlVNRUU+nMarv9U6HDkguYP7ChzjIIYSbgnEShfRxSBkg36ss v6y9QCWqPDFKC6MAj9ryKR5P/py7V2dseqVsYqkUKr7dREwTb1BtsjAdPvTwywbxIMOH y1o1nBoGOg8bnaLj1FF+6PcmPCDQ6n72aI56meX0Y26F3JEy1jPrsdmRmvHPx1vXKV6Z ausziUAMHfrG8aiYkEIyUl6raxLlXIFHgijBc4BhxcGvwnehLD53ZJJLuMRAJieYB5d0 cM5A== Received: by 10.50.40.225 with SMTP id a1mr548159igl.7.1352863329290; Tue, 13 Nov 2012 19:22:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.9.170 with HTTP; Tue, 13 Nov 2012 19:21:49 -0800 (PST) In-Reply-To: <20121114025836.2D6B8368D27B@lawyers.icir.org> References: <012C3117EDDB3C4781FD802A8C27DD4F0D785F62@SACEXCMBX02-PRD.hq.netapp.com> <20121114025836.2D6B8368D27B@lawyers.icir.org> From: Yuchung Cheng Date: Tue, 13 Nov 2012 19:21:49 -0800 Message-ID: To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnxxmJud4iRQAsKb83A6eDhNX+S5JuCsf5FiB8PhUqlagCDGMjtZb3+QaGqVAJxPnHSy1Y79ML3nw5gkJzCJmtrP5mBolgG/gQU4vAR79xDHCvf7OiyQd20RUTfVsGyBSu7pbqPvhcMP9jpAu9zJieKxZsZ6UJXVaTeJFZ5GcYLJuej1+yk10jcR9QZd0drLZ3hO46b Cc: tcpm , Michael Welzl Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Nov 2012 03:22:10 -0000 On Tue, Nov 13, 2012 at 6:58 PM, Mark Allman wrote: > >> I'd be also interested as to why 6298 suggests the use of an even more >> conservative RTO timer, by restarting not with the last sent (and >> unacknowledged) packet, but with the last received ACK... > > I am not sure what your suggestion is here. > > The general idea behind restarting on an ACK of previously unACKed data > is that the connection is making progress and so lets keep the RTO out > of the way. > > More generally ... > > If the WG couldn't reach consensus on making this PS then I can't see > rolling this into a 6298bis. > > That said, I would be fine with the tweak going PS. And, rolling it > into a 6298bis seems OK in principle to me. > > And, even more generally ... > > We should *get out of this business* of trying to optimize the hell out > of the RTO. I.e., > > http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-01.txt > > We can all imagine a bazillion different small tweaks. As long as the > RTO adheres to some basic principles, none of these little things > matters much. Maybe they help in some cases. They certainly do not > hurt. Nod. Linux for example uses a different estimator, different min-RTO, different sampling frequency, plus another X tweaks. I think this should go directly to the bis because it's just one sentence: "When re-arming the RTO, the implementation can choose to offset the time elapsed since SNDUNA has been last transmitted to improve performance, if such an information is available". That's it! > > allman > > > From mallman@icir.org Tue Nov 13 19:29:20 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A0821F8669 for ; Tue, 13 Nov 2012 19:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szEYEcQ8Jmt8 for ; Tue, 13 Nov 2012 19:29:19 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A121F865E for ; Tue, 13 Nov 2012 19:29:18 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id qAE3TFOX027937; Tue, 13 Nov 2012 19:29:15 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 444FA368E972; Tue, 13 Nov 2012 22:29:15 -0500 (EST) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Authority Song X-URL-0: http://www.icir.org/mallman-files/Document82978.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma4107-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 13 Nov 2012 22:29:15 -0500 Sender: mallman@icir.org Message-Id: <20121114032915.444FA368E972@lawyers.icir.org> Cc: tcpm , Michael Welzl Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 03:29:20 -0000 ----------ma4107-1 Content-Type: text/plain Content-Disposition: inline > Nod. Linux for example uses a different estimator, different min-RTO, > different sampling frequency, plus another X tweaks. And, the world hasn't blown up. > I think this should go directly to the bis because it's just one > sentence: "When re-arming the RTO, the implementation can choose to > offset the time elapsed since SNDUNA has been last transmitted to > improve performance, if such an information is available". That's it! If I had my druthers we'd do it right and put in place the higher level considerations. But, that doesn't necessarily make Yuchung wrong. allman ----------ma4107-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlCjEAsACgkQWyrrWs4yIs74ywCeKlcj1IiePCjHZfdW7+23whwh ZD4AoIFu3glPI2GTB0hJ4yotwUUXU7Zm =G6eX -----END PGP SIGNATURE----- ----------ma4107-1-- From wes@mti-systems.com Tue Nov 13 21:48:18 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E37021F869F for ; Tue, 13 Nov 2012 21:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWOSPAU1zTWt for ; Tue, 13 Nov 2012 21:48:17 -0800 (PST) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 305A021F869C for ; Tue, 13 Nov 2012 21:48:16 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAE5mGWt031273 for ; Wed, 14 Nov 2012 00:48:16 -0500 Received: (qmail 15341 invoked by uid 0); 14 Nov 2012 05:48:16 -0000 Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.143.209) by 0 with ESMTPA; 14 Nov 2012 05:48:16 -0000 Message-ID: <50A3309C.9020902@mti-systems.com> Date: Wed, 14 Nov 2012 00:48:12 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org" , draft-ietf-tcpm-experimental-options@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] AD review 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, 14 Nov 2012 05:48:18 -0000 Hi, I'm doing AD review of the draft on Shared Use of Experimental TCP Options. It's in basically good shape, and I would like to get it processed quickly, especially since people are starting to use it. Section 3.2 (Migration to Assigned Options) still bothers me a bit though. It mentions that we expect options going from Experimental to Standards Track will get a real option number, yet says: The updated protocol specification SHOULD recommend that implementations intended to be backward-compatible with experimental deployments MUST support both the experimental codepoint/magic number and assigned codepoint variants of the option. But, this would seem to really pollute the SYN, since you would have to put both flavors of option in the SYN to negotiate use of either the new Standards Track one or the old Experimental one. This needs to be discussed and addressed. I'm not sure we're giving very good / clear guidance here, or being very honest about the tradeoffs involved in moving to a new codepoint when going to Standards Track. Also, I think we'd heard that the Experimental codepoints were being used by an earlier middlebox discovery mechanism too (not just by the AO precursor), which might bear mention in the introduction. The document mentions inappropriately used option numbers in the Introduction, and that this could cause dangerous collisions that could be mitigated via use of magic numbers. Yet, 3.2 says: Once a specific TCP option codepoint is assigned to a protocol, that protocol SHOULD NOT continue to use a magic number as part of that assigned codepoint. So, we're advising them not to be robust to option squatting then? I know this doc is supposed to be focused on use of 253/254, but it does mention the inappropriate use of other numbers as well, and seems to give conflicting guidance. The magic number just seems to be useful all-around for robustness in the face of currently unknown bad actors. -- Wes Eddy MTI Systems From touch@isi.edu Tue Nov 13 23:19:16 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA83C21F85D5 for ; Tue, 13 Nov 2012 23:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.983 X-Spam-Level: X-Spam-Status: No, score=-103.983 tagged_above=-999 required=5 tests=[AWL=-1.384, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyxQfyHegIko for ; Tue, 13 Nov 2012 23:19:16 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1921F85D3 for ; Tue, 13 Nov 2012 23:19:16 -0800 (PST) Received: from [192.168.1.94] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qAE7IxWn025581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Nov 2012 23:19:03 -0800 (PST) Message-ID: <50A345E2.5040606@isi.edu> Date: Tue, 13 Nov 2012 23:18:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Wesley Eddy References: <50A3309C.9020902@mti-systems.com> In-Reply-To: <50A3309C.9020902@mti-systems.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: draft-ietf-tcpm-experimental-options@tools.ietf.org, "tcpm@ietf.org" Subject: Re: [tcpm] AD review 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, 14 Nov 2012 07:19:16 -0000 Hi, Wes, On 11/13/2012 9:48 PM, Wesley Eddy wrote: > Hi, I'm doing AD review of the draft on Shared Use of Experimental > TCP Options. > > It's in basically good shape, and I would like to get it processed > quickly, especially since people are starting to use it. > > Section 3.2 (Migration to Assigned Options) still bothers me a bit > though. It mentions that we expect options going from Experimental > to Standards Track will get a real option number, yet says: > > The updated protocol specification SHOULD recommend that > implementations intended to be backward-compatible with experimental > deployments MUST support both the experimental codepoint/magic > number and assigned codepoint variants of the option. > > But, this would seem to really pollute the SYN, since you would have > to put both flavors of option in the SYN to negotiate use of either > the new Standards Track one or the old Experimental one. The intent was to support both variants in the receiver processing during any overlap period, not to put both in the SYN. > This needs to be discussed and addressed. I'm not sure we're giving > very good / clear guidance here, or being very honest about the > tradeoffs involved in moving to a new codepoint when going to Standards > Track. One possible solution is for the sender is to use the assigned option and wait for it to be confirmed; if it is not, it might retry with the experimental variant in a separate SYN. However, this doc is not intended as a study in all possible tradeoffs in the various ways to transition from experimental to standards-track codepoints. That appears to be an open field of research for which we do not have clear recommendations. > Also, I think we'd heard that the Experimental codepoints were being > used by an earlier middlebox discovery mechanism too (not just by the > AO precursor), which might bear mention in the introduction. We continue to hear about misuse of experimental codepoints (being deployed operationally). We can note that such misuses are likely to continue. > The document mentions inappropriately used option numbers in the > Introduction, and that this could cause dangerous collisions that > could be mitigated via use of magic numbers. Yet, 3.2 says: > > Once a specific TCP option codepoint is assigned to a protocol, > that protocol SHOULD NOT continue to use a magic number as part of > that assigned codepoint. > > So, we're advising them not to be robust to option squatting then? I > know this doc is supposed to be focused on use of 253/254, but it does > mention the inappropriate use of other numbers as well, and seems to > give conflicting guidance. The magic number just seems to be useful > all-around for robustness in the face of currently unknown bad actors. This doc is about the use of the experimental options. Recommendations on best practices for assigned codepoints don't seem to be in scope. However, we definitely do NOT want to encourage continued use of magic numbers once codepoints are assigned. Option space is far to small for every option to use this technique forever. Joe From michael.scharf@alcatel-lucent.com Wed Nov 14 09:24:54 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6DE21F8615 for ; Wed, 14 Nov 2012 09:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.47 X-Spam-Level: X-Spam-Status: No, score=-9.47 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVCohIIaauAZ for ; Wed, 14 Nov 2012 09:24:54 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B6FF521F85C4 for ; Wed, 14 Nov 2012 09:24:53 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAEHOgII004187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Nov 2012 18:24:49 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 14 Nov 2012 18:24:45 +0100 From: "Scharf, Michael (Michael)" To: "mallman@icir.org" Date: Wed, 14 Nov 2012 18:24:43 +0100 Thread-Topic: draft-allman-tcpm-rto-consider Thread-Index: Ac3CE/qKJ/QjK01ASlqcAY7xGlFeZgAdilTQ Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A8DB@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D785F62@SACEXCMBX02-PRD.hq.netapp.com> <20121114025836.2D6B8368D27B@lawyers.icir.org> In-Reply-To: <20121114025836.2D6B8368D27B@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: tcpm Subject: [tcpm] draft-allman-tcpm-rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Nov 2012 17:24:55 -0000 > We should *get out of this business* of trying to optimize=20 > the hell out of the RTO. I.e., >=20 > =20 > http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consi der-01.txt >=20 > We can all imagine a bazillion different small tweaks. As=20 > long as the RTO adheres to some basic principles, none of=20 > these little things matters much. Maybe they help in some=20 > cases. They certainly do not hurt.=20 For what it is worth (I might have said this earlier): I have refered to th= is draft more than once already, specifically in discussions on RTO design = for UDP-based TCP-ish protocols. There are quite a number of them in the IE= TF... I do think that this document would indeed be a useful output of TCPM in or= der to provide general guidance esp. for non-TCP protocols. It is probably = independent of other documents. Michael (chair hat off) From michael.scharf@alcatel-lucent.com Wed Nov 14 10:30:18 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF1F21F8516 for ; Wed, 14 Nov 2012 10:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.522 X-Spam-Level: X-Spam-Status: No, score=-9.522 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph8zqGJBno5C for ; Wed, 14 Nov 2012 10:30:18 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1845621F8513 for ; Wed, 14 Nov 2012 10:30:17 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAEIUBGa009364 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Nov 2012 19:30:15 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 14 Nov 2012 19:30:13 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , Wesley Eddy Date: Wed, 14 Nov 2012 19:30:12 +0100 Thread-Topic: [tcpm] AD review of draft-ietf-tcpm-experimental-options Thread-Index: Ac3COGGUH3I8shz8QuiwkfrBMwRCZAAWq+hw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A8E0@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <50A3309C.9020902@mti-systems.com> <50A345E2.5040606@isi.edu> In-Reply-To: <50A345E2.5040606@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "draft-ietf-tcpm-experimental-options@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] AD review 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, 14 Nov 2012 18:30:19 -0000 > > It's in basically good shape, and I would like to get it processed=20 > > quickly, especially since people are starting to use it. > > > > Section 3.2 (Migration to Assigned Options) still bothers me a bit=20 > > though. It mentions that we expect options going from=20 > Experimental to=20 > > Standards Track will get a real option number, yet says: > > > > The updated protocol specification SHOULD recommend that > > implementations intended to be backward-compatible with=20 > experimental > > deployments MUST support both the experimental codepoint/magic > > number and assigned codepoint variants of the option. > > > > But, this would seem to really pollute the SYN, since you=20 > would have=20 > > to put both flavors of option in the SYN to negotiate use of either=20 > > the new Standards Track one or the old Experimental one. >=20 > The intent was to support both variants in the receiver=20 > processing during any overlap period, not to put both in the SYN. As document sheperd, that was my understanding of that section as well, esp= . in the context of the previous section. But maybe we could add some expli= cit discussion regarding SYNs to "Once a specific TCP option codepoint is a= ssigned to a protocol, that protocol SHOULD NOT continue to use a magic num= ber as part of that assigned codepoint."=20 > > This needs to be discussed and addressed. I'm not sure=20 > we're giving=20 > > very good / clear guidance here, or being very honest about the=20 > > tradeoffs involved in moving to a new codepoint when going to=20 > > Standards Track. > > One possible solution is for the sender is to use the=20 > assigned option and wait for it to be confirmed; if it is=20 > not, it might retry with the experimental variant in a separate SYN. This certainly works for a new connection to the same destination, i.e., de= stination caching.=20 Out of my head, I wonder if this would indeed work for the first connection= for which the sender has already seen the SYN-ACK? =20 > However, this doc is not intended as a study in all possible=20 > tradeoffs in the various ways to transition from experimental=20 > to standards-track codepoints. That appears to be an open=20 > field of research for which we do not have clear recommendations. If that is not cleam maybe we could state more explicitly, e. g., in "This = document does not require a specific migration plan..."? I am not a native speaker, but maybe "require" could be replaced by another= word? > > Also, I think we'd heard that the Experimental codepoints=20 > were being=20 > > used by an earlier middlebox discovery mechanism too (not=20 > just by the=20 > > AO precursor), which might bear mention in the introduction. >=20 > We continue to hear about misuse of experimental codepoints=20 > (being deployed operationally). We can note that such misuses=20 > are likely to continue. >=20 > > The document mentions inappropriately used option numbers in the=20 > > Introduction, and that this could cause dangerous collisions that=20 > > could be mitigated via use of magic numbers. Yet, 3.2 says: > > > > Once a specific TCP option codepoint is assigned to a protocol, > > that protocol SHOULD NOT continue to use a magic number=20 > as part of > > that assigned codepoint. > > > > So, we're advising them not to be robust to option=20 > squatting then? I=20 > > know this doc is supposed to be focused on use of 253/254,=20 > but it does=20 > > mention the inappropriate use of other numbers as well, and=20 > seems to=20 > > give conflicting guidance. The magic number just seems to=20 > be useful=20 > > all-around for robustness in the face of currently unknown=20 > bad actors. >=20 > This doc is about the use of the experimental options.=20 > Recommendations on best practices for assigned codepoints=20 > don't seem to be in scope. I think TCPM discussions focused on 253/254. Other codepoints would imply a much larger scope. I recall community feedba= ck that it should be possible to get and use dedicated codepoint without im= plementing this draft (provided that the IESG assigns the codepoint). Thus,= recommending magic numbers for other codepoints might require further disc= ussions in TCPM. > However, we definitely do NOT want to encourage continued use=20 > of magic numbers once codepoints are assigned. Option space=20 > is far to small for every option to use this technique forever. +1 Michael >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From michael.scharf@alcatel-lucent.com Wed Nov 14 10:50:37 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8021F8622 for ; Wed, 14 Nov 2012 10:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.568 X-Spam-Level: X-Spam-Status: No, score=-9.568 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Evrb1rQNLDaR for ; Wed, 14 Nov 2012 10:50:36 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4256F21F8558 for ; Wed, 14 Nov 2012 10:50:36 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAEIoUJY020080 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 14 Nov 2012 19:50:34 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 14 Nov 2012 19:50:32 +0100 From: "Scharf, Michael (Michael)" To: tcpm Date: Wed, 14 Nov 2012 19:50:31 +0100 Thread-Topic: Milestone on detailed ECN feedback - please provide feedback! Thread-Index: Ac3CmOw3WgEWlLvYTFaXriLHU7XeEw== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A8E1@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [tcpm] Milestone on detailed ECN feedback - please provide feedback! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Nov 2012 18:50:37 -0000 All, The chairs discussed the outcome of the meeting. We came up with a new prop= osal for a milestone on detailed ECN feedback. The suggestion for a charter milestone would be as follows: "Nov 2013 Submit document on an analysis of more detailed ECN feedback in = TCP to the IESG for publication as an Informational RFC" Unlike previous suggestions, the idea is to focus on an informational docum= ent that analyzes the different variants. That is pretty much in line with = the current discussions. Selection and standardization of one specific appr= oach could then be done by a follow-up document. Please provide feedback on that proposed TCPM charter item, both if you agr= ee of if you disagree. Suggestions for alternative wordings are also welcom= e. Thanks Michael From pasi.sarolahti@iki.fi Wed Nov 14 13:59:26 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DF21F881C for ; Wed, 14 Nov 2012 13:59:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHRlLTUW8Uvw for ; Wed, 14 Nov 2012 13:59:26 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 17AE421F8814 for ; Wed, 14 Nov 2012 13:59:25 -0800 (PST) Received: from [192.168.1.65] (80.223.92.46) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 50871416004E0C9E; Wed, 14 Nov 2012 23:59:19 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <20121114025836.2D6B8368D27B@lawyers.icir.org> Date: Wed, 14 Nov 2012 23:59:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <068BC99D-F854-436A-8808-C67164CD05FF@iki.fi> References: <20121114025836.2D6B8368D27B@lawyers.icir.org> To: X-Mailer: Apple Mail (2.1283) Cc: tcpm , Michael Welzl Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Nov 2012 21:59:27 -0000 On Nov 14, 2012, at 4:58 AM, Mark Allman wrote: > More generally ... >=20 > If the WG couldn't reach consensus on making this PS then I can't see > rolling this into a 6298bis. >=20 > That said, I would be fine with the tweak going PS. And, rolling it > into a 6298bis seems OK in principle to me. I see RTO restart adoption and revising RFC 6298 as separate steps. And = adopting draft-hurtig-tcpm-rtorestart is what we had consensus call = about last week. Even if RTO restart progresses as Experimental, I think = we can later adopt a new draft-allman-tcpm-rfc6298bis for PS working = group item at any time when people are ready to agree so, and that draft = could include ideas from the RTO restart document. Right? Maybe between those two steps we should get better understanding if = similar benefits could be achieved with small adjustments to RFC 6298 = without additional branches or variables, and if not, why not? Or are = there some special cases that cause problems without the "nr of = outstanding < 4" condition? (Personally, I'm not a big fan of adding new = special conditions or state variables to RTO logic if those could be = avoided) - Pasi From touch@isi.edu Thu Nov 15 12:43:27 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24D921F8A16 for ; Thu, 15 Nov 2012 12:43:27 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQrD7A7bvB8D for ; Thu, 15 Nov 2012 12:43:26 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B75E921F84D5 for ; Thu, 15 Nov 2012 12:43:26 -0800 (PST) Received: from [75.192.216.137] (137.sub-75-192-216.myvzw.com [75.192.216.137]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qAFKfjnl020504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Nov 2012 12:42:12 -0800 (PST) Message-ID: <50A55385.8060606@isi.edu> Date: Thu, 15 Nov 2012 12:41:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <50A3309C.9020902@mti-systems.com> <50A345E2.5040606@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A8E0@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0A8E0@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "draft-ietf-tcpm-experimental-options@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] AD review 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: Thu, 15 Nov 2012 20:43:27 -0000 Hi, Michael, et al., On 11/14/2012 10:30 AM, Scharf, Michael (Michael) wrote: >>> It's in basically good shape, and I would like to get it processed >>> quickly, especially since people are starting to use it. >>> >>> Section 3.2 (Migration to Assigned Options) still bothers me a bit >>> though. It mentions that we expect options going from >> Experimental to >>> Standards Track will get a real option number, yet says: >>> >>> The updated protocol specification SHOULD recommend that >>> implementations intended to be backward-compatible with >> experimental >>> deployments MUST support both the experimental codepoint/magic >>> number and assigned codepoint variants of the option. >>> >>> But, this would seem to really pollute the SYN, since you >> would have >>> to put both flavors of option in the SYN to negotiate use of either >>> the new Standards Track one or the old Experimental one. >> >> The intent was to support both variants in the receiver >> processing during any overlap period, not to put both in the SYN. > > As document sheperd, that was my understanding of that section as well, esp. in the context of the previous section. But maybe we could add some explicit discussion regarding SYNs to "Once a specific TCP option codepoint is assigned to a protocol, that protocol SHOULD NOT continue to use a magic number as part of that assigned codepoint." Certainly. >>> This needs to be discussed and addressed. I'm not sure >> we're giving >>> very good / clear guidance here, or being very honest about the >>> tradeoffs involved in moving to a new codepoint when going to >>> Standards Track. >> >> One possible solution is for the sender is to use the >> assigned option and wait for it to be confirmed; if it is >> not, it might retry with the experimental variant in a separate SYN. > > This certainly works for a new connection to the same destination, i.e., destination caching. Yes, but it also implies that either the TCP layer (unlikely) or the app retries the second connection with the different configuration. I doubt that will be desirable. I generally assume that any assigned codepoint might work as if the experiment never happened - i.e., use that new codepoint only, and expect the endpoint to use it too. So there are two cases: - an endpoint speaks only the old (experimental) variant, at which point it uses the experimental codepoint with the magic number - an endpoint speaks the new variant, at which point it uses the new codepoint (without the magic number) An implementation might support b oth modes, but an application would more likely pick just one to try. I.e., the implementation can support "legacy" use of the experimental codepoint/magic number if desired. IMO, we should shy away from proposing untested mechanisms for trying alternates of a single option. > Out of my head, I wonder if this would indeed work for the first connection for which the sender has already seen the SYN-ACK? See above; let's not propose new untested mechanism. >> However, this doc is not intended as a study in all possible >> tradeoffs in the various ways to transition from experimental >> to standards-track codepoints. That appears to be an open >> field of research for which we do not have clear recommendations. > > If that is not cleam maybe we could state more explicitly, e. g., in "This document does not require a specific migration plan..."? > > I am not a native speaker, but maybe "require" could be replaced by another word? This document does not imply or indicate that specifications defining TCP options that use the experimental codepoints with magic numbers need to include a migration plan. >>> Also, I think we'd heard that the Experimental codepoints >> were being >>> used by an earlier middlebox discovery mechanism too (not >> just by the >>> AO precursor), which might bear mention in the introduction. >> >> We continue to hear about misuse of experimental codepoints >> (being deployed operationally). We can note that such misuses >> are likely to continue. >> >>> The document mentions inappropriately used option numbers in the >>> Introduction, and that this could cause dangerous collisions that >>> could be mitigated via use of magic numbers. Yet, 3.2 says: >>> >>> Once a specific TCP option codepoint is assigned to a protocol, >>> that protocol SHOULD NOT continue to use a magic number >> as part of >>> that assigned codepoint. >>> >>> So, we're advising them not to be robust to option >> squatting then? I >>> know this doc is supposed to be focused on use of 253/254, >> but it does >>> mention the inappropriate use of other numbers as well, and >> seems to >>> give conflicting guidance. The magic number just seems to >> be useful >>> all-around for robustness in the face of currently unknown >> bad actors. >> >> This doc is about the use of the experimental options. >> Recommendations on best practices for assigned codepoints >> don't seem to be in scope. > > I think TCPM discussions focused on 253/254. This document focuses on TCP 253/254. > Other codepoints would imply a much larger scope. I recall community feedback that it should be possible to get and use dedicated codepoint without implementing this draft (provided that the IESG assigns the codepoint). Thus, recommending magic numbers for other codepoints might require further discussions in TCPM. > The approach in this doc could be useful elsewhere, but may not be needed elsewhere. It makes some assumptions (that the option space is limited and that the option fields can support the insertion of a magic number). Those assumptions may not be important elsewhere. >> However, we definitely do NOT want to encourage continued use >> of magic numbers once codepoints are assigned. Option space >> is far to small for every option to use this technique forever. > > +1 > > Michael > >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From internet-drafts@ietf.org Fri Nov 16 20:17:27 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C3021F8B6A; Fri, 16 Nov 2012 20:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNiUZP+FCyLG; Fri, 16 Nov 2012 20:17:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD94221F8B10; Fri, 16 Nov 2012 20:17:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121117041726.25573.43734.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 20:17:26 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-initcwnd-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: Sat, 17 Nov 2012 04:17:27 -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 : Increasing TCP's Initial Window Author(s) : Jerry Chu Nandita Dukkipati Yuchung Cheng Matt Mathis Filename : draft-ietf-tcpm-initcwnd-06.txt Pages : 23 Date : 2012-11-16 Abstract: This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments, with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purpose recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-initcwnd-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nishida@sfc.wide.ad.jp Mon Nov 19 11:25:58 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122E721F869F for ; Mon, 19 Nov 2012 11:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.312 X-Spam-Level: X-Spam-Status: No, score=-98.312 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpRRB-wOJ-wF for ; Mon, 19 Nov 2012 11:25:57 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id F11EB21F85E0 for ; Mon, 19 Nov 2012 11:25:56 -0800 (PST) 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 84696278136 for ; Tue, 20 Nov 2012 04:25:49 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id y2so4319848lbk.31 for ; Mon, 19 Nov 2012 11:25:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.86.35 with SMTP id m3mr5515719lbz.7.1353353146979; Mon, 19 Nov 2012 11:25:46 -0800 (PST) Received: by 10.112.142.196 with HTTP; Mon, 19 Nov 2012 11:25:46 -0800 (PST) Date: Mon, 19 Nov 2012 11:25:46 -0800 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] publication request for draft-ietf-tcpm-initcwnd-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Nov 2012 19:25:58 -0000 Hello folks, Publication request for iw10 has been sent to IESG. I've attached the write-up for the draft below. Thanks, -- Yoshifumi -------------------------------------------------------------------------------------------------------------------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document describes a proposal to increase initial window size of TCP at most 10 segments. As it is indicated in the title page header, the consensus of the WG is to publish this document as an Experimental RFC. We will need further experiments for this proposal to be advanced as described in Section 12. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes an experimental proposal to increase initial congestion window of TCP to at most 10 segments as well as a fall-back mechanism to limit any negative effects in limited buffer or bandwidth situations. It also provides guidelines to enable/disable this features in addition to some metrics to monitor the effect of this. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There has been dominant opinions in the WG to increase initial window size of TCP. Question was whether we have a single updated value, or increasing the value gradually with a certain schedule, or defining a mechanics to adjust initial window size over time. We have explored several possibilities and eventually having a single updated value has become the consensus of the WG as other methods have some difficulties for large-scale deployment. Some of the approach in other methods have been merged into the draft during this process. The consensus was clear as no opinion against this proposal has been raised since then. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Linux has already incorporated this proposal in the main kernel distribution. This document was reviewed by various people and has been discussed in the WG for nearly three years. The authors have provided results from their extensive experiments with a larger initial window. They also provided data to address questions and concerns by reviewers. In addition, there have been some related experiments by other TCPM contributors, mostly based on simulation. The document has been updated based on feedback from the community. I believe the authors did fairly extensive work for an experimental RFC, even if valid questions are still to be answered. The remaining questions, which need further experiments, are hard to address by the authors alone. Appendix A in the document contains the list for major discussion points of the draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Wesley Eddy. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I've reviewed the documents and made several editorial suggestions in order to enhance the readability of the drafts. I believe the quality of this draft is matured enough to be published. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concern about it. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. There is no need for particular reviews. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, each authors has confirmed this. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document is widely supported as we have seen positive comments from various participants in the WG meetings as well as the ML. The consensus was solid and clear. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has indicated discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits gives the following errors and warnings. I've put my comments below. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -> I think we can fix this through editing process -- The draft header indicates that this document updates RFC3390, but the abstract doesn't seem to directly say this. It does mention RFC3390 though, so this could be OK. -- The draft header indicates that this document updates RFC5681, but the abstract doesn't seem to mention this, which it should. -> I think these are minor points. As it is explained in the Introduction and the draft tries to update a rather minor portion of RFC3390 and RFC5681. == Unused Reference: 'RFC6077' is defined on line 844, but no explicit reference was found in the text -> It is referred in the text. This might be a bug for ID nits? -- Obsolete informational reference (is this intentional?): RFC 2414 (Obsoleted by RFC 3390) -> This is intentional. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. I believe no formal review is needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This draft contains a proposal for adjusting initial window after SYN, SYN/ACK retransmission, which will update RFC3390 and RFC5681. This is described in the Abstract and Introduction and Section 2 explains the motivation. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not involve any IANA considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no need to require expert review for future allocations. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains no formal language. From touch@isi.edu Tue Nov 20 14:21:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2761C21F881E for ; Tue, 20 Nov 2012 14:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzY9aeUeE4c2 for ; Tue, 20 Nov 2012 14:21:48 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6921F8808 for ; Tue, 20 Nov 2012 14:21:48 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qAKMLUMV024019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Nov 2012 14:21:30 -0800 (PST) Message-ID: <50AC026A.2050303@isi.edu> Date: Tue, 20 Nov 2012 14:21:30 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <50AC0175.6060908@isi.edu> In-Reply-To: <50AC0175.6060908@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] publication request for draft-ietf-tcpm-initcwnd-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Nov 2012 22:21:49 -0000 Hi, all, One point below... On 11/19/2012 11:25 AM, Yoshifumi Nishida wrote: > Hello folks, > > Publication request for iw10 has been sent to IESG. > I've attached the write-up for the draft below. > > Thanks, > -- > Yoshifumi > > -------------------------------------------------------------------------------------------------------------------------- > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why is > this the proper type of RFC? Is this type of RFC indicated in the > title page header? > > > This document describes a proposal to increase initial window size of TCP > at most 10 segments. As it is indicated in the title page header, > the consensus > of the WG is to publish this document as an Experimental RFC. > We will need further experiments for this proposal to be advanced > as described > in Section 12. > > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: > > Technical Summary: > > Relevant content can frequently be found in the abstract and/or > introduction of the document. If not, this may be an indication that > there are deficiencies in the abstract or introduction. > > > This document describes an experimental proposal to increase > initial congestion window > of TCP to at most 10 segments as well as a fall-back mechanism to > limit any negative > effects in limited buffer or bandwidth situations. > It also provides guidelines to enable/disable this features in > addition to some metrics > to monitor the effect of this. > > > Working Group Summary: > > Was there anything in WG process that is worth noting? For example, > was there controversy about particular points or were there decisions > where the consensus was particularly rough? > > > There has been dominant opinions in the WG to increase initial > window size of TCP. > Question was whether we have a single updated value, or increasing > the value gradually > with a certain schedule, or defining a mechanics to adjust initial > window size over time. > We have explored several possibilities and eventually having a > single updated value > has become the consensus of the WG as other methods have some > difficulties for > large-scale deployment. Some of the approach in other methods have > been merged into the > draft during this process. The consensus was clear as no opinion > against this proposal > has been raised since then. > > > Document Quality: > > Are there existing implementations of the protocol? Have a significant > number of vendors indicated their plan to implement the specification? > Are there any reviewers that merit special mention as having done a > thorough review, e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If there was a > MIB Doctor, Media Type or other expert review, what was its course > (briefly)? In the case of a Media Type review, on what date was the > request posted? > > > Linux has already incorporated this proposal in the main kernel distribution. It is important to note that this deployment did not include any automatic or other reporting of errors, so if it is causing problems we simply do not know. As a result, this deployment does NOT follow the recommendations of this document, esp. in Sec. 12. Joe > This document was reviewed by various people and has been discussed > in the WG for > nearly three years. The authors have provided results from their > extensive experiments > with a larger initial window. They also provided data to address > questions and concerns > by reviewers. In addition, there have been some related experiments > by other TCPM contributors, > mostly based on simulation. The document has been updated based on > feedback from the community. > > I believe the authors did fairly extensive work for an experimental > RFC, even if valid questions > are still to be answered. The remaining questions, which need > further experiments, are hard > to address by the authors alone. Appendix A in the document > contains the list for major > discussion points of the draft. > > > Personnel: > > Who is the Document Shepherd? Who is the Responsible Area Director? > > Yoshifumi Nishida is the Document Shepherd for this document. > The Responsible Area Director is Wesley Eddy. > > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. > > I've reviewed the documents and made several editorial suggestions > in order to enhance the > readability of the drafts. I believe the quality of this draft is > matured enough to be > published. > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > > I have no concern about it. > > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. > > There is no need for particular reviews. > > (6) Describe any specific concerns or issues that the Document > Shepherd has with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he or she is > uncomfortable with certain parts of the document, or has concerns > whether there really is a need for it. In any event, if the WG has > discussed those issues and has indicated that it still wishes to > advance the document, detail those concerns here. > > I have no concerns with the document. > > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP > 78 and BCP 79 have already been filed. If not, explain why? > > Yes, each authors has confirmed this. > > (8) Has an IPR disclosure been filed that references this document? If > so, summarize any WG discussion and conclusion regarding the IPR > disclosures. > > No. > > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > The document is widely supported as we have seen positive comments > from various participants > in the WG meetings as well as the ML. The consensus was solid and clear. > > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) > > No one has indicated discontent. > > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the > Internet-Drafts Checklist). Boilerplate checks are not enough; this > check needs to be thorough. > > ID nits gives the following errors and warnings. I've put my comments below. > > > ** There is 1 instance of too long lines in the document, the longest one > being 1 character in excess of 72. > > -> I think we can fix this through editing process > > > -- The draft header indicates that this document updates RFC3390, but the > abstract doesn't seem to directly say this. It does mention RFC3390 > though, so this could be OK. > > -- The draft header indicates that this document updates RFC5681, but the > abstract doesn't seem to mention this, which it should. > > -> I think these are minor points. As it is explained in the Introduction > and the draft tries to update a rather minor portion of RFC3390 > and RFC5681. > > > == Unused Reference: 'RFC6077' is defined on line 844, but no explicit > reference was found in the text > > -> It is referred in the text. This might be a bug for ID nits? > > -- Obsolete informational reference (is this intentional?): RFC 2414 > (Obsoleted by RFC 3390) > > -> This is intentional. > > > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. > > I believe no formal review is needed. > > (13) Have all references within this document been identified as > either normative or informative? > > Yes. > > (14) Are there normative references to documents that are not ready > for advancement or are otherwise in an unclear state? If such > normative references exist, what is the plan for their completion? > > No. > > (15) Are there downward normative references references (see RFC > 3967)? If so, list these downward references to support the Area > Director in the Last Call procedure. > > No. > > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are > not listed in the Abstract and Introduction, explain why, and point to > the part of the document where the relationship of this document to > the other RFCs is discussed. If this information is not in the > document, explain why the WG considers it unnecessary. > > This draft contains a proposal for adjusting initial window after > SYN, SYN/ACK > retransmission, which will update RFC3390 and RFC5681. This is > described in the Abstract > and Introduction and Section 2 explains the motivation. > > (17) Describe the Document Shepherd's review of the IANA > considerations section, especially with regard to its consistency with > the body of the document. Confirm that all protocol extensions that > the document makes are associated with the appropriate reservations in > IANA registries. Confirm that any referenced IANA registries have been > clearly identified. Confirm that newly created IANA registries include > a detailed specification of the initial contents for the registry, > that allocations procedures for future registrations are defined, and > a reasonable name for the new registry has been suggested (see RFC > 5226). > > The document does not involve any IANA considerations. > > (18) List any new IANA registries that require Expert Review for > future allocations. Provide any public guidance that the IESG would > find useful in selecting the IANA Experts for these new registries. > > There is no need to require expert review for future allocations. > > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. > > The document contains no formal language. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Tue Nov 20 14:17:48 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1E21F874B for ; Tue, 20 Nov 2012 14:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.287 X-Spam-Level: X-Spam-Status: No, score=-103.287 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie1h4otW7Bxv for ; Tue, 20 Nov 2012 14:17:47 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 30BF221F86E5 for ; Tue, 20 Nov 2012 14:17:47 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qAKMHPbl022305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Nov 2012 14:17:25 -0800 (PST) Message-ID: <50AC0175.6060908@isi.edu> Date: Tue, 20 Nov 2012 14:17:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 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 X-Mailman-Approved-At: Wed, 21 Nov 2012 10:51:53 -0800 Cc: " " "@isi.edu Subject: Re: [tcpm] publication request for draft-ietf-tcpm-initcwnd-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Nov 2012 22:17:48 -0000 Hi, all, One point below... On 11/19/2012 11:25 AM, Yoshifumi Nishida wrote: > Hello folks, > > Publication request for iw10 has been sent to IESG. > I've attached the write-up for the draft below. > > Thanks, > -- > Yoshifumi > > -------------------------------------------------------------------------------------------------------------------------- > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why is > this the proper type of RFC? Is this type of RFC indicated in the > title page header? > > > This document describes a proposal to increase initial window size of TCP > at most 10 segments. As it is indicated in the title page header, > the consensus > of the WG is to publish this document as an Experimental RFC. > We will need further experiments for this proposal to be advanced > as described > in Section 12. > > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: > > Technical Summary: > > Relevant content can frequently be found in the abstract and/or > introduction of the document. If not, this may be an indication that > there are deficiencies in the abstract or introduction. > > > This document describes an experimental proposal to increase > initial congestion window > of TCP to at most 10 segments as well as a fall-back mechanism to > limit any negative > effects in limited buffer or bandwidth situations. > It also provides guidelines to enable/disable this features in > addition to some metrics > to monitor the effect of this. > > > Working Group Summary: > > Was there anything in WG process that is worth noting? For example, > was there controversy about particular points or were there decisions > where the consensus was particularly rough? > > > There has been dominant opinions in the WG to increase initial > window size of TCP. > Question was whether we have a single updated value, or increasing > the value gradually > with a certain schedule, or defining a mechanics to adjust initial > window size over time. > We have explored several possibilities and eventually having a > single updated value > has become the consensus of the WG as other methods have some > difficulties for > large-scale deployment. Some of the approach in other methods have > been merged into the > draft during this process. The consensus was clear as no opinion > against this proposal > has been raised since then. > > > Document Quality: > > Are there existing implementations of the protocol? Have a significant > number of vendors indicated their plan to implement the specification? > Are there any reviewers that merit special mention as having done a > thorough review, e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If there was a > MIB Doctor, Media Type or other expert review, what was its course > (briefly)? In the case of a Media Type review, on what date was the > request posted? > > > Linux has already incorporated this proposal in the main kernel distribution. It is important to note that this deployment did not include any automatic or other reporting of errors, so if it is causing problems we simply do not know. As a result, this deployment does NOT follow the recommendations of this document, esp. in Sec. 12. Joe > This document was reviewed by various people and has been discussed > in the WG for > nearly three years. The authors have provided results from their > extensive experiments > with a larger initial window. They also provided data to address > questions and concerns > by reviewers. In addition, there have been some related experiments > by other TCPM contributors, > mostly based on simulation. The document has been updated based on > feedback from the community. > > I believe the authors did fairly extensive work for an experimental > RFC, even if valid questions > are still to be answered. The remaining questions, which need > further experiments, are hard > to address by the authors alone. Appendix A in the document > contains the list for major > discussion points of the draft. > > > Personnel: > > Who is the Document Shepherd? Who is the Responsible Area Director? > > Yoshifumi Nishida is the Document Shepherd for this document. > The Responsible Area Director is Wesley Eddy. > > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. > > I've reviewed the documents and made several editorial suggestions > in order to enhance the > readability of the drafts. I believe the quality of this draft is > matured enough to be > published. > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > > I have no concern about it. > > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. > > There is no need for particular reviews. > > (6) Describe any specific concerns or issues that the Document > Shepherd has with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he or she is > uncomfortable with certain parts of the document, or has concerns > whether there really is a need for it. In any event, if the WG has > discussed those issues and has indicated that it still wishes to > advance the document, detail those concerns here. > > I have no concerns with the document. > > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP > 78 and BCP 79 have already been filed. If not, explain why? > > Yes, each authors has confirmed this. > > (8) Has an IPR disclosure been filed that references this document? If > so, summarize any WG discussion and conclusion regarding the IPR > disclosures. > > No. > > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > The document is widely supported as we have seen positive comments > from various participants > in the WG meetings as well as the ML. The consensus was solid and clear. > > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) > > No one has indicated discontent. > > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the > Internet-Drafts Checklist). Boilerplate checks are not enough; this > check needs to be thorough. > > ID nits gives the following errors and warnings. I've put my comments below. > > > ** There is 1 instance of too long lines in the document, the longest one > being 1 character in excess of 72. > > -> I think we can fix this through editing process > > > -- The draft header indicates that this document updates RFC3390, but the > abstract doesn't seem to directly say this. It does mention RFC3390 > though, so this could be OK. > > -- The draft header indicates that this document updates RFC5681, but the > abstract doesn't seem to mention this, which it should. > > -> I think these are minor points. As it is explained in the Introduction > and the draft tries to update a rather minor portion of RFC3390 > and RFC5681. > > > == Unused Reference: 'RFC6077' is defined on line 844, but no explicit > reference was found in the text > > -> It is referred in the text. This might be a bug for ID nits? > > -- Obsolete informational reference (is this intentional?): RFC 2414 > (Obsoleted by RFC 3390) > > -> This is intentional. > > > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. > > I believe no formal review is needed. > > (13) Have all references within this document been identified as > either normative or informative? > > Yes. > > (14) Are there normative references to documents that are not ready > for advancement or are otherwise in an unclear state? If such > normative references exist, what is the plan for their completion? > > No. > > (15) Are there downward normative references references (see RFC > 3967)? If so, list these downward references to support the Area > Director in the Last Call procedure. > > No. > > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are > not listed in the Abstract and Introduction, explain why, and point to > the part of the document where the relationship of this document to > the other RFCs is discussed. If this information is not in the > document, explain why the WG considers it unnecessary. > > This draft contains a proposal for adjusting initial window after > SYN, SYN/ACK > retransmission, which will update RFC3390 and RFC5681. This is > described in the Abstract > and Introduction and Section 2 explains the motivation. > > (17) Describe the Document Shepherd's review of the IANA > considerations section, especially with regard to its consistency with > the body of the document. Confirm that all protocol extensions that > the document makes are associated with the appropriate reservations in > IANA registries. Confirm that any referenced IANA registries have been > clearly identified. Confirm that newly created IANA registries include > a detailed specification of the initial contents for the registry, > that allocations procedures for future registrations are defined, and > a reasonable name for the new registry has been suggested (see RFC > 5226). > > The document does not involve any IANA considerations. > > (18) List any new IANA registries that require Expert Review for > future allocations. Provide any public guidance that the IESG would > find useful in selecting the IANA Experts for these new registries. > > There is no need to require expert review for future allocations. > > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. > > The document contains no formal language. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wes@mti-systems.com Sun Nov 25 20:48:15 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBC321F8661 for ; Sun, 25 Nov 2012 20:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RBSNTeK5xar for ; Sun, 25 Nov 2012 20:48:15 -0800 (PST) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1C26421F85D6 for ; Sun, 25 Nov 2012 20:48:14 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAQ4mDpj023474 for ; Sun, 25 Nov 2012 23:48:14 -0500 Received: (qmail 16923 invoked by uid 0); 26 Nov 2012 04:48:13 -0000 Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.143.209) by 0 with ESMTPA; 26 Nov 2012 04:48:13 -0000 Message-ID: <50B2F48A.9040603@mti-systems.com> Date: Sun, 25 Nov 2012 23:48:10 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "draft-ietf-tcpm-proportional-rate-reduction@tools.ietf.org"@atl4mhob08.myregisteredsite.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: [tcpm] AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Nov 2012 04:48:16 -0000 I've completed AD review of this document and have a few small comments, some of which should be cleared up before going to the IESG review. It is basically in really good shape, but I see painful DISCUSS ballots coming if we don't clean up these small things: (1) It's really minor, but SACKs report received data, not lost data. Lost data is inferred from what wasn't SACK'ed. A couple places (like the last sentence of the 3rd paragraph in Section 1) indicate that SACKs report missing data. I know what you really mean, but it's technically wrong. (2) All the references to 3517 probably made sense when the doc was first written, but will really confuse the IESG, now that 6675 obsoletes 3517. I *think* we can change all instances of 3517 to 6675 and they all still work ... I know that it already says: """ The analysis and measurement study presented here predates [RFC6675], which updates RFC 3517. """ How about something like: """ The analysis and measurement study presented here predate [RFC6675], which updates RFC 3517. Thus, RFC 3517 was used as the basis for comparisons and some definitions, however, it is believed that the changes in RFC 6675 do not significantly alter the results. """ Would that be true? If so, we should do this and change the references. If not, then we need to do a little bit more explaining about what in 6675 would change things. (3) We are constantly seeing the IESG ask "What is the experiment?" for Experimental RFCs. Indeed, the WG even asked this during the last call when we looked at going to Standards Track. We should have a paragraph (probably in section 6) that indicates a bit more why we stuck with Experimental. A less cryptic version of what Matt said in the WGLC thread would probably be good: """ Finally there are some details in PRR that are effected by Laminar. I would rather not go to the effort of fixing the current draft to make it a proper normative PS, but not totally correct. (Hint: Yoshifumi Nishida's "off by one" comment reflects the difference between pipe and total_pipe). """ -- Wes Eddy MTI Systems From touch@isi.edu Sun Nov 25 22:18:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2171321F8671 for ; Sun, 25 Nov 2012 22:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.202 X-Spam-Level: X-Spam-Status: No, score=-105.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXw5xgOHQ8sY for ; Sun, 25 Nov 2012 22:18:30 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B3C2221F852E for ; Sun, 25 Nov 2012 22:18:30 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qAQ6HrLM001134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 25 Nov 2012 22:18:04 -0800 (PST) References: <50B2F48A.9040603@mti-systems.com> In-Reply-To: <50B2F48A.9040603@mti-systems.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-B2F225DE-28C9-4628-87B5-4CF00F02EEAC Message-Id: <120D63A9-7CDE-47C8-AA83-6AA05FD14E00@isi.edu> X-Mailer: iPad Mail (10A523) From: Joe Touch Date: Sun, 25 Nov 2012 22:17:52 -0800 To: Wesley Eddy X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Nov 2012 06:18:31 -0000 --Apple-Mail-B2F225DE-28C9-4628-87B5-4CF00F02EEAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Nov 25, 2012, at 8:48 PM, Wesley Eddy wrote: > (3) We are constantly seeing the IESG ask "What is the experiment?" > for Experimental RFCs. ... That seems like useful info to report to the Nomcom. That sort of ignorance= ought to justify relieving that party of their appointment. Fwiw, it may stem from the following, e.g., section 3 item 1. It may continu= e to confuse the point that the protocol itself is the experiment.=20 http://www.ietf.org/iesg/informational-vs-experimental.html Joe= --Apple-Mail-B2F225DE-28C9-4628-87B5-4CF00F02EEAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Nov 25, 2012, at 8:48 PM, W= esley Eddy <wes@mti-systems.com> wrote:

That seems like usef= ul info to report to the Nomcom.  That sort of ignorance ought to justi= fy relieving that party of their appointment.

Fwiw,= it may stem from the following, e.g., section 3 item 1. It may continue to c= onfuse the point that the protocol itself is the experiment. 
http://www.ietf.org/iesg/informational-vs-experimental.html

= --Apple-Mail-B2F225DE-28C9-4628-87B5-4CF00F02EEAC-- From wes@mti-systems.com Mon Nov 26 06:45:29 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7209D21F851E for ; Mon, 26 Nov 2012 06:45:29 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhSGhqHI-Fmb for ; Mon, 26 Nov 2012 06:45:29 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id CE8BD21F8448 for ; Mon, 26 Nov 2012 06:45:28 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAQEjRBV004918 for ; Mon, 26 Nov 2012 09:45:27 -0500 Received: (qmail 13254 invoked by uid 0); 26 Nov 2012 14:45:26 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.47.194.81) by 0 with ESMTPA; 26 Nov 2012 14:45:26 -0000 Message-ID: <50B38082.1000609@mti-systems.com> Date: Mon, 26 Nov 2012 09:45:22 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Joe Touch References: <50B2F48A.9040603@mti-systems.com> <120D63A9-7CDE-47C8-AA83-6AA05FD14E00@isi.edu> In-Reply-To: <120D63A9-7CDE-47C8-AA83-6AA05FD14E00@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Nov 2012 14:45:29 -0000 On 11/26/2012 1:17 AM, Joe Touch wrote: > > > On Nov 25, 2012, at 8:48 PM, Wesley Eddy > wrote: >> (3) We are constantly seeing the IESG ask "What is the experiment?" >> for Experimental RFCs. ... > > That seems like useful info to report to the Nomcom. That sort of > ignorance ought to justify relieving that party of their appointment. > > Fwiw, it may stem from the following, e.g., section 3 item 1. It may > continue to confuse the point that the protocol itself is the experiment. > http://www.ietf.org/iesg/informational-vs-experimental.html The question isn't Informational vs Experimental, but rather one of "if the algorithm is really as good as you say it is, and if you've already got this large measurement study done, and it looks like it's clearly okay, then why is TCPM not coming with it for Proposed Standard?". I think, in general, the point is just that we should be specific about whether there are aspects of the protocol/algorithm that we aren't really sure about yet. For instance, the current document is really good about this in terms of PRR-CRB vs PRR-SSRB, by explaining the differences and why an implementation might favor one over the other. -- Wes Eddy MTI Systems From touch@isi.edu Mon Nov 26 09:58:15 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771A321F8505 for ; Mon, 26 Nov 2012 09:58:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qhwSmm-Ul6n for ; Mon, 26 Nov 2012 09:58:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A1A7921F8503 for ; Mon, 26 Nov 2012 09:58:14 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qAQHvpJx007322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Nov 2012 09:57:51 -0800 (PST) Message-ID: <50B3AD9E.1040801@isi.edu> Date: Mon, 26 Nov 2012 09:57:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Wesley Eddy References: <50B2F48A.9040603@mti-systems.com> <120D63A9-7CDE-47C8-AA83-6AA05FD14E00@isi.edu> <50B38082.1000609@mti-systems.com> In-Reply-To: <50B38082.1000609@mti-systems.com> Content-Type: text/plain; charset=UTF-8; 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] AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Nov 2012 17:58:15 -0000 On 11/26/2012 6:45 AM, Wesley Eddy wrote: > On 11/26/2012 1:17 AM, Joe Touch wrote: >> >> >> On Nov 25, 2012, at 8:48 PM, Wesley Eddy > > wrote: >>> (3) We are constantly seeing the IESG ask "What is the experiment?" >>> for Experimental RFCs. ... >> >> That seems like useful info to report to the Nomcom. That sort of >> ignorance ought to justify relieving that party of their appointment. >> >> Fwiw, it may stem from the following, e.g., section 3 item 1. It may >> continue to confuse the point that the protocol itself is the experiment. >> http://www.ietf.org/iesg/informational-vs-experimental.html > > > The question isn't Informational vs Experimental, but rather one > of "if the algorithm is really as good as you say it is, and if > you've already got this large measurement study done, and it looks > like it's clearly okay, then why is TCPM not coming with it for > Proposed Standard?". That seems like the IESG pushing things towards PS; the default ought to be "not PS" unless there is community consensus. Is it really necessary to explain that to the IESG? Or do they not believe TCPM when we make a recommendation? > I think, in general, the point is just that we should be specific > about whether there are aspects of the protocol/algorithm that we > aren't really sure about yet. That's not the only case for Experimental. It can also be that there is insufficient operational experience, insufficient interest in implementing/deployment. The latter does not imply a lack of confidence in the algorithm or parameters. Again, it's disturbing that there is a need t constantly remind the IESG of this. Joe From wes@mti-systems.com Mon Nov 26 12:22:21 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A532221F849A for ; Mon, 26 Nov 2012 12:22:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTYzQF5TFETa for ; Mon, 26 Nov 2012 12:22:21 -0800 (PST) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id EC5D121F858E for ; Mon, 26 Nov 2012 12:22:20 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAQKMJZr005092 for ; Mon, 26 Nov 2012 15:22:20 -0500 Received: (qmail 3675 invoked by uid 0); 27 Nov 2012 00:20:40 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.47.194.81) by 0 with ESMTPA; 27 Nov 2012 00:20:40 -0000 Message-ID: <50B3CF70.3080101@mti-systems.com> Date: Mon, 26 Nov 2012 15:22:08 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Joe Touch References: <50B2F48A.9040603@mti-systems.com> <120D63A9-7CDE-47C8-AA83-6AA05FD14E00@isi.edu> <50B38082.1000609@mti-systems.com> <50B3AD9E.1040801@isi.edu> In-Reply-To: <50B3AD9E.1040801@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Nov 2012 20:22:21 -0000 On 11/26/2012 12:57 PM, Joe Touch wrote: > > > On 11/26/2012 6:45 AM, Wesley Eddy wrote: >> On 11/26/2012 1:17 AM, Joe Touch wrote: >>> >>> >>> On Nov 25, 2012, at 8:48 PM, Wesley Eddy >> > wrote: >>>> (3) We are constantly seeing the IESG ask "What is the experiment?" >>>> for Experimental RFCs. ... >>> >>> That seems like useful info to report to the Nomcom. That sort of >>> ignorance ought to justify relieving that party of their appointment. >>> >>> Fwiw, it may stem from the following, e.g., section 3 item 1. It may >>> continue to confuse the point that the protocol itself is the >>> experiment. >>> http://www.ietf.org/iesg/informational-vs-experimental.html >> >> >> The question isn't Informational vs Experimental, but rather one >> of "if the algorithm is really as good as you say it is, and if >> you've already got this large measurement study done, and it looks >> like it's clearly okay, then why is TCPM not coming with it for >> Proposed Standard?". > > That seems like the IESG pushing things towards PS; the default ought to > be "not PS" unless there is community consensus. Is it really necessary > to explain that to the IESG? Or do they not believe TCPM when we make a > recommendation? I think it's perfectly fair for people to ask what the rationale for a decision is, and for that rationale to be part of the document. In N years, when someone comes to ask to move to the Standards Track, this gives a starting point for assessing if it's ready. Just so we're clear, the IESG hasn't asked for this yet. I'm saying that it's a common question when rationale isn't clear, and I'm personally saying that it's not clear in this I-D. The rest of the IESG hasn't said anything about it, and I'd like to address it in the I-D so they won't wonder. Nobody is trying to counter the WG's decision or push towards PS; in fact, I fully agree with you that the default should be "not PS" without strong consensus. >> I think, in general, the point is just that we should be specific >> about whether there are aspects of the protocol/algorithm that we >> aren't really sure about yet. > > That's not the only case for Experimental. It can also be that there is > insufficient operational experience, insufficient interest in > implementing/deployment. The latter does not imply a lack of confidence > in the algorithm or parameters. Exactly. Do you believe that the I-D says which of these is the case? On the contrary, it gives a lot of measurement data, and talks about implementation and deployment experience at a large site. > Again, it's disturbing that there is a need t constantly remind the IESG > of this. So far, this is in the AD Review state and it's my comment, so you aren't reminding the rest of the IESG about anything yet :). -- Wes Eddy MTI Systems From iesg-secretary@ietf.org Mon Nov 26 13:29:41 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4347D21F8586; Mon, 26 Nov 2012 13:29:41 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe6dBoL+iX2u; Mon, 26 Nov 2012 13:29:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA7D21F8509; Mon, 26 Nov 2012 13:29:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126212940.20378.58186.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 13:29:40 -0800 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Increasing TCP's Initial Window) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 21:29:41 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Increasing TCP's Initial Window' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments, with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purpose recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/ No IPR declarations have been submitted directly on this I-D. From mattmathis@google.com Tue Nov 27 11:09:03 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6273921F8724 for ; Tue, 27 Nov 2012 11:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em3PnKly9Ox7 for ; Tue, 27 Nov 2012 11:09:00 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6403721F8727 for ; Tue, 27 Nov 2012 11:09:00 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so6056786bku.31 for ; Tue, 27 Nov 2012 11:08:59 -0800 (PST) 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=vqRtpmVFImtG3gtXXRq4iTpj2qLCViTn27iuyNCC/h4=; b=ExyyKvCrAyLRIyNzUXriHUloU0I5XjWMoPzcnAmB7H3mIicAOxiUDxQ7TTS4znmQpV 9NJh8TikrKVYgAGAvgl3K4t7IFFuRgAtkGrulr7RDZbKzleNJmOTRq87nSt5pRqCH+xh YeHqsTMfRzFNAYnejX5QDpM3I5nzXeTmdnjnlhglvB9mfY0/iFsSgfZNEaevtKpdpoJE pil/wO5fsjFT7M8ndJgTXp4c/p6BkXvH6dP/2R026N1stf68kqrqzEZ9lyhUeQ+Iy4mO QZ9hhbosjohIOb1hre6u0OvbX4jzNQkt7Uv17M/d6fHaB/aqpDu8knVhRRYVA56mtqms NoQg== 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=vqRtpmVFImtG3gtXXRq4iTpj2qLCViTn27iuyNCC/h4=; b=iNrgEBKgrbGLaBTGrNfaBHthVRWngY1UD8k3DKVXfa2uIpnX1992Cm9GqyjCaklXTS /F8OSRxgtpOyMLF84YZqJB+BjvpCJIL4OQH61AdGmybYkTpy407jpfTMX5UZoDUrUZGu 0TDazaPLubPvl3t47iFR2fy+qBBYeod4MA+zavKXH9pOlBjvnH2s9ylw1LZI0z3nN4MD cUXjCtFdvGg9FK481pTqU60VJI7Bz9Jb6fyk9qSdidpxypIRNl4osKoqbyLXmQ87rCzb N5uk72Av+KiBTm2MTpbVWWXeLzPo44vsHhG/G7waX/T/z69pFYQMkS84xay93yONIWH5 Ay2A== MIME-Version: 1.0 Received: by 10.204.5.202 with SMTP id 10mr4712425bkw.135.1354043339041; Tue, 27 Nov 2012 11:08:59 -0800 (PST) Received: by 10.204.200.209 with HTTP; Tue, 27 Nov 2012 11:08:58 -0800 (PST) In-Reply-To: <50B2F48A.9040603@mti-systems.com> References: <50B2F48A.9040603@mti-systems.com> Date: Tue, 27 Nov 2012 11:08:58 -0800 Message-ID: From: Matt Mathis To: Wesley Eddy Content-Type: multipart/alternative; boundary=001517588cf83bea7e04cf7ec888 X-Gm-Message-State: ALoCoQm6JSiaGsXglR/NcMNq76ThIVv7SD5B2MYZwjcKqOeQKoFZpCGfptNXTnSTIsXJkoIb7EQG7X06HuWTFWatjlC/1WEA/Ea5KEO2d4cRlS1k1zUcD55JHf8/F/Ud2ZzirFAK8PrAU9j9rmN0f8H/tR9Lrvfb0Ec8JFV9+uzic5Mh1xQCN2hakixFmpxCKmAWrySPXnO5 Cc: "draft-ietf-tcpm-proportional-rate-reduction@tools.ietf.org"@atl4mhob08.myregisteredsite.com, "tcpm@ietf.org" Subject: Re: [tcpm] AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Nov 2012 19:09:03 -0000 --001517588cf83bea7e04cf7ec888 Content-Type: text/plain; charset=ISO-8859-1 Your comments are on the mark: I will roll a new draft. I agree with Joe, however I know there are communities that desperately want "RFC" to mean something other than "Request For Comments" because they depend on PS status to compel manufacturers to do things that they don't want to do. These communities are undermined by the existence of strong well established de facto standards that are only weakly documented in the IETF process. Pissing on the entire process (as I did in my prior rant on the subject) isn't really constructive, and potentially harms areas like network management, where it is important to be able to write contract language that explicitly requires verbatim implementations of RFC. I will do your item (3) as a concession to the IETF process mongers. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Nov 25, 2012 at 8:48 PM, Wesley Eddy wrote: > I've completed AD review of this document and have a few small > comments, some of which should be cleared up before going to > the IESG review. It is basically in really good shape, but I > see painful DISCUSS ballots coming if we don't clean up these > small things: > > > (1) It's really minor, but SACKs report received data, not lost > data. Lost data is inferred from what wasn't SACK'ed. A couple > places (like the last sentence of the 3rd paragraph in Section 1) > indicate that SACKs report missing data. I know what you really > mean, but it's technically wrong. > > > (2) All the references to 3517 probably made sense when the doc > was first written, but will really confuse the IESG, now that > 6675 obsoletes 3517. I *think* we can change all instances of > 3517 to 6675 and they all still work ... I know that it already > says: > """ > The analysis and measurement study presented here predates [RFC6675], > which updates RFC 3517. > """ > How about something like: > """ > The analysis and measurement study presented here predate [RFC6675], > which updates RFC 3517. Thus, RFC 3517 was used as the basis for > comparisons and some definitions, however, it is believed that the > changes in RFC 6675 do not significantly alter the results. > """ > Would that be true? If so, we should do this and change the > references. If not, then we need to do a little bit more > explaining about what in 6675 would change things. > > > (3) We are constantly seeing the IESG ask "What is the experiment?" > for Experimental RFCs. Indeed, the WG even asked this during the > last call when we looked at going to Standards Track. We should > have a paragraph (probably in section 6) that indicates a bit more > why we stuck with Experimental. A less cryptic version of what > Matt said in the WGLC thread would probably be good: > """ > Finally there are some details in PRR that are effected by Laminar. I > would rather not go to the effort of fixing the current draft to make > it a proper normative PS, but not totally correct. (Hint: Yoshifumi > Nishida's "off by one" comment reflects the difference between pipe > and total_pipe). > """ > > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001517588cf83bea7e04cf7ec888 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Y= our comments are on the mark: I will roll a new draft.

I= agree with Joe, however I know there are communities that desperately want= "RFC" to mean something other than "Request For Comments&qu= ot; because they depend on PS status to compel manufacturers to do things t= hat they don't want to do. =A0These communities are undermined=A0by the= =A0existence=A0of strong well=A0established de facto standards that are onl= y weakly documented in the IETF process.

Pissing on the entire process (as I did in my prior ran= t on the subject) isn't really constructive, and potentially harms area= s like network management, where it is important to be able to write contra= ct language that explicitly requires=A0verbatim=A0implementations of RFC.

I will do your item (3) as a concession to the IETF pro= cess mongers.

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

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


On Sun, Nov 25, 2012 at 8:48 PM, Wesley = Eddy <wes@mti-systems.com> wrote:
I've completed AD review of this document and have a few small
comments, some of which should be cleared up before going to
the IESG review. =A0It is basically in really good shape, but I
see painful DISCUSS ballots coming if we don't clean up these
small things:


(1) It's really minor, but SACKs report received data, not lost
data. =A0Lost data is inferred from what wasn't SACK'ed. =A0A coupl= e
places (like the last sentence of the 3rd paragraph in Section 1)
indicate that SACKs report missing data. =A0I know what you really
mean, but it's technically wrong.


(2) All the references to 3517 probably made sense when the doc
was first written, but will really confuse the IESG, now that
6675 obsoletes 3517. =A0I *think* we can change all instances of
3517 to 6675 and they all still work ... I know that it already
says:
"""
The analysis and measurement study presented here predates [RFC6675],
which updates RFC 3517.
"""
How about something like:
"""
The analysis and measurement study presented here predate [RFC6675],
which updates RFC 3517. =A0Thus, RFC 3517 was used as the basis for
comparisons and some definitions, however, it is believed that the
changes in RFC 6675 do not significantly alter the results.
"""
Would that be true? =A0If so, we should do this and change the
references. =A0If not, then we need to do a little bit more
explaining about what in 6675 would change things.


(3) We are constantly seeing the IESG ask "What is the experiment?&quo= t;
for Experimental RFCs. =A0Indeed, the WG even asked this during the
last call when we looked at going to Standards Track. =A0We should
have a paragraph (probably in section 6) that indicates a bit more
why we stuck with Experimental. =A0A less cryptic version of what
Matt said in the WGLC thread would probably be good:
"""
Finally there are some details in PRR that are effected by Laminar. =A0I would rather not go to the effort of fixing the current draft to make
it a proper normative PS, but not totally correct. =A0(Hint: Yoshifumi
Nishida's "off by one" comment reflects the difference betwee= n pipe
and total_pipe).
"""

--
Wes Eddy
MTI Systems
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--001517588cf83bea7e04cf7ec888-- From mattmathis@google.com Tue Nov 27 11:12:03 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB921F887C for ; Tue, 27 Nov 2012 11:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1rSGLe+CqsN for ; Tue, 27 Nov 2012 11:12:02 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9290E21F8790 for ; Tue, 27 Nov 2012 11:12:01 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so6057992bku.31 for ; Tue, 27 Nov 2012 11:12:00 -0800 (PST) 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=Xr8U3ti68KAWMavx2+LEd5pnCIwHYZpLw6tH3Q+Q3sI=; b=IHFE0Eqk+mMUq55tBJaGcn2WxqFTcHtbCACA9w0D9qeFoDHxtvO2uOyHyL0/EJ5bll 4a4VYpYaPCDKftuV2u+KNjhBFC82Ljy9a+Bw9gHebnsbG89LjMryNoZGRvZJ0QGi0PtT pre0jTPTnbCzw9AaHl0lpfNpRJV3cP4X1f/RrkUFEaNMj4EkCAc1rT6budG1rV1unLOy LlxHJTln8av1mSR2S7LwmOSj7TlctuYm8rgMnEQcQXkQsWHt44M53pBCqvhTYCAxDAQv Fb3sNq3nDnCPifwb5+1foOyZlV4HNyt59YlOQazfjACrS5fG0PwAfOWXY3vRUjDow7Zr Yj6g== 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=Xr8U3ti68KAWMavx2+LEd5pnCIwHYZpLw6tH3Q+Q3sI=; b=ZagziyMG6qT3wvjmHZcHOmMNVOn6xOhd5AhYOYfKFg7Vcfr+zvuE1BJoB7Kx2qzyo4 gnCsE8pg04wmRvZGF0ZMxGmLjm/ksthju8bCqrY/RS9PMAPOUlt4tm4uHTy6Jv3QeWxY xD7jRLrVcb9qPFPPtOty1jGUNdk3WMBnYuH2RxtlQbZ4gumvx3yylhZ1qaVUH06hni1x nuqBjkb7Snj4o2yy0YkZZNWCfbbMTN0m5BtnhjHWqSdynAxlDVmf/teK0+urGLRPkCd3 s3BvCS+Woh16rskc+J2WWUSkMF2nFUn5oZB6USvwFYd8QMfCWuic0l++WgbH5C7Qc8vd QIkA== MIME-Version: 1.0 Received: by 10.204.8.17 with SMTP id f17mr4763702bkf.110.1354043520560; Tue, 27 Nov 2012 11:12:00 -0800 (PST) Received: by 10.204.200.209 with HTTP; Tue, 27 Nov 2012 11:12:00 -0800 (PST) In-Reply-To: References: <50B2F48A.9040603@mti-systems.com> Date: Tue, 27 Nov 2012 11:12:00 -0800 Message-ID: From: Matt Mathis To: Wesley Eddy Content-Type: multipart/alternative; boundary=0015174be9aa0daea404cf7ed3f8 X-Gm-Message-State: ALoCoQmdcEDmLZZmxlIQoTfRNb8Iow1RWTlcaT3MO9dlRabOFH7JQQfDBfTCLbhOuKyGxzdbgUyyVhnKSgcw/vISP65VquHuweJ71DCIKJF8Nvnri2RxEde2JSajWLtRUMXLgV5se4xaXJLVwwEB9zkToVNYoVuahwjgxZwUZyzz4rbkN89cilCiX1dyt0Fn2DzrdhxzDwAW Cc: draft-ietf-tcpm-proportional-rate-reduction@tools.ietf.org, TCP Maintenance and Minor Extensions WG Subject: [tcpm] Fwd: AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Nov 2012 19:12:03 -0000 --0015174be9aa0daea404cf7ed3f8 Content-Type: text/plain; charset=ISO-8859-1 The addresses on your earlier message were corrupted. Replying bounced. --MM-- The best way to predict the future is to create it. - Alan Kay ---------- Forwarded message ---------- From: Matt Mathis Date: Tue, Nov 27, 2012 at 11:08 AM Subject: Re: [tcpm] AD review of PRR draft To: Wesley Eddy Cc: "draft-ietf-tcpm-proportional-rate-reduction@tools.ietf.org"@ atl4mhob08.myregisteredsite.com, "tcpm@ietf.org" Your comments are on the mark: I will roll a new draft. I agree with Joe, however I know there are communities that desperately want "RFC" to mean something other than "Request For Comments" because they depend on PS status to compel manufacturers to do things that they don't want to do. These communities are undermined by the existence of strong well established de facto standards that are only weakly documented in the IETF process. Pissing on the entire process (as I did in my prior rant on the subject) isn't really constructive, and potentially harms areas like network management, where it is important to be able to write contract language that explicitly requires verbatim implementations of RFC. I will do your item (3) as a concession to the IETF process mongers. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Nov 25, 2012 at 8:48 PM, Wesley Eddy wrote: > I've completed AD review of this document and have a few small > comments, some of which should be cleared up before going to > the IESG review. It is basically in really good shape, but I > see painful DISCUSS ballots coming if we don't clean up these > small things: > > > (1) It's really minor, but SACKs report received data, not lost > data. Lost data is inferred from what wasn't SACK'ed. A couple > places (like the last sentence of the 3rd paragraph in Section 1) > indicate that SACKs report missing data. I know what you really > mean, but it's technically wrong. > > > (2) All the references to 3517 probably made sense when the doc > was first written, but will really confuse the IESG, now that > 6675 obsoletes 3517. I *think* we can change all instances of > 3517 to 6675 and they all still work ... I know that it already > says: > """ > The analysis and measurement study presented here predates [RFC6675], > which updates RFC 3517. > """ > How about something like: > """ > The analysis and measurement study presented here predate [RFC6675], > which updates RFC 3517. Thus, RFC 3517 was used as the basis for > comparisons and some definitions, however, it is believed that the > changes in RFC 6675 do not significantly alter the results. > """ > Would that be true? If so, we should do this and change the > references. If not, then we need to do a little bit more > explaining about what in 6675 would change things. > > > (3) We are constantly seeing the IESG ask "What is the experiment?" > for Experimental RFCs. Indeed, the WG even asked this during the > last call when we looked at going to Standards Track. We should > have a paragraph (probably in section 6) that indicates a bit more > why we stuck with Experimental. A less cryptic version of what > Matt said in the WGLC thread would probably be good: > """ > Finally there are some details in PRR that are effected by Laminar. I > would rather not go to the effort of fixing the current draft to make > it a proper normative PS, but not totally correct. (Hint: Yoshifumi > Nishida's "off by one" comment reflects the difference between pipe > and total_pipe). > """ > > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0015174be9aa0daea404cf7ed3f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
T= he addresses on your earlier message were corrupted. Replying bounced.
--MM--
The best way to predict the future is to create it. = =A0- Alan Kay

---------- Forwarded message ----------
F= rom: Matt Mathis <mattmathis@google.com>=
Date: Tue, Nov 27, 2012 at 11:08 AM
Subject: Re: [tcpm] AD review of PRR= draft
To: Wesley Eddy <wes@mt= i-systems.com>
Cc: "draft-ietf-tcpm-proportional-rate-red= uction@tools.ietf.org"@atl4mhob08.myregisteredsite.com, "tcpm@ietf.org" <tcpm@= ietf.org>


Your comments are on the mark: I will roll a new draft.

I agree with Joe, however I know there are communities that desperately w= ant "RFC" to mean something other than "Request For Comments= " because they depend on PS status to compel manufacturers to do thing= s that they don't want to do. =A0These communities are undermined=A0by = the=A0existence=A0of strong well=A0established de facto standards that are = only weakly documented in the IETF process.

Pissing on the entire process (as I did in my prior ran= t on the subject) isn't really constructive, and potentially harms area= s like network management, where it is important to be able to write contra= ct language that explicitly requires=A0verbatim=A0implementations of RFC.

I will do your item (3) as a concession to the IETF pro= cess mongers.

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

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



On Sun, Nov 25, 2012 at 8:48 PM, Wesley = Eddy <wes@mti-systems.com> wrote:
I've completed AD review of this document and have a few small
comments, some of which should be cleared up before going to
the IESG review. =A0It is basically in really good shape, but I
see painful DISCUSS ballots coming if we don't clean up these
small things:


(1) It's really minor, but SACKs report received data, not lost
data. =A0Lost data is inferred from what wasn't SACK'ed. =A0A coupl= e
places (like the last sentence of the 3rd paragraph in Section 1)
indicate that SACKs report missing data. =A0I know what you really
mean, but it's technically wrong.


(2) All the references to 3517 probably made sense when the doc
was first written, but will really confuse the IESG, now that
6675 obsoletes 3517. =A0I *think* we can change all instances of
3517 to 6675 and they all still work ... I know that it already
says:
"""
The analysis and measurement study presented here predates [RFC6675],
which updates RFC 3517.
"""
How about something like:
"""
The analysis and measurement study presented here predate [RFC6675],
which updates RFC 3517. =A0Thus, RFC 3517 was used as the basis for
comparisons and some definitions, however, it is believed that the
changes in RFC 6675 do not significantly alter the results.
"""
Would that be true? =A0If so, we should do this and change the
references. =A0If not, then we need to do a little bit more
explaining about what in 6675 would change things.


(3) We are constantly seeing the IESG ask "What is the experiment?&quo= t;
for Experimental RFCs. =A0Indeed, the WG even asked this during the
last call when we looked at going to Standards Track. =A0We should
have a paragraph (probably in section 6) that indicates a bit more
why we stuck with Experimental. =A0A less cryptic version of what
Matt said in the WGLC thread would probably be good:
"""
Finally there are some details in PRR that are effected by Laminar. =A0I would rather not go to the effort of fixing the current draft to make
it a proper normative PS, but not totally correct. =A0(Hint: Yoshifumi
Nishida's "off by one" comment reflects the difference betwee= n pipe
and total_pipe).
"""

--
Wes Eddy
MTI Systems
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm


--0015174be9aa0daea404cf7ed3f8-- From internet-drafts@ietf.org Wed Nov 28 13:24:23 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3791F21F884C; Wed, 28 Nov 2012 13:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3AmLVJ0t+fR; Wed, 28 Nov 2012 13:24:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F98C21F86FD; Wed, 28 Nov 2012 13:24:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121128212422.28011.38770.idtracker@ietfa.amsl.com> Date: Wed, 28 Nov 2012 13:24:22 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-03.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, 28 Nov 2012 21:24:23 -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-03.txt Pages : 9 Date : 2012-11-28 Abstract: This document describes how the experimental TCP option codepoints can support concurrent use through the use of a magic number. This mechanism avoids the need for a coordinated registry and is backward-compatible with currently known uses. 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Wed Nov 28 13:25:08 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95BB21F8575 for ; Wed, 28 Nov 2012 13:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.376 X-Spam-Level: X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 589lMF9wgwbX for ; Wed, 28 Nov 2012 13:25:08 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E24B021F880C for ; Wed, 28 Nov 2012 13:25:07 -0800 (PST) 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 qASLOb9Y006842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2012 13:24:37 -0800 (PST) Message-ID: <50B68115.9030704@isi.edu> Date: Wed, 28 Nov 2012 13:24:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Wesley Eddy References: <50A3309C.9020902@mti-systems.com> <50A345E2.5040606@isi.edu> In-Reply-To: <50A345E2.5040606@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-tcpm-experimental-options@tools.ietf.org, "tcpm@ietf.org" Subject: Re: [tcpm] AD review 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, 28 Nov 2012 21:25:08 -0000 Hi, all, I have updated a new version (03) draft based on AD review and Apps review as follows. It should show up in the usual places shortly. Please let me know if this addresses your concerns, or if anyone has any other feedback. Thanks, Joe --------------------------------------- AD review: 1) reorganized the sections split section 3 into separate first-level sections inserted subsections in section 3 to clarify the discussion 2) revised the discussion of migration to assigned options the current text is intended to be agnostic to a specific solution, but to make recommendations on what NOT to do 3) cleaned up the wording in many places, esp. the RFC2119 recommendations Apps review: 4) added an explanation of the use of experimental codepoints vs. Experimental RFCs in the intro 5) cleaned up the discussion of collisions in section 4 ------------------------ From pasi.sarolahti@iki.fi Thu Nov 29 03:49:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0668321F89F3 for ; Thu, 29 Nov 2012 03:49:24 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bq7XSo7Sd6s for ; Thu, 29 Nov 2012 03:49:23 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 43B8721F89F2 for ; Thu, 29 Nov 2012 03:49:23 -0800 (PST) Received: from [163.117.87.4] (163.117.87.4) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087141600836288 for tcpm@ietf.org; Thu, 29 Nov 2012 13:49:21 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Pasi Sarolahti In-Reply-To: <2229_1352728860_50A1011C_2229_861_2_837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> Date: Thu, 29 Nov 2012 12:49:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2229_1352728860_50A1011C_2229_861_2_837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> To: tcpm X-Mailer: Apple Mail (2.1283) Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Nov 2012 11:49:24 -0000 Hi, To wrap up the past mailing list discussion: it seems people were = supportive of adding this milestone for Experimental RFC, so we will = proceed based on the below drafted text. (and if experience shows this = works well, preparing RFC 6298 revision is certainly one possible future = path) - Pasi On Nov 12, 2012, at 3:01 PM, Pasi Sarolahti wrote: > In the TCPM meeting last week there was a clear consensus for adopting = RTO restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, = targeted for Experimental RFC. Here is a proposal for a new milestone = item: >=20 > Aug 2013 Submit document on restarting the RTO timer to the IESG for = publication as an Experimental RFC >=20 > Any comments or objections about the milestone? From pasi.sarolahti@iki.fi Thu Nov 29 04:11:07 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9B221F8983 for ; Thu, 29 Nov 2012 04:11:07 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcgR-jrHljqf for ; Thu, 29 Nov 2012 04:11:07 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE5421F8710 for ; Thu, 29 Nov 2012 04:11:04 -0800 (PST) Received: from [163.117.87.4] (163.117.87.4) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508714160083797D for tcpm@ietf.org; Thu, 29 Nov 2012 14:11:04 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Nov 2012 13:11:02 +0100 Message-Id: <098EB5EC-480D-4DC6-898F-26CD9E31B580@iki.fi> To: tcpm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] Adopting draft-fairhurst-tcpm-newcwv X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Nov 2012 12:11:07 -0000 Hi, The other adoption call we did in the Atlanta meeting was about = draft-fairhurst-tcpm-newcwv-05. In the room there was unanimous support = for adopting this, but we did not discuss much about the intended status = of the document. I understood the authors' current preference is to go = for Proposed Standard, and this is what the draft header suggests. Any = thoughts about this? Does anyone think Experimental would be more = appropriate at this point (and on what basis)? - Pasi From iesg-secretary@ietf.org Thu Nov 29 06:46:47 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BCE21F8A6F; Thu, 29 Nov 2012 06:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRXI4RWm1aYp; Thu, 29 Nov 2012 06:46:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F45B21F8A6B; Thu, 29 Nov 2012 06:46:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121129144647.18045.70643.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2012 06:46:47 -0800 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Shared Use of Experimental TCP Options) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 14:46:48 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Shared Use of Experimental TCP Options' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how the experimental TCP option codepoints can support concurrent use through the use of a magic number. This mechanism avoids the need for a coordinated registry and is backward-compatible with currently known uses. It is recommended for all new TCP options that use these codepoints. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/ No IPR declarations have been submitted directly on this I-D. From ycheng@google.com Fri Nov 30 09:27:26 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751C21F899A for ; Fri, 30 Nov 2012 09:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt1-7sS567+R for ; Fri, 30 Nov 2012 09:27:26 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B53E21F8543 for ; Fri, 30 Nov 2012 09:27:25 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so756853obc.31 for ; Fri, 30 Nov 2012 09:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=n7Mh0h42MYiopbyiXt37R/XWHsqyevWk8qY3vNAJcfE=; b=lzYbIW3LfgGmspiA3p3qZlTiDjewH2MXDrbO6EHxrhOp+U0rx+paOsE7wRMHwx3Lhf 7mRiFc/WZP3JdoMcsoAVxXCJxiPCI/AMBCNKazqheTUefdG0XdRtex7Bgq0t0O0UL3Sb AC2rLHuwVvOFjcIQOjc1fE+MSH6FudJBEkOEWroJT3MV+0T08X6H8ashdqayJaD4vrax Gh64/GfTNxabPpGeAYkcFytdhdEVdlGWmv5kC3AODB2OhWmZi3MXUl1E2pS8nJnf+mBk RMdmjNUJjY0knF8OUDrPz2fT015xUTMtiXNGviNZNLCjUbHjI+OrQxWX2KddmlyMVEdi ZExQ== 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=n7Mh0h42MYiopbyiXt37R/XWHsqyevWk8qY3vNAJcfE=; b=Z0Cii0ViiwRiczNp+sG7HDGNKuQjXovLmvvj0L1x4X2GBwO85d7olazr67H6jIEK0w B8m7re4c9xnYz9++D6R/J1xa85doHQ0WGmf0vWHu6jY5zwXZE4Eov/uku+nwL8gmcVUq ZpHm5+cQeH0tfRhtp/o4Ii4vUMuRlYjVK0DkRed0YRcMbLRUJHOo0kRsuZM17v4I7HBl Ma7V5HL1cVfxCO71A8DCFIw4Yofy1ZG4ftG6iHKqt7wEVRbJO0f6EIK/epFKSfUEqGf7 pb4ey+FoYcTnY9wD0rScnlleu5DhXolulLLtJ3AfqlWD6q+mC09zgg+KdxoknnWThMeT MWSQ== Received: by 10.60.32.210 with SMTP id l18mr1530806oei.99.1354296445521; Fri, 30 Nov 2012 09:27:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.24.233 with HTTP; Fri, 30 Nov 2012 09:27:05 -0800 (PST) In-Reply-To: <098EB5EC-480D-4DC6-898F-26CD9E31B580@iki.fi> References: <098EB5EC-480D-4DC6-898F-26CD9E31B580@iki.fi> From: Yuchung Cheng Date: Sat, 1 Dec 2012 01:27:05 +0800 Message-ID: To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkSMIT2kBppC/hQ4R0a7Bj/4VCf/gGOjSN1c2/evaABCqw80TmdxiC7sSgd7YVXL6losS1+Lv1eGpsV844mSJ18YDNnJ+uKO6x9Qutlm7hpUQ5VKLYxuc8p8Pltw/x0231zoJbfoD4GDldL7e0IGLm2h28iToBn0lFDSGISTFhKNFNBd0idPxh8XLyJmsCxVQ74vjvS Cc: tcpm Subject: Re: [tcpm] Adopting draft-fairhurst-tcpm-newcwv X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 17:27:26 -0000 On Thu, Nov 29, 2012 at 8:11 PM, Pasi Sarolahti wro= te: > Hi, > > The other adoption call we did in the Atlanta meeting was about draft-fai= rhurst-tcpm-newcwv-05. In the room there was unanimous support for adopting= this, but we did not discuss much about the intended status of the documen= t. I understood the authors' current preference is to go for Proposed Stand= ard, and this is what the draft header suggests. Any thoughts about this? D= oes anyone think Experimental would be more appropriate at this point (and = on what basis)? > According to RFC2026 PS: "A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation." Has the idea "pipeAck" and 5min idle-time been implemented and evaluated in real systems/networks? > - Pasi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm