From nobody Tue Jan 3 11:58:47 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2B312940F; Tue, 3 Jan 2017 11:58:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148347352605.27987.5107939896268043727.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 11:58:46 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 19:58:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : TCP Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-07.txt Pages : 23 Date : 2017-01-03 Abstract: TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 3 12:05:04 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2026129B68 for ; Tue, 3 Jan 2017 12:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TbFpzOX-iHW for ; Tue, 3 Jan 2017 12:05:01 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D02129B5B for ; Tue, 3 Jan 2017 12:05:01 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v03K3vkl025246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Jan 2017 12:03:57 -0800 (PST) References: <148347352605.27987.5107939896268043727.idtracker@ietfa.amsl.com> To: tcpm@ietf.org From: Joe Touch Message-ID: <48ac7437-a1e0-7886-7cae-2d2ed0c445ef@isi.edu> Date: Tue, 3 Jan 2017 12:03:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148347352605.27987.5107939896268043727.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 03 Jan 2017 20:05:02 -0000 Hi, all, This update addresses document expiration only. Joe On 1/3/2017 11:58 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. > > Title : TCP Extended Data Offset Option > Authors : Joe Touch > Wesley M. Eddy > Filename : draft-ietf-tcpm-tcp-edo-07.txt > Pages : 23 > Date : 2017-01-03 > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options but the size of the field can limit the space available for > complex options such as SACK and Multipath TCP and can limit the > combination of such options supported in a single connection. This > document updates RFC 793 with an optional TCP extension to that > space to support the use of multiple large options. It also explains > why the initial SYN of a connection cannot be extending a single > segment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jan 5 20:17:31 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87FC12986F for ; Thu, 5 Jan 2017 20:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYUAPbqyR4If for ; Thu, 5 Jan 2017 20:17:29 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F9F1297A5 for ; Thu, 5 Jan 2017 20:17:28 -0800 (PST) Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2828D27862D for ; Fri, 6 Jan 2017 13:17:26 +0900 (JST) Received: by mail-ua0-f178.google.com with SMTP id y9so66505040uae.2 for ; Thu, 05 Jan 2017 20:17:26 -0800 (PST) X-Gm-Message-State: AIkVDXL2BVpP46Hglw9mNZvo0TbzA/6n1kDyNUK6b1XgdRfYV0G9DlqHvAiX7D9/YKoQQ2Zjl3uxfFEi3IQ2BA== X-Received: by 10.176.66.100 with SMTP id i91mr57226867uai.131.1483676244687; Thu, 05 Jan 2017 20:17:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.90.132 with HTTP; Thu, 5 Jan 2017 20:17:24 -0800 (PST) In-Reply-To: References: From: Yoshifumi Nishida Date: Thu, 5 Jan 2017 20:17:24 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b766286c3870545654bab Archived-At: Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 04:17:30 -0000 --94eb2c0b766286c3870545654bab Content-Type: text/plain; charset=UTF-8 Hello, This is just a reminder. We will appreciate your feedback! Thanks, -- Yoshi On Fri, Dec 16, 2016 at 3:10 PM, Yoshifumi Nishida wrote: > Hello, > > As we have discussed during Seoul meeting, the chairs decided to start > running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn. > > We would like to confirm that the TCPM community agrees to: > > * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working > group item to publish it as an experimental RFC. > * add a corresponding milestone to the TCPM charter. > > Aug 2017 Submit document on alternative backoff with ECN algorithm > to the IESG for publication as an Experimental RFC > > > As the end of the year is approaching, we decided to run a longer call > than usual. Please let us know by * Friday January 6 2017 *, whether you > support or object adoption of the document. > > Thanks, > -- > tcpm co-chairs > --94eb2c0b766286c3870545654bab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
This is just a reminder. We will appreciate you= r feedback!
Thanks,
--
Yoshi

On Fri, Dec 16, 2016 at 3:10 PM,= Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hello,

As we have dis= cussed during Seoul meeting, the chairs decided to start running a call for= adoption of draft-khademi-tcpm-alternativebackoff-ecn.=C2=A0

= We would like to confirm that the TCPM community agrees to:

=C2=A0 *= adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working gro= up item to publish it as an experimental RFC.
=C2=A0 * add a correspondi= ng milestone to the TCPM charter.

=C2=A0 =C2=A0 =C2=A0Aug 2017 =C2= =A0Submit document on alternative backoff with ECN algorithm to the IESG fo= r publication as an Experimental RFC


As the end of the year is a= pproaching, we decided to run a longer call than usual. Please let us know = by * Friday January 6 =C2=A02017 *, whether you support or object adoption = of the document.=C2=A0

Thanks,
--
tcpm co-chairs
<= /div>

--94eb2c0b766286c3870545654bab-- From nobody Fri Jan 6 01:23:11 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447B4129C9C for ; Fri, 6 Jan 2017 01:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=simula-no.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLBBq8MUGh6R for ; Fri, 6 Jan 2017 01:23:07 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DD01298C1 for ; Fri, 6 Jan 2017 01:23:06 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id k184so20839118wme.1 for ; Fri, 06 Jan 2017 01:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simula-no.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5od+A5P72pJ73ycxZTXXWpjKlcArUPa9za9GEleikgo=; b=WMkIwL9rFN3LGvPFJ2W1tF0Mo0EW0gYbAktWSrjwRw8Ese9HlB/79nEJEze/koNPd0 h6hOdXws0pqTW03KDolzds3pqm9FU7EkY8HIJ4Hi+caUpwbzQVl8Vgj8NR1CHCJRVH4q yzh/1o5fNKr2kS1yyUaKD6vJyba79ryIVPv+ZmEOPNb3LUj81hjvjZok7CO8A8go/eK9 RcDdce7dNLoUJ0cBE4ZMPG9ZX4DFMY0w8FixDYkWtMl+xDm8HPblJhfrDDkHilVhquVp Q1o26kTH/PPjQN3TeMFM0SQaVayIOTU35mqp5hRUDyXwxmq9JSiaiyyYauFwp5hIvsX8 Gopw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5od+A5P72pJ73ycxZTXXWpjKlcArUPa9za9GEleikgo=; b=aPyBMBIUpSRxVGZPJbeGtZL9+A+gymW+uUQELWyit9eGM+svCJ4zuB7G6U5U3E7MTs YcCXIFJe/+HqQtbYJGz+KCQrnoBbzht8eGquscZG5uyPPG7k2z+QLZcwXPGlczqezM2n BzMWCXo+O+GS9Y0lU9HW3rUDFgkcHFuhchckrBl+6qsk+INKLIhs3xfsD/ij/ygxh1wY v98cDbBTNCYwk/+ewy7jnw938GZ4Hm48BZflh9kP4ApZfnsgVV0x6Dg6dImxtwyRuZa9 ppUYZUwWGFuUL/K6NYRe96gPBz87kTPH6hJ0sFfgbI+g5M/ixVaMHDs90UkLbUsXqpoI n9Mg== X-Gm-Message-State: AIkVDXJ8Jumnvq6GEEdqI8gV+BO051HBqc8JADkesGj8frGElJZce4XswvCSKfqJxE/Is1wk X-Received: by 10.223.145.166 with SMTP id 35mr282393wri.98.1483694585225; Fri, 06 Jan 2017 01:23:05 -0800 (PST) Received: from [192.168.0.26] (ARennes-653-1-180-140.w92-135.abo.wanadoo.fr. [92.135.147.140]) by smtp.gmail.com with ESMTPSA id d64sm2460000wmh.3.2017.01.06.01.23.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Jan 2017 01:23:04 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FADADA67-21C3-4AEC-88EB-2D55E406D8C9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Ros In-Reply-To: Date: Fri, 6 Jan 2017 10:23:05 +0100 Message-Id: References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 09:23:09 -0000 --Apple-Mail=_FADADA67-21C3-4AEC-88EB-2D55E406D8C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I support adoption of this draft. Thanks, David On 06 Jan 2017, at 05:17, Yoshifumi Nishida = wrote: > Hello, > This is just a reminder. We will appreciate your feedback! > Thanks, > -- > Yoshi >=20 > On Fri, Dec 16, 2016 at 3:10 PM, Yoshifumi Nishida = wrote: > Hello, >=20 > As we have discussed during Seoul meeting, the chairs decided to start = running a call for adoption of = draft-khademi-tcpm-alternativebackoff-ecn.=20 >=20 > We would like to confirm that the TCPM community agrees to: >=20 > * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working = group item to publish it as an experimental RFC. > * add a corresponding milestone to the TCPM charter. >=20 > Aug 2017 Submit document on alternative backoff with ECN = algorithm to the IESG for publication as an Experimental RFC >=20 >=20 > As the end of the year is approaching, we decided to run a longer call = than usual. Please let us know by * Friday January 6 2017 *, whether = you support or object adoption of the document.=20 >=20 > Thanks, > -- > tcpm co-chairs >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_FADADA67-21C3-4AEC-88EB-2D55E406D8C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

I support adoption = of this = draft.

Thanks,

David
On 06 Jan 2017, at 05:17, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> = wrote:

Hello,
This is just a reminder. We = will appreciate your = feedback!
Thanks,
--
Yoshi

On Fri, Dec 16, = 2016 at 3:10 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> = wrote:
Hello,

As we have discussed during Seoul meeting, the = chairs decided to start running a call for adoption of = draft-khademi-tcpm-alternativebackoff-ecn. 

We would = like to confirm that the TCPM community agrees to:

  * adopt = draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working group = item to publish it as an experimental RFC.
  * add a = corresponding milestone to the TCPM charter.

    =  Aug 2017  Submit document on alternative backoff with ECN = algorithm to the IESG for publication as an Experimental = RFC


As the end of the year is approaching, we decided to run = a longer call than usual. Please let us know by * Friday January 6 =  2017 *, whether you support or object adoption of the = document. 

Thanks,
--
tcpm = co-chairs

_______________________________________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tcpm

= --Apple-Mail=_FADADA67-21C3-4AEC-88EB-2D55E406D8C9-- From nobody Fri Jan 6 01:29:14 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D107D129484 for ; Fri, 6 Jan 2017 01:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx7nYJoM0JlV for ; Fri, 6 Jan 2017 01:29:10 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAC7129413 for ; Fri, 6 Jan 2017 01:29:10 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cPQpg-0001mg-1p for tcpm@ietf.org; Fri, 06 Jan 2017 10:29:08 +0100 Received: from vpn-client397.uio.no ([193.157.137.144]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user steing (Exim 4.80) (envelope-from ) id 1cPQpf-00016g-EE; Fri, 06 Jan 2017 10:29:07 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_EC90CB83-944E-4BBB-9C82-498579C79059" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Stein Gjessing In-Reply-To: Date: Fri, 6 Jan 2017 10:29:06 +0100 Message-Id: References: To: nishida@sfc.wide.ad.jp X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 23127 max rcpts/h 46 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.2, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.194, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 44BF7AE7C0DC190BCC0D6D7686BBC7BF56D5562A X-UiO-SPAM-Test: remote_host: 193.157.137.144 spam_score: -71 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 493 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 09:29:13 -0000 --Apple-Mail=_EC90CB83-944E-4BBB-9C82-498579C79059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I support adoption of the document Cheers, Stein On 06 Jan 2017, at 05:17, Yoshifumi Nishida > wrote: > Hello, > This is just a reminder. We will appreciate your feedback! > Thanks, > -- > Yoshi >=20 > On Fri, Dec 16, 2016 at 3:10 PM, Yoshifumi Nishida = > wrote: > Hello, >=20 > As we have discussed during Seoul meeting, the chairs decided to start = running a call for adoption of = draft-khademi-tcpm-alternativebackoff-ecn.=20 >=20 > We would like to confirm that the TCPM community agrees to: >=20 > * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working = group item to publish it as an experimental RFC. > * add a corresponding milestone to the TCPM charter. >=20 > Aug 2017 Submit document on alternative backoff with ECN = algorithm to the IESG for publication as an Experimental RFC >=20 >=20 > As the end of the year is approaching, we decided to run a longer call = than usual. Please let us know by * Friday January 6 2017 *, whether = you support or object adoption of the document.=20 >=20 > Thanks, > -- > tcpm co-chairs >=20 > _______________________________________________ > 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 --Apple-Mail=_EC90CB83-944E-4BBB-9C82-498579C79059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I = support adoption of the document

Cheers,
Stein

On = 06 Jan 2017, at 05:17, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

Hello,
This is = just a reminder. We will appreciate your feedback!
Thanks,
--
Yoshi

On Fri, Dec 16, 2016 at 3:10 PM, = Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hello,

As we have discussed = during Seoul meeting, the chairs decided to start running a call for = adoption of draft-khademi-tcpm-alternativebackoff-ecn. 

We = would like to confirm that the TCPM community agrees to:
  * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working group item to = publish it as an experimental RFC.
  * add a = corresponding milestone to the TCPM charter.

     Aug 2017  Submit document on = alternative backoff with ECN algorithm to the IESG for publication as an = Experimental RFC


As the end = of the year is approaching, we decided to run a longer call than usual. = Please let us know by * Friday January 6  2017 *, whether you = support or object adoption of the document. 

Thanks,
--
tcpm = co-chairs

_______________________________________________
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

= --Apple-Mail=_EC90CB83-944E-4BBB-9C82-498579C79059-- From chamil@erg.abdn.ac.uk Fri Jan 6 09:05:22 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37E129D10 for ; Fri, 6 Jan 2017 09:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0oFGgCad6AM for ; Fri, 6 Jan 2017 09:05:20 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA4129D0D for ; Fri, 6 Jan 2017 09:05:18 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 9333A1B00210; Fri, 6 Jan 2017 19:02:56 +0000 (GMT) Received: from 193.1.184.239 (SquirrelMail authenticated user chamil) by erg.abdn.ac.uk with HTTP; Fri, 6 Jan 2017 17:05:15 -0000 Message-ID: <1e0d79938944c083e632c648d397e3a4.squirrel@erg.abdn.ac.uk> Date: Fri, 6 Jan 2017 17:05:15 -0000 From: chamil@erg.abdn.ac.uk To: tcpm@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:06:56 -0000 Hi, I support adoption of this draft. Thanks, Chamil Kulatunga On Fri, Dec 16, 2016 at 3:10 PM, Yoshifumi Nishida > wrote: > Hello, > > As we have discussed during Seoul meeting, the chairs decided to start running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn. > > We would like to confirm that the TCPM community agrees to: > > * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working group item to publish it as an experimental RFC. > * add a corresponding milestone to the TCPM charter. > > Aug 2017 Submit document on alternative backoff with ECN algorithm to the IESG for publication as an Experimental RFC > > > As the end of the year is approaching, we decided to run a longer call than usual. Please let us know by * Friday January 6 2017 *, whether you support or object adoption of the document. > > Thanks, > -- > tcpm co-chairs > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jan 6 09:30:09 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7317B129D2B for ; Fri, 6 Jan 2017 09:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikzu5qUpGutN for ; Fri, 6 Jan 2017 09:30:06 -0800 (PST) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id AB344129B73 for ; Fri, 6 Jan 2017 09:30:06 -0800 (PST) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 39D0917509; Fri, 6 Jan 2017 09:30:05 -0800 (PST) Date: Fri, 6 Jan 2017 09:30:05 -0800 From: hiren panchasara To: Yoshifumi Nishida Message-ID: <20170106173005.GB61376@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:30:07 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/16/16 at 03:10P, Yoshifumi Nishida wrote: > Hello, >=20 > As we have discussed during Seoul meeting, the chairs decided to start > running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn. I support the adoption. Cheers, Hiren --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJYb9QZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lZywH/A6QlaqbEw09xwiPvhNq/J5l ys43IIqkWYN7ICMVCI2maFsMO6tOxg1nTs8Yq1jTHQUqmTr3s/ioSfGc7VNNsIs7 YhGO49RUZH7MloWuD4OLsS+zUk7KEKFhDPCnSQw+vdvSUkPmYA//QXZj4fHOUlwp 03xLGkXtzsTMxIfSWbhdBpnMjrm0i+rWDET2quRWM3GvfF406kFCSbRJD0VB0PRp 9oJ1TRXCudvnDpBNGBXFTCDLSxM/3Wxwnd014+FAz1eAh5f8NDvu751U43hZZZIY aDnlfAFfPsw6wm7HusOEGurqyaTDyOCR9cK4HBWBW6IDlTtAFZbsz0YBGfeYAUs= =yZfV -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From nobody Fri Jan 6 13:18:44 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD222129EFD for ; Fri, 6 Jan 2017 13:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hSsXA8gvSGB for ; Fri, 6 Jan 2017 13:18:41 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 59056129EFB for ; Fri, 6 Jan 2017 13:18:41 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 66B5090A296; Fri, 6 Jan 2017 16:18:39 -0500 (EST) Date: Fri, 6 Jan 2017 16:18:39 -0500 From: John Leslie To: Yoshifumi Nishida Message-ID: <20170106211839.GA69857@verdi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 21:18:43 -0000 Yoshifumi Nishida wrote: > > > > As we have discussed during Seoul meeting, the chairs decided to start > > running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn. > > > > We would like to confirm that the TCPM community agrees to: > > > > * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working > > group item to publish it as an experimental RFC. > > * add a corresponding milestone to the TCPM charter. > > > > Aug 2017 Submit document on alternative backoff with ECN algorithm > > to the IESG for publication as an Experimental RFC I am happy to see an experiment proposed. But I don't think this document adequately describes the experiment: thus I'd rather see agreement on a few things before we adopt this. - what is the duration of the experiment? - how will the results be evaluated? - (how will we even tell which senders are experimenting?) Also, we should allow for other experiments. I am not convinced that the optimum response to an ECN mark is to reduce flightsize by exactly 20% in every case. (At the least, we should allow experimenting on what reaction there should be to a _second_ ECN mark within one RTT.) I remind folks that by it's very nature, ECN-marking can signal things by the _rate_ of marking. It would be a shame to paint ourselves into a corner where we can't take advantage of that. -- John Leslie From nobody Fri Jan 6 13:31:55 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D35A12951A for ; Fri, 6 Jan 2017 13:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V05CQBjS9ecM for ; Fri, 6 Jan 2017 13:31:52 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407DE12948A for ; Fri, 6 Jan 2017 13:31:52 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id c20so6605444itb.0 for ; Fri, 06 Jan 2017 13:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NmwBg4NeF1o6UQfAHBxhi6LgWCU7I4dK7MTtnLTaUCI=; b=tXUOb3eY0aElHNvlSvxQe8C0GuHNIpOQzRrIGthkXBe+XTrBZbPG7ApFFlH4XzY4Va Yi1AH+DrEp4m3wnjRg2n6Rbt0UV5S7OED+kGXsXWwHH0bglu67i13axDaEqrkJRrA5OT v05yEi22KVn15rhzcTJrdJpQM6Se++mTXHbWqKvT+cKbeB9y4WEbOpT4JXK3t0wFkTa+ +xHYXb8t8cmlc0seZPKrZ5dAzkEnePdd0cB9azbcypDx4K0ATas2Bxsdt3N3jWvpFBNT mefS87JmBX9eAtszZ7iQJScmeciw6jB1DKc5SyI0zNXouMwEWuX7EpkSXbOO0ID6o66k bMCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NmwBg4NeF1o6UQfAHBxhi6LgWCU7I4dK7MTtnLTaUCI=; b=G1WC9woTtdr/uFCFQat7wLEcfvYK4/ApTrtIuLPM/V75HNDBVCMAEdLsfuxDaGroyS lJWullSlaXPDH0pY/jQ2AQWETE/VQR3loMo4Or2z6jRRVGY01S6nnwq7tsn2sK299ZG2 20TXwYzpn1ygVjmDLgTH1AgaFTVmSiQpOMRXeAZeK8U6aNadbalWiROoYrTyG3u0L1PI j90zsAhma6Q6Yp/7ij5hXhudhAGdbE2rEXkl1XkTO88uJoo34W0eDFZYGNa91MYViiD/ saXinfcDTth9sDsV7EA7mvzFzhCwuaz5GOmdvNDXPSloFwi4tWr7SDOw7wga6sNC5HtR vqXQ== X-Gm-Message-State: AIkVDXLRefPBm6NGBOR80oIbsLNgi8OJE3baraZycQ48W+HgNgpgoLh09CZBv9PlwV9NUnMQ+2r87qFbdczoxQCX X-Received: by 10.36.194.70 with SMTP id i67mr607829itg.21.1483738311354; Fri, 06 Jan 2017 13:31:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.0.11 with HTTP; Fri, 6 Jan 2017 13:31:10 -0800 (PST) In-Reply-To: <20170106211839.GA69857@verdi> References: <20170106211839.GA69857@verdi> From: Yuchung Cheng Date: Fri, 6 Jan 2017 13:31:10 -0800 Message-ID: To: John Leslie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 21:31:54 -0000 On Fri, Jan 6, 2017 at 1:18 PM, John Leslie wrote: > Yoshifumi Nishida wrote: >> > >> > As we have discussed during Seoul meeting, the chairs decided to start >> > running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn. >> > >> > We would like to confirm that the TCPM community agrees to: >> > >> > * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working >> > group item to publish it as an experimental RFC. >> > * add a corresponding milestone to the TCPM charter. >> > >> > Aug 2017 Submit document on alternative backoff with ECN algorithm >> > to the IESG for publication as an Experimental RFC > > I am happy to see an experiment proposed. > > But I don't think this document adequately describes the experiment: > thus I'd rather see agreement on a few things before we adopt this. > > - what is the duration of the experiment? > > - how will the results be evaluated? > > - (how will we even tell which senders are experimenting?) I share same sentiments. > > Also, we should allow for other experiments. I am not convinced that > the optimum response to an ECN mark is to reduce flightsize by exactly > 20% in every case. (At the least, we should allow experimenting on what > reaction there should be to a _second_ ECN mark within one RTT.) > > I remind folks that by it's very nature, ECN-marking can signal things > by the _rate_ of marking. It would be a shame to paint ourselves into a > corner where we can't take advantage of that. > > -- > John Leslie > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Jan 7 15:51:03 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC0E129679 for ; Sat, 7 Jan 2017 15:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.057 X-Spam-Level: X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohNq_mq-LcCc for ; Sat, 7 Jan 2017 15:51:00 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2977A1295BD for ; Sat, 7 Jan 2017 15:51:00 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 3B465AEBF3D24; Sat, 7 Jan 2017 23:50:54 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v07NotDX020047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Jan 2017 23:50:58 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v07NooY6006241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Jan 2017 23:50:52 GMT Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.116]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Sun, 8 Jan 2017 00:50:50 +0100 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org" Thread-Topic: Comments on draft-ietf-tcpm-cubic-03 Thread-Index: AdJpQN5YwjQW0dnbSkmfOOFXKa51kw== Date: Sat, 7 Jan 2017 23:50:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48C16A0C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tcpm-cubic@tools.ietf.org" Subject: [tcpm] Comments on draft-ietf-tcpm-cubic-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 07 Jan 2017 23:51:02 -0000 Hi all, As individual contributor to TCPM I have read draft-ietf-tcpm-cubic-03. To = me, the technical content is by and large ready to move forward. I have some editorial suggestions, which would in my personal opinion impro= ve the document. Also, I have one question on the interaction of CUBIC with= huge buffers. 1/ Abstract To me the abstract is a bit long and the historical (?) reference to BIC-TC= P could easily be moved e.g. to the introduction. A shorter abstract would = e.g. be: CUBIC is an extension of the current TCP congestion control. The protoc= ol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. CUBIC and its predecessor algorithm have been adopted= as=20 default by Linux and have been used for many years. This document provid= es a specification of CUBIC to enable third party implementation and=20 to solicit the community feedback through experimentation on the performance of CUBIC. This document does not replace the standard TCP congestion control [RFC5681]. As the IESG typically reviews the meta-data of documents, I believe an expl= icit statement on the relationship to RFC5681 would be useful. This would b= e one potential wording. The remaining content currently in the abstract could e.g. be added to the = Introduction. I assume Linux has switched to CUBIC many years ago, right? S= o, some wording could be... BIC-TCP, a predecessor of CUBIC, has been selected as default TCP conges= tion control algorithm by Linux in the year 2005 and been used for several ye= ars by the Internet community at large. CUBIC is using a similar window grow= th function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. CUBIC has already been deployed globally by Linux. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for testing and deployment in the global Internet. 2/ Section 1. Introduction To me the introduction is quite long and covers two different aspects: Firs= t, it provides context on the history of CUBIC, and second it provides a (n= on-normative) overview of the design principle. I believe both could be spl= it into two parts, e.g., with a ToC like this: 1. Introduction 2. Design principle of CUBIC 3. Conventions 4. CUBIC Congestion Control ... (There are other options.) This would just be a reorganization of the text. At least some parts of the= current introduction section assume that the reader has a pretty good unde= rstanding of congestion control and they are not really introductory, so th= is is why moving these description to a dedicated "design principles" secti= on could make sense. But, similar like my comment on the abstract, this may= be a question of personal preference only. Nit: Please expand "MIMD" on first use. 3/ Section 4. Discussion In order to explain the section structure in Section 4, it could perhaps he= lp to refer to RFC 5033 again at the beginning of Section 4. 4/ Section 4.4. Investigating a Range of Environments Wouldn't it make sense to mention somewhere in the document, e.g. in Sectio= n 4.4, that CUBIC can fill large buffers, in particular large buffers with = drop-tail, and that this can increase delay for other connections? This seems to be an inherent characteristic of high-speed congestion contro= l algorithms only reacting to loss, and it will not matter if proper queue = management is in place, but still I wonder if this aspect should be mention= ed. Thanks Michael From nobody Sat Jan 7 18:42:37 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56191296F7 for ; Sat, 7 Jan 2017 18:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_eTmIHqhrN3 for ; Sat, 7 Jan 2017 18:42:27 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0088.outbound.protection.outlook.com [207.46.163.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC8E1296E0 for ; Sat, 7 Jan 2017 18:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WSIitH45pQmXCoUdFzO4obnp7rpyYYCr6qpexwSeteY=; b=cKSHYTpXqsCVTGf65fXP4XEPtMBnlwN2g6B1EA/8hJ8UhkKsVWL7FkMyiE/18kkqhdnfB6CJcTZ3FQGkxsKCO+pck0SBv0S+GBwWSf46+IqHP6GupzKvWQmmfDPbUuo3I0hscYglR82qNw4euJZH3svFDR7MJzbXlQr/8n327fQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.164] (97.98.140.59) by DM5PR08MB2523.namprd08.prod.outlook.com (10.173.220.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Sun, 8 Jan 2017 02:42:24 +0000 To: "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D48C16A0C@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <0fc3c3e0-7bdb-a108-03f8-e9bcee04724b@unl.edu> Date: Sat, 7 Jan 2017 20:42:24 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D48C16A0C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: DM5PR15CA0014.namprd15.prod.outlook.com (10.173.207.152) To DM5PR08MB2523.namprd08.prod.outlook.com (10.173.220.137) X-MS-Office365-Filtering-Correlation-Id: d72de575-f45c-4d3f-8159-08d4376ffa83 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR08MB2523; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2523; 3:1ZW5RFWLvglnSbuIBp5Gkv6OO4NoD0pb0/TOyqnBR2jx64ZLB7pYjgMqtyBuE5T6wkDeo4edqyYntYuaolTZKDWZfBdWhmn0MXakS55ufOvoeLT3oUN34k7fohh+ADkUseIic8OGvsJjIKJq9mFRVLXIKvzI9NBsNZCgweAMswLEv6zpIViFzxySgspcPskPh1VXWZW4YfFzc5O1Al1TTNDG9wVT/tR6c8igtunTD8JoIeTAnj86PO3JrBsr4GWWxvRR36G1PGPIkWiNYLMu+g==; 25:1SWwY9rB6StwajqlfBf9s0Q7Zd5UOpa6S689usCm367hmg1+b/oBoXClTDjeqr685dHsOelq1do9ur4bIjHz2jlA3/EGcnT3JrsOOCMwdgcIFZRjvn+R8C8rpxbKhUYJxNb+L2js2WxoPpqKzqGyxfkzl/UxhkVGl8FfGSbMyMQd0Q6wcNmpy5/h9qEbqQTVyeanZNLS7d/cyZ9uoPHBpzLlgJBMVFRLbDbkzBh6r8VbKjTzcvM20ygWMxFvQFegojn5oX6jZ1tBhkGxqdNk6KnfU7oFVUigUYJTsNATXB8+DlZt41S3AfoMsQzwUgR/mjq9PhH4cENG+JFBPgJ6q4I3DY8eudUeeyzwJoLTc4fj09yXDjAiKcmvJzUJUE0Qo69wgP7FzRYYyJsD+u95PjkP0zu+2/SbfrvLMJ6yrwienDpPSy6reOBb9f4ayT1m65b5OBK3+9tBPjAH+OfVVQ== X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2523; 31:6snkyQoGIJMWgmu68rzd9ASZEHXEDXYxk98SH9luLSEvvlibpZgyhf4W5Ej8muUL89cMpQdl6Ij6UaLl+KsORGQQzYXPaBjnUdWmIhhDSbgnjSbxDPXAxOPYXcP9JWc2wbzivlh+LxWWxFWnPgcu9hu8AF2zakO4Zrz5/Oymgkg7IwJo9f+wCbTP8x0F5kPd4e/qhNuyGBD27m+qE7mi7+c5jsqCi/RTfCl/C44iAKiGWN3UgPeHoS5AnW6KZXOKU91f3fv2ZGghIEfx4k3dRg==; 20:C7d4YtWj0i+fFZJqAvz9kkpFXzCtvLpuujYjKopuAPCBjCGHxciQOB5+qKNcd+HdIxuukmh9ozNTVlPjyeUQBts3Sikzuv9yUzb3g+/9M14mJppKoqNWJEZfLvHSEOSYodqlRmI13ihp4dpHfO57Ug8GV9ejT6iLF4hRATlm+Ky/9LSV3TNHBp7GMkFD5uSVkclph8ORmoOeIFAtr1nI1FPbRlXozmFmV33yJwHdz1hFC2m/ianRK69W+28fdI2usc0G/gzdDmyDQBcLLylvR5KlRObic/StaXNU1kAZ4Fmlm+8yYkbpL1qIyB4nH34Bu71OcXcYpxX7fSg8IFuRXUo5EgvPlWsDZ+IN324RSPSDNuERx5zM92PB2GTwEhKEY8OZ5PC47M0vY2ZbmknglMC2m0KGTvUh8sd74+apbBLzihQrjDZ7fI/m8KOHq9+2ehZ2pg6mPVuaZorh2MJqvQsbQpN5WJwNKwATfhlTo9d/fPcMojmRWxo7te55Vls6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DM5PR08MB2523; BCL:0; PCL:0; RULEID:; SRVR:DM5PR08MB2523; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2523; 4:3/vYDo7tsUHshZEPVmeyIOnyX67/xx/ugVqoZYs03qjJbLLHZvLstWYoI4A5gzWR/L8lrx43HqjhLWBaj9E9/28Rfh14XfCoJpaCOfsmy7XAlPTF0LLN/CgbcuDYjXbFqeIqugY+H8/0HcJ9hcEBz/2mIqoipOTqjlrmChV+YqJUVnXIoTJT8J1nUeLn3Kyz1cv7rIaeg2uOH8WacygiTT6xXoHhOt5GG22OtBIX7XSe3oDBXEB21mCiEy95npsb5eQqG9PBRP2nMPPN6GdjUR6ujkUzudXogXbdJN/iLMvrz9K0A6OE61ai9QyRoePqQAo7Xf5mOCgLXAmm5V5tdNNZeBIXQKOrGkqa90eKkh0ZSKIhi2XYNC85zGE/WO440CGVaiyKHncNH9nLmI2Y8i5vFhE17FT5h0UB4PDdVJ9T7slzk7QIeEIFvoQKOsrPmAsE8cbBuiV+RkmknLi+1wHqsXUIYKIhoEscALIrD6HE0H88MHhjm/Me7yGPlYuiSZnd/nGyM7ACpdGy+1SpMDuUh25vfmkBxkwKCHRHUYm+kT+TZxzFKJvV+LqF48OxpyEdKBgaRaOWIDasdDCFGRfL95za763oFwPEiqkMf0Y= X-Forefront-PRVS: 0181F4652A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(377454003)(199003)(45984002)(24454002)(54094003)(189002)(53754006)(4001350100001)(88552002)(97736004)(6116002)(3846002)(77096006)(90366009)(189998001)(5001770100001)(92566002)(68736007)(2906002)(4326007)(65826007)(6486002)(50466002)(2950100002)(5660300001)(64126003)(38730400001)(25786008)(229853002)(2501003)(81166006)(81156014)(8676002)(83506001)(65806001)(65956001)(66066001)(47776003)(23746002)(31696002)(101416001)(75432002)(230700001)(36756003)(86362001)(230783001)(105586002)(117156001)(106356001)(33646002)(42186005)(6306002)(305945005)(76176999)(54356999)(50986999)(31686004)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB2523; H:[192.168.0.164]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM5PR08MB2523; 23:jynKSKyHGMH0dW91JZIu62aK7VoQsZT40/1gY?= =?Windows-1252?Q?DzywAeGYXpI0QebvhvhKfWJzv+0Bi0i4zsXrxrCkyujBwZVGMgqsDN4G?= =?Windows-1252?Q?JBrB5Dryjlg5y+UgszyFGMBvoAwCzdCOdo/iH6/gxRhURHffxkOgISQX?= =?Windows-1252?Q?ryErkBNMl1wkqK/pXasGR+aaGtUq9DBREL42gSmjO+OHP3ddw4Cby8Vx?= =?Windows-1252?Q?neSbnSKD/j/A4xjn7EBtJTLnz9+F2pO1pqGcNdoIBIesaHuaj+rxH382?= =?Windows-1252?Q?uI0Jam+2cueRij2BQLf1DxCou5oH2l132oAdq7fgZYJbaFgwlFTSUmOp?= =?Windows-1252?Q?Q/1iG/FfcWf8Ch1jiNPvDXYWq9/YOKBv2Oh8JXl97mMwibMbLqOAlCcc?= =?Windows-1252?Q?kQpEpEWSXVNyyiR18+oF6myXEjBPOXC9+lx/L0trjdF8SIzVzDgtBmcM?= =?Windows-1252?Q?IyoC5OE4ybO7/d1+KlDzW/zIJW/1qoXMbNReTvRwVAmOFb0ojumqYoX8?= =?Windows-1252?Q?lvFl1X1XheAUvuMs6b8thCihJuaX79IVCy8nYiaAwzvU252WG8Mpogcl?= =?Windows-1252?Q?yJf1EMpybBlgXi3ICRxZpgBgnvcPOuYNKxfjmY8h9k56JTp3lrfX7cKA?= =?Windows-1252?Q?8IRBW6+BS8j6PmQzBRA7EVMw3f01V6KcqI/0en4my+yP6VojGq2hNtrL?= =?Windows-1252?Q?UpJrORo+1Np3CHtJLKH7wVekbkqvYTHyQedYTbfuJpZhej+xG8ceIkhn?= =?Windows-1252?Q?mHC09qjJAsw2BlT38/cKy6JxhF9UNUuHeXSBrNZUT/OhHJQiQDaPjNY6?= =?Windows-1252?Q?Nw3KysSOREB9FNKhEodjS/9wfX1cRtEiYr0y5kVeOX9MbMAnSUQCgUN/?= =?Windows-1252?Q?3On+4KcEgjoBOT8tVsaw19xiv8/K3i1k2Yu/V5Iq4IDYjlSybKbi6E11?= =?Windows-1252?Q?20PxMbT4lp3yhYYiTcQvMWNui6JM/eJExC4pmCrilIWpQzOdLK2Yst2H?= =?Windows-1252?Q?fw9JDb0bfWVAsc4yMoQxZ9uX03A57vgWiSeTRqBxB0evBbVzwuhhWmPl?= =?Windows-1252?Q?32ysixv9DPgFR6+2+OGuqIpr5BxPMSx5jUq0nRu9Lb9CwzjZ9npb5FRr?= =?Windows-1252?Q?NSbFUr6AiY+VUfIr7yNYiHvnxuW/LJioAutAu+W6uyRjFaEvrdTXoDEB?= =?Windows-1252?Q?HvobKnCUeIwbFM92fZDhotfIN0b1BATi9RRNw+K64QrI3B21Hg8DfzMR?= =?Windows-1252?Q?Qdo+cC8mPl1PArvJ19+LWyYelaM/rQkYTG1U8VHkZSA2vMbKdYHdDFTo?= =?Windows-1252?Q?bk3Ox5cdBnECfccNak+PJOyq36Wa7SDFY05pvPeQvndWbr9oWhxFuUfj?= =?Windows-1252?Q?gS519XKWk2/2PnATzXwuw1m4wnWwZmS4Tf2mkvycHD8VB06pN3hIEC85?= =?Windows-1252?Q?dBJ0e0XD/NYbBk8Sx0USyZFi0jgxWoN1j+4BddizHlcizxnFBc0umeyJ?= =?Windows-1252?Q?d3pYhIh8R07PKRwGnACQv98YqJx7uFp9ZIl8qnBQWBpOYHRIaoSll45Z?= =?Windows-1252?Q?6MR3B8x3FCzUs/Zay7IZWtbzUI8tLcvsTJQq7C+HMIZykcgbpp7Z3eHT?= =?Windows-1252?Q?30O2pxrwxXH1WSYHsrjC+s=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2523; 6:CfDjmR7gUwM9ey/BRiyuEknFhnkN+S+nOublv9VPJBsem2u2XKlwtQdlPb3VTM2h04vi1MvAGYlGLTjo11lTd8r2Gw/RSTH1bSrBiWGSuuvL3plp3B6cNr4kiAfGGjZrj4XHMCw4wsbv8TyZPn5QQbgyRgCW+WG2iNlxFTpVsGs0+zidCRS557NwWGhfXT/b4xnkhfuFjHZGtVUr8IZIT9F6ALh9SWFVAvxWp7n5cZ0EiZLEC50Oz6UDxF+Ml372xFyfRqWF7daWwjwmqJUrAODrYpNXzNfylEp2aO9tfpGfiMetYRQQ0trg9z6xe3XOlmwdUP4E4xxRh5P36Pn8BWNAXzJXjmtE4G1EPSwjiIOHEtpkNf+S5t3EMqOeu2E3BeoxgYbFlqMc660j3iUtMaP3fsjbebdWDg+Q+Dj65b0=; 5:RiMezjOn+Z4PQUAq8M3f3pMn9MWHn0GNSbfVwD3UymGCxbRr8HqewulwFyHHAGhuYecZP7rWZzIafcxlikOM4zHen1zBGKmXT+aXNYtHk25NrWkwlCtVCQVpNnmCmznl6I5mDM7PVuPaAVhlXvXqSw==; 24:PH/j4RA6PnfJ9/iidO+vpb/DVJcNUlaSAP1p7oe2N+mlsJgoTU/yubRgpoK9gKMDMBTljtbq2G6yIm/etX7tXrYI8/mmuLPUQGLTl36CeoQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2523; 7:+nj8c9ujWWXZZkcDtZ+02VK54w26CFvHlsp/3AFR7uBWOzseW/MW/ls2x8Qfr8Vj2oaDGqFJsOG4+Cnh2tuBVhEcUq9ka+Ce/Sw9ttrR0bl+EH83uXVANnkK5UsbsGUEvrqJukukxQkJwQe7UXf/k+KWlu1kZjMqfCRLw99DMcVhpIIViVU+HoPPS1Hq66xY9EV7eBCftxeovJ41XlintfxqktewKhKFQB3JpfS6phfPGvJBwbYU9L81tqqwVwcJAknKXX92I692dgLsLnEaWDgFfxdZz/1LgXrwPljIPh68bSOzFmpFwhFMCwWZpuKBnOQjKv386nrQMrwt4q5ZZd3bjdzrOSYxyTladE91cz1UTvEfMkeQrhSLOXlqnVYyWFrAWGRGczrDIMy9NsAKwznsYJCI77ClkbZKQH0xS163hST4vMDO2UV2LNcydqsdWVlE4xdZXk9wEqDhVC0joQ== X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2017 02:42:24.6789 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2523 Archived-At: Cc: "draft-ietf-tcpm-cubic@tools.ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-cubic-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Jan 2017 02:42:34 -0000 Thank you very much, Michael! This is very helpful! We will revise the draft according to your editorial suggestions. Regarding the last question on the interaction of CUBIC with huge buffers, yes, CUBIC, as a loss-based (not delay-based) algorithm, fills router buffers (large or small) until there is a packet loss. But I guess we should not say that CUBIC increases the delay for other connections, because that depends on whether other connections are loss based or delay based. If other connections are also loss based, they themselves also fill router buffers. Thanks Lisong On 1/7/2017 5:50 PM, Scharf, Michael (Nokia - DE) wrote: > Hi all, > > As individual contributor to TCPM I have read draft-ietf-tcpm-cubic-03. To me, the technical content is by and large ready to move forward. > > I have some editorial suggestions, which would in my personal opinion improve the document. Also, I have one question on the interaction of CUBIC with huge buffers. > > > 1/ Abstract > > To me the abstract is a bit long and the historical (?) reference to BIC-TCP could easily be moved e.g. to the introduction. A shorter abstract would e.g. be: > > CUBIC is an extension of the current TCP congestion control. The protocol > differs from the current TCP standards only in the congestion window > adjustment function in the sender side. In particular, it uses a > cubic function instead of a linear window increase of the current TCP > standards to improve scalability and stability under fast and long > distance networks. CUBIC and its predecessor algorithm have been adopted as > default by Linux and have been used for many years. This document provides a > specification of CUBIC to enable third party implementation and > to solicit the community feedback through experimentation on the > performance of CUBIC. This document does not replace the standard TCP > congestion control [RFC5681]. > > As the IESG typically reviews the meta-data of documents, I believe an explicit statement on the relationship to RFC5681 would be useful. This would be one potential wording. > > The remaining content currently in the abstract could e.g. be added to the Introduction. I assume Linux has switched to CUBIC many years ago, right? So, some wording could be... > > BIC-TCP, a predecessor of CUBIC, has been selected as default TCP congestion > control algorithm by Linux in the year 2005 and been used for several years > by the Internet community at large. CUBIC is using a similar window growth function > as BIC-TCP and is designed to be less aggressive and fairer to TCP in > bandwidth usage than BIC-TCP while maintaining the strengths of BIC- > TCP such as stability, window scalability and RTT fairness. > > CUBIC has already been deployed globally by Linux. Through > extensive testing in various Internet scenarios, we believe that > CUBIC is safe for testing and deployment in the global Internet. > > 2/ Section 1. Introduction > > To me the introduction is quite long and covers two different aspects: First, it provides context on the history of CUBIC, and second it provides a (non-normative) overview of the design principle. I believe both could be split into two parts, e.g., with a ToC like this: > > 1. Introduction > 2. Design principle of CUBIC > 3. Conventions > 4. CUBIC Congestion Control > ... > > (There are other options.) > > This would just be a reorganization of the text. At least some parts of the current introduction section assume that the reader has a pretty good understanding of congestion control and they are not really introductory, so this is why moving these description to a dedicated "design principles" section could make sense. But, similar like my comment on the abstract, this may be a question of personal preference only. > > Nit: Please expand "MIMD" on first use. > > 3/ Section 4. Discussion > > In order to explain the section structure in Section 4, it could perhaps help to refer to RFC 5033 again at the beginning of Section 4. > > 4/ Section 4.4. Investigating a Range of Environments > > Wouldn't it make sense to mention somewhere in the document, e.g. in Section 4.4, that CUBIC can fill large buffers, in particular large buffers with drop-tail, and that this can increase delay for other connections? > > This seems to be an inherent characteristic of high-speed congestion control algorithms only reacting to loss, and it will not matter if proper queue management is in place, but still I wonder if this aspect should be mentioned. > > Thanks > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Jan 8 03:22:28 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B01112940E for ; Sun, 8 Jan 2017 03:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.057 X-Spam-Level: X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBwOYXTWmyUQ for ; Sun, 8 Jan 2017 03:22:24 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC3A126D73 for ; Sun, 8 Jan 2017 03:22:24 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 1D38FDDBAD27A; Sun, 8 Jan 2017 11:22:18 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v08BMFjA021517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Jan 2017 11:22:18 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v08BLwq2001686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jan 2017 11:22:08 GMT Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.116]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Sun, 8 Jan 2017 12:22:02 +0100 From: "Scharf, Michael (Nokia - DE)" To: Lisong Xu , "tcpm@ietf.org" Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-cubic-03 Thread-Index: AdJpQN5YwjQW0dnbSkmfOOFXKa51kwAD5dYAABN+0JA= Date: Sun, 8 Jan 2017 11:22:01 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48C16DBD@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48C16A0C@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0fc3c3e0-7bdb-a108-03f8-e9bcee04724b@unl.edu> In-Reply-To: <0fc3c3e0-7bdb-a108-03f8-e9bcee04724b@unl.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tcpm-cubic@tools.ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-cubic-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Jan 2017 11:22:27 -0000 Hi Lisong, One scenario where this could IMHO matter is if CUBIC shares an over-buffer= ed bottleneck link with other app-limited applications. In that case, the o= ther app-limited connections only contribute very little to filling the buf= fer even if they run a loss-based algorithm, while CUBIC of course does wha= t a loss-based algorithm is expected to do. This delay increase by full buffers is not a CUBIC specific issue. Reno as = a loss-based algorithm obviously has this property, too. Yet, IMHO in high-= BDP scenarios CUBIC can fill the buffer much faster, and it backs off less,= so I suspect that there can be a difference to Reno, right? But I don't ha= ve any own data on the impact on latency to app-limited applications in ove= r-buffered scenarios, so I cannot comment on how relevant the effect really= is. And I don't ask for further data on this specific detail. But somehow I believe it could make sense to remind readers that loss-based= congestion control requires proper queue sizing and management. One or two= sentences just as a heads-up could be enough. Maybe also an informative re= ference to RFC 7567. This would probably more target those readers who don'= t have a strong congestion control background. Michael (entirely as individual contributor) > -----Original Message----- > From: Lisong Xu [mailto:xu@unl.edu] > Sent: Sunday, January 08, 2017 3:42 AM > To: Scharf, Michael (Nokia - DE); tcpm@ietf.org > Cc: draft-ietf-tcpm-cubic@tools.ietf.org > Subject: Re: [tcpm] Comments on draft-ietf-tcpm-cubic-03 >=20 > Thank you very much, Michael! This is very helpful! We will revise the > draft according to your editorial suggestions. >=20 > Regarding the last question on the interaction of CUBIC with huge > buffers, yes, CUBIC, as a loss-based (not delay-based) algorithm, fills > router buffers (large or small) until there is a packet loss. But I > guess we should not say that CUBIC increases the delay for other > connections, because that depends on whether other connections are loss > based or delay based. If other connections are also loss based, they > themselves also fill router buffers. >=20 > Thanks >=20 > Lisong >=20 >=20 > On 1/7/2017 5:50 PM, Scharf, Michael (Nokia - DE) wrote: > > Hi all, > > > > As individual contributor to TCPM I have read draft-ietf-tcpm-cubic-03.= To > me, the technical content is by and large ready to move forward. > > > > I have some editorial suggestions, which would in my personal opinion > improve the document. Also, I have one question on the interaction of CUB= IC > with huge buffers. > > > > > > 1/ Abstract > > > > To me the abstract is a bit long and the historical (?) reference to BI= C-TCP > could easily be moved e.g. to the introduction. A shorter abstract would = e.g. > be: > > > > CUBIC is an extension of the current TCP congestion control. The > protocol > > differs from the current TCP standards only in the congestion windo= w > > adjustment function in the sender side. In particular, it uses a > > cubic function instead of a linear window increase of the current T= CP > > standards to improve scalability and stability under fast and long > > distance networks. CUBIC and its predecessor algorithm have been ad= opted > as > > default by Linux and have been used for many years. This document > provides a > > specification of CUBIC to enable third party implementation and > > to solicit the community feedback through experimentation on the > > performance of CUBIC. This document does not replace the standard T= CP > > congestion control [RFC5681]. > > > > As the IESG typically reviews the meta-data of documents, I believe an > explicit statement on the relationship to RFC5681 would be useful. This w= ould > be one potential wording. > > > > The remaining content currently in the abstract could e.g. be added to = the > Introduction. I assume Linux has switched to CUBIC many years ago, right?= So, > some wording could be... > > > > BIC-TCP, a predecessor of CUBIC, has been selected as default TCP > congestion > > control algorithm by Linux in the year 2005 and been used for sever= al > years > > by the Internet community at large. CUBIC is using a similar window > growth function > > as BIC-TCP and is designed to be less aggressive and fairer to TCP = in > > bandwidth usage than BIC-TCP while maintaining the strengths of BIC= - > > TCP such as stability, window scalability and RTT fairness. > > > > CUBIC has already been deployed globally by Linux. Through > > extensive testing in various Internet scenarios, we believe that > > CUBIC is safe for testing and deployment in the global Internet. > > > > 2/ Section 1. Introduction > > > > To me the introduction is quite long and covers two different aspects: > First, it provides context on the history of CUBIC, and second it provide= s a > (non-normative) overview of the design principle. I believe both could be > split into two parts, e.g., with a ToC like this: > > > > 1. Introduction > > 2. Design principle of CUBIC > > 3. Conventions > > 4. CUBIC Congestion Control > > ... > > > > (There are other options.) > > > > This would just be a reorganization of the text. At least some parts of= the > current introduction section assume that the reader has a pretty good > understanding of congestion control and they are not really introductory,= so > this is why moving these description to a dedicated "design principles" > section could make sense. But, similar like my comment on the abstract, t= his > may be a question of personal preference only. > > > > Nit: Please expand "MIMD" on first use. > > > > 3/ Section 4. Discussion > > > > In order to explain the section structure in Section 4, it could perhap= s > help to refer to RFC 5033 again at the beginning of Section 4. > > > > 4/ Section 4.4. Investigating a Range of Environments > > > > Wouldn't it make sense to mention somewhere in the document, e.g. in Se= ction > 4.4, that CUBIC can fill large buffers, in particular large buffers with = drop- > tail, and that this can increase delay for other connections? > > > > This seems to be an inherent characteristic of high-speed congestion co= ntrol > algorithms only reacting to loss, and it will not matter if proper queue > management is in place, but still I wonder if this aspect should be menti= oned. > > > > Thanks > > > > Michael > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Jan 8 12:02:58 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EBE12987D for ; Sun, 8 Jan 2017 12:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx-IOeC_eXLC for ; Sun, 8 Jan 2017 12:02:55 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6292129476 for ; Sun, 8 Jan 2017 12:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UAbTHEs26AYLF/4z3e/mxLTHVNPTuQbH6GZa1o89K2w=; b=B4LbQJIVBWEIYJoWieOuQ2MLL1aR/d/V/JE6OULzJStkvWIgffcMHEBCrn585AFeh8GWcZ0d9UhY9IxQD6SUFUov/wulULR4hMGsKzf4J2zCi1H/BQpWg+ujulU3c8yNpRmspn1buIKCY5+8aynBdG0idGBdJOTSTH5ORofJGkQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.164] (97.98.140.59) by BN6PR08MB2516.namprd08.prod.outlook.com (10.172.147.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Sun, 8 Jan 2017 20:02:52 +0000 To: "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D48C16A0C@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0fc3c3e0-7bdb-a108-03f8-e9bcee04724b@unl.edu> <655C07320163294895BBADA28372AF5D48C16DBD@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <0cbf8259-6c67-e6f9-0029-12f56a49f2be@unl.edu> Date: Sun, 8 Jan 2017 14:02:52 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D48C16DBD@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: SN1PR12CA0009.namprd12.prod.outlook.com (10.162.96.147) To BN6PR08MB2516.namprd08.prod.outlook.com (10.172.147.138) X-MS-Office365-Filtering-Correlation-Id: 7bdcfc3b-4e6b-4d35-85e2-08d4380154d2 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR08MB2516; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 3:dnsMwQL94OSZ+mAEiXHBK+8nPdaHcuIQiZV7Iqq0V+0OD+DfyNEECVD63qDsMl//Wgz+5rKq85WvX/5R59aiY/utUVJ7E41xPtu7Pvnlk0Vs6Y8uwol2Kqg2s2u51hsXc3UDlSrflRdAjc/PmN43i8X46q7ERavIJpCXPTZE85q9hJRPZxx1MEZv5Bu5p+PKQzQYhgD3eZ5wN9pFK50PYb2tvsHIRjj7iWRtfz/Y60U+UEA0zab73epVUUlfTj55A9chqclpBGBsywK6Fp+O5A== X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 25:3w3Gi08A065eQUQe1eDV+PgTUW+cktT6bHMn+dQHdCkmwZM7m5zziPin+wX7ZcVm6ve3dxIzq/5QwSRo3am8Y62J2wi+L9i2uY2mCVtMatCsf0Wrt0kXcxKw/Y8kqHThMEI2F8OytJlTK+xkEwUbp3eKnKg1bskNLIC4mdNgNjjKetymv7hykHweGSupQ6otqwjvmScB8xfldbW9sUpeSZeA7GVZK9tWDpkS0HXeiX1Jc5jx+RkRlQ3p8M+biq2MkH/CJqjszGqFaXVnH/MdQIV211/jSxMeRnFJmnV1Gq7FJhlW7jO2DSNjOW4Hahh9MfpjM9wISfNzEPfC3K88LVEo0zY9jswQnnK2r1C1O/0pfYvyPaWv4sELcSscM8VTwcQTbCxCz2yHjEzMupam5aWzn/zAJeaAgPcsULUkg1vjA1zdXU7I2wUt+PsRJxN9oLds1FOf/gP0WgMeYeq8XEIB35e3h2r0+4NV47/9fT792adCx2k/ZygVzSKhOk1pUjCwhWfBDsnwdP6mlCo2qiFTZsBPjhrPGsg+psaBiHRjSClRgyLRFEkZIuGqV9KvN9dtRmbm53/JMqNcBZVMwPHEWbkR5vgPYaweiQYPATx77seYR/vieKE62M41EMlFgQnYPBDpG1EQMPMYA21dokv0Xo3UN4+VdV2Zxjwy8svzcBl+iXF2DKgZTr4tavGq/luluAWFSHLuynKheKyghVJPjDaciUy7plPWp+eg49wnTd2GD3bUYfVRMaVRfh1QVDNlnxjTZH8SN4GoNYVUutkGL7FIYp31/N+AxcuaqRbgCtQrXpzIi09iqRPjF/MOfuSnXz8X6yR04XJRhCpVoA== X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 31:rEHYw37TOGsSWh4tU5WBUccdxI7LVHrM0BM5N4fZqdDm1xfu0V9MdLuu9Ua4/uhCwq2QbHPt4RnaLBDZ5VWPQDyPbzV+/eoUF9aBtsJw5X21liRQ6iB4k7I9SkHDzY9xuLxZFW7w8G8QUt8Z7n5PJKTN81J6BzCxTlgWvdvs3RvXgHvmqHGlMeXlURMDiRv9mLAkvhVAbMNNYRj7UIPpjuU0yvL6K/wGQYN5Jmf0YEu7pd2LcqmvcK4fU1LtDhTMl8P7ffZEP8E7t1EuriVVuRcmYC4E3JYp4NAsFDS1bFE=; 20:xW+TfbUal/CJRghuVeRmr45mBa5dSIKwfZJbd4yKWzxj/y+ujJ3Ef8tJ19YfstWWgpOw3y1HOHs0owBGzFMFdjX9JAuYjtt6a3k6Kmr4EKLpahhROKh8Npm2AXbv14gTl0OIE0bgihkVhsIstlva9/Zw3nnaW6rGalpfAiaa2PioBDPGv7xCbxbjHjTS/f8JqiMtmB07tkOr3c853f5143HoDNny41We7AhYb59zFAaJZDyeZJYxB0ZMWoAv0SXE3G1jTZBidE/zMXOkVheErKi3ohGdtvhWQfLdDkDJQML7zXlIcBYFrrsFE85jSbbZGacYz2w9eC1U087lr17q+3mniTcWuSv3LUDODs9Wp0yYz/Uef6oEH0jmc4IHDD9QdTI46d75yze/7iloKxj3qbTw1rc2G92PLBDrPsXUNtxJjuMos6ZoNYVCf9bZW8IHw3wNQrvGetDLE3Dh9kjCn1hhfLf81RPZG9hgLqOubLbb8qlzJtJZD/ocMCKB5Cm/ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN6PR08MB2516; BCL:0; PCL:0; RULEID:; SRVR:BN6PR08MB2516; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 4:HsOw8fZkwQHKuN5TUj+7GHP25qPT0M+mWZ0iwF/eFFITFeMU5ULCN1GmcHU77ZvsJZVRy03BjCgKVk1qfEX+zDQzffEc6VkZnyZfeqikXgJPh8Gkp3S2vPGIfbe9+hmsIkjwX064cWcwb3B+Tq4ri5+fikvjw3e3atU+zPURjGVF1EJqAiNGMpCwl+W53DKf+rCYdmYyfw1jpQpvgNZ6SGuImcYxB04GYVjfhS3AePjQln1simN9lwHD/XxtdPTN2o2mDw3PHRuc3jQnzLUQ5Vpyabe8HXEekv/5k+0prcSMo291sztaKXx+dM759zQLOMwElRMIThNuiM5SKwsfkr+N4Kky5CWYtRCfN318HdaFxVdW7HO5ot7O1GwyAvh4z3aUgxoF6dgJnhNmViV2H2bMIVTiKHdC+CifiNVHbNcHvy+kPBFfBD0FFiSwanodDBnnJPDVkIxCAM2DUYc+WmYOBBv2eJc031msi99Br6zkEshW/kXnv4/WE8zkRu7+YXkbLUor03UXIdIg2bdnxN8zMfXaYv4maubeIMz478c31BlmXy2NhnfsD+lY+mrU0uXgyHTW/TVKbmp6iK2CBU3Biijv1sALb2FLjGet0nWJFzBl1OmFtiInVSrugTCD+dqPRN6DQBKGGe36HHllOQ== X-Forefront-PRVS: 0181F4652A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(24454002)(53754006)(377454003)(13464003)(199003)(45984002)(189002)(54094003)(5660300001)(50986999)(3846002)(64126003)(77096006)(25786008)(76176999)(7736002)(105586002)(305945005)(65826007)(54356999)(36756003)(92566002)(42186005)(6116002)(47776003)(229853002)(230700001)(189998001)(2501003)(38730400001)(6486002)(83506001)(68736007)(86362001)(81156014)(97736004)(23746002)(88552002)(66066001)(31686004)(2906002)(65806001)(65956001)(2950100002)(6306002)(90366009)(81166006)(4001350100001)(75432002)(31696002)(8676002)(117156001)(106356001)(230783001)(4326007)(5001770100001)(50466002)(33646002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR08MB2516; H:[192.168.0.164]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BN6PR08MB2516; 23:Qe/1AgsV7eAYN5Q8BPRM3AyhXU12QH53Hbu6t?= =?Windows-1252?Q?S+xPF7JeRhxT/krQLJJ1+HOug5NRuBwLrynobItWzGpMVToiUdTFYKtC?= =?Windows-1252?Q?eX2ZPReUtlzxZmeXu9/8F2Dr+OeLw7hTOoTaK1BEUHjTJ1051XdUuWzg?= =?Windows-1252?Q?UGAcuVsOGV/Xx/ujJQ9WTBQOPvmnn015N2sf0rAW28TWjutZfGujKEVN?= =?Windows-1252?Q?tceRA3Sq1cKvrod0Roe1LzoK86GZtfaZDJeRNXckpW27UVdYjmSw3+4G?= =?Windows-1252?Q?OZdvAhO0Ymch2fxBLFjB0qVkLvzOzx43m7LJbVKqQPp+g8qPIz/Ur3H2?= =?Windows-1252?Q?tLCgxeyqsu4LCtjuYdBv97P4l1VhZp/sRTuR1nqdkFW2QBQ0lYDID36V?= =?Windows-1252?Q?EEy71BS/m8UXo6vxS9E+pq7nMMIetAHuF5+Lh8gGwGi/gkG6XojbHu3T?= =?Windows-1252?Q?1r0g3ex/WpVBLXdQrx5Q5dUuVuwJGYJA0qU55z9LoHfLnVjILacDw1fu?= =?Windows-1252?Q?MvDvrvqc1p32vJVrmIF6BhBdtHt+6RDNBArYT/d1mbK+Uk7K7d2LFC8o?= =?Windows-1252?Q?dlsrbY35JRunhuhVAjcSey2LINas5oaHTDdanlpAtnB3t5gKweMaCYMx?= =?Windows-1252?Q?YsTlvPvBYeJsc+AiGGGujt9qkXbK9zFKxo9q4veEHyyqOg31xcanJIc1?= =?Windows-1252?Q?seWp9DRZEMoi7xXrJ8qKI3A58z49h3j7jFFjDaHrqV3KEQTQjxuVK+BD?= =?Windows-1252?Q?OrjyPYXGmRNVJMUpdB2tiCq+prnfqn5EF/gwOgY08QeqkJpM5r2CQEE1?= =?Windows-1252?Q?zNBvq0m0PZSH8kXh25hn8KXoprKcg5iSl1vamrDnbP1HHWUQRkHRcguF?= =?Windows-1252?Q?1rxHeBQocWwAClDy/ibQbOyfMD7w3GXCHmg9z77AOOIbMb4FM3zOpzPi?= =?Windows-1252?Q?RkGql6pzBrZbEzeZqIHT0W5GKkpyWtJIowSh5WeqTeW2YmTHEwvNEWKh?= =?Windows-1252?Q?vm6qFCISyshs7cGotVz/jWCZMQpMfhCE26BHHwTLygpfF1ZSLYiZUo31?= =?Windows-1252?Q?0xoySyX8xfxgMRp2qVFK40FG8Vtk2n0JxeVVn11N2Zh1ybWLIqk1idsu?= =?Windows-1252?Q?eWdxVf7VaakoJxF0420FyET2lr/4o24FzBCBtZFPvHxGLME5+WosI2T4?= =?Windows-1252?Q?dogb4F39P/hEZViWVOaw1gAxT63pos+N3aq056DIsFSk48REbE+1eBBG?= =?Windows-1252?Q?+ecv0/kjeWdXS0Y9lp/T64r0jzCqrJhZf+7q1OQF/aQwQ0WWTELplYFK?= =?Windows-1252?Q?TWkI7DMgEYfnUJHQqZrZarFySflvu8tN3vu6jIzvw7VRdRI2F72cyJhH?= =?Windows-1252?Q?nxTnxQbiJep8G8ACnCozaAMxfuzfLqsr6ZZWLQpxElWQlSROMk6ch617?= =?Windows-1252?Q?mfejMaEBpBqH063u/Tu6oFTJDaQd2FVKArppp/A6RfVIciuc5CcFZ4l7?= =?Windows-1252?Q?LmhFNH3XYHkbRsgrXnz8eaI/Py8ISE5sg6t7PWFikt0S7s204Mo37g47?= =?Windows-1252?Q?RDkAvmtR1rccYAJte4RAmNXsQYMvl/2BQNOdVW3wxfRjYTneSZHYO77N?= =?Windows-1252?Q?X4kEit3QJJhTeXSVkwAZ4k+GHkLpmUJhPixQ+qKvqfC?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 6:1POns2S4UpdaYAVedJ5ItM7qoyzef+33xiqElQXRZi41p5yllbvMpa+Puyal+Lxn3H8znJ8cO7EroeI5ACscK6rmdyuq9vKF66u3/szMbeewyI6kWmHOtJjUEU322xpAgw9C9oU/6zgwePSmPgI/DZhKqRRzU8zvwbOySScc8lmZH+pWvgSlZ86xXgeP+qxa+BzITawAIuJAcnNavGWAZf9noFpm7KSVmdHqv7Lg0CjVqqkabBRYcWq8eSGqBBSogyHt6AlN3qs7TTlc4/353GfZ8OAn9SNWQQhVJLYbe2bkF9cuzdbc8Y8B/dW6vU3OinFDz7MsUJgJyU+BbVxFt2C6X5FK3LTvxFb0cfIHzMZZX/T8im5lfj0j9j649r1lA5zxokz4JxxPVs/df+zp2jX/B4Y0beCLSb2mIahpf2Y=; 5:MQGnb1HZA6L3yiaHiGrMaA5rT5z1GpwVmiAdabPethxfZWqiy6LPNffF6VsKFHTnHXowwGsRAdjl+SfRDFuzPt7WVlW50CvXbC68B3ajRcQOD60u+tdyQgwEwxlQgLvOC09SOjelV/ZLXeE953B/y8AgFIp63s82i+iS7/qpqAQ=; 24:ewNLPYtDz6bNhXj1yBKF1dEMS7elNkARFfnC2K5IqtKSTM2BE/Xr4QyCvih4/FLGcH2Z3jqjm9S4tWDEoCqQ9Jh+ClesJtpXu+rLEJC3kBw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 7:b9DMffT2y9631udgFHM3JKuOIr22XYp8zRbWdoav4Yxs47rME0HWrKO/cLIIX3Ydufv8bO3N52HN8KYoawmJvEqUvqrTzWsI76iogsh3KXWWlkQynUQhIvBAuJxmgM/8Hw/klBAtJVg8GcoriDXTjPleuA/OnuH3DR10cX/AxGL7uXCtfFdBTyXg65N5oezXYljSgfLgmx05rKcyGLZUGY+fNOImREze4y/FmQk+kF4yz4iU/Vaeia2ltX5HqYDhXQFJ1hW74Jy5pEo+uCEaal8lTn9+zQYIwzDxhK8HeovpA4R2h3wEGIN9rXEhs2fBpEbeUEttyQvP4Owukhdyo15v1+O7+/gsqagTPIhbFzH11zFVBEd6AGT/GoV7P9WisLhlXJNehQZ702c+7lJSVkg3uvEyj3lzPz/dPbi0C9/NcX81kz0tAdTYyOcpzTN1wZfQn1bJM1yODwE+bX5vOw== X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2017 20:02:52.9823 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR08MB2516 Archived-At: Cc: "draft-ietf-tcpm-cubic@tools.ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-cubic-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Jan 2017 20:02:57 -0000 Got it. We will briefly mention that in the draft. Thanks, Michael! Lisong On 1/8/2017 5:22 AM, Scharf, Michael (Nokia - DE) wrote: > Hi Lisong, > > One scenario where this could IMHO matter is if CUBIC shares an over-buffered bottleneck link with other app-limited applications. In that case, the other app-limited connections only contribute very little to filling the buffer even if they run a loss-based algorithm, while CUBIC of course does what a loss-based algorithm is expected to do. > > This delay increase by full buffers is not a CUBIC specific issue. Reno as a loss-based algorithm obviously has this property, too. Yet, IMHO in high-BDP scenarios CUBIC can fill the buffer much faster, and it backs off less, so I suspect that there can be a difference to Reno, right? But I don't have any own data on the impact on latency to app-limited applications in over-buffered scenarios, so I cannot comment on how relevant the effect really is. And I don't ask for further data on this specific detail. > > But somehow I believe it could make sense to remind readers that loss-based congestion control requires proper queue sizing and management. One or two sentences just as a heads-up could be enough. Maybe also an informative reference to RFC 7567. This would probably more target those readers who don't have a strong congestion control background. > > Michael (entirely as individual contributor) > > >> -----Original Message----- >> From: Lisong Xu [mailto:xu@unl.edu] >> Sent: Sunday, January 08, 2017 3:42 AM >> To: Scharf, Michael (Nokia - DE); tcpm@ietf.org >> Cc: draft-ietf-tcpm-cubic@tools.ietf.org >> Subject: Re: [tcpm] Comments on draft-ietf-tcpm-cubic-03 >> >> Thank you very much, Michael! This is very helpful! We will revise the >> draft according to your editorial suggestions. >> >> Regarding the last question on the interaction of CUBIC with huge >> buffers, yes, CUBIC, as a loss-based (not delay-based) algorithm, fills >> router buffers (large or small) until there is a packet loss. But I >> guess we should not say that CUBIC increases the delay for other >> connections, because that depends on whether other connections are loss >> based or delay based. If other connections are also loss based, they >> themselves also fill router buffers. >> >> Thanks >> >> Lisong >> >> >> On 1/7/2017 5:50 PM, Scharf, Michael (Nokia - DE) wrote: >>> Hi all, >>> >>> As individual contributor to TCPM I have read draft-ietf-tcpm-cubic-03. To >> me, the technical content is by and large ready to move forward. >>> I have some editorial suggestions, which would in my personal opinion >> improve the document. Also, I have one question on the interaction of CUBIC >> with huge buffers. >>> >>> 1/ Abstract >>> >>> To me the abstract is a bit long and the historical (?) reference to BIC-TCP >> could easily be moved e.g. to the introduction. A shorter abstract would e.g. >> be: >>> CUBIC is an extension of the current TCP congestion control. The >> protocol >>> differs from the current TCP standards only in the congestion window >>> adjustment function in the sender side. In particular, it uses a >>> cubic function instead of a linear window increase of the current TCP >>> standards to improve scalability and stability under fast and long >>> distance networks. CUBIC and its predecessor algorithm have been adopted >> as >>> default by Linux and have been used for many years. This document >> provides a >>> specification of CUBIC to enable third party implementation and >>> to solicit the community feedback through experimentation on the >>> performance of CUBIC. This document does not replace the standard TCP >>> congestion control [RFC5681]. >>> >>> As the IESG typically reviews the meta-data of documents, I believe an >> explicit statement on the relationship to RFC5681 would be useful. This would >> be one potential wording. >>> The remaining content currently in the abstract could e.g. be added to the >> Introduction. I assume Linux has switched to CUBIC many years ago, right? So, >> some wording could be... >>> BIC-TCP, a predecessor of CUBIC, has been selected as default TCP >> congestion >>> control algorithm by Linux in the year 2005 and been used for several >> years >>> by the Internet community at large. CUBIC is using a similar window >> growth function >>> as BIC-TCP and is designed to be less aggressive and fairer to TCP in >>> bandwidth usage than BIC-TCP while maintaining the strengths of BIC- >>> TCP such as stability, window scalability and RTT fairness. >>> >>> CUBIC has already been deployed globally by Linux. Through >>> extensive testing in various Internet scenarios, we believe that >>> CUBIC is safe for testing and deployment in the global Internet. >>> >>> 2/ Section 1. Introduction >>> >>> To me the introduction is quite long and covers two different aspects: >> First, it provides context on the history of CUBIC, and second it provides a >> (non-normative) overview of the design principle. I believe both could be >> split into two parts, e.g., with a ToC like this: >>> 1. Introduction >>> 2. Design principle of CUBIC >>> 3. Conventions >>> 4. CUBIC Congestion Control >>> ... >>> >>> (There are other options.) >>> >>> This would just be a reorganization of the text. At least some parts of the >> current introduction section assume that the reader has a pretty good >> understanding of congestion control and they are not really introductory, so >> this is why moving these description to a dedicated "design principles" >> section could make sense. But, similar like my comment on the abstract, this >> may be a question of personal preference only. >>> Nit: Please expand "MIMD" on first use. >>> >>> 3/ Section 4. Discussion >>> >>> In order to explain the section structure in Section 4, it could perhaps >> help to refer to RFC 5033 again at the beginning of Section 4. >>> 4/ Section 4.4. Investigating a Range of Environments >>> >>> Wouldn't it make sense to mention somewhere in the document, e.g. in Section >> 4.4, that CUBIC can fill large buffers, in particular large buffers with drop- >> tail, and that this can increase delay for other connections? >>> This seems to be an inherent characteristic of high-speed congestion control >> algorithms only reacting to loss, and it will not matter if proper queue >> management is in place, but still I wonder if this aspect should be mentioned. >>> Thanks >>> >>> Michael >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jan 9 11:38:27 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEC9129DC1 for ; Mon, 9 Jan 2017 11:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikAmmvKVTIiJ for ; Mon, 9 Jan 2017 11:38:24 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F98129DC0 for ; Mon, 9 Jan 2017 11:38:23 -0800 (PST) Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A7AC527847F for ; Tue, 10 Jan 2017 04:38:21 +0900 (JST) Received: by mail-vk0-f49.google.com with SMTP id t8so14287978vke.3 for ; Mon, 09 Jan 2017 11:38:21 -0800 (PST) X-Gm-Message-State: AIkVDXKg6vDv9F8SUBIwomANOBohZv2MI2Vf7kTpMxt6w+E2k9m2EXIwM4JFmDwA3nfobaWX5JiYewEMevECNg== X-Received: by 10.31.92.9 with SMTP id q9mr9861643vkb.88.1483990700213; Mon, 09 Jan 2017 11:38:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.145 with HTTP; Mon, 9 Jan 2017 11:38:19 -0800 (PST) In-Reply-To: <20170106211839.GA69857@verdi> References: <20170106211839.GA69857@verdi> From: Yoshifumi Nishida Date: Mon, 9 Jan 2017 11:38:19 -0800 X-Gmail-Original-Message-ID: Message-ID: To: John Leslie Content-Type: multipart/alternative; boundary=001a114e1702894d610545ae8236 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:38:26 -0000 --001a114e1702894d610545ae8236 Content-Type: text/plain; charset=UTF-8 Hello, On Fri, Jan 6, 2017 at 1:18 PM, John Leslie wrote: > Yoshifumi Nishida wrote: > > > > > > As we have discussed during Seoul meeting, the chairs decided to start > > > running a call for adoption of draft-khademi-tcpm- > alternativebackoff-ecn. > > > > > > We would like to confirm that the TCPM community agrees to: > > > > > > * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working > > > group item to publish it as an experimental RFC. > > > * add a corresponding milestone to the TCPM charter. > > > > > > Aug 2017 Submit document on alternative backoff with ECN > algorithm > > > to the IESG for publication as an Experimental RFC > > I am happy to see an experiment proposed. > > But I don't think this document adequately describes the experiment: > thus I'd rather see agreement on a few things before we adopt this. > > - what is the duration of the experiment? > > - how will the results be evaluated? > > - (how will we even tell which senders are experimenting?) > hmm. I think it's a valid point for an experimental draft. But, I'm not sure if we need to agree on them before the adoption. We might want to know generic milestone before the adoption, but I'm not sure if we need to see the details. Thanks, -- Yoshi --001a114e1702894d610545ae8236 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

On Fri, Jan 6, 2017 at 1:18 PM, John Leslie <= ;john@jlc.net> wrote:
Yoshifumi Nis= hida <nishida@sfc.wide.ad.jp> wrote:
> >
> > As we have discussed during Seoul meeting, the chairs decided to = start
> > running a call for adoption of draft-khademi-tcpm-alternativ= ebackoff-ecn.
> >
> > We would like to confirm that the TCPM community agrees to:
> >
> >=C2=A0 =C2=A0* adopt draft-khademi-tcpm-alternativebackoff-ec= n as a TCPM working
> > group item to publish it as an experimental RFC.
> >=C2=A0 =C2=A0* add a corresponding milestone to the TCPM charter.<= br> > >
> >=C2=A0 =C2=A0 =C2=A0 Aug 2017=C2=A0 Submit document on alternative= backoff with ECN algorithm
> > to the IESG for publication as an Experimental RFC

=C2=A0 =C2=A0I am happy to see an experiment proposed.

=C2=A0 =C2=A0But I don't think this document adequately describes the e= xperiment:
thus I'd rather see agreement on a few things before we adopt this.

- what is the duration of the experiment?

- how will the results be evaluated?

- (how will we even tell which senders are experimenting?)
=

hmm. I think it's a valid point for an experimental= draft.=C2=A0
But, I'm not sure if we need to agree on them b= efore the adoption.=C2=A0
We might want to know generic milestone= before the adoption, but I'm not sure if we need to see the details.

Thanks,
--
Yoshi
--001a114e1702894d610545ae8236-- From nobody Tue Jan 10 04:42:07 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9C129C14 for ; Tue, 10 Jan 2017 04:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORGjMSX3llvN for ; Tue, 10 Jan 2017 04:42:05 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2CC129530 for ; Tue, 10 Jan 2017 04:42:05 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1A3A59087E7; Tue, 10 Jan 2017 07:42:04 -0500 (EST) Date: Tue, 10 Jan 2017 07:42:04 -0500 From: John Leslie To: Yoshifumi Nishida Message-ID: <20170110124204.GB10525@verdi> References: <20170106211839.GA69857@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 12:42:06 -0000 Yoshifumi Nishida wrote: > On Fri, Jan 6, 2017 at 1:18 PM, John Leslie wrote: >... >> I am happy to see an experiment proposed. >> >> But I don't think this document adequately describes the experiment: >> thus I'd rather see agreement on a few things before we adopt this. >> >> - what is the duration of the experiment? >> >> - how will the results be evaluated? >> >> - (how will we even tell which senders are experimenting?) > > hmm. I think it's a valid point for an experimental draft. > But, I'm not sure if we need to agree on them before the adoption. > We might want to know generic milestone before the adoption, but I'm not > sure if we need to see the details. Obviously, any language covering my three questions may be revised after adoption. But I find the total absence of language about these three worrysome. When I asked for "agreement" I didn't intend formal "consensus" -- just that the proposal should address those three. Without addressing them, it looks like it's intended as Proposesd Standard. -- John Leslie From nobody Wed Jan 11 00:23:10 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502AB129A8E for ; Wed, 11 Jan 2017 00:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnmfhMOcP74z for ; Wed, 11 Jan 2017 00:23:07 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2434B129A8D for ; Wed, 11 Jan 2017 00:23:06 -0800 (PST) Received: from mail-ua0-f171.google.com (mail-ua0-f171.google.com [209.85.217.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6DF002783DE for ; Wed, 11 Jan 2017 17:23:04 +0900 (JST) Received: by mail-ua0-f171.google.com with SMTP id i68so401277719uad.0 for ; Wed, 11 Jan 2017 00:23:04 -0800 (PST) X-Gm-Message-State: AIkVDXKBF/WCvA4OIdLoRichEfdbXnkBwJSsayQNlBM+IbW+0bt5XbRDT7nNeTRpNsOqY2LvdbwZRCALjK+9AQ== X-Received: by 10.176.66.66 with SMTP id i60mr3928474uai.131.1484122982960; Wed, 11 Jan 2017 00:23:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.145 with HTTP; Wed, 11 Jan 2017 00:23:02 -0800 (PST) In-Reply-To: <20170110124204.GB10525@verdi> References: <20170106211839.GA69857@verdi> <20170110124204.GB10525@verdi> From: Yoshifumi Nishida Date: Wed, 11 Jan 2017 00:23:02 -0800 X-Gmail-Original-Message-ID: Message-ID: To: John Leslie Content-Type: multipart/alternative; boundary=94eb2c0939ce3401b30545cd4f9c Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:23:09 -0000 --94eb2c0939ce3401b30545cd4f9c Content-Type: text/plain; charset=UTF-8 Hi John, On Tue, Jan 10, 2017 at 4:42 AM, John Leslie wrote: > Yoshifumi Nishida wrote: > > On Fri, Jan 6, 2017 at 1:18 PM, John Leslie wrote: > >... > >> I am happy to see an experiment proposed. > >> > >> But I don't think this document adequately describes the experiment: > >> thus I'd rather see agreement on a few things before we adopt this. > >> > >> - what is the duration of the experiment? > >> > >> - how will the results be evaluated? > >> > >> - (how will we even tell which senders are experimenting?) > > > > hmm. I think it's a valid point for an experimental draft. > > But, I'm not sure if we need to agree on them before the adoption. > > We might want to know generic milestone before the adoption, but I'm not > > sure if we need to see the details. > > Obviously, any language covering my three questions may be revised > after adoption. > > But I find the total absence of language about these three worrysome. > > When I asked for "agreement" I didn't intend formal "consensus" -- > just that the proposal should address those three. Without addressing > them, it looks like it's intended as Proposesd Standard. > Thanks. It makes senses to me. I believe these points should be addressed in the new version. Do the authors feel comfortable with it? any concerns? I think I saw enough supports for the draft while I don't see any objections. I am thinking that it can be adopted if the authors can guarantee to address these points in a new version. Thanks, -- Yoshi --94eb2c0939ce3401b30545cd4f9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi J= ohn,

O= n Tue, Jan 10, 2017 at 4:42 AM, John Leslie <john@jlc.net> wrot= e:
Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote: > On Fri, Jan 6, 2017 at 1:18 PM, John Leslie <john@jlc.net> wrote:
>...
>> I am happy to see an experiment proposed. >>
>> But I don't think this document adequately describes the exper= iment:
>> thus I'd rather see agreement on a few things before we adopt = this.
>>
>> - what is the duration of the experiment?
>>
>> - how will the results be evaluated?
>>
>> - (how will we even tell which senders are experimenting?)
>
> hmm. I think it's a valid point for an experimental draft.
> But, I'm not sure if we need to agree on them before the adoption.=
> We might want to know generic milestone before the adoption, but I'= ;m not
> sure if we need to see the details.

=C2=A0 =C2=A0Obviously, any language covering my three questions may= be revised
after adoption.

=C2=A0 =C2=A0But I find the total absence of language about these three wor= rysome.

=C2=A0 =C2=A0When I asked for "agreement" I didn't intend for= mal "consensus" --
just that the proposal should address those three. Without addressing
them, it looks like it's intended as Proposesd Standard.

Thanks. It makes senses to me.=C2=A0 I believe these = points should be addressed in the new version.
Do the authors fee= l comfortable with it? any concerns?

I think I saw= enough supports for the draft while I don't see any objections.
<= div>I am thinking that it can be adopted if the authors can guarantee to ad= dress these points in a new version.=C2=A0

Thanks,= =C2=A0
--
Yoshi

--94eb2c0939ce3401b30545cd4f9c-- From nobody Wed Jan 11 00:33:41 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2BA129A8A for ; Wed, 11 Jan 2017 00:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y88dJvwEfDNm for ; Wed, 11 Jan 2017 00:33:36 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D365C120725 for ; Wed, 11 Jan 2017 00:33:35 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id B40841B00191; Wed, 11 Jan 2017 10:31:21 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 11 Jan 2017 08:33:33 -0000 Message-ID: In-Reply-To: References: <20170106211839.GA69857@verdi> <20170110124204.GB10525@verdi> Date: Wed, 11 Jan 2017 08:33:33 -0000 From: gorry@erg.abdn.ac.uk To: "Yoshifumi Nishida" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:33:39 -0000 Hi John, Yoshifumi, and others, I haver some thoughts on these comments, see below. > Hi John, > > On Tue, Jan 10, 2017 at 4:42 AM, John Leslie wrote: > >> Yoshifumi Nishida wrote: >> > On Fri, Jan 6, 2017 at 1:18 PM, John Leslie wrote: >> >... >> >> I am happy to see an experiment proposed. >> >> >> >> But I don't think this document adequately describes the experiment: >> >> thus I'd rather see agreement on a few things before we adopt this. >> >> >> >> - what is the duration of the experiment? >> >> >> >> - how will the results be evaluated? >> >> >> >> - (how will we even tell which senders are experimenting?) >> > >> > hmm. I think it's a valid point for an experimental draft. >> > But, I'm not sure if we need to agree on them before the adoption. >> > We might want to know generic milestone before the adoption, but I'm >> not >> > sure if we need to see the details. >> >> Obviously, any language covering my three questions may be revised >> after adoption. >> >> But I find the total absence of language about these three worrysome. >> >> When I asked for "agreement" I didn't intend formal "consensus" -- >> just that the proposal should address those three. Without addressing >> them, it looks like it's intended as Proposesd Standard. >> > > Thanks. It makes senses to me. I believe these points should be addressed > in the new version. > Do the authors feel comfortable with it? any concerns? > > I think I saw enough supports for the draft while I don't see any > objections. > I am thinking that it can be adopted if the authors can guarantee to > address these points in a new version. > > Thanks, > -- > Yoshi > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > I agree there are many things that can be done when information is fed back about the reception of individual marks (as in Acc ECN), such as responding to multiple ECN marks within the same RTT, adjustments based on the rate of marking, etc. However, I think that such advanced reactions need to have the more accurate feedback. As one of the authors, I also agree we should try to bound the duration of the experiment, if we can. ABE is a simple change, and I’d hope could soon see deployment. ABE is a proposed change to the basic reaction when Marks are reported within a RTT - using only RFC3168 feedback (i.e., ECN-Echo). That’s why I think it is good that ABE can be taken forward in TCPM. In parallel to this work, I’d be interested to see *how* to best react after negotiating Accurate ECN, which I’d expect opens a much bigger (more exciting?) set of questions, is this part of what you are suggesting? - I’d expect this debate will likely follow in tsvwg as we discuss L4S and other new ideas for AQM and transport reactions. If it helps, we can offer to make this clearer in the ID (improving on what is said in section 3.2) and could note the context much earlier, since I expect much more will emerge about ECN after this is published). Gorry From nobody Wed Jan 11 05:31:55 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DCB129BF8 for ; Wed, 11 Jan 2017 05:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk61_4TicCN3 for ; Wed, 11 Jan 2017 05:31:51 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BD3129BF4 for ; Wed, 11 Jan 2017 05:31:51 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cRJ0G-000E8Q-Dp for tcpm@ietf.org; Wed, 11 Jan 2017 14:31:48 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cRJ0F-0003AZ-Q9; Wed, 11 Jan 2017 14:31:48 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Wed, 11 Jan 2017 14:31:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170106211839.GA69857@verdi> <20170110124204.GB10525@verdi> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 32 msgs/h 6 sum rcpts/h 36 sum msgs/h 8 total rcpts 50650 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.194, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 91152C6C5319C2A9EE3145C8E07FEA0F66B00D55 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -71 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 12050 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 13:31:53 -0000 > On 11 Jan 2017, at 09:23, Yoshifumi Nishida = wrote: >=20 > Hi John, >=20 > On Tue, Jan 10, 2017 at 4:42 AM, John Leslie wrote: > Yoshifumi Nishida wrote: > > On Fri, Jan 6, 2017 at 1:18 PM, John Leslie wrote: > >... > >> I am happy to see an experiment proposed. > >> > >> But I don't think this document adequately describes the = experiment: > >> thus I'd rather see agreement on a few things before we adopt this. > >> > >> - what is the duration of the experiment? > >> > >> - how will the results be evaluated? > >> > >> - (how will we even tell which senders are experimenting?) > > > > hmm. I think it's a valid point for an experimental draft. > > But, I'm not sure if we need to agree on them before the adoption. > > We might want to know generic milestone before the adoption, but I'm = not > > sure if we need to see the details. >=20 > Obviously, any language covering my three questions may be revised > after adoption. >=20 > But I find the total absence of language about these three = worrysome. >=20 > When I asked for "agreement" I didn't intend formal "consensus" -- > just that the proposal should address those three. Without addressing > them, it looks like it's intended as Proposesd Standard. >=20 > Thanks. It makes senses to me. I believe these points should be = addressed in the new version. > Do the authors feel comfortable with it? any concerns? For me, comfortable yes, concerns none :) > I think I saw enough supports for the draft while I don't see any = objections. > I am thinking that it can be adopted if the authors can guarantee to = address these points in a new version.=20 I have no problem to make that promise, I do think it's a very = reasonable request Cheers, Michael From nobody Wed Jan 11 11:16:44 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112DE12996C for ; Wed, 11 Jan 2017 11:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz9loXH6mXYU for ; Wed, 11 Jan 2017 11:16:41 -0800 (PST) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D7F12949F for ; Wed, 11 Jan 2017 11:16:40 -0800 (PST) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id v0BJGZYE025770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Jan 2017 06:16:35 +1100 To: tcpm@ietf.org References: <20170106211839.GA69857@verdi> <20170110124204.GB10525@verdi> From: grenville armitage Message-ID: <58768493.6000106@swin.edu.au> Date: Thu, 12 Jan 2017 06:16:35 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:16:43 -0000 On 01/12/2017 00:31, Michael Welzl wrote: >> On 11 Jan 2017, at 09:23, Yoshifumi Nishida wrote: >> [..] >> I think I saw enough supports for the draft while I don't see any objections. >> I am thinking that it can be adopted if the authors can guarantee to address these points in a new version. > I have no problem to make that promise, I do think it's a very reasonable request > +1 (as another co-author) cheers, gja From nobody Fri Jan 13 01:00:50 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8E6129B23 for ; Fri, 13 Jan 2017 01:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5URVP1um-svy for ; Fri, 13 Jan 2017 01:00:45 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29E3129AE6 for ; Fri, 13 Jan 2017 01:00:45 -0800 (PST) Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 08DFB278304 for ; Fri, 13 Jan 2017 18:00:43 +0900 (JST) Received: by mail-vk0-f48.google.com with SMTP id 137so29465862vkl.0 for ; Fri, 13 Jan 2017 01:00:42 -0800 (PST) X-Gm-Message-State: AIkVDXJwH2Jt7JnVtDf21hcjCg5yyjUejR9PQHZ/2F/hiCxhBtIUGZQxfVWY1KLN/QfUUO2jRHR39zEvkXLhHg== X-Received: by 10.31.218.68 with SMTP id r65mr8926534vkg.27.1484298041457; Fri, 13 Jan 2017 01:00:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.145 with HTTP; Fri, 13 Jan 2017 01:00:41 -0800 (PST) From: Yoshifumi Nishida Date: Fri, 13 Jan 2017 01:00:41 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07b01c8166920545f6112b Archived-At: Subject: [tcpm] WG acceptance of draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 09:00:48 -0000 --94eb2c07b01c8166920545f6112b Content-Type: text/plain; charset=UTF-8 Hello everyone, This e-mail confirms the WG acceptance of draft-khademi-tcpm-alternativebackoff-ecn. We appreciate lots of feedback and comments on the draft. Authors, when you submit the draft, please change the draft name to draft-ietf-tcpm-alternativebackoff-ecn. Thanks, -- tcpm co-chairs --94eb2c07b01c8166920545f6112b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,=C2=A0

This e-mail confirms the WG a= cceptance of=C2=A0draft-khademi-tcpm-alternativebackoff-ecn.
We appreci= ate lots of feedback and comments on the draft.

Authors, when y= ou submit the draft, please change the draft name to draft-ietf-tcpm-altern= ativebackoff-ecn.=C2=A0

Thanks,
--
tcpm co-chairs
--94eb2c07b01c8166920545f6112b-- From nobody Fri Jan 13 01:02:26 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44B3129AAC for ; Fri, 13 Jan 2017 01:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_tZK6Zsv79K for ; Fri, 13 Jan 2017 01:02:22 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD42B1294CC for ; Fri, 13 Jan 2017 01:02:21 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1cRxkZ-0007WM-JR for tcpm@ietf.org; Fri, 13 Jan 2017 10:02:19 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cRxkY-0002lh-SE for tcpm@ietf.org; Fri, 13 Jan 2017 10:02:19 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2017 10:02:18 +0100 References: <148426824447.2967.17423364285337799287.idtracker@ietfa.amsl.com> To: tcpm IETF list Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 50749 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.194, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A80DFEF1D1D687F5D0A3A116D2E97A7C09661EB8 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -71 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12090 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-2140bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 09:02:25 -0000 Dear all, Here's an update of our 2140bis draft; I'd like to request a short slot = (maybe 10 mins, like last time) to present this in Chicago, if possible. Cheers, Michael > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-touch-tcpm-2140bis-02.txt > Date: 13 Jan 2017 01:44:04 CET > To: Jianjie You , Joe Touch , = "Safiqul Islam" , Joseph Touch , = Michael Welzl > Resent-From: >=20 >=20 > A new version of I-D, draft-touch-tcpm-2140bis-02.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. >=20 > Name: draft-touch-tcpm-2140bis > Revision: 02 > Title: TCP Control Block Interdependence > Document date: 2017-01-12 > Group: Individual Submission > Pages: 23 > URL: = https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-02.txt > Status: = https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/ > Htmlized: = https://tools.ietf.org/html/draft-touch-tcpm-2140bis-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-2140bis-02 >=20 > Abstract: > This memo describes interdependent TCP control blocks, where part of > the TCP state is shared among similar concurrent or consecutive > connections. TCP state includes a combination of parameters, such as > connection state, current round-trip time estimates, congestion > control information, and process information. Most of this state is > maintained on a per-connection basis in the TCP Control Block (TCB), > but implementations can (and do) share certain TCB information > across connections to the same host. Such sharing is intended to > improve overall transient transport performance, while maintaining > backward-compatibility with existing implementations. The sharing > described herein is limited to only the TCB initialization and so > has no effect on the long-term behavior of TCP after a connection > has been established. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Tue Jan 17 00:11:20 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55FC1293FD for ; Tue, 17 Jan 2017 00:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJA7pU0QsynH for ; Tue, 17 Jan 2017 00:11:16 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB35126BF7 for ; Tue, 17 Jan 2017 00:11:15 -0800 (PST) Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1ED7F2784FC for ; Tue, 17 Jan 2017 17:11:14 +0900 (JST) Received: by mail-vk0-f44.google.com with SMTP id x75so87730563vke.2 for ; Tue, 17 Jan 2017 00:11:14 -0800 (PST) X-Gm-Message-State: AIkVDXLowxDPM2OOlmUZCYBPre1HJJEXnkLn0C5eGNSUTCRUTRy/CQrLDkbqvZG+w/+eUKr7xbMiZH4iI8qx0w== X-Received: by 10.31.218.68 with SMTP id r65mr17624080vkg.27.1484640672894; Tue, 17 Jan 2017 00:11:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.145 with HTTP; Tue, 17 Jan 2017 00:11:12 -0800 (PST) In-Reply-To: References: <148426824447.2967.17423364285337799287.idtracker@ietfa.amsl.com> From: Yoshifumi Nishida Date: Tue, 17 Jan 2017 00:11:12 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=94eb2c07b01ced6e32054645d730 Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-2140bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 08:11:19 -0000 --94eb2c07b01ced6e32054645d730 Content-Type: text/plain; charset=UTF-8 Hello, I remember that there were some discussions about the status of the draft. Whether this should be informational or BCP. ( https://tools.ietf.org/wg/tcpm/minutes?item=minutes-97-tcpm-00.html) Should we proceed it as an informational draft? Or, do we explore some ways to make it BCP? Thanks, -- Yoshi On Fri, Jan 13, 2017 at 1:02 AM, Michael Welzl wrote: > Dear all, > > Here's an update of our 2140bis draft; I'd like to request a short slot > (maybe 10 mins, like last time) to present this in Chicago, if possible. > > Cheers, > Michael > > > > Begin forwarded message: > > > > From: > > Subject: New Version Notification for draft-touch-tcpm-2140bis-02.txt > > Date: 13 Jan 2017 01:44:04 CET > > To: Jianjie You , Joe Touch , > "Safiqul Islam" , Joseph Touch , > Michael Welzl > > Resent-From: > > > > > > A new version of I-D, draft-touch-tcpm-2140bis-02.txt > > has been successfully submitted by Joe Touch and posted to the > > IETF repository. > > > > Name: draft-touch-tcpm-2140bis > > Revision: 02 > > Title: TCP Control Block Interdependence > > Document date: 2017-01-12 > > Group: Individual Submission > > Pages: 23 > > URL: https://www.ietf.org/internet-drafts/draft-touch-tcpm- > 2140bis-02.txt > > Status: https://datatracker.ietf.org/ > doc/draft-touch-tcpm-2140bis/ > > Htmlized: https://tools.ietf.org/html/draft-touch-tcpm-2140bis-02 > > Diff: https://www.ietf.org/rfcdiff? > url2=draft-touch-tcpm-2140bis-02 > > > > Abstract: > > This memo describes interdependent TCP control blocks, where part of > > the TCP state is shared among similar concurrent or consecutive > > connections. TCP state includes a combination of parameters, such as > > connection state, current round-trip time estimates, congestion > > control information, and process information. Most of this state is > > maintained on a per-connection basis in the TCP Control Block (TCB), > > but implementations can (and do) share certain TCB information > > across connections to the same host. Such sharing is intended to > > improve overall transient transport performance, while maintaining > > backward-compatibility with existing implementations. The sharing > > described herein is limited to only the TCB initialization and so > > has no effect on the long-term behavior of TCP after a connection > > has been established. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --94eb2c07b01ced6e32054645d730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I remember that there were some = discussions about the status of the draft. Whether this should be informati= onal or BCP. (https://tools.ietf.org/wg/tcpm/minutes?item=3Dminutes-= 97-tcpm-00.html)
Should we proceed it as an informational dra= ft? Or, do we explore some ways to make it BCP?

Th= anks,
--
Yoshi
On Fri, Jan 13, 2017 at 1:02 AM, Michael Welzl = <michawe@ifi.uio.no> wrote:
Dear all,
Here's an update of our 2140bis draft; I'd like to request a short = slot (maybe 10 mins, like last time) to present this in Chicago, if possibl= e.

Cheers,
Michael


> Begin forwarded message:
>
> From: <internet-drafts@= ietf.org>
> Subject: New Version Notification for draft-touch-tcpm-2140bis-02.txt
> Date: 13 Jan 2017 01:44:04 CET
> To: Jianjie You <youjianji= e@huawei.com>, Joe Touch <touch@= isi.edu>, "Safiqul Islam" <safiquli@ifi.uio.no>, Joseph Touch <touch@isi.edu>, Michael Welzl <michawe@ifi.uio.no>
> Resent-From: <michawe@ifi.uio= .no>
>
>
> A new version of I-D, draft-touch-tcpm-2140bis-02.txt
> has been successfully submitted by Joe Touch and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-touch-tcpm-2140bis
> Revision:=C2=A0 =C2=A0 =C2=A002
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP Cont= rol Block Interdependence
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-01-12
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 23
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-touch-tc= pm-2140bis-02.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-touch-tcpm-2140bis-02
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-214= 0bis-02
>
> Abstract:
>=C2=A0 =C2=A0This memo describes interdependent TCP control blocks, whe= re part of
>=C2=A0 =C2=A0the TCP state is shared among similar concurrent or consec= utive
>=C2=A0 =C2=A0connections. TCP state includes a combination of parameter= s, such as
>=C2=A0 =C2=A0connection state, current round-trip time estimates, conge= stion
>=C2=A0 =C2=A0control information, and process information. Most of this= state is
>=C2=A0 =C2=A0maintained on a per-connection basis in the TCP Control Bl= ock (TCB),
>=C2=A0 =C2=A0but implementations can (and do) share certain TCB informa= tion
>=C2=A0 =C2=A0across connections to the same host. Such sharing is inten= ded to
>=C2=A0 =C2=A0improve overall transient transport performance, while mai= ntaining
>=C2=A0 =C2=A0backward-compatibility with existing implementations. The = sharing
>=C2=A0 =C2=A0described herein is limited to only the TCB initialization= and so
>=C2=A0 =C2=A0has no effect on the long-term behavior of TCP after a con= nection
>=C2=A0 =C2=A0has been established.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>

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

--94eb2c07b01ced6e32054645d730-- From nobody Tue Jan 17 15:28:25 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D0129445 for ; Tue, 17 Jan 2017 15:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCA479aks4IS for ; Tue, 17 Jan 2017 15:28:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F4012711D for ; Tue, 17 Jan 2017 15:28:22 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0HNRlGq003598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Jan 2017 15:27:48 -0800 (PST) To: Yoshifumi Nishida , Michael Welzl References: <148426824447.2967.17423364285337799287.idtracker@ietfa.amsl.com> From: Joe Touch Message-ID: Date: Tue, 17 Jan 2017 15:27:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------866910EF4477412F2B3AE6A9" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-2140bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:28:24 -0000 This is a multi-part message in MIME format. --------------866910EF4477412F2B3AE6A9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, Yoshi, We're open to either one. I'd be glad to see it move towards BCP as we're incorporating exactly that - best current practice - into the doc during these revisions. However, I think we can also make the final decision on that after the doc is adopted and based on the final content. At this point, IMO, it should qualify as a WG doc at least as one of those two. Joe On 1/17/2017 12:11 AM, Yoshifumi Nishida wrote: > Hello, > > I remember that there were some discussions about the status of the > draft. Whether this should be informational or BCP. > (https://tools.ietf.org/wg/tcpm/minutes?item=minutes-97-tcpm-00.html) > Should we proceed it as an informational draft? Or, do we explore some > ways to make it BCP? > > Thanks, > -- > Yoshi > > On Fri, Jan 13, 2017 at 1:02 AM, Michael Welzl > wrote: > > Dear all, > > Here's an update of our 2140bis draft; I'd like to request a short > slot (maybe 10 mins, like last time) to present this in Chicago, > if possible. > > Cheers, > Michael > > > > Begin forwarded message: > > > > From: > > > Subject: New Version Notification for > draft-touch-tcpm-2140bis-02.txt > > Date: 13 Jan 2017 01:44:04 CET > > To: Jianjie You >, Joe Touch >, "Safiqul Islam" >, Joseph Touch >, Michael Welzl > > > Resent-From: > > > > > > > A new version of I-D, draft-touch-tcpm-2140bis-02.txt > > has been successfully submitted by Joe Touch and posted to the > > IETF repository. > > > > Name: draft-touch-tcpm-2140bis > > Revision: 02 > > Title: TCP Control Block Interdependence > > Document date: 2017-01-12 > > Group: Individual Submission > > Pages: 23 > > URL: > https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-02.txt > > > Status: > https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/ > > > Htmlized: > https://tools.ietf.org/html/draft-touch-tcpm-2140bis-02 > > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-2140bis-02 > > > > > Abstract: > > This memo describes interdependent TCP control blocks, where > part of > > the TCP state is shared among similar concurrent or consecutive > > connections. TCP state includes a combination of parameters, > such as > > connection state, current round-trip time estimates, congestion > > control information, and process information. Most of this > state is > > maintained on a per-connection basis in the TCP Control Block > (TCB), > > but implementations can (and do) share certain TCB information > > across connections to the same host. Such sharing is intended to > > improve overall transient transport performance, while maintaining > > backward-compatibility with existing implementations. The sharing > > described herein is limited to only the TCB initialization and so > > has no effect on the long-term behavior of TCP after a connection > > has been established. > > > > > > > > > > Please note that it may take a couple of minutes from the time > of submission > > until the htmlized version and diff are available at > tools.ietf.org . > > > > The IETF Secretariat > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------866910EF4477412F2B3AE6A9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi, Yoshi,

We're open to either one. I'd be glad to see it move towards BCP as we're incorporating exactly that - best current practice - into the doc during these revisions.

However, I think we can also make the final decision on that after the doc is adopted and based on the final content. At this point, IMO, it should qualify as a WG doc at least as one of those two.

Joe


On 1/17/2017 12:11 AM, Yoshifumi Nishida wrote:
Hello,

I remember that there were some discussions about the status of the draft. Whether this should be informational or BCP. (https://tools.ietf.org/wg/tcpm/minutes?item=minutes-97-tcpm-00.html)
Should we proceed it as an informational draft? Or, do we explore some ways to make it BCP?

Thanks,
--
Yoshi

On Fri, Jan 13, 2017 at 1:02 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Dear all,

Here's an update of our 2140bis draft; I'd like to request a short slot (maybe 10 mins, like last time) to present this in Chicago, if possible.

Cheers,
Michael


> Begin forwarded message:
>
> From: <internet-drafts@ietf.org>
> Subject: New Version Notification for draft-touch-tcpm-2140bis-02.txt
> Date: 13 Jan 2017 01:44:04 CET
> To: Jianjie You <youjianjie@huawei.com>, Joe Touch <touch@isi.edu>, "Safiqul Islam" <safiquli@ifi.uio.no>, Joseph Touch <touch@isi.edu>, Michael Welzl <michawe@ifi.uio.no>
> Resent-From: <michawe@ifi.uio.no>
>
>
> A new version of I-D, draft-touch-tcpm-2140bis-02.txt
> has been successfully submitted by Joe Touch and posted to the
> IETF repository.
>
> Name:         draft-touch-tcpm-2140bis
> Revision:     02
> Title:                TCP Control Block Interdependence
> Document date:        2017-01-12
> Group:                Individual Submission
> Pages:                23
> URL:            https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/
> Htmlized:       https://tools.ietf.org/html/draft-touch-tcpm-2140bis-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-2140bis-02
>
> Abstract:
>   This memo describes interdependent TCP control blocks, where part of
>   the TCP state is shared among similar concurrent or consecutive
>   connections. TCP state includes a combination of parameters, such as
>   connection state, current round-trip time estimates, congestion
>   control information, and process information. Most of this state is
>   maintained on a per-connection basis in the TCP Control Block (TCB),
>   but implementations can (and do) share certain TCB information
>   across connections to the same host. Such sharing is intended to
>   improve overall transient transport performance, while maintaining
>   backward-compatibility with existing implementations. The sharing
>   described herein is limited to only the TCB initialization and so
>   has no effect on the long-term behavior of TCP after a connection
>   has been established.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

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



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

--------------866910EF4477412F2B3AE6A9-- From nobody Wed Jan 18 23:30:59 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F24120726 for ; Wed, 18 Jan 2017 23:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79FG0n0AS_Sm for ; Wed, 18 Jan 2017 23:30:55 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4081294F7 for ; Wed, 18 Jan 2017 23:30:55 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id c206so63542690wme.0 for ; Wed, 18 Jan 2017 23:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=05uJiQxCPR4jquY11RlqWo3dl2u5K5oudrG60JhK52E=; b=Wd9Yn4cJNmkTazsoBHAcs5IUARuKXwLzylp3uM8fLCQd8knZulgPIVAA1ce0j5V9Kr M3M7ehOnPW/VU2GPtHp+BMRZ4jq78H2HcFvOjI8Oslucq6c0Km3uZ89tymJlGhlXoKfo z0fhHE/ZypEsoh4p5lRNLD0IlggxjmQAufpXX+mSIa35RSbzR9pefPhchq+NVH2SoT0G tPWF/Mm6pXq6hxT+IIzieOVrom+9E1HTRXaA+EpOAXgCqq0bG/LUw+E9GGrE2OLbeT0c uiwMvhAYzUFfpI/KaCQAA6Ev9BAWWayuY2VITFfvQw9CuFc5THuvCqFxnrGnA6AU1mYo 3W+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=05uJiQxCPR4jquY11RlqWo3dl2u5K5oudrG60JhK52E=; b=Pk8Ak0/QbA2lYS8VADIa2T10vIirkX7sVcJB4mU2xUlaP0mi3aitPsr60IfHGfuQ/s TtZSRkALWn+cVhDImQd39lJ74HplsrUd8m9AABqlkI4LSOyMRNyKulyCUWPVbQoT5J/6 klWaDxKVlvwvIi6SZaXHEkdkleBUMV951OpRSHAqp0JCARqbltgtFP4eCz/5O9YRZB8K +iaEVqI5nLCYcNkC6HDN7VOxBepLC0+34JuZsxvgKvO7UoDRvOljpYeMcAQj0OXgTdPq nQUC+ZQEiBS3qYtC1MJ9XD6fYQKuU5vMX5m3BfvTcnQa+//nbFGA2AOoPplLybZeAGkN 4w2w== X-Gm-Message-State: AIkVDXK1fL5TGd5OO0kD9QTdzN3SvhTFzJ/qKDkwFxYI2RLdlGY4+SigmBaGobf5jSHj0cxg X-Received: by 10.28.67.134 with SMTP id q128mr22361478wma.34.1484811053799; Wed, 18 Jan 2017 23:30:53 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:a478:b82f:382b:c844]) by smtp.gmail.com with ESMTPSA id q1sm10863266wmd.6.2017.01.18.23.30.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 23:30:52 -0800 (PST) To: tcpm IETF list , draft-nishida-tcpm-maxwin@ietf.org From: marcelo bagnulo braun Message-ID: <7df22790-f177-e61f-47a7-10c246f52535@it.uc3m.es> Date: Thu, 19 Jan 2017 08:30:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] comment about draft-nishida-tcpm-maxwin-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 07:30:58 -0000 Hi, Thanks for writing this draft, seems useful to me. A couple of minor comments: - I understand that this extension MUST be used with PAWS, correct? I mean, using a larger RCVWND without PAWS is likely to result in inability to distinguish old duplicate packets from new ones, correct? Should this requirement of this being used in conjunction with PAWS be explicitly stated? - If an endpoint that does support this extension communicates with endpoints that do not support this extension, it will result in the endpoint that does support the extension to be allocating the double buffer size for every connection with a legacy endpoint that it should. I agree that is not fatal, but wouldnt this be a problem in terms of resources? Would this excess of demand in resource usage would make adoption of this extension not very attractive? Maybe it would be better to use the 15 shift count when the other endpoint also replies with a 15 shift count or something like this? - The second paragraph in section 4, it talks about "performance degradation caused by misinterpretation of the shift count" I dont understand what you are referring to, can you clarify? thanks, marcelo From nobody Thu Jan 19 13:01:51 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07112957E for ; Thu, 19 Jan 2017 13:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oEzlPmsQ24l for ; Thu, 19 Jan 2017 13:01:47 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857DF12956C for ; Thu, 19 Jan 2017 13:01:46 -0800 (PST) Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 31B182783BF for ; Fri, 20 Jan 2017 06:01:43 +0900 (JST) Received: by mail-vk0-f44.google.com with SMTP id r136so39150696vke.1 for ; Thu, 19 Jan 2017 13:01:43 -0800 (PST) X-Gm-Message-State: AIkVDXJfpoq+ZxYTbEU8b0reOsqSUEAjZp/Pr6qvGVl8Iv/CShgBq1DBLLkTQc9+JCmioVGpwqi8h0jB0PnIEA== X-Received: by 10.31.92.9 with SMTP id q9mr5837239vkb.88.1484859701675; Thu, 19 Jan 2017 13:01:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.145 with HTTP; Thu, 19 Jan 2017 13:01:41 -0800 (PST) In-Reply-To: References: <7df22790-f177-e61f-47a7-10c246f52535@it.uc3m.es> From: Yoshifumi Nishida Date: Thu, 19 Jan 2017 13:01:41 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" , marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a114e17020fcb39054678d7a3 Archived-At: Subject: [tcpm] Fwd: comment about draft-nishida-tcpm-maxwin-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 21:01:49 -0000 --001a114e17020fcb39054678d7a3 Content-Type: text/plain; charset=UTF-8 Hi Marcelo, Thanks for reading the draft! Sorry, I forgot to CC to tcpm..So, I resent it. On Wed, Jan 18, 2017 at 11:30 PM, marcelo bagnulo braun wrote: > Hi, > > Thanks for writing this draft, seems useful to me. > > A couple of minor comments: > > - I understand that this extension MUST be used with PAWS, correct? I > mean, using a larger RCVWND without PAWS is likely to result in inability > to distinguish old duplicate packets from new ones, correct? Should this > requirement of this being used in conjunction with PAWS be explicitly > stated? > That's right. We presume the use of PAWS here. We can add some texts. > > - If an endpoint that does support this extension communicates with > endpoints that do not support this extension, it will result in the > endpoint that does support the extension to be allocating the double buffer > size for every connection with a legacy endpoint that it should. I agree > that is not fatal, but wouldnt this be a problem in terms of resources? > Would this excess of demand in resource usage would make adoption of this > extension not very attractive? Maybe it would be better to use the 15 shift > count when the other endpoint also replies with a 15 shift count or > something like this? > Yes, we have thought about it before. One potential issue of the approach is it will require other endpoint to use 15 shift count, although it might want to use smaller shift count. WS option exchange is one way notification. So, I just didn't want to use it as a negotiation mechanism to activate the feature. On the other hand, we presumed not so many TCP connections want to use this feature, such as at most 10 connections at one time. Also, adding a certain negotiation mechanism to activate the feature could be another way. (01 version has described the mechanism, which is deleted in 02 version) We've compared these points and have chosen the current mechanism. > - The second paragraph in section 4, it talks about "performance > degradation caused by misinterpretation of the shift count" I dont > understand what you are referring to, can you clarify? > When an endpoint A offers shift count 15 but a conventional endpoint B regards it as 14, we could have performance degradation issue. Because when A says "I have X<<15 buffer", B will think "A has X<<14 buffer". But, when X=65535, we shouldn't see performance degradation issue because 65535<<14 is the max window size that B can support. So, if A allocates 65535<<15 + 65535<<14 buffer, A can always send X=65535 because B's buffer is at most 65535<<14, it cannot consume the buffer at A more than that. Thanks, -- Yoshi --001a114e17020fcb39054678d7a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,
Thanks for reading the draft! Sorry, I forgot to CC to tcp= m..So, I resent it.

On Wed, Jan 18, 2017 at 11:30 PM, marcelo bagnulo = braun <marcelo@it.uc3m.es> wrote:
Hi,

Thanks for writing this draft, seems useful to me.

A couple of minor comments:

- I understand that this extension MUST be used with PAWS, correct? I mean,= using a larger RCVWND without PAWS is likely to result in inability to dis= tinguish old duplicate packets from new ones, correct? Should this requirem= ent of this being used in conjunction with PAWS be explicitly stated?

That's right. We presume the use = of PAWS here. We can add some texts.

- If an endpoint that does support this extension communicates with endpoin= ts that do not support this extension, it will result in the endpoint that = does support the extension to be allocating the double buffer size for ever= y connection with a legacy endpoint that it should. I agree that is not fat= al, but wouldnt this be a problem in terms of resources? Would this excess = of demand in resource usage would make adoption of this extension not very = attractive? Maybe it would be better to use the 15 shift count when the oth= er endpoint also replies with a 15 shift count or something like this?
<= /blockquote>

Yes, we have thought about it before= . One potential issue of the approach is it will require other endpoint to = use 15 shift count, although it might want to use smaller shift count. WS o= ption exchange is one way notification. So, I just didn't want to use i= t as a negotiation mechanism to activate the feature.
On the othe= r hand, we presumed not so many TCP connections want to use this feature, s= uch as at most 10 connections at one time.=C2=A0
Also, adding a c= ertain negotiation mechanism to activate the feature could be another way. = =C2=A0(01 version has described the mechanism, which is deleted in 02 versi= on) We've compared these points and have chosen the current mechanism.= =C2=A0
=C2=A0
References: <7df22790-f177-e61f-47a7-10c246f52535@it.uc3m.es> From: marcelo bagnulo braun Message-ID: <44c23acf-a271-71e4-3e8d-f1169f2a2f6f@it.uc3m.es> Date: Fri, 20 Jan 2017 08:27:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Fwd: comment about draft-nishida-tcpm-maxwin-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Jan 2017 07:27:27 -0000 below... El 19/01/17 a las 22:01, Yoshifumi Nishida escribió: > Hi Marcelo, > > Thanks for reading the draft! Sorry, I forgot to CC to tcpm..So, I > resent it. > > On Wed, Jan 18, 2017 at 11:30 PM, marcelo bagnulo braun > > wrote: > > Hi, > > Thanks for writing this draft, seems useful to me. > > A couple of minor comments: > > - I understand that this extension MUST be used with PAWS, > correct? I mean, using a larger RCVWND without PAWS is likely to > result in inability to distinguish old duplicate packets from new > ones, correct? Should this requirement of this being used in > conjunction with PAWS be explicitly stated? > > > That's right. We presume the use of PAWS here. We can add some texts. I understand it is not safe to use the increased window without paws, so, i would think the draft should sate that PAWS MUST be used with the increased window. > > - If an endpoint that does support this extension communicates > with endpoints that do not support this extension, it will result > in the endpoint that does support the extension to be allocating > the double buffer size for every connection with a legacy endpoint > that it should. I agree that is not fatal, but wouldnt this be a > problem in terms of resources? Would this excess of demand in > resource usage would make adoption of this extension not very > attractive? Maybe it would be better to use the 15 shift count > when the other endpoint also replies with a 15 shift count or > something like this? > > > Yes, we have thought about it before. One potential issue of the > approach is it will require other endpoint to use 15 shift count, > although it might want to use smaller shift count. WS option exchange > is one way notification. So, I just didn't want to use it as a > negotiation mechanism to activate the feature. Right, imposing the use of 15 shift count in a connection endpoint that doesnt need it is also a waste of resources, so depending which endpoint is more constrained in resources this may or may not be a good approach (and we dont know which one is the bottleneck in advance). Moreover, i would think that supporting very different buffers at the endpoints of a connection is very important. I mean, in a connection where a server providing content to a client, the client needs the big rcv buffer and the server doesnt and it is the server who has the greater demand if it is serving a large number of clients. > On the other hand, we presumed not so many TCP connections want to use > this feature, such as at most 10 connections at one time. I am uncertain about this argument. I would assume that the bandwidth will increase (for links and for connections) and hopefully latency will decrease in the future (eliminating bufferbloat and with mechanisms like l4s) so i think we should design this to be widely used, dont you think? > Also, adding a certain negotiation mechanism to activate the feature > could be another way. (01 version has described the mechanism, which > is deleted in 02 version) We've compared these points and have chosen > the current mechanism. Right, just checked this. I am not sure it is worth consuming a new option codepoint for this, and especially not the use of the new option in the SYN packet, which is already crowded. What about this: The shift count is expressed in a byte, but only the values between 1 and 14 are acceptable as per RFC 7323. With this draft, the 15 shift count value would become acceptable, but it seems we will never need more than 16 values in the shift count (unless we increase the TCP seq number). So, this means that we have 4 bits to play with in the shift count field. One way of using it would be the following: We divide the shift count filed in two fields of 4 bits. The first 4 bits are used to express the shift count for legacy (RFC7323) endpoints. The last 4 bits are used to express the shift count for endpoints that support this specification. So, this would result in the following combinations: - updated client talks to updated server: it expresses its own shift count using the last 4 bits, the server replies expressing its own shift count in the last 4 bits. Both endpoints understand that they are talking to updated endpoints, so they use the new values. - updated client talks to legacy server. It expresses its own shift count using the last bits. The legacy server receives the option, checks that the value is larger than 14 and then uses 14 as shift count for this client. The server replies with its own shift count encoded in the first 4 bits. The client understands that the server is legacy and uses a 14 shift count for its own shift count. - legacy client talking to legacy or updated server, behaves as described in RFC7323 If we do this, then when both endpoints are updated, one of the endpoints can use a smaller shift count even if the other endpoint uses a 15 shift count. This doesnt help in the situation where the server is legacy, but at least in the long run if this extension is widely deployed, the behaviour is the desired one. what do you think? > - The second paragraph in section 4, it talks about "performance > degradation caused by misinterpretation of the shift count" I dont > understand what you are referring to, can you clarify? > > > When an endpoint A offers shift count 15 but a conventional endpoint B > regards it as 14, we could have performance degradation issue. > Because when A says "I have X<<15 buffer", B will think "A has X<<14 > buffer". > > But, when X=65535, we shouldn't see performance degradation issue > because 65535<<14 is the max window size that B can support. > So, if A allocates 65535<<15 + 65535<<14 buffer, A can always send > X=65535 because B's buffer is at most 65535<<14, it cannot consume the > buffer at A more than that. > So, there is no performance degradation issue :-) I guess we agree, i guess just find it confusing when the draft talks about a performance degradation issue where this is not one. Regards, marcelo > Thanks, > -- > Yoshi > From nishida@sfc.wide.ad.jp Fri Jan 20 11:32:41 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A988C128874 for ; Fri, 20 Jan 2017 11:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scfy-qLNXmdX for ; Fri, 20 Jan 2017 11:32:39 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6311279EB for ; Fri, 20 Jan 2017 11:32:38 -0800 (PST) Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E643C2786EC for ; Sat, 21 Jan 2017 04:32:35 +0900 (JST) Received: by mail-ua0-f177.google.com with SMTP id y9so70807946uae.2 for ; Fri, 20 Jan 2017 11:32:35 -0800 (PST) X-Gm-Message-State: AIkVDXL4M6Cw6z1rM1bz4kOxLwmCP22K5JMZZvx7UQkrNfNzBQdOrypAh2uEl17faJtVzSMuTtBBnoD8a1mAPQ== X-Received: by 10.159.38.131 with SMTP id 3mr7518106uay.59.1484940754217; Fri, 20 Jan 2017 11:32:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.145 with HTTP; Fri, 20 Jan 2017 11:32:33 -0800 (PST) In-Reply-To: <44c23acf-a271-71e4-3e8d-f1169f2a2f6f@it.uc3m.es> References: <7df22790-f177-e61f-47a7-10c246f52535@it.uc3m.es> <44c23acf-a271-71e4-3e8d-f1169f2a2f6f@it.uc3m.es> From: Yoshifumi Nishida Date: Fri, 20 Jan 2017 11:32:33 -0800 X-Gmail-Original-Message-ID: Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=94eb2c0932a62af0dc05468bb68e Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: comment about draft-nishida-tcpm-maxwin-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Jan 2017 19:32:41 -0000 --94eb2c0932a62af0dc05468bb68e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Marcelo, Thanks for the comments. On Thu, Jan 19, 2017 at 11:27 PM, marcelo bagnulo braun wrote: > below... > > El 19/01/17 a las 22:01, Yoshifumi Nishida escribi=C3=B3: > >> Hi Marcelo, >> >> Thanks for reading the draft! Sorry, I forgot to CC to tcpm..So, I resen= t >> it. >> >> On Wed, Jan 18, 2017 at 11:30 PM, marcelo bagnulo braun < >> marcelo@it.uc3m.es > wrote: >> >> Hi, >> >> Thanks for writing this draft, seems useful to me. >> >> A couple of minor comments: >> >> - I understand that this extension MUST be used with PAWS, >> correct? I mean, using a larger RCVWND without PAWS is likely to >> result in inability to distinguish old duplicate packets from new >> ones, correct? Should this requirement of this being used in >> conjunction with PAWS be explicitly stated? >> >> >> That's right. We presume the use of PAWS here. We can add some texts. >> > > I understand it is not safe to use the increased window without paws, so, > i would think the draft should sate that PAWS MUST be used with the > increased window. Yes, We'll state this point. > >> - If an endpoint that does support this extension communicates >> with endpoints that do not support this extension, it will result >> in the endpoint that does support the extension to be allocating >> the double buffer size for every connection with a legacy endpoint >> that it should. I agree that is not fatal, but wouldnt this be a >> problem in terms of resources? Would this excess of demand in >> resource usage would make adoption of this extension not very >> attractive? Maybe it would be better to use the 15 shift count >> when the other endpoint also replies with a 15 shift count or >> something like this? >> >> >> Yes, we have thought about it before. One potential issue of the approac= h >> is it will require other endpoint to use 15 shift count, although it mig= ht >> want to use smaller shift count. WS option exchange is one way >> notification. So, I just didn't want to use it as a negotiation mechanis= m >> to activate the feature. >> > > Right, imposing the use of 15 shift count in a connection endpoint that > doesnt need it is also a waste of resources, so depending which endpoint = is > more constrained in resources this may or may not be a good approach (and > we dont know which one is the bottleneck in advance). > > Moreover, i would think that supporting very different buffers at the > endpoints of a connection is very important. I mean, in a connection wher= e > a server providing content to a client, the client needs the big rcv buff= er > and the server doesnt and it is the server who has the greater demand if = it > is serving a large number of clients. Yes, I agree. > > > On the other hand, we presumed not so many TCP connections want to use >> this feature, such as at most 10 connections at one time. >> > > I am uncertain about this argument. I would assume that the bandwidth wil= l > increase (for links and for connections) and hopefully latency will > decrease in the future (eliminating bufferbloat and with mechanisms like > l4s) so i think we should design this to be widely used, dont you think? I actually didn't think about this point very much. But, if we can have nice design that can support wider use, yes, it's of course better. > > Also, adding a certain negotiation mechanism to activate the feature coul= d >> be another way. (01 version has described the mechanism, which is delet= ed >> in 02 version) We've compared these points and have chosen the current >> mechanism. >> > > Right, just checked this. I am not sure it is worth consuming a new optio= n > codepoint for this, and especially not the use of the new option in the S= YN > packet, which is already crowded. > Yep. That's why we didn't include it in the current version. > What about this: > The shift count is expressed in a byte, but only the values between 1 and > 14 are acceptable as per RFC 7323. > With this draft, the 15 shift count value would become acceptable, but it > seems we will never need more than 16 values in the shift count (unless w= e > increase the TCP seq number). > So, this means that we have 4 bits to play with in the shift count field. > One way of using it would be the following: > We divide the shift count filed in two fields of 4 bits. The first 4 bits > are used to express the shift count for legacy (RFC7323) endpoints. > The last 4 bits are used to express the shift count for endpoints that > support this specification. > > So, this would result in the following combinations: > - updated client talks to updated server: it expresses its own shift coun= t > using the last 4 bits, the server replies expressing its own shift count = in > the last 4 bits. Both endpoints understand that they are talking to updat= ed > endpoints, so they use the new values. > - updated client talks to legacy server. It expresses its own shift count > using the last bits. The legacy server receives the option, checks that t= he > value is larger than 14 and then uses 14 as shift count for this client. > The server replies with its own shift count encoded in the first 4 bits. > The client understands that the server is legacy and uses a 14 shift coun= t > for its own shift count. > - legacy client talking to legacy or updated server, behaves as described > in RFC7323 > > If we do this, then when both endpoints are updated, one of the endpoints > can use a smaller shift count even if the other endpoint uses a 15 shift > count. This doesnt help in the situation where the server is legacy, but = at > least in the long run if this extension is widely deployed, the behaviour > is the desired one. > > what do you think? I've thought about it and I think it's a pretty good idea. It's more explicit than the current scheme, but doesn't consume extra option space. In this scheme, when an updated endpoint talks to a non-updated endpoint, the shift count will automatically 14. But, I guess this cannot be solved without adding extra negotiation scheme. So, I think it's acceptable. One question I have is if we need to use 4bits for this. It might be ok to use just one bit in the last 4 bits to indicate it supports new version. But, this might be a very minor point. > - The second paragraph in section 4, it talks about "performance >> degradation caused by misinterpretation of the shift count" I dont >> understand what you are referring to, can you clarify? >> >> >> When an endpoint A offers shift count 15 but a conventional endpoint B >> regards it as 14, we could have performance degradation issue. >> Because when A says "I have X<<15 buffer", B will think "A has X<<14 >> buffer". >> >> But, when X=3D65535, we shouldn't see performance degradation issue beca= use >> 65535<<14 is the max window size that B can support. >> So, if A allocates 65535<<15 + 65535<<14 buffer, A can always send >> X=3D65535 because B's buffer is at most 65535<<14, it cannot consume the >> buffer at A more than that. >> >> > So, there is no performance degradation issue :-) > I guess we agree, i guess just find it confusing when the draft talks > about a performance degradation issue where this is not one. > Got it. I might think about finding less confusing texts. Or, with your proposed scheme, we don't need this part. Thanks, -- Yoshi --94eb2c0932a62af0dc05468bb68e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,

Thanks for the comments.

On Thu, Jan= 19, 2017 at 11:27 PM, marcelo bagnulo braun <marcelo@it.uc3m.es>= wrote:
below...

El 19/01/17 a las 22:01, Yoshifumi Nishida escribi=C3=B3:
Hi Marcelo,

Thanks for reading the draft! Sorry, I forgot to CC to tcpm..So, I resent i= t.

 On Wed, Jan 18, 2017 at 11:30 PM, marcelo bagnulo braun <marcelo@it.uc3m.es <mailto:= marcelo@it.uc3m.es<= /a>>> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 Thanks for writing this draft, seems useful to me.

=C2=A0 =C2=A0 A couple of minor comments:

=C2=A0 =C2=A0 - I understand that this extension MUST be used with PAWS, =C2=A0 =C2=A0 correct? I mean, using a larger RCVWND without PAWS is likely= to
=C2=A0 =C2=A0 result in inability to distinguish old duplicate packets from= new
=C2=A0 =C2=A0 ones, correct? Should this requirement of this being used in<= br> =C2=A0 =C2=A0 conjunction with PAWS be explicitly stated?


That's right. We presume the use of PAWS here. We can add some texts.

I understand it is not safe to use the increased window without paws, so, i= would think the draft should sate that PAWS MUST be used with the increase= d window.

Yes, We'll state this point.<= /div>
=C2=A0 =C2=A0 - If an endpoint that does support this extension communicate= s
=C2=A0 =C2=A0 with endpoints that do not support this extension, it will re= sult
=C2=A0 =C2=A0 in the endpoint that does support the extension to be allocat= ing
=C2=A0 =C2=A0 the double buffer size for every connection with a legacy end= point
=C2=A0 =C2=A0 that it should. I agree that is not fatal, but wouldnt this b= e a
=C2=A0 =C2=A0 problem in terms of resources? Would this excess of demand in=
=C2=A0 =C2=A0 resource usage would make adoption of this extension not very=
=C2=A0 =C2=A0 attractive? Maybe it would be better to use the 15 shift coun= t
=C2=A0 =C2=A0 when the other endpoint also replies with a 15 shift count or=
=C2=A0 =C2=A0 something like this?


Yes, we have thought about it before. One potential issue of the approach i= s it will require other endpoint to use 15 shift count, although it might w= ant to use smaller shift count. WS option exchange is one way notification.= So, I just didn't want to use it as a negotiation mechanism to activat= e the feature.

 Right, imposing the use of 15 shift count in a connection endpoint that doe= snt need it is also a waste of resources, so depending which endpoint is mo= re constrained in resources this may or may not be a good approach (and we = dont know which one is the bottleneck in advance).

Moreover, i would think that supporting very different buffers at the endpo= ints of a connection is very important. I mean, in a connection where a ser= ver providing content to a client, the client needs the big rcv buffer and = the server doesnt and it is the server who has the greater demand if it is = serving a large number of clients.

Yes, I a= gree.=C2=A0


On the other hand, we presumed not so many TCP connections want to use this= feature, such as at most 10 connections at one time.

 I am uncertain about this argument. I would assume that the bandwidth will = increase (for links and for connections) and hopefully latency will decreas= e in the future (eliminating bufferbloat and with mechanisms like l4s) so i= think we should design this to be widely used, dont you think?

I actually didn't think about this point very much= .=C2=A0
But, if we can have nice design that can support wider us= e, yes, it's of course better.

Also, adding a certain negotiation mechanism to activate the feature could = be another way.=C2=A0 (01 version has described the mechanism, which is del= eted in 02 version) We've compared these points and have chosen the cur= rent mechanism.

Right, just checked this. I am not sure it is worth consuming a new option = codepoint for this, and especially not the use of the new option in the SYN= packet, which is already crowded.

Yep.= That's why we didn't include it in the current version.
= =C2=A0
What about this:
The shift count is expressed in a byte, but only the values between 1 and 1= 4 are acceptable as per RFC 7323.
With this draft, the 15 shift count value would become acceptable, but it s= eems we will never need more than 16 values in the shift count (unless we i= ncrease the TCP seq number).
So, this means that we have 4 bits to play with in the shift count field. One way of using it would be the following:
We divide the shift count filed in two fields of 4 bits. The first 4 bits a= re used to express the shift count for legacy (RFC7323) endpoints.
The last 4 bits are used to express the shift count for endpoints that supp= ort this specification.

So, this would result in the following combinations:
- updated client talks to updated server: it expresses its own shift count = using the last 4 bits, the server replies expressing its own shift count in= the last 4 bits. Both endpoints understand that they are talking to update= d endpoints, so they use the new values.
- updated client talks to legacy server. It expresses its own shift count u= sing the last bits. The legacy server receives the option, checks that the = value is larger than 14 and then uses 14 as shift count for this client. Th= e server replies with its own shift count encoded in the first 4 bits. The = client understands that the server is legacy and uses a 14 shift count for = its own shift count.
- legacy client talking to legacy or updated server, behaves as described i= n RFC7323

If we do this, then when both endpoints are updated, one of the endpoints c= an use a smaller shift count even if the other endpoint uses a 15 shift cou= nt. This doesnt help in the situation where the server is legacy, but at le= ast in the long run if this extension is widely deployed, the behaviour is = the desired one.

what do you think?

I've thought about i= t and I think it's a pretty good idea. It's more explicit than the = current scheme, but doesn't consume extra option space.
In th= is scheme, when an updated endpoint talks to a non-updated endpoint, the sh= ift count will automatically 14. But, I guess this cannot be solved without= adding extra negotiation scheme. So, I think it's acceptable.
One question I have is if we need to use 4bits for this. It might be ok t= o use just one bit in the last 4 bits to indicate it supports new version.<= /div>
But, this might be a very minor point.=C2=A0
=C2=A0
=C2=A0 =C2=A0 - The second paragraph in section 4, it talks about "per= formance
=C2=A0 =C2=A0 degradation caused by misinterpretation of the shift count&qu= ot; I dont
=C2=A0 =C2=A0 understand what you are referring to, can you clarify?


When an endpoint A offers shift count 15 but a conventional endpoint B rega= rds it as 14, we could have performance degradation issue.
Because when A says "I have X<<15 buffer", B will think &qu= ot;A has X<<14 buffer".

But, when X=3D65535, we shouldn't see performance degradation issue bec= ause 65535<<14 is the max window size that B can support.
So, if A allocates 65535<<15 + 65535<<14 buffer, A can always s= end X=3D65535 because B's buffer is at most 65535<<14, it cannot = consume the buffer at A more than that.


 So, there is no performance degradation issue :-)
I guess we agree, i guess just find it confusing when the draft talks about= a performance degradation issue where this is not one.

Got it. I might think about finding less confusing texts.= =C2=A0
Or, with your proposed scheme, we don't need this part= .=C2=A0

Thanks,
--
Yoshi=C2=A0=
--94eb2c0932a62af0dc05468bb68e-- From nobody Fri Jan 20 12:28:21 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E586129430 for ; Fri, 20 Jan 2017 12:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGQi3CFq5zqH for ; Fri, 20 Jan 2017 12:28:16 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2E112940F for ; Fri, 20 Jan 2017 12:28:16 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r144so61779818wme.1 for ; Fri, 20 Jan 2017 12:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rArsuDzJBgsHfB8j9BCar4m32BSTHLPxZWKICQCwr0g=; b=yMbt4ne496PEZDm0S1IbI9epu2rRgpPUpeTniQn0v5Ry9PGGg3hYXBhaUFQYjwHoQj EJr+uUUeGQ54mIQsMhxUpf/R8OeU3jmL0UsTG1sAl2aTiYeXJTdc/fOveQpmt3Ikor6E qbaPfiwD8dIw2jSIYghIB82jwWLWFgZMgX/BKWjf57qbFhMt+Ceqa9uuC31c9NNkBWNs 2UEEJRLYW4PuuCzWh4/55pUrkJ1+cuxEnEMlq73i4i7sEs+Gb0I1HqtPYmJPX9fJHSYD KGNAPvN2/umAlQBuU/xWDCsnUou8Ea080g/Vg8rXmAJnAkA9GOJKMkJb/EXydVIKRkxH I6Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rArsuDzJBgsHfB8j9BCar4m32BSTHLPxZWKICQCwr0g=; b=hDkyaw55UWk/M3yazl3zE77t3aCgEdhzHlbcpmqtJX9HM/fly6F2bU0E/R1OpTRw+L yiGVrQoLyLwvrA+JG0Oy3+Hfdl3Oi1xeCc5qYeb0i6J9fTPtEgDhlP9MYCcig2GCSIo2 kn3jNbDoP8K++nwXEh0Q5iIpVGXOY3V2dOGcuPKA1aU+3CymWD6F33JI41d7lVuUqlTc TLd/5GG9YUt519KRZW/HfxinkzAHtJqNZEZRHSeNBo7M0rEW/KsYuD/DBTcBFv15Tipe By/qeWNzOWCzU/l0Yoo/iuxgARcORd0jct09BU4TguCoJFxn7HWzh/wocB/Tfpq3H4X0 ko7Q== X-Gm-Message-State: AIkVDXJ5/c3ktZJDuQufjmZjVAFSl3c5qz4Xl1Hjcy91b2kE4ddyrwTxqvB5ZM1PgeJq4T3z X-Received: by 10.28.129.147 with SMTP id c141mr5209115wmd.12.1484944094562; Fri, 20 Jan 2017 12:28:14 -0800 (PST) Received: from Macintosh-6.local (73.175.16.95.dynamic.jazztel.es. [95.16.175.73]) by smtp.gmail.com with ESMTPSA id u81sm7757337wmu.10.2017.01.20.12.28.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 12:28:12 -0800 (PST) To: Yoshifumi Nishida References: <7df22790-f177-e61f-47a7-10c246f52535@it.uc3m.es> <44c23acf-a271-71e4-3e8d-f1169f2a2f6f@it.uc3m.es> From: marcelo bagnulo braun Message-ID: Date: Fri, 20 Jan 2017 21:28:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: comment about draft-nishida-tcpm-maxwin-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Jan 2017 20:28:19 -0000 below... El 20/01/17 a las 20:32, Yoshifumi Nishida escribió: > > What about this: > The shift count is expressed in a byte, but only the values > between 1 and 14 are acceptable as per RFC 7323. > With this draft, the 15 shift count value would become acceptable, > but it seems we will never need more than 16 values in the shift > count (unless we increase the TCP seq number). > So, this means that we have 4 bits to play with in the shift count > field. > One way of using it would be the following: > We divide the shift count filed in two fields of 4 bits. The first > 4 bits are used to express the shift count for legacy (RFC7323) > endpoints. > The last 4 bits are used to express the shift count for endpoints > that support this specification. > > So, this would result in the following combinations: > - updated client talks to updated server: it expresses its own > shift count using the last 4 bits, the server replies expressing > its own shift count in the last 4 bits. Both endpoints understand > that they are talking to updated endpoints, so they use the new > values. > - updated client talks to legacy server. It expresses its own > shift count using the last bits. The legacy server receives the > option, checks that the value is larger than 14 and then uses 14 > as shift count for this client. The server replies with its own > shift count encoded in the first 4 bits. The client understands > that the server is legacy and uses a 14 shift count for its own > shift count. > - legacy client talking to legacy or updated server, behaves as > described in RFC7323 > > If we do this, then when both endpoints are updated, one of the > endpoints can use a smaller shift count even if the other endpoint > uses a 15 shift count. This doesnt help in the situation where the > server is legacy, but at least in the long run if this extension > is widely deployed, the behaviour is the desired one. > > what do you think? > > > I've thought about it and I think it's a pretty good idea. It's more > explicit than the current scheme, but doesn't consume extra option space. > In this scheme, when an updated endpoint talks to a non-updated > endpoint, the shift count will automatically 14. But, I guess this > cannot be solved without adding extra negotiation scheme. So, I think > it's acceptable. > One question I have is if we need to use 4bits for this. It might be > ok to use just one bit in the last 4 bits to indicate it supports new > version. agree. So, the shift count field in the WSO could then look like this: +----------+ |SSSS|L|RRR| +----------+ With SSSS being 4 bits used to express the shift count, L, being the bit to express the Large window support and RRR 3 reserved bits. Makes sense? Regards, marcelo > But, this might be a very minor point. > > - The second paragraph in section 4, it talks about > "performance > degradation caused by misinterpretation of the shift > count" I dont > understand what you are referring to, can you clarify? > > > When an endpoint A offers shift count 15 but a conventional > endpoint B regards it as 14, we could have performance > degradation issue. > Because when A says "I have X<<15 buffer", B will think "A has > X<<14 buffer". > > But, when X=65535, we shouldn't see performance degradation > issue because 65535<<14 is the max window size that B can support. > So, if A allocates 65535<<15 + 65535<<14 buffer, A can always > send X=65535 because B's buffer is at most 65535<<14, it > cannot consume the buffer at A more than that. > > > So, there is no performance degradation issue :-) > I guess we agree, i guess just find it confusing when the draft > talks about a performance degradation issue where this is not one. > > > Got it. I might think about finding less confusing texts. > Or, with your proposed scheme, we don't need this part. > > Thanks, > -- > Yoshi From nobody Fri Jan 20 13:15:03 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EFD129495 for ; Fri, 20 Jan 2017 13:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g9npxXfuTeR for ; Fri, 20 Jan 2017 13:14:59 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469AC129494 for ; Fri, 20 Jan 2017 13:14:58 -0800 (PST) Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 69AA42786B5 for ; Sat, 21 Jan 2017 06:14:47 +0900 (JST) Received: by mail-ua0-f177.google.com with SMTP id 96so72254698uaq.3 for ; Fri, 20 Jan 2017 13:14:47 -0800 (PST) X-Gm-Message-State: AIkVDXL2UQdx2naOR4+GrBlv0mBfrbLiRTgjCw8kz/xBodgIgZUQE16kwCml3sdSJ8ZCvNqxw3JBijf0sLuvvQ== X-Received: by 10.159.36.165 with SMTP id 34mr9372156uar.48.1484946886004; Fri, 20 Jan 2017 13:14:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.145 with HTTP; Fri, 20 Jan 2017 13:14:45 -0800 (PST) In-Reply-To: References: <7df22790-f177-e61f-47a7-10c246f52535@it.uc3m.es> <44c23acf-a271-71e4-3e8d-f1169f2a2f6f@it.uc3m.es> From: Yoshifumi Nishida Date: Fri, 20 Jan 2017 13:14:45 -0800 X-Gmail-Original-Message-ID: Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a113cf800a6b68f05468d23c5 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: comment about draft-nishida-tcpm-maxwin-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Jan 2017 21:15:02 -0000 --001a113cf800a6b68f05468d23c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Marcelo, On Fri, Jan 20, 2017 at 12:28 PM, marcelo bagnulo braun wrote: > below... > > El 20/01/17 a las 20:32, Yoshifumi Nishida escribi=C3=B3: > > >> What about this: >> The shift count is expressed in a byte, but only the values >> between 1 and 14 are acceptable as per RFC 7323. >> With this draft, the 15 shift count value would become acceptable, >> but it seems we will never need more than 16 values in the shift >> count (unless we increase the TCP seq number). >> So, this means that we have 4 bits to play with in the shift count >> field. >> One way of using it would be the following: >> We divide the shift count filed in two fields of 4 bits. The first >> 4 bits are used to express the shift count for legacy (RFC7323) >> endpoints. >> The last 4 bits are used to express the shift count for endpoints >> that support this specification. >> >> So, this would result in the following combinations: >> - updated client talks to updated server: it expresses its own >> shift count using the last 4 bits, the server replies expressing >> its own shift count in the last 4 bits. Both endpoints understand >> that they are talking to updated endpoints, so they use the new >> values. >> - updated client talks to legacy server. It expresses its own >> shift count using the last bits. The legacy server receives the >> option, checks that the value is larger than 14 and then uses 14 >> as shift count for this client. The server replies with its own >> shift count encoded in the first 4 bits. The client understands >> that the server is legacy and uses a 14 shift count for its own >> shift count. >> - legacy client talking to legacy or updated server, behaves as >> described in RFC7323 >> >> If we do this, then when both endpoints are updated, one of the >> endpoints can use a smaller shift count even if the other endpoint >> uses a 15 shift count. This doesnt help in the situation where the >> server is legacy, but at least in the long run if this extension >> is widely deployed, the behaviour is the desired one. >> >> what do you think? >> >> >> I've thought about it and I think it's a pretty good idea. It's more >> explicit than the current scheme, but doesn't consume extra option space= . >> In this scheme, when an updated endpoint talks to a non-updated endpoint= , >> the shift count will automatically 14. But, I guess this cannot be solve= d >> without adding extra negotiation scheme. So, I think it's acceptable. >> One question I have is if we need to use 4bits for this. It might be ok >> to use just one bit in the last 4 bits to indicate it supports new versi= on. >> > > agree. > So, the shift count field in the WSO could then look like this: > > +----------+ > |SSSS|L|RRR| > +----------+ > > With SSSS being 4 bits used to express the shift count, L, being the bit > to express the Large window support and RRR 3 reserved bits. > > Makes sense? > Yes, make sense to me. Thanks! -- Yoshi --001a113cf800a6b68f05468d23c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,

On Fri, Jan 20, 2017 at 12:28 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
below...

El 20/01/17 a las 20:32, Yoshifumi Nishida escribi=C3=B3:


=C2=A0 =C2=A0 What about this:
=C2=A0 =C2=A0 The shift count is expressed in a byte, but only the values =C2=A0 =C2=A0 between 1 and 14 are acceptable as per RFC 7323.
=C2=A0 =C2=A0 With this draft, the 15 shift count value would become accept= able,
=C2=A0 =C2=A0 but it seems we will never need more than 16 values in the sh= ift
=C2=A0 =C2=A0 count (unless we increase the TCP seq number).
=C2=A0 =C2=A0 So, this means that we have 4 bits to play with in the shift = count
=C2=A0 =C2=A0 field.
=C2=A0 =C2=A0 One way of using it would be the following:
=C2=A0 =C2=A0 We divide the shift count filed in two fields of 4 bits. The = first
=C2=A0 =C2=A0 4 bits are used to express the shift count for legacy (RFC732= 3)
=C2=A0 =C2=A0 endpoints.
=C2=A0 =C2=A0 The last 4 bits are used to express the shift count for endpo= ints
=C2=A0 =C2=A0 that support this specification.

=C2=A0 =C2=A0 So, this would result in the following combinations:
=C2=A0 =C2=A0 - updated client talks to updated server: it expresses its ow= n
=C2=A0 =C2=A0 shift count using the last 4 bits, the server replies express= ing
=C2=A0 =C2=A0 its own shift count in the last 4 bits. Both endpoints unders= tand
=C2=A0 =C2=A0 that they are talking to updated endpoints, so they use the n= ew
=C2=A0 =C2=A0 values.
=C2=A0 =C2=A0 - updated client talks to legacy server. It expresses its own=
=C2=A0 =C2=A0 shift count using the last bits. The legacy server receives t= he
=C2=A0 =C2=A0 option, checks that the value is larger than 14 and then uses= 14
=C2=A0 =C2=A0 as shift count for this client. The server replies with its o= wn
=C2=A0 =C2=A0 shift count encoded in the first 4 bits. The client understan= ds
=C2=A0 =C2=A0 that the server is legacy and uses a 14 shift count for its o= wn
=C2=A0 =C2=A0 shift count.
=C2=A0 =C2=A0 - legacy client talking to legacy or updated server, behaves = as
=C2=A0 =C2=A0 described in RFC7323

=C2=A0 =C2=A0 If we do this, then when both endpoints are updated, one of t= he
=C2=A0 =C2=A0 endpoints can use a smaller shift count even if the other end= point
=C2=A0 =C2=A0 uses a 15 shift count. This doesnt help in the situation wher= e the
=C2=A0 =C2=A0 server is legacy, but at least in the long run if this extens= ion
=C2=A0 =C2=A0 is widely deployed, the behaviour is the desired one.

=C2=A0 =C2=A0 what do you think?


I've thought about it and I think it's a pretty good idea. It's= more explicit than the current scheme, but doesn't consume extra optio= n space.
In this scheme, when an updated endpoint talks to a non-updated endpoint, t= he shift count will automatically 14. But, I guess this cannot be solved wi= thout adding extra negotiation scheme. So, I think it's acceptable.
One question I have is if we need to use 4bits for this. It might be ok to = use just one bit in the last 4 bits to indicate it supports new version.

agree.
So, the shift count field in the WSO could then look like this:

+----------+
|SSSS|L|RRR|
+----------+

With SSSS being 4 bits used to express the shift count, L, being the bit to= express the Large window support and RRR 3 reserved bits.

Makes sense?

Yes, make sense to me. Tha= nks!
--
Yoshi
--001a113cf800a6b68f05468d23c5-- From nobody Mon Jan 30 00:22:21 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93581204D9 for ; Mon, 30 Jan 2017 00:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC4lChEq-duu for ; Mon, 30 Jan 2017 00:22:18 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89821293F5 for ; Mon, 30 Jan 2017 00:22:17 -0800 (PST) Received: from mail-ot0-f173.google.com (mail-ot0-f173.google.com [74.125.82.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 68A41278805 for ; Mon, 30 Jan 2017 17:22:15 +0900 (JST) Received: by mail-ot0-f173.google.com with SMTP id 32so78897785oth.3 for ; Mon, 30 Jan 2017 00:22:15 -0800 (PST) X-Gm-Message-State: AIkVDXJKoNwlumCHcRZqhPFcLgF5nKDIil4z4xMPUpweXTEu/MbkrH7zR1xbN/XFISCU3OGEeKAEpaAznmHrZw== X-Received: by 10.157.6.164 with SMTP id 33mr8987383otx.43.1485764533957; Mon, 30 Jan 2017 00:22:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.32.234 with HTTP; Mon, 30 Jan 2017 00:22:13 -0800 (PST) In-Reply-To: <148576349694.29928.12666861093651236401.idtracker@ietfa.amsl.com> References: <148576349694.29928.12666861093651236401.idtracker@ietfa.amsl.com> From: Yoshifumi Nishida Date: Mon, 30 Jan 2017 00:22:13 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04f74e443f8305474b8378 Archived-At: Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-maxwin-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 08:22:20 -0000 --94eb2c04f74e443f8305474b8378 Content-Type: text/plain; charset=UTF-8 Hello, We have integrated Marcelo's suggestions into the new version of max winsize draft. Please let us know if you have comments or questions. Thanks, -- Yoshi ---------- Forwarded message ---------- From: Date: Mon, Jan 30, 2017 at 12:04 AM Subject: I-D Action: draft-nishida-tcpm-maxwin-03.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Increasing Maximum Window Size of TCP Authors : Yoshifumi Nishida Hirochika Asai Marcelo Bagnulo Filename : draft-nishida-tcpm-maxwin-03.txt Pages : 7 Date : 2017-01-30 Abstract: This document proposes to increase the current max window size allowed in TCP. It describes the current logic that limits the maximum window size and provides a rationale to relax the limitation as well as the negotiation mechanism to enable this feature safely. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nishida-tcpm-maxwin/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-nishida-tcpm-maxwin-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-nishida-tcpm-maxwin-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --94eb2c04f74e443f8305474b8378 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
We have integrated Marcelo's sug= gestions into the new version of max winsize draft.
Please let us= know if you have comments or questions.

Thanks,
--
Yoshi

= ---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Jan 30, 2017 at 12:04= AM
Subject: I-D Action: draft-nishida-tcpm-maxwin-03.txt
To: i-d-announce@ietf.org



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


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Increasing Maximum Window Size of TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hirochika Asai
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marcelo Bagnulo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-maxwin-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-30

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


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-nishi= da-tcpm-maxwin-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-nishida-tcpm-maxwin-03


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--94eb2c04f74e443f8305474b8378--