From nobody Mon Jan 4 11:55:59 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF681A90DB for ; Mon, 4 Jan 2016 11:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIh4ASmm74rj for ; Mon, 4 Jan 2016 11:55:56 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234FA1A90ED for ; Mon, 4 Jan 2016 11:55:56 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u04JnJcf019822; Mon, 4 Jan 2016 11:49:19 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 84B85363BB00; Mon, 4 Jan 2016 14:49:18 -0500 (EST) To: RFC Errata System From: Mark Allman In-Reply-To: <20151222101825.27A22180004@rfc-editor.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Mama Kin X-URL-0: http://www.icir.org/mallman-files/Document46419.jpg X-URL-1: http://www.icir.org/mallman-files/Document6649.html X-URL-2: http://www.icir.org/mallman-files/Document55604.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Jan 2016 14:49:18 -0500 Message-ID: <31029.1451936958@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, nmalykh@gmail.com, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 19:55:57 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Yep- this is a small error that could well be noted in the RFC errata. I looked at it has its roots in RFC 2414 (the RFC that 3390 obsoleted). So, you might as well add a note to that one, too. allman > The following errata report has been submitted for RFC3390, > "Increasing TCP's Initial Window". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3390&eid=3D4569 >=20 > -------------------------------------- > Type: Technical > Reported by: Nikolai Malykh >=20 > Section: 8.1 >=20 > Original Text > ------------- > A second set of experiments explored TCP performance over dialup > modem links. In experiments over a 28.8 bps dialup channel [All97a, > AHO98], a four-segment initial window decreased the transfer time of > a 16KB file by roughly 10%, with no accompanying increase in the drop > rate. A simulation study [RFC2416] investigated the effects of using > a larger initial window on a host connected by a slow modem link and > a router with a 3 packet buffer. The study concluded that for the > scenario investigated, the use of larger initial windows was not > harmful to TCP performance. >=20 > Corrected Text > -------------- > A second set of experiments explored TCP performance over dialup > modem links. In experiments over a 28.8 Kbps dialup channel [All97a, > AHO98], a four-segment initial window decreased the transfer time of > a 16KB file by roughly 10%, with no accompanying increase in the drop > rate. A simulation study [RFC2416] investigated the effects of using > a larger initial window on a host connected by a slow modem link and > a router with a 3 packet buffer. The study concluded that for the > scenario investigated, the use of larger initial windows was not > harmful to TCP performance. >=20 > Notes > ----- > Error bit rate - bps instead of Kbps. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3390 (draft-ietf-tsvwg-initwin-04) > -------------------------------------- > Title: Increasing TCP's Initial Window > Publication Date : October 2002 > Author(s): M. Allman, S. Floyd, C. Partridge > Category: PROPOSED STANDARD > Source: Transport Area Working Group > Area: Transport > Stream: IETF > Verifying Party : IESG --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaKzL4ACgkQWyrrWs4yIs4rBgCfXrAIGeLbiKSaNL1WgdJH/fMh PRwAn1GrpL1U2Wz1V4tudAtTAM20Uq+w =zQDC -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jan 4 12:35:10 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3541A9238 for ; Mon, 4 Jan 2016 12:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z50ls2U44C-3 for ; Mon, 4 Jan 2016 12:35:04 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id BF3871A9173 for ; Mon, 4 Jan 2016 12:35:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YKJxDKKGXsepBdHhkBoQAYa8K5IrFrpy32IM2J+M9HZGLaaXwcnY49AvRrReynBM; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [50.136.188.174] (helo=[10.0.0.5]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1aGBpV-0003bh-Ro; Mon, 04 Jan 2016 15:34:14 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mitchell Erblich In-Reply-To: <31029.1451936958@lawyers.icir.org> Date: Mon, 4 Jan 2016 12:34:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31029.1451936958@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1878.6) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79fc98516f39f944b318cba6503fa21f8c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 50.136.188.174 Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, nmalykh@gmail.com, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org, RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 20:35:07 -0000 Mark Allman and group, As a later follow-up=85. Wouldn=92t it make sense to mention that TCP=92s Reno=92s = Fast Re-transmit=94 capability suggests that initial increases of the = initial window should generate earlier detection of congestion because = of the non-wait of the coarse timeout ,, assuming that the number of Dup = ACKs is adjusted accordingly? Mitchell Erblich On Jan 4, 2016, at 11:49 AM, Mark Allman wrote: >=20 > Yep- this is a small error that could well be noted in the RFC > errata. >=20 > I looked at it has its roots in RFC 2414 (the RFC that 3390 > obsoleted). So, you might as well add a note to that one, too. >=20 > allman >=20 >=20 >=20 >> The following errata report has been submitted for RFC3390, >> "Increasing TCP's Initial Window". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D3390&eid=3D4569 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Nikolai Malykh >>=20 >> Section: 8.1 >>=20 >> Original Text >> ------------- >> A second set of experiments explored TCP performance over dialup >> modem links. In experiments over a 28.8 bps dialup channel = [All97a, >> AHO98], a four-segment initial window decreased the transfer time = of >> a 16KB file by roughly 10%, with no accompanying increase in the = drop >> rate. A simulation study [RFC2416] investigated the effects of = using >> a larger initial window on a host connected by a slow modem link = and >> a router with a 3 packet buffer. The study concluded that for the >> scenario investigated, the use of larger initial windows was not >> harmful to TCP performance. >>=20 >> Corrected Text >> -------------- >> A second set of experiments explored TCP performance over dialup >> modem links. In experiments over a 28.8 Kbps dialup channel = [All97a, >> AHO98], a four-segment initial window decreased the transfer time = of >> a 16KB file by roughly 10%, with no accompanying increase in the = drop >> rate. A simulation study [RFC2416] investigated the effects of = using >> a larger initial window on a host connected by a slow modem link = and >> a router with a 3 packet buffer. The study concluded that for the >> scenario investigated, the use of larger initial windows was not >> harmful to TCP performance. >>=20 >> Notes >> ----- >> Error bit rate - bps instead of Kbps. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC3390 (draft-ietf-tsvwg-initwin-04) >> -------------------------------------- >> Title: Increasing TCP's Initial Window >> Publication Date : October 2002 >> Author(s): M. Allman, S. Floyd, C. Partridge >> Category: PROPOSED STANDARD >> Source: Transport Area Working Group >> Area: Transport >> Stream: IETF >> Verifying Party : IESG >=20 >=20 >=20 >=20 From nobody Mon Jan 4 12:48:22 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7452D1A92B6 for ; Mon, 4 Jan 2016 12:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlaGrsZl2tG1 for ; Mon, 4 Jan 2016 12:48:20 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9472C1A92B5 for ; Mon, 4 Jan 2016 12:48:20 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u04Km3kC027402; Mon, 4 Jan 2016 12:48:04 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B324D363E541; Mon, 4 Jan 2016 15:48:02 -0500 (EST) To: Mitchell Erblich From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Mama Kin X-URL-0: http://www.icir.org/mallman-files/Document54296.html X-URL-1: http://www.icir.org/mallman-files/Document78536.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Jan 2016 15:48:02 -0500 Message-ID: <49015.1451940482@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, nmalykh@gmail.com, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org, RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 20:48:21 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Wouldn=E2=80=99t it make sense to mention that TCP=E2=80=99s Reno=E2=80= =99s > Fast Re-transmit=E2=80=9D capability suggests that initial > increases of the initial window should generate > earlier detection of congestion because of the > non-wait of the coarse timeout ,, assuming that the > number of Dup ACKs is adjusted accordingly?=20 I am too old and have written too many words in my life to remember precisely---and I don't have time to look---but presumably we said something along these lines? And, if not, it is more than an errata, IMHO. (There is nothing about adjusting the dup ACK threshold in 3390, I am sure. That is in RFC 5827.) allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaK2oIACgkQWyrrWs4yIs4TvgCfUQEQwBdEpWnHM8dhebxYXMY4 SP8AnihxIsyba7ksP8NLmEiIhlJ8BnkJ =nu6X -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jan 4 17:05:15 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2FC1ACE03 for ; Mon, 4 Jan 2016 17:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLByKr4MnEMw for ; Mon, 4 Jan 2016 17:05:12 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC601ACE07 for ; Mon, 4 Jan 2016 17:05:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5894E1E5A34; Mon, 4 Jan 2016 17:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shGkkauK6XQs; Mon, 4 Jan 2016 17:04:39 -0800 (PST) Received: from [10.0.1.12] (pool-108-48-203-211.washdc.fios.verizon.net [108.48.203.211]) by c8a.amsl.com (Postfix) with ESMTPA id 4F8DA1E5A32; Mon, 4 Jan 2016 17:04:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <1008031961.4121046.1450829876023.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 4 Jan 2016 20:05:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1008031961.4121046.1450829876023.JavaMail.yahoo.ref@mail.yahoo.com> <1008031961.4121046.1450829876023.JavaMail.yahoo@mail.yahoo.com> To: lloyd.wood@yahoo.co.uk X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, nmalykh@gmail.com, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org, mallman@bbn.com, RFC System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:05:14 -0000 Lloyd, We believe we have updated as intended. Please review the report as = listed at http://www.rfc-editor.org/errata_search.php?rfc=3D3390&eid=3D456= 9 and let us know any objections. Thank you. RFC Editor/mf On Dec 22, 2015, at 7:17 PM, lloyd.wood@yahoo.co.uk wrote: > Should actually be lower case k kbps (for 1000, not 1024 or Kibps.) >=20 > Lloyd Wood > lloyd.wood@yahoo.co.uk > http://about.me/lloydwood=20 >=20 > -------------------------------------------- > On Tue, 22/12/15, RFC Errata System wrote: >=20 > Subject: [tsvwg] [Technical Errata Reported] RFC3390 (4569) > To: mallman@bbn.com, floyd@icir.org, craig@bbn.com, = spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, = david.black@emc.com > Cc: tsvwg@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org > Date: Tuesday, 22 December, 2015, 21:18 >=20 > The following errata report has been > submitted for RFC3390, > "Increasing TCP's Initial Window". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3390&eid=3D4569 >=20 > -------------------------------------- > Type: Technical > Reported by: Nikolai Malykh >=20 > Section: 8.1 >=20 > Original Text > ------------- > A second set of experiments explored TCP > performance over dialup > modem links. In experiments over a > 28.8 bps dialup channel [All97a, > AHO98], a four-segment initial window > decreased the transfer time of > a 16KB file by roughly 10%, with no > accompanying increase in the drop > rate. A simulation study [RFC2416] > investigated the effects of using > a larger initial window on a host > connected by a slow modem link and > a router with a 3 packet buffer. The > study concluded that for the > scenario investigated, the use of larger > initial windows was not > harmful to TCP performance. >=20 > Corrected Text > -------------- > A second set of experiments explored TCP > performance over dialup > modem links. In experiments over a > 28.8 Kbps dialup channel [All97a, > AHO98], a four-segment initial window > decreased the transfer time of > a 16KB file by roughly 10%, with no > accompanying increase in the drop > rate. A simulation study [RFC2416] > investigated the effects of using > a larger initial window on a host > connected by a slow modem link and > a router with a 3 packet buffer. The > study concluded that for the > scenario investigated, the use of larger > initial windows was not > harmful to TCP performance. >=20 > Notes > ----- > Error bit rate - bps instead of Kbps. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If > necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > (IESG) > can log in to change the status and edit the report, if > necessary.=20 >=20 > -------------------------------------- > RFC3390 (draft-ietf-tsvwg-initwin-04) > -------------------------------------- > Title =20 > : Increasing TCP's Initial Window > Publication Date : October 2002 > Author(s) : M. > Allman, S. Floyd, C. Partridge > Category : PROPOSED > STANDARD > Source : > Transport Area Working Group > Area =20 > : Transport > Stream : > IETF > Verifying Party : IESG >=20 >=20 From nobody Mon Jan 4 17:05:51 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2181AC3CE for ; Mon, 4 Jan 2016 13:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccDS_3TOW7e9 for ; Mon, 4 Jan 2016 13:38:24 -0800 (PST) Received: from aland.bbn.com (aland.bbn.com [50.245.101.242]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269F81AC3CA for ; Mon, 4 Jan 2016 13:38:24 -0800 (PST) Received: from aland.bbn.com (unknown [50.245.101.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by aland.bbn.com (Postfix) with ESMTPS id 10961420241; Mon, 4 Jan 2016 16:38:32 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_F74E68A3-69ED-4BE8-BC2F-E52E2CCE2CA5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Craig Partridge In-Reply-To: <49015.1451940482@lawyers.icir.org> Date: Mon, 4 Jan 2016 16:38:22 -0500 Message-Id: <4EBD4A5A-9BFB-4D67-866C-3B171C1B945A@aland.bbn.com> References: <49015.1451940482@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3112) Archived-At: X-Mailman-Approved-At: Mon, 04 Jan 2016 17:05:50 -0800 Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, nmalykh@gmail.com, Craig Partridge , mls.ietf@gmail.com, tsvwg@ietf.org, RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:38:25 -0000 --Apple-Mail=_F74E68A3-69ED-4BE8-BC2F-E52E2CCE2CA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My view is errata is for technical nits that matter =E2=80=94 not = discussion or editorial improvement. Speaking for myself (not as a member of the RFC Editorial Board). Thanks! Craig > On Jan 4, 2016, at 3:48 PM, Mark Allman wrote: >=20 >=20 >> Wouldn=E2=80=99t it make sense to mention that TCP=E2=80=99= s Reno=E2=80=99s >> Fast Re-transmit=E2=80=9D capability suggests that = initial >> increases of the initial window should generate >> earlier detection of congestion because of the >> non-wait of the coarse timeout ,, assuming that the >> number of Dup ACKs is adjusted accordingly?=20 >=20 > I am too old and have written too many words in my life to remember > precisely---and I don't have time to look---but presumably we said > something along these lines? And, if not, it is more than an > errata, IMHO. >=20 > (There is nothing about adjusting the dup ACK threshold in 3390, I > am sure. That is in RFC 5827.) >=20 > allman >=20 >=20 >=20 --Apple-Mail=_F74E68A3-69ED-4BE8-BC2F-E52E2CCE2CA5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDYzCCA18w ggLIoAMCAQICAUkwDQYJKoZIhvcNAQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNz YWNodXNldHRzMRkwFwYDVQQKExBCQk4gVGVjaG5vbG9naWVzMSkwJwYDVQQLEyBJbnRlcm5ldHdv cmsgUmVzZWFyY2ggRGVwYXJ0bWVudDETMBEGA1UEAxMKaXIuYmJuLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAaXIuYmJuLmNvbTAeFw0xNTExMDUxNTMyNTlaFw0xNzExMDQxNTMyNTlaMEsxCzAJBgNV BAYTAlVTMRgwFgYDVQQDDA9DcmFpZyBQYXJ0cmlkZ2UxIjAgBgkqhkiG9w0BCQEWE2NyYWlnQGFs YW5kLmJibi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChO7MrEuCJnHHzpWZy nKE4Z141Bo5qZiQka82ZCdi+mOUoQ7DiCyrB/A4STXzowX1vrIfISZkYOSSGZd/e23Zc2moDqio2 Kb7mm/lTofourMXB4NBfKWUpU7chZyCuMLDvTxTmr+j3ZaKFciTTy1ig8o4f4oGsa4rm2fl2RiPJ qHKUHqiojHHmQCTXxkZ64dhdH8qtTTJJUBndaSHZhgO4X1q+oaumTqT1RVD7WWjUlsbm/yNhyCwb SpM9mX67B0Cem3C5aJCuCsDYYQinuYGtl1i7253QHrVBmgdHw0h8KUUB6wXLRdOk3UB+5Gb7W8lt dotDK7a8NZZ4RHEnUZ91AgMBAAGjezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5T U0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBS/E5FapkcmC78ZtYfKHQUsPN8g9zAf BgNVHSMEGDAWgBQl4GPv5M7chfnVViumbLo6gfwL8jANBgkqhkiG9w0BAQUFAAOBgQAQ1/BwcxOY xPhsXegJEKgVIdp0kDmkx2ZCyj2ulWclBM+KiPHuKhjtiIxIEQeCf4vcKXGp23zwQA2mhpjxQEYB zqyU8ZMBhZpERvAHsBm3lOqMTbB84q0uL+ydaxUJb2v/lGmJLvosliNhGOd0m8jU84Zs8oGMmNZ6 eShal4i6PTGCA58wggObAgEBMIGkMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVz ZXR0czEZMBcGA1UEChMQQkJOIFRlY2hub2xvZ2llczEpMCcGA1UECxMgSW50ZXJuZXR3b3JrIFJl c2VhcmNoIERlcGFydG1lbnQxEzARBgNVBAMTCmlyLmJibi5jb20xHDAaBgkqhkiG9w0BCQEWDWNh QGlyLmJibi5jb20CAUkwCQYFKw4DAhoFAKCCAc8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTYwMTA0MjEzODIzWjAjBgkqhkiG9w0BCQQxFgQUgaMhI+BeWc2k6Ix2 dviukx7UKfgwgbUGCSsGAQQBgjcQBDGBpzCBpDCBnjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1h c3NhY2h1c2V0dHMxGTAXBgNVBAoTEEJCTiBUZWNobm9sb2dpZXMxKTAnBgNVBAsTIEludGVybmV0 d29yayBSZXNlYXJjaCBEZXBhcnRtZW50MRMwEQYDVQQDEwppci5iYm4uY29tMRwwGgYJKoZIhvcN AQkBFg1jYUBpci5iYm4uY29tAgFJMIG3BgsqhkiG9w0BCRACCzGBp6CBpDCBnjELMAkGA1UEBhMC VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxGTAXBgNVBAoTEEJCTiBUZWNobm9sb2dpZXMxKTAn BgNVBAsTIEludGVybmV0d29yayBSZXNlYXJjaCBEZXBhcnRtZW50MRMwEQYDVQQDEwppci5iYm4u Y29tMRwwGgYJKoZIhvcNAQkBFg1jYUBpci5iYm4uY29tAgFJMA0GCSqGSIb3DQEBAQUABIIBACtJ HXnhTHaXTUHCFw+emeSbVHdOrVV0F8vN8wUSiP+rgjZ9I52QUguiTwF1Ksc4imTzDrjb9LIA6SYj ewMwcv8KTHOGt+bXjnBh+hIi1PU3GIP0/VW8RKRgEG/aZltk/Udj0nT3Y689/XeDeSCdUsVaHH25 6FbMRVGpfxHo+LtDpB/WAvhJgYf0Yre2VR4EOUTSaZjfpGUQPaU4YD78yFQvNoAwbsaoJ+k+ZtAQ wiq8OD3prhKeefROHjNAekM+hcofk0z8vi7Q363PjCp8j+4QPk/b7ayhUnu41KNAqu69K5j4wgPe eJ3fEU2OZ7Z8PZ+L9Ne7YI2RRG7aWie9b4cAAAAAAAA= --Apple-Mail=_F74E68A3-69ED-4BE8-BC2F-E52E2CCE2CA5-- From nobody Tue Jan 5 21:42:44 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCE11A9308 for ; Tue, 5 Jan 2016 21:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKi9_es2UHTR for ; Tue, 5 Jan 2016 21:42:40 -0800 (PST) Received: from nm25-vm4.bullet.mail.ir2.yahoo.com (nm25-vm4.bullet.mail.ir2.yahoo.com [212.82.97.37]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366951ABB1A for ; Tue, 5 Jan 2016 21:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1452058958; bh=lG9xkvgf8670+mq4ebyzpFLw/1/3azUyy0ctXJVEuvk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=siHFRm5fczzSDqC1WGjpdEN69g/xymIwPs66ysgCAr+KoUJW6xZhRtswuh3kBU6WorERr+9HULROxelueg8YcPe1CVmPjVbre6Yo70ZyykshEXYDCoS/422sdNREoVgFOWNj9xv05Zvo3tw/dJmj0OTVozrxPIBxOSOAMS9jE9ZsuS9HQoLE2XltIn9T16m6V4lQLoZjKO8dyjTRhi8u/bZ9p9cQsGu4kKi70X4BjXFC/rar8PCYkAywmz4Q92cBHcxg10oQdt2gen361g3zRl4G4MqcIM0LTgXwt/TUkN/zIWVKjITBUczyGGpvEsqamI/jYc066wZ+S91VJN+b5w== Received: from [212.82.98.56] by nm25.bullet.mail.ir2.yahoo.com with NNFMP; 06 Jan 2016 05:42:38 -0000 Received: from [212.82.98.81] by tm9.bullet.mail.ir2.yahoo.com with NNFMP; 06 Jan 2016 05:42:38 -0000 Received: from [127.0.0.1] by omp1018.mail.ir2.yahoo.com with NNFMP; 06 Jan 2016 05:42:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 307423.35254.bm@omp1018.mail.ir2.yahoo.com X-YMail-OSG: ZES9wmcVM1l3rRx5gvTTjs9_XQ1h37tjNzu_57KT.2cGt4j5rXyn0azeVz0AkuD ABczlQW.t9e64T6pGKILG1YjOmyTl9wPJrV_XE_WmdDY9SsdLI1RvDswd5e6qBQ4dIut3N.1nGFy jgD2jbZLiSKKvb9QrJvOyQ.Lo5sz.XInmLP_2xvXdwrQ8KcIm9weJn_ezbrnhShtSwMYP9aPYrdn 0OS1.Clpde9gAyYVm4Cp4Ge59O2z3kwYLb_jfZy4s8icu7wwRZ9GnripBwOF6CanS2baKf_kVLnN nPgObROanRItO7ruPqxTAKui8i93Vw9YzC.mYFrjBHJfw8RQmdCryfArT2bP7oStMHXXS9dI34yL 1bQ69X0mRsmsQbn_TGLiVKT2tA.aEViI5BdWjJsj3gJW_z7EHl46OR6N6yewUtx8BoqPYPZEdeis XOCVaR_aPHx9vGSy_HVV31QC9haZNui1076ePJdyU4YT_sGbkKFdRx5QctYlRXsWXWN4neZdNTrj h2M4sDJE1ab4X5_igWc7aye7LKR3OCwZM_Fs- Received: by 212.82.98.116; Wed, 06 Jan 2016 05:42:37 +0000 Date: Wed, 6 Jan 2016 05:42:18 +0000 (UTC) From: To: Megan Ferguson Message-ID: <169720239.2158786.1452058938324.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "floyd@icir.org" , "nmalykh@gmail.com" , "craig@bbn.com" , "mls.ietf@gmail.com" , "tsvwg@ietf.org" , "mallman@bbn.com" , RFC System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lloyd.wood@yahoo.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 05:42:42 -0000 Megan, please also raise this as an erratum to the earlier RFC 2414, as allman points out. Credit again to Nikolai. RFC 2414: *** A second set of experiments has explored TCP performance over dialup modem links. In experiments over a 28.8 bps dialup channel [All97a, AHO98],*** there should be *** A second set of experiments has explored TCP performance over dialup modem links. In experiments over a 28.8 kbps dialup channel [All97a, AHO98],*** Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood ----- Original Message ----- From: Megan Ferguson To: lloyd.wood@yahoo.co.uk Cc: mallman@bbn.com; floyd@icir.org; craig@bbn.com; spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com; gorry@erg.abdn.ac.uk; david.black@emc.com; RFC System ; tsvwg@ietf.org; nmalykh@gmail.com Sent: Tuesday, 5 January 2016, 12:05 Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) Lloyd, We believe we have updated as intended. Please review the report as listed at http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4569 and let us know any objections. Thank you. RFC Editor/mf On Dec 22, 2015, at 7:17 PM, lloyd.wood@yahoo.co.uk wrote: > Should actually be lower case k kbps (for 1000, not 1024 or Kibps.) > > Lloyd Wood > lloyd.wood@yahoo.co.uk > http://about.me/lloydwood > > -------------------------------------------- > On Tue, 22/12/15, RFC Errata System wrote: > > Subject: [tsvwg] [Technical Errata Reported] RFC3390 (4569) > To: mallman@bbn.com, floyd@icir.org, craig@bbn.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com > Cc: tsvwg@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org > Date: Tuesday, 22 December, 2015, 21:18 > > The following errata report has been > submitted for RFC3390, > "Increasing TCP's Initial Window". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4569 > > -------------------------------------- > Type: Technical > Reported by: Nikolai Malykh > > Section: 8.1 > > Original Text > ------------- > A second set of experiments explored TCP > performance over dialup > modem links. In experiments over a > 28.8 bps dialup channel [All97a, > AHO98], a four-segment initial window > decreased the transfer time of > a 16KB file by roughly 10%, with no > accompanying increase in the drop > rate. A simulation study [RFC2416] > investigated the effects of using > a larger initial window on a host > connected by a slow modem link and > a router with a 3 packet buffer. The > study concluded that for the > scenario investigated, the use of larger > initial windows was not > harmful to TCP performance. > > Corrected Text > -------------- > A second set of experiments explored TCP > performance over dialup > modem links. In experiments over a > 28.8 Kbps dialup channel [All97a, > AHO98], a four-segment initial window > decreased the transfer time of > a 16KB file by roughly 10%, with no > accompanying increase in the drop > rate. A simulation study [RFC2416] > investigated the effects of using > a larger initial window on a host > connected by a slow modem link and > a router with a 3 packet buffer. The > study concluded that for the > scenario investigated, the use of larger > initial windows was not > harmful to TCP performance. > > Notes > ----- > Error bit rate - bps instead of Kbps. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If > necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > (IESG) > can log in to change the status and edit the report, if > necessary. > > -------------------------------------- > RFC3390 (draft-ietf-tsvwg-initwin-04) > -------------------------------------- > Title > : Increasing TCP's Initial Window > Publication Date : October 2002 > Author(s) : M. > Allman, S. Floyd, C. Partridge > Category : PROPOSED > STANDARD > Source : > Transport Area Working Group > Area > : Transport > Stream : > IETF > Verifying Party : IESG > > From nobody Wed Jan 6 10:55:39 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59A11A00F0 for ; Wed, 6 Jan 2016 10:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn51GXXMXk4n for ; Wed, 6 Jan 2016 10:55:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6E48C1A00EA for ; Wed, 6 Jan 2016 10:55:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 07BA7180011; Wed, 6 Jan 2016 10:54:38 -0800 (PST) To: mallman@bbn.com, floyd@icir.org, craig@bbn.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160106185438.07BA7180011@rfc-editor.org> Date: Wed, 6 Jan 2016 10:54:38 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org, touch@isi.edu Subject: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:55:36 -0000 The following errata report has been submitted for RFC3390, "Increasing TCP's Initial Window". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4583 -------------------------------------- Type: Technical Reported by: Joe Touch Section: 1. Original Text ------------- This increased initial window is optional: a TCP MAY start with a larger initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above. Corrected Text -------------- This increased initial window is optional: a TCP MAY start with a smaller initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above. Notes ----- The MAY allows use of values smaller than this document allows, not larger. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3390 (draft-ietf-tsvwg-initwin-04) -------------------------------------- Title : Increasing TCP's Initial Window Publication Date : October 2002 Author(s) : M. Allman, S. Floyd, C. Partridge Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Jan 6 11:16:20 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A2B1A0119 for ; Wed, 6 Jan 2016 11:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcXXEoaQnd6a for ; Wed, 6 Jan 2016 11:16:17 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603791A0114 for ; Wed, 6 Jan 2016 11:16:17 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u06J9XrC007352; Wed, 6 Jan 2016 11:09:33 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 922293680213; Wed, 6 Jan 2016 14:09:32 -0500 (EST) To: RFC Errata System From: Mark Allman In-Reply-To: <20160106185438.07BA7180011@rfc-editor.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document90816.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jan 2016 14:09:32 -0500 Message-ID: <15654.1452107372@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, touch@isi.edu, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:16:19 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This is clearly a correction to the document. The intent of the authors and the WG was never to allow the initial window to be higher than given in the document. (It was hard enough to get folks to accept an initial window of 2-4 segments. It'd have been impossible to get the community to agree to leave an explicit escape hatch for larger values.) This error also applies to RFC 2414 (where the text originated). allman > The following errata report has been submitted for RFC3390, > "Increasing TCP's Initial Window". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3390&eid=3D4583 >=20 > -------------------------------------- > Type: Technical > Reported by: Joe Touch >=20 > Section: 1. >=20 > Original Text > ------------- > This increased initial window is optional: a TCP MAY start with a > larger initial window. However, we expect that most general-purpose > TCP implementations would choose to use the larger initial congestion > window given in equation (1) above. >=20 > Corrected Text > -------------- > This increased initial window is optional: a TCP MAY start with a > smaller initial window. However, we expect that most general-purpose > TCP implementations would choose to use the larger initial congestion > window given in equation (1) above. >=20 > Notes > ----- > The MAY allows use of values smaller than this document allows, not large= r. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3390 (draft-ietf-tsvwg-initwin-04) > -------------------------------------- > Title: Increasing TCP's Initial Window > Publication Date : October 2002 > Author(s): M. Allman, S. Floyd, C. Partridge > Category: PROPOSED STANDARD > Source: Transport Area Working Group > Area: Transport > Stream: IETF > Verifying Party : IESG --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaNZmwACgkQWyrrWs4yIs5trQCfah9P9pPCss8rbByrjgZNCH8l 2SQAn2LMiIrATj9LjAyRa2dAEuJxsT7W =sIAv -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jan 6 11:20:34 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA89E1A0126 for ; Wed, 6 Jan 2016 11:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEW8TVtCWJbM for ; Wed, 6 Jan 2016 11:20:30 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809D11A011D for ; Wed, 6 Jan 2016 11:20:30 -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 u06JJAcF012152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 11:19:12 -0800 (PST) To: mallman@icir.org, RFC Errata System References: <15654.1452107372@lawyers.icir.org> From: Joe Touch Message-ID: <568D68AE.5040407@isi.edu> Date: Wed, 6 Jan 2016 11:19:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <15654.1452107372@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, touch@isi.edu, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:20:33 -0000 On 1/6/2016 11:09 AM, Mark Allman wrote: > > This is clearly a correction to the document. The intent of the > authors and the WG was never to allow the initial window to be > higher than given in the document. (It was hard enough to get folks > to accept an initial window of 2-4 segments. It'd have been > impossible to get the community to agree to leave an explicit escape > hatch for larger values.) > > This error also applies to RFC 2414 (where the text originated). Agreed, but since 2414 is obsoleted by 3390, do we also need an errata there too? Joe > > allman > > > >> The following errata report has been submitted for RFC3390, >> "Increasing TCP's Initial Window". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4583 >> >> -------------------------------------- >> Type: Technical >> Reported by: Joe Touch >> >> Section: 1. >> >> Original Text >> ------------- >> This increased initial window is optional: a TCP MAY start with a >> larger initial window. However, we expect that most general-purpose >> TCP implementations would choose to use the larger initial congestion >> window given in equation (1) above. >> >> Corrected Text >> -------------- >> This increased initial window is optional: a TCP MAY start with a >> smaller initial window. However, we expect that most general-purpose >> TCP implementations would choose to use the larger initial congestion >> window given in equation (1) above. >> >> Notes >> ----- >> The MAY allows use of values smaller than this document allows, not larger. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3390 (draft-ietf-tsvwg-initwin-04) >> -------------------------------------- >> Title: Increasing TCP's Initial Window >> Publication Date : October 2002 >> Author(s): M. Allman, S. Floyd, C. Partridge >> Category: PROPOSED STANDARD >> Source: Transport Area Working Group >> Area: Transport >> Stream: IETF >> Verifying Party : IESG > > > > From nobody Wed Jan 6 11:35:12 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0621A0161 for ; Wed, 6 Jan 2016 11:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgWLZVcp9GaR for ; Wed, 6 Jan 2016 11:35:08 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE3C1A016A for ; Wed, 6 Jan 2016 11:35:08 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u06JSYQI009052; Wed, 6 Jan 2016 11:28:34 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7D20B36805BC; Wed, 6 Jan 2016 14:28:33 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <568D68AE.5040407@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document136.jpg X-URL-1: http://www.icir.org/mallman-files/Document61103.doc X-URL-2: http://www.icir.org/mallman-files/Document27654.html X-URL-3: http://www.icir.org/mallman-files/Document62610.pdf X-URL-4: http://www.icir.org/mallman-files/Document42110.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jan 2016 14:28:33 -0500 Message-ID: <19287.1452108513@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org, RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:35:11 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > On 1/6/2016 11:09 AM, Mark Allman wrote: > >=20 > > This is clearly a correction to the document. The intent of the > > authors and the WG was never to allow the initial window to be > > higher than given in the document. (It was hard enough to get folks > > to accept an initial window of 2-4 segments. It'd have been > > impossible to get the community to agree to leave an explicit escape > > hatch for larger values.) > >=20 > > This error also applies to RFC 2414 (where the text originated). >=20 > Agreed, but since 2414 is obsoleted by 3390, do we also need an errata > there too? Someone else more pedantic that I can decide that. If we're going to the trouble it seems like it is low cost to flag it for RFC 2414, too. But, I for damn sure will not fight about it. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaNauEACgkQWyrrWs4yIs58lwCeIWhEUf5THyHerN7E8ZdgewGf NQkAnjbOLM+IPBZu2v7g2rJ56uwbr+MR =7rhM -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jan 6 11:41:25 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B7F1A0178 for ; Wed, 6 Jan 2016 11:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aECTDorBAFKW for ; Wed, 6 Jan 2016 11:41:22 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F601A0173 for ; Wed, 6 Jan 2016 11:41:22 -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 u06Jegkk018327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 11:40:43 -0800 (PST) To: mallman@icir.org References: <19287.1452108513@lawyers.icir.org> From: Joe Touch Message-ID: <568D6DBA.9060209@isi.edu> Date: Wed, 6 Jan 2016 11:40:42 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <19287.1452108513@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, touch@isi.edu, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org, RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:41:23 -0000 Well, the text in RFC2414 actually has the opposite intent: This increased initial window is optional: that a TCP MAY start with a larger initial window, not that it SHOULD. I.e., in that text it really is an admission that there's no forced restriction limiting the IW. However, in the case of 3390, that text may have been imported but I agree that was probably not the intent at that time. So, IMO, we should leave 2414 as it is. Joe On 1/6/2016 11:28 AM, Mark Allman wrote: > >> On 1/6/2016 11:09 AM, Mark Allman wrote: >>> >>> This is clearly a correction to the document. The intent of the >>> authors and the WG was never to allow the initial window to be >>> higher than given in the document. (It was hard enough to get folks >>> to accept an initial window of 2-4 segments. It'd have been >>> impossible to get the community to agree to leave an explicit escape >>> hatch for larger values.) >>> >>> This error also applies to RFC 2414 (where the text originated). >> >> Agreed, but since 2414 is obsoleted by 3390, do we also need an errata >> there too? > > Someone else more pedantic that I can decide that. If we're going > to the trouble it seems like it is low cost to flag it for RFC 2414, > too. But, I for damn sure will not fight about it. > > allman > > > From nobody Wed Jan 6 11:45:39 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717081A017E for ; Wed, 6 Jan 2016 11:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLUJ_OvuYFp6 for ; Wed, 6 Jan 2016 11:45:35 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA591A017D for ; Wed, 6 Jan 2016 11:45:35 -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 u06Jiw6p019428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 11:44:59 -0800 (PST) To: lloyd.wood@yahoo.co.uk, Megan Ferguson References: <169720239.2158786.1452058938324.JavaMail.yahoo@mail.yahoo.com> From: Joe Touch Message-ID: <568D6EBA.8090705@isi.edu> Date: Wed, 6 Jan 2016 11:44:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <169720239.2158786.1452058938324.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "floyd@icir.org" , "nmalykh@gmail.com" , touch@isi.edu, "craig@bbn.com" , "mls.ietf@gmail.com" , "mallman@bbn.com" , RFC System , "tsvwg@ietf.org" Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:45:37 -0000 FWIW, I don't think it's useful to bother updating obsoleted RFCs, esp. when their replacement is fixed (or at least has this errata). Joe On 1/5/2016 9:42 PM, lloyd.wood@yahoo.co.uk wrote: > Megan, > > please also raise this as an erratum to the earlier RFC 2414, as allman points out. > Credit again to Nikolai. > > RFC 2414: > *** > A second set of experiments has explored TCP performance over dialup > modem links. In experiments over a 28.8 bps dialup channel [All97a, > AHO98],*** > there should be > > *** > A second set of experiments has explored TCP performance over dialup > modem links. In experiments over a 28.8 kbps dialup channel [All97a, > AHO98],*** > > Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood > > > ----- Original Message ----- > From: Megan Ferguson > To: lloyd.wood@yahoo.co.uk > Cc: mallman@bbn.com; floyd@icir.org; craig@bbn.com; spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com; gorry@erg.abdn.ac.uk; david.black@emc.com; RFC System ; tsvwg@ietf.org; nmalykh@gmail.com > Sent: Tuesday, 5 January 2016, 12:05 > Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) > > Lloyd, > > We believe we have updated as intended. Please review the report as listed at http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4569 and let us know any objections. > > Thank you. > > RFC Editor/mf > > > On Dec 22, 2015, at 7:17 PM, lloyd.wood@yahoo.co.uk wrote: > >> Should actually be lower case k kbps (for 1000, not 1024 or Kibps.) >> >> Lloyd Wood >> lloyd.wood@yahoo.co.uk >> http://about.me/lloydwood >> >> -------------------------------------------- >> On Tue, 22/12/15, RFC Errata System wrote: >> >> Subject: [tsvwg] [Technical Errata Reported] RFC3390 (4569) >> To: mallman@bbn.com, floyd@icir.org, craig@bbn.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com >> Cc: tsvwg@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org >> Date: Tuesday, 22 December, 2015, 21:18 >> >> The following errata report has been >> submitted for RFC3390, >> "Increasing TCP's Initial Window". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4569 >> >> -------------------------------------- >> Type: Technical >> Reported by: Nikolai Malykh >> >> Section: 8.1 >> >> Original Text >> ------------- >> A second set of experiments explored TCP >> performance over dialup >> modem links. In experiments over a >> 28.8 bps dialup channel [All97a, >> AHO98], a four-segment initial window >> decreased the transfer time of >> a 16KB file by roughly 10%, with no >> accompanying increase in the drop >> rate. A simulation study [RFC2416] >> investigated the effects of using >> a larger initial window on a host >> connected by a slow modem link and >> a router with a 3 packet buffer. The >> study concluded that for the >> scenario investigated, the use of larger >> initial windows was not >> harmful to TCP performance. >> >> Corrected Text >> -------------- >> A second set of experiments explored TCP >> performance over dialup >> modem links. In experiments over a >> 28.8 Kbps dialup channel [All97a, >> AHO98], a four-segment initial window >> decreased the transfer time of >> a 16KB file by roughly 10%, with no >> accompanying increase in the drop >> rate. A simulation study [RFC2416] >> investigated the effects of using >> a larger initial window on a host >> connected by a slow modem link and >> a router with a 3 packet buffer. The >> study concluded that for the >> scenario investigated, the use of larger >> initial windows was not >> harmful to TCP performance. >> >> Notes >> ----- >> Error bit rate - bps instead of Kbps. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If >> necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> (IESG) >> can log in to change the status and edit the report, if >> necessary. >> >> -------------------------------------- >> RFC3390 (draft-ietf-tsvwg-initwin-04) >> -------------------------------------- >> Title >> : Increasing TCP's Initial Window >> Publication Date : October 2002 >> Author(s) : M. >> Allman, S. Floyd, C. Partridge >> Category : PROPOSED >> STANDARD >> Source : >> Transport Area Working Group >> Area >> : Transport >> Stream : >> IETF >> Verifying Party : IESG >> >> From nobody Wed Jan 6 11:49:05 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360E01A017F for ; Wed, 6 Jan 2016 11:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nea1_teU30M for ; Wed, 6 Jan 2016 11:49:03 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9EE1A0007 for ; Wed, 6 Jan 2016 11:49:03 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u06Jmss2010890; Wed, 6 Jan 2016 11:48:54 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7332A3680880; Wed, 6 Jan 2016 14:48:53 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <568D6DBA.9060209@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document72769.docx X-URL-1: http://www.icir.org/mallman-files/Document25826.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jan 2016 14:48:53 -0500 Message-ID: <22805.1452109733@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, craig@bbn.com, mls.ietf@gmail.com, tsvwg@ietf.org, RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:49:04 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Well, the text in RFC2414 actually has the opposite intent: >=20 > This increased initial window is optional: that a TCP MAY start with > a larger initial window, not that it SHOULD. >=20 > I.e., in that text it really is an admission that there's no > forced restriction limiting the IW. However, in the case of 3390, > that text may have been imported but I agree that was probably not > the intent at that time. FWIW. RFC3390 replaces ", not that it SHOULD" with this sentence: However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above. I think the intent was these things were the same, but we explained it a bit more in RFC3390. I think it is clear that in both cases s/larger/smaller/ applies. (And, am sort of at a loss for how this wasn't caught given all the times we were over this document and how many people reviewed the thing. Oh Well.) allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaNb6UACgkQWyrrWs4yIs41nwCgi9ANoliSYV+8c8uGLxAVOMCM Dc0AoIXT4ABuDezp3kcNJSeUIj/+UyKE =piO4 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jan 6 11:50:56 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C825D1A0184 for ; Wed, 6 Jan 2016 11:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTKmdaQevf6v for ; Wed, 6 Jan 2016 11:50:54 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759A31A017F for ; Wed, 6 Jan 2016 11:50:54 -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 u06Jo8oS021703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 11:50:09 -0800 (PST) To: Craig Partridge , mallman@icir.org References: <49015.1451940482@lawyers.icir.org> <4EBD4A5A-9BFB-4D67-866C-3B171C1B945A@aland.bbn.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <568D6FF0.7090701@isi.edu> Date: Wed, 6 Jan 2016 11:50:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4EBD4A5A-9BFB-4D67-866C-3B171C1B945A@aland.bbn.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, nmalykh@gmail.com, touch@isi.edu, mls.ietf@gmail.com, RFC Errata System , floyd@icir.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:50:55 -0000 On 1/4/2016 1:38 PM, Craig Partridge wrote: > My view is errata is for technical nits that matter — not discussion or editorial improvement. There are two types of errata - technical and editorial, as per: https://www.rfc-editor.org/errata-definitions/ Both are to flag errors. Neither is intended to cache issues for document updates or improvements. I've seen errata proposed that way, but we really should push back on that practice. Joe > > Speaking for myself (not as a member of the RFC Editorial Board). > > Thanks! > > Craig > >> On Jan 4, 2016, at 3:48 PM, Mark Allman wrote: >> >> >>> Wouldn’t it make sense to mention that TCP’s Reno’s >>> Fast Re-transmit†capability suggests that initial >>> increases of the initial window should generate >>> earlier detection of congestion because of the >>> non-wait of the coarse timeout ,, assuming that the >>> number of Dup ACKs is adjusted accordingly? >> >> I am too old and have written too many words in my life to remember >> precisely---and I don't have time to look---but presumably we said >> something along these lines? And, if not, it is more than an >> errata, IMHO. >> >> (There is nothing about adjusting the dup ACK threshold in 3390, I >> am sure. That is in RFC 5827.) >> >> allman >> >> >> > From nobody Wed Jan 6 11:54:15 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CAD1A0199 for ; Wed, 6 Jan 2016 11:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7lktmTGRn2o for ; Wed, 6 Jan 2016 11:54:12 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB251A0196 for ; Wed, 6 Jan 2016 11:54:12 -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 u06JrbkF022586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 11:53:37 -0800 (PST) To: mallman@icir.org References: <22805.1452109733@lawyers.icir.org> From: Joe Touch Message-ID: <568D70C1.3090600@isi.edu> Date: Wed, 6 Jan 2016 11:53:37 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <22805.1452109733@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, touch@isi.edu, craig@bbn.com, mls.ietf@gmail.com, RFC Errata System , floyd@icir.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:54:13 -0000 On 1/6/2016 11:48 AM, Mark Allman wrote: > >> Well, the text in RFC2414 actually has the opposite intent: >> >> This increased initial window is optional: that a TCP MAY start with >> a larger initial window, not that it SHOULD. >> >> I.e., in that text it really is an admission that there's no >> forced restriction limiting the IW. However, in the case of 3390, >> that text may have been imported but I agree that was probably not >> the intent at that time. > > FWIW. > > RFC3390 replaces ", not that it SHOULD" with this sentence: > > However, we expect that most general-purpose TCP implementations > would choose to use the larger initial congestion window given in > equation (1) above. > > I think the intent was these things were the same, but we explained > it a bit more in RFC3390. I think it is clear that in both cases > s/larger/smaller/ applies. > > (And, am sort of at a loss for how this wasn't caught given all the > times we were over this document and how many people reviewed the > thing. Oh Well.) Hmm. I can see it being interpreted either way in 2414 - i.e.,: (A) not that you should use a larger window than recommended (B) not that you should use a smaller window than recommended In 3390, the intent is more clear (i.e., (B)) I'm happy to submit the errata to 2414 if we all think the intent there was also (B) and not (A). Joe From nobody Wed Jan 6 17:07:41 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC31A21BE for ; Wed, 6 Jan 2016 17:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9r-EL354auq for ; Wed, 6 Jan 2016 17:07:39 -0800 (PST) Received: from nm21-vm5.bullet.mail.ir2.yahoo.com (nm21-vm5.bullet.mail.ir2.yahoo.com [212.82.97.2]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A9D1A21B5 for ; Wed, 6 Jan 2016 17:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1452128857; bh=vidXeHZuRUUKIgadmWfp7KXIu5GC3nDXe/cvxlPg1Sw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=mYzu+mWTKw9CVOL/kZFuz8SSYt/3Kc1ZIdMoWxRza6cCyLNlSfWanL1GEtgjfVk2ADKxr6LZV9MPmYCERCa3Y/bubGQvjS6wm8yiKkPQgHyumC9A6TFcJCdC36WEsN6eDCM//fX7IQ3UQuR+d2O77Qg9r/ytJnQYxi8xEoHw7slKFl3z0wQNva6Mrc52kaqGi9xtbyVNqHRPMAHepCUI3knJAGyP/COsJTrn+I3umZbAhlSAyrPO+lEIiFJvpayYCm9EZjyado4KaSVvrBfvIij02wwwu/9SrCvINl4oVaCf+UQNIef1xQ+WWjx+Qskq/pmC3C3FIXZpaqR9AtfPQw== Received: from [212.82.98.51] by nm21.bullet.mail.ir2.yahoo.com with NNFMP; 07 Jan 2016 01:07:37 -0000 Received: from [212.82.98.111] by tm4.bullet.mail.ir2.yahoo.com with NNFMP; 07 Jan 2016 01:07:37 -0000 Received: from [127.0.0.1] by omp1048.mail.ir2.yahoo.com with NNFMP; 07 Jan 2016 01:07:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 290433.83616.bm@omp1048.mail.ir2.yahoo.com X-YMail-OSG: .3m3XF0VM1nrjoheGRuA5hAHuUP5REfVKNknKZ.zDin2NHnAbVzlRUZpLIUUQ9S BNQ18N3beO.cx5xs11szJxNYNHkEc193Ja.E13lY2ZOp83pj1twBzdR9qwJS.tVRrljf25SVGEQ. m5HZ0qpP_1bU9wQuvZkxOSmnuRoAu0rxt0gfAb7JVykPSELRxrpl0yENGich7bLKKeNTlS1q9V21 KhKIxMew7vP8owTqgycp9zW4s5TFnREFs.MhF8FZG.4EuJFWzDxWZ5TTdGm_yn_blZRWqvV1AFNq hMl4bj1bv5b5MeAM6YKk0t.UFfFRQCLZU3_vWsZI711fV5l6hVD7k0SxUMN2KhPeKqSpFCTOUOwq FPaPhSH68.kaOMZ_uNPpZMZRX4AS0XmiWx3srFjpCVoqbRt9XROQQdwH3s5xhx8EdKaUXBcNkDEu 1Co63RjApNTrE0nXBGvW6pX2kzwzB1AVOufvnzMF0MP3EdTJel.UFNPA2AtscN2cAp_reqO9vZsD bgLHjFnqplodfKb3dxw-- Received: by 212.82.98.118; Thu, 07 Jan 2016 01:07:36 +0000 Date: Thu, 7 Jan 2016 01:07:36 +0000 (UTC) From: To: "mallman@icir.org" , Joe Touch Message-ID: <51159561.1875396.1452128856289.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <19287.1452108513@lawyers.icir.org> References: <19287.1452108513@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "floyd@icir.org" , "craig@bbn.com" , "mls.ietf@gmail.com" , "tsvwg@ietf.org" , RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lloyd.wood@yahoo.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 01:07:41 -0000 someone more pedantic observes that it's 'an erratum'. like data/datum. Given that the RFCs are archival and on the web, listing applicable errata even once the RFCs are obsoleted is helpful. I'd also want 'obsoleted by' to be listed at the top of all errata just to make it more visible. Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood ----- Original Message ----- From: Mark Allman To: Joe Touch Cc: gorry@erg.abdn.ac.uk; floyd@icir.org; craig@bbn.com; mls.ietf@gmail.com; tsvwg@ietf.org; RFC Errata System Sent: Thursday, 7 January 2016, 6:28 Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) > On 1/6/2016 11:09 AM, Mark Allman wrote: > > > > This is clearly a correction to the document. The intent of the > > authors and the WG was never to allow the initial window to be > > higher than given in the document. (It was hard enough to get folks > > to accept an initial window of 2-4 segments. It'd have been > > impossible to get the community to agree to leave an explicit escape > > hatch for larger values.) > > > > This error also applies to RFC 2414 (where the text originated). > > Agreed, but since 2414 is obsoleted by 3390, do we also need an errata > there too? Someone else more pedantic that I can decide that. If we're going to the trouble it seems like it is low cost to flag it for RFC 2414, too. But, I for damn sure will not fight about it. allman From nobody Wed Jan 6 17:46:21 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAA11A6EF4 for ; Wed, 6 Jan 2016 17:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vWnqxzV9gM9 for ; Wed, 6 Jan 2016 17:46:19 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107821A6EF9 for ; Wed, 6 Jan 2016 17:46:19 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u071jVu0011480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 17:45:31 -0800 (PST) To: lloyd.wood@yahoo.co.uk, "mallman@icir.org" References: <19287.1452108513@lawyers.icir.org> <51159561.1875396.1452128856289.JavaMail.yahoo@mail.yahoo.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <568DC33A.1020901@isi.edu> Date: Wed, 6 Jan 2016 17:45:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <51159561.1875396.1452128856289.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u071jVu0011480 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , touch@isi.edu, "craig@bbn.com" , "mls.ietf@gmail.com" , RFC Errata System , "floyd@icir.org" Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 01:46:20 -0000 On 1/6/2016 5:07 PM, lloyd.wood@yahoo.co.uk wrote: > someone more pedantic observes that it's 'an erratum'. See the usage note here: http://dictionary.reference.com/browse/errata Note that even the RFC Editor page refers to the entry as an "errata", e.g., see the button on this page: https://www.rfc-editor.org/errata.php > Given that the RFCs are archival and on the web, > listing applicable errata even once the RFCs are obsoleted > is helpful. Isn't "Obsoleted by" the ultimate errata (in total or as a group, whatever you prefer)? > I'd also want 'obsoleted by' to be listed at > the top of all errata just to make it more visible. The errata applies to the RFC; to find out anything useful about the RFC requires looking at the RFC itself anyway. Joe > ----- Original Message ----- > From: Mark Allman > To: Joe Touch > Cc: gorry@erg.abdn.ac.uk; floyd@icir.org; craig@bbn.com; mls.ietf@gmail.com; tsvwg@ietf.org; RFC Errata System > Sent: Thursday, 7 January 2016, 6:28 > Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) > > >> On 1/6/2016 11:09 AM, Mark Allman wrote: >>> >>> This is clearly a correction to the document. The intent of the >>> authors and the WG was never to allow the initial window to be >>> higher than given in the document. (It was hard enough to get folks >>> to accept an initial window of 2-4 segments. It'd have been >>> impossible to get the community to agree to leave an explicit escape >>> hatch for larger values.) >>> >>> This error also applies to RFC 2414 (where the text originated). >> >> Agreed, but since 2414 is obsoleted by 3390, do we also need an errata >> there too? > > Someone else more pedantic that I can decide that. If we're going > to the trouble it seems like it is low cost to flag it for RFC 2414, > too. But, I for damn sure will not fight about it. > > allman > From nobody Thu Jan 7 01:22:57 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206951A8828 for ; Thu, 7 Jan 2016 01:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oynm1x7R4Bzk for ; Thu, 7 Jan 2016 01:22:51 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 4518B1A8820 for ; Thu, 7 Jan 2016 01:22:51 -0800 (PST) X-Spam-Processed: mail.kau.se, Thu, 07 Jan 2016 10:22:42 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 193.11.155.22 X-MDArrival-Date: Thu, 07 Jan 2016 10:22:42 +0100 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se To: Joe Touch , mallman@icir.org References: <22805.1452109733@lawyers.icir.org> <568D70C1.3090600@isi.edu> From: Anna Brunstrom Message-ID: <568E2E63.5070100@kau.se> Date: Thu, 7 Jan 2016 10:22:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568D70C1.3090600@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gorry@erg.abdn.ac.uk, floyd@icir.org, craig@bbn.com, Martin Stiemerling , rfc-editor@rfc-editor.org, tsvwg@ietf.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4583) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:22:53 -0000 The text is unclear, but needs to be interpreted in context I think. In the context of where it is written (discussion of the new upper bound for the initial window size, and expanding on "This increased initial window is optional"), I would interpret the text as: A TCP MAY start with a larger initial window as specified in this document, but can still use a value of one segment if it wants. (RFC 2414) A TCP MAY start with a larger initial window as specified in this document, but can still use a value of one or two segments if it wants. We expect most implementations to use an initial window as specified in this document. (RFC 3390) The "a larger initial window" in the text relates to the MSS dependence as I interpret it. This would be consistent with the believed intent of the documents. s/larger/smaller/ in RFC 3390 as suggested would make the text clearer I think. s/larger/smaller/ in RFC 2414 would not make the text clearer I think. Anna On 2016-01-06 20:53, Joe Touch wrote: > > On 1/6/2016 11:48 AM, Mark Allman wrote: >>> Well, the text in RFC2414 actually has the opposite intent: >>> >>> This increased initial window is optional: that a TCP MAY start with >>> a larger initial window, not that it SHOULD. >>> >>> I.e., in that text it really is an admission that there's no >>> forced restriction limiting the IW. However, in the case of 3390, >>> that text may have been imported but I agree that was probably not >>> the intent at that time. >> FWIW. >> >> RFC3390 replaces ", not that it SHOULD" with this sentence: >> >> However, we expect that most general-purpose TCP implementations >> would choose to use the larger initial congestion window given in >> equation (1) above. >> >> I think the intent was these things were the same, but we explained >> it a bit more in RFC3390. I think it is clear that in both cases >> s/larger/smaller/ applies. >> >> (And, am sort of at a loss for how this wasn't caught given all the >> times we were over this document and how many people reviewed the >> thing. Oh Well.) > Hmm. I can see it being interpreted either way in 2414 - i.e.,: > > (A) not that you should use a larger window than recommended > > (B) not that you should use a smaller window than recommended > > In 3390, the intent is more clear (i.e., (B)) > > I'm happy to submit the errata to 2414 if we all think the intent there > was also (B) and not (A). > > Joe > From nobody Thu Jan 7 11:23:55 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FF71AC3BE for ; Thu, 7 Jan 2016 11:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ90VHMxLptj for ; Thu, 7 Jan 2016 11:23:50 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 E3BAB1AC3BB for ; Thu, 7 Jan 2016 11:23:48 -0800 (PST) Received: from 96.21.198.146.dyn.plus.net ([146.198.21.96]:36183 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aHG9x-0003kD-Lz; Thu, 07 Jan 2016 19:23:46 +0000 To: Steve Baillargeon , "tsvwg@ietf.org" References: From: Bob Briscoe Message-ID: <568EBB40.9030803@bobbriscoe.net> Date: Thu, 7 Jan 2016 19:23:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090109000905010005010108" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: Ingemar Johansson S Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:23:54 -0000 This is a multi-part message in MIME format. --------------090109000905010005010108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit tsvwg folks, In case people missed this over the holiday period, can anyone with experience of doing bis RFCs give advice on the least confusing way to do an RFC6040bis out of options a-d below. Cheers Bob On 30/12/15 14:15, Steve Baillargeon wrote: > > Adding IETF tsvwg list. > > -Steve B > > *From:*Bob Briscoe [mailto:research@bobbriscoe.net] > *Sent:* Wednesday, December 23, 2015 6:49 PM > *To:* Steve Baillargeon > *Cc:* Ingemar Johansson S; John Kaippallimalil > *Subject:* Re: RFC6040 Questions > > Steve, > > We should be having this conversation on the IETF tsvwg list. Then we > would get other people's views. I'm not sure of the IETF position on this. > > Do you mind fwd'ing this thread to tsvwg? > > > Bob > > On 23/12/15 18:27, Steve Baillargeon wrote: > > Hi Bob > > What about doing a RFC6040 bis? > > RFC 6040 title is already generic enough to include all tunnels. > > My view is the IP header of the GTP-U tunnel belongs to IETF and > 3GPP must repeat or reduce its scope as needed within its 3GPP spec. > > -Steve > > *From:*Bob Briscoe [mailto:research@bobbriscoe.net] > *Sent:* Tuesday, December 22, 2015 8:16 PM > *To:* Steve Baillargeon > *Cc:* Ingemar Johansson S; John Kaippallimalil > *Subject:* Re: RFC6040 Questions > > Steve, > > On 20/12/15 15:40, Steve Baillargeon wrote: > > Hi Bob > > I had the time to look into ecn-encap draft. > > At this point in timer, my biggest concern is mostly how the > information is organized. > > ecn-encap states : > > /Therefore, in all such tightly coupled IP-in-IP tunnelling > protocols, the rules in [RFC6040] for propagating the ECN > field between the two IP headers SHOULD be applied directly./ > > But RFC 6040 states the doc is for IP-in-IP tunnels (only). > > Yes I felt into the trap and originally assumed RFC 6040 would > apply to all “IP-based tunneling protocols” i.e. any tunnel > that requires an outer IP header. > > I general, I prefer to have all the info for a given topic in > one doc. I am sure they are many RFCs out there that do not > follow this “guideline”. > > But it will be great to have all ECN propagation rules and > guidelines about all IP-based tunneling protocols in 1 place > i.e. in RFC 6040. > > I also think that having such consolidated IETF document will > make it easier for 3GPP to updates their documents related to > LTE traffic over GTP-U tunnel and IPSec. > > I will take an action to discuss updates to GTPv1-U spec. I > would prefer to add a reference to a complete RFC 6040 as > opposed to “re-invent the wheel” in the GTPv1-U spec. > > For a 3GPP protocol (like GTP), the IETF doesn't have change > authority over it anyway. The 3GPP has to change the GTP spec. And > once ecn-encap is published as an RFC it will give the 3GPP the > necessary IETF reference to do that. > > However the standards ownership is a bit hard to unpick, because > GTP is a construction of IP (=IETF) headers with a GTP header > (=3GPP) in between. So the 3GPP has to specify what values a GTP > tunnel endpoint should put in IP header fields, when the 3GPP > doesn't actually have jurisdiction over IP. That's why I'm trying > to make it easy for 3GPP, giving them an IETF spec to cite that > says what the IETF would do in the general case. But in writing > that, I have to be careful not to tread on the 3GPP's toes! > > Rather than state this rule only in ecn-encap (once it is an RFC), > I would also prefer to be able to tweak RFC6040 to widen the > over-narrow scope I gave it at the time. I will try, but RFCs can > never be materially changed one published, so the only ways to do > that are: > a) An erratum to RFC6040; > b) A new RFC containing the whole text of RFC6040 verbatim, plus > the extra scope statement. > c) Add an "Updates RFC6040" header to ecn-encap, so when it > becomes RFC the short section on tunnelling will update RFC6040. > d) A very short new standards track RFC with the additional scope > statement for RFC6040, and a header that says > Updates: RFC6040 > which will then cause RFC6040 to be flagged as "Updated by RFCXXXX" > > (a) is only applicable to correct a non-technical error, so > unlikely to be acceptable to the IETF. > (b) isn't the way the IETF normally works, because it opens up all > the original debates on the wording of RFC6040 that were closed > when it was published. > (c) is not feasible, because ecn-encap is a BCP, which cannot > update a Proposed Standard. Also, ecn-encap is long, and only one > short paragraph would update RFC6040, so I don't like this > approach because it's messy and unclear > (d) is likely to be the only way the IETF allows - it is the > 'normal' way the IETF works. > > Altho (b) would be tidier, (d) is all that can happen. > > > > Regarding the aspect of having multiple IP-based tunnels > terminating at the same end node/device. > > For instance: inner IP/GTP-U/middle IP /ESP/outer IP (omitting UDP > here) > > If ECN propagation is not successfully at the outer encapsulator, > then I believe the end node must inspect the middle IP header and > propagate middle ECN to inner IP as you have it defined in Figure > 4 in RFC 6040. > > Therefore, in practice, I believe we will always need to inspect > both middle and outer IP headers at the dual tunnel decapsulator . > > What does "ECN propagation is not successful at the outer > encapsulator" actually mean? > > Actually you don't need to answer. Because I have realised that > the ECN propagation rules have to be applied to one pair of IP > headers at a time, even before one considers testing for all the > illegal or CU (Currently Unused) combinations of ECN fields in Fig > 4 of RFC6040. > > A CE middle can legitimately be encapsulated by an ECT(0) outer if > the tunnel ingress is RFC3168-compliant (which is why this is a > legitimate combination in Fig 4 in RFC6040). So the outer can > legitimately be ECT(0) while the middle is CE, and the inner is > ECT(0) (say). So, it would be wrong for decap to ignore the CE in > the middle by just applying RFC6040 propagation rules between > outer and inner. > > > > My second biggest concern is how to achieve “incremental > deployment” without negatively impacting the forwarding capacity > of the tunnel encapsulators/decapsulators. > > I suspect many existing tunnel encapsulators and decapsulators do > not support ECN field nor ECN propagation rules. > > For implementers who follow standards carefully, that should be > rare for IPsec hardware, because ECN was around (if experimental) > when IPsec was defined, and there was a lot of discussion with the > security community about ECN. > > However, even for standards-conscientious implementers, it's > likely that early non-IPsec (IP-in-IP) tunnel hardware doesn't > support ECN. And possibly later hardware too, because RFC3168 > omitted to flag in its headers that it updated RFC2003. However > when I noticed this I registered an erratum to RFC2003, so that at > least it is flagged as updated by RFC3168. > > Nonetheless, I am also well-aware that a number of IPsec tunnel > implementers are not standards-conscientious, and think they are > entitled to ignore ECN propagation (or invent their own way of > doing it). Reasoning ranges from i) not even being aware of ECN, > through ii) "ECN isn't deployed yet" to iii) a belief that a > security hat entitles you to ignore standards that do not seem to > be security-related (as I've said, information security people can > tend to be blind to traffic security issues). > > > > Do you expect the implementer to initial support the RFC 6040 ECN > propagation rules in “software”? > > If so, I suspect it will cause reduction in forwarding capacity (?). > > Do you have any feedback or suggestion on this matter? > > I wouldn't expect support for RFC6040 to be universal yet because > it's only 5 years old, but it doesn't have to be universal - > compliance with the earlier protocols that it consolidated > (RFC3168 and/or RFC4301) would be sufficient for interoperability. > > However, I would have very little sympathy for an implementer that > had failed to comply with a 15-year-old standards-track change > [RFC3168] to the most important interoperability protocols in the > world (IPv4 & IPv6). So if an operator discovers it is operating > boxes in its network that do not comply with (say) RFC3168, it > should check when it tendered for the box. IMO, if this was less > than 15 years ago, it would be perfectly entitled to go back to > the implementer and seek redress for a failure to comply with the > IP standards in force at the time of tender (obviously depending > on the exact wording of the contracts and tenders). > > If all ECN-tunnelling standards have been ignored, I imagine the > most likely behaviour will be: > * copy inner to outer on encap (because the outer is usually > constructed by modifying a copy of the inner). [This would be > RFC6040 compliant anyway] > * ignore outer on decap [non-compliant] > So the problem is only on decap. > > I think there is a temporary hardware solution for decap, by > abbreviating the rules in Table 4 of RFC6040 to reduce the codepath: > foreach packet { > if (read(packet, ECN_outer) == CE) { > strip_outer(); > remark(packet, ECN_inner) = CE; > } else strip_outer(); > } > > These three steps can be done by configuration of today's > hardware. An operator could temporarily use this hack as long as: > a) it was doing no ECT(1) marking in its network (at the moment > only PCN does that) > b) it had deployed nothing in its network that relied on the drop > behaviour in Table 4 of RFC6040 > > Don't quote me on this! I'm not really advocating that operators > don't need to comply with RFC6040. The whole point of which was to > ensure a single predictable behaviour from all tunnel equipment. > > Nonetheless, if introducing the extra steps for CE-marked packets > reduced performance, it shouldn't be too bad, as long as CE > packets were a small proportion of the aggregate (which would be > typical initially, altho the introduction of scalable TCP hosts in > a few year's time could change that). > If the hardware couldn't keep up, it would merely drop some CE > packets. > > On the other hand, if decap were left completely non-compliant, > the result would also be drops - but probably worse episodes of > drop than might be caused by very occasional processor overload > due to one extra process step. The drop would probably be worse, > because, it would be caused by an oscillation of end-system load > overrunning capacity. Explanation: if there were an ECN router in > the middle of such a tunnel, any congestion marking would get > discarded at egress, leading to the sender causing more and more > severe congestion until drop started. That wouldn't be fatal, but > it would lead to intermittently high drop. > > > > Bob > > > Thank you Bob > > Regards > > Steve Baillargeon > > *From:*Steve Baillargeon > *Sent:* Thursday, December 03, 2015 11:52 AM > *To:* 'Bob Briscoe' > *Cc:* Ingemar Johansson S; John Kaippallimalil > *Subject:* RE: RFC6040 Questions > > Hi Bob > > Thank you for the detailed response. Very helpful. > > Let me review your proposal i.e. ignore the intermediate header. > > I will investigate the main GTP-U and IPSec uses cases and it see > if it holds. > > I will also try to comment as you requested on > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-04#section-5.1 > > Regards > > Steve Baillargeon > > Ericsson > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------090109000905010005010108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit tsvwg folks,

In case people missed this over the holiday period, can anyone with experience of doing bis RFCs give advice on the least confusing way to do an RFC6040bis out of options a-d below.

Cheers


Bob

On 30/12/15 14:15, Steve Baillargeon wrote:

Adding IETF tsvwg list.

 

-Steve B

 

From: Bob Briscoe [mailto:research@bobbriscoe.net]
Sent: Wednesday, December 23, 2015 6:49 PM
To: Steve Baillargeon
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: Re: RFC6040 Questions

 

Steve,

We should be having this conversation on the IETF tsvwg list. Then we would get other people's views. I'm not sure of the IETF position on this.

Do you mind fwd'ing this thread to tsvwg?


Bob

On 23/12/15 18:27, Steve Baillargeon wrote:

Hi Bob

What about doing a RFC6040 bis?

RFC 6040 title is already generic enough to include all tunnels.

 

My view is the IP header of the GTP-U tunnel belongs to IETF and 3GPP must repeat or reduce its scope as needed within its 3GPP spec.

 

-Steve

 

 

From: Bob Briscoe [mailto:research@bobbriscoe.net]
Sent: Tuesday, December 22, 2015 8:16 PM
To: Steve Baillargeon
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: Re: RFC6040 Questions

 

Steve,

On 20/12/15 15:40, Steve Baillargeon wrote:

Hi Bob

I had the time to look into ecn-encap draft.

At this point in timer, my biggest concern is mostly how the information is organized.

 

ecn-encap states :

Therefore, in all such tightly coupled IP-in-IP tunnelling protocols, the rules in [RFC6040] for propagating the ECN field between the two IP headers SHOULD be applied directly.

 

But RFC 6040 states the doc is for IP-in-IP tunnels (only).

 

Yes I felt into the trap and originally assumed RFC 6040 would apply to all “IP-based tunneling protocols” i.e. any tunnel that requires an outer IP header.

 

I general, I prefer to have all the info for a given topic in one doc. I am sure they are many RFCs out there that do not follow this “guideline”.

But it will be great to have all ECN propagation rules and guidelines about all IP-based tunneling protocols in 1 place i.e. in RFC 6040.

 

I also think that having such consolidated IETF document will make it easier for 3GPP to updates their documents related to LTE traffic over GTP-U tunnel and IPSec.

I will take an action to discuss updates to GTPv1-U spec. I would prefer to add a reference to a complete RFC 6040 as opposed to “re-invent the wheel” in the GTPv1-U spec.

For a 3GPP protocol (like GTP), the IETF doesn't have change authority over it anyway. The 3GPP has to change the GTP spec. And once ecn-encap is published as an RFC it will give the 3GPP the necessary IETF reference to do that.

However the standards ownership is a bit hard to unpick, because GTP is a construction of IP (=IETF) headers with a GTP header (=3GPP) in between. So the 3GPP has to specify what values a GTP tunnel endpoint should put in IP header fields, when the 3GPP doesn't actually have jurisdiction over IP. That's why I'm trying to make it easy for 3GPP, giving them an IETF spec to cite that says what the IETF would do in the general case. But in writing that, I have to be careful not to tread on the 3GPP's toes!

Rather than state this rule only in ecn-encap (once it is an RFC), I would also prefer to be able to tweak RFC6040 to widen the over-narrow scope I gave it at the time. I will try, but RFCs can never be materially changed one published, so the only ways to do that are:
a) An erratum to RFC6040;
b) A new RFC containing the whole text of RFC6040 verbatim, plus the extra scope statement.
c) Add an "Updates RFC6040" header to ecn-encap, so when it becomes RFC the short section on tunnelling will update RFC6040.
d) A very short new standards track RFC with the additional scope statement for RFC6040, and a header that says
    Updates: RFC6040
which will then cause RFC6040 to be flagged as "Updated by RFCXXXX"

(a) is only applicable to correct a non-technical error, so unlikely to be acceptable to the IETF.
(b) isn't the way the IETF normally works, because it opens up all the original debates on the wording of RFC6040 that were closed when it was published.
(c) is not feasible, because ecn-encap is a BCP, which cannot update a Proposed Standard. Also, ecn-encap is long, and only one short paragraph would update RFC6040, so I don't like this approach because it's messy and unclear
(d) is likely to be the only way the IETF allows - it is the 'normal' way the IETF works.

Altho (b) would be tidier, (d) is all that can happen.



 

Regarding the aspect of having multiple IP-based tunnels terminating at the same end node/device.

For instance: inner IP/GTP-U/middle IP /ESP/outer IP (omitting UDP here)

If ECN propagation is not successfully at the outer encapsulator, then I believe the end node must inspect the middle IP header and propagate middle ECN to inner IP as you have it defined in Figure 4 in RFC 6040.

Therefore, in practice, I believe we will always need to inspect both middle and outer IP headers at the dual tunnel decapsulator .

What does "ECN propagation is not successful at the outer encapsulator" actually mean?

Actually you don't need to answer. Because I have realised that the ECN propagation rules have to be applied to one pair of IP headers at a time, even before one considers testing for all the illegal or CU (Currently Unused) combinations of ECN fields in Fig 4 of RFC6040.

A CE middle can legitimately be encapsulated by an ECT(0) outer if the tunnel ingress is RFC3168-compliant (which is why this is a legitimate combination in Fig 4 in RFC6040). So the outer can legitimately be ECT(0) while the middle is CE, and the inner is ECT(0) (say). So, it would be wrong for decap to ignore the CE in the middle by just applying RFC6040 propagation rules between outer and inner.



 

My second biggest concern is how to achieve “incremental deployment” without negatively impacting the forwarding capacity of the tunnel encapsulators/decapsulators.

I suspect many existing tunnel encapsulators and decapsulators do not support ECN field nor ECN propagation rules.

For implementers who follow standards carefully, that should be rare for IPsec hardware, because ECN was around (if experimental) when IPsec was defined, and there was a lot of discussion with the security community about ECN.

However, even for standards-conscientious implementers, it's likely that early non-IPsec (IP-in-IP) tunnel hardware doesn't support ECN. And possibly later hardware too, because RFC3168 omitted to flag in its headers that it updated RFC2003. However when I noticed this I registered an erratum to RFC2003, so that at least it is flagged as updated by RFC3168.

Nonetheless, I am also well-aware that a number of IPsec tunnel implementers are not standards-conscientious, and think they are entitled to ignore ECN propagation (or invent their own way of doing it). Reasoning ranges from i) not even being aware of ECN, through ii) "ECN isn't deployed yet" to iii) a belief that a security hat entitles you to ignore standards that do not seem to be security-related (as I've said, information security people can tend to be blind to traffic security issues).



Do you expect the implementer to initial support the RFC 6040 ECN propagation rules in “software”?

If so, I suspect it will cause reduction in forwarding capacity (?).

Do you have any feedback or suggestion on this matter?

I wouldn't expect support for RFC6040 to be universal yet because it's only 5 years old, but it doesn't have to be universal - compliance with the earlier protocols that it consolidated (RFC3168 and/or RFC4301) would be sufficient for interoperability.

However, I would have very little sympathy for an implementer that had failed to comply with a 15-year-old standards-track change [RFC3168] to the most important interoperability protocols in the world (IPv4 & IPv6). So if an operator discovers it is operating boxes in its network that do not comply with (say) RFC3168, it should check when it tendered for the box. IMO, if this was less than 15 years ago, it would be perfectly entitled to go back to the implementer and seek redress for a failure to comply with the IP standards in force at the time of tender (obviously depending on the exact wording of the contracts and tenders).

If all ECN-tunnelling standards have been ignored, I imagine the most likely behaviour will be:
* copy inner to outer on encap (because the outer is usually constructed by modifying a copy of the inner). [This would be RFC6040 compliant anyway]
* ignore outer on decap [non-compliant]
So the problem is only on decap.

I think there is a temporary hardware solution for decap, by abbreviating the rules in Table 4 of RFC6040 to reduce the codepath:
   foreach packet {
        if (read(packet, ECN_outer) == CE) {
            strip_outer();
            remark(packet, ECN_inner) = CE;
        } else strip_outer();
    }

These three steps can be done by configuration of today's hardware. An operator could temporarily use this hack as long as:
a) it was doing no ECT(1) marking in its network (at the moment only PCN does that)
b) it had deployed nothing in its network that relied on the drop behaviour in Table 4 of RFC6040

Don't quote me on this! I'm not really advocating that operators don't need to comply with RFC6040. The whole point of which was to ensure a single predictable behaviour from all tunnel equipment.

Nonetheless, if introducing the extra steps for CE-marked packets reduced performance, it shouldn't be too bad, as long as CE packets were a small proportion of the aggregate (which would be typical initially, altho the introduction of scalable TCP hosts in a few year's time could change that).
If the hardware couldn't keep up, it would merely drop some CE packets.

On the other hand, if decap were left completely non-compliant, the result would also be drops - but probably worse episodes of drop than might be caused by very occasional processor overload due to one extra process step. The drop would probably be worse, because, it would be caused by an oscillation of end-system load overrunning capacity. Explanation: if there were an ECN router in the middle of such a tunnel, any congestion marking would get discarded at egress, leading to the sender causing more and more severe congestion until drop started. That wouldn't be fatal, but it would lead to intermittently high drop.



Bob


 

Thank you Bob

 

Regards

Steve Baillargeon

 

 

 

 

 

From: Steve Baillargeon
Sent: Thursday, December 03, 2015 11:52 AM
To: 'Bob Briscoe'
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: RE: RFC6040 Questions

 

Hi Bob

Thank you for the detailed response. Very helpful.

 

Let me review your proposal i.e. ignore the intermediate header.

I will investigate the main GTP-U and IPSec uses cases and it see if it holds.

 

I will also try to comment as you requested on  https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-04#section-5.1

 

 

Regards

Steve Baillargeon

Ericsson

 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------090109000905010005010108-- From nobody Thu Jan 7 13:21:01 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4076B1A0117 for ; Thu, 7 Jan 2016 13:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfIJDQcGCCr4 for ; Thu, 7 Jan 2016 13:20:50 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 903431A011B for ; Thu, 7 Jan 2016 13:20:50 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u07LK0UG011703 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Jan 2016 16:20:01 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u07LK0UG011703 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1452201601; bh=SYr283SaUiPNHsvfd01YE2Bm6e4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=YvPidaoadvsDk0ItoF6PK0L4lv7d6LW7xsO/9MQustVHulkNSqab/IgMNvqAjEtzA 1KxpQzwhx0ZHGv50S4Ib/vxAopkBtKOT6QMuAIoyvBAXYE1b2PbToWOENAG4fAkXqp I9CAsj7cC/LLyIhMOjJfXhLUcpeOAZ+sLEvmwsK0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u07LK0UG011703 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 7 Jan 2016 16:18:43 -0500 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u07LJnc9006747 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2016 16:19:49 -0500 Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub14.corp.emc.com (128.222.70.235) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 7 Jan 2016 16:19:48 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0266.001; Thu, 7 Jan 2016 16:19:48 -0500 From: "Black, David" To: Bob Briscoe , Steve Baillargeon , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Please expand RFC6040 to address all IP-based tunnels Thread-Index: AdFDDJdvp7oK4aa7SNaj6b/hI1fB2wGnj24AAAco69A= Date: Thu, 7 Jan 2016 21:19:47 +0000 Message-ID: References: <568EBB40.9030803@bobbriscoe.net> In-Reply-To: <568EBB40.9030803@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362334C936MX104CL02corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Ingemar Johansson S Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 21:21:00 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362334C936MX104CL02corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, > In case people missed this over the holiday period, can anyone with exper= ience of doing bis RFCs give advice > on the least confusing way to do an RFC6040bis out of options a-d below. If this is the problem we are trying to solve: > But RFC 6040 states the doc is for IP-in-IP tunnels (only). with RFC 6040's scope needing to be widened for the ECN encapsulation draft= , then c) is the best way to do it, IMHO: > c) Add an "Updates RFC6040" header to ecn-encap, so when it becomes RFC t= he short section on tunneling will update RFC6040. The table of contents would need to include a section called "Update to RFC= 6040" or something like that to make this change easy to find. It's also = a good idea to summarize the update to RFC 6040 in the introduction (and po= ssibly the abstract, but this seems like a minor update that may not merit = mention in the abstract). > (c) is not feasible, because ecn-encap is a BCP, which cannot update a Pr= oposed Standard. That sort of process issue is what ADs are for :-), If the right thing to= do is to use the ecn-encap draft to update RFC 6040, and there's a process= problem, then the WG chairs get to talk to our ADs about asking the IESG t= o grant the process exception as part of evaluation/approval of the ecn-enc= ap draft. If we go this route, the process exception would be explicitly c= alled out as part of the WG and IETF Last Calls. > Also, ecn-encap is long, and only one short paragraph would update RFC604= 0, so I don't like this approach because it's messy and unclear Between summarizing the update in the introduction and putting that paragra= ph in its own section with a clear title that appears in the table of conte= nts, e.g., "Update to RFC 6040", I think the result will be clear enough. If the process exception proves infeasible or unwise, then d) is the altern= ative: > d) A very short new standards track RFC with the additional scope stateme= nt for RFC6040, and a header that says > Updates: RFC6040 This has been done in the past in other contexts - here's an example from t= he Security Area: https://tools.ietf.org/html/rfc6685 . One consequence of d) is that it causes both Working Group and IETF Last Ca= lls on the RFC 6040 scope change, whereas c) subsumes the change into WG an= d IETF LCs for the ECN encapsulation draft - I'd be interested in opinions = on whether this scope change is important enough that a separate draft shou= ld be used with separate WG and IETF LCs to call attention to the change. Thanks, --David From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Bob Briscoe Sent: Thursday, January 07, 2016 2:24 PM To: Steve Baillargeon; tsvwg@ietf.org Cc: Ingemar Johansson S Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnels tsvwg folks, In case people missed this over the holiday period, can anyone with experie= nce of doing bis RFCs give advice on the least confusing way to do an RFC60= 40bis out of options a-d below. Cheers Bob On 30/12/15 14:15, Steve Baillargeon wrote: Adding IETF tsvwg list. -Steve B From: Bob Briscoe [mailto:research@bobbriscoe.net] Sent: Wednesday, December 23, 2015 6:49 PM To: Steve Baillargeon Cc: Ingemar Johansson S; John Kaippallimalil Subject: Re: RFC6040 Questions Steve, We should be having this conversation on the IETF tsvwg list. Then we would= get other people's views. I'm not sure of the IETF position on this. Do you mind fwd'ing this thread to tsvwg? Bob On 23/12/15 18:27, Steve Baillargeon wrote: Hi Bob What about doing a RFC6040 bis? RFC 6040 title is already generic enough to include all tunnels. My view is the IP header of the GTP-U tunnel belongs to IETF and 3GPP must = repeat or reduce its scope as needed within its 3GPP spec. -Steve From: Bob Briscoe [mailto:research@bobbriscoe.net] Sent: Tuesday, December 22, 2015 8:16 PM To: Steve Baillargeon Cc: Ingemar Johansson S; John Kaippallimalil Subject: Re: RFC6040 Questions Steve, On 20/12/15 15:40, Steve Baillargeon wrote: Hi Bob I had the time to look into ecn-encap draft. At this point in timer, my biggest concern is mostly how the information is= organized. ecn-encap states : Therefore, in all such tightly coupled IP-in-IP tunnelling protocols, the r= ules in [RFC6040] for propagating the ECN field between the two IP headers = SHOULD be applied directly. But RFC 6040 states the doc is for IP-in-IP tunnels (only). Yes I felt into the trap and originally assumed RFC 6040 would apply to all= "IP-based tunneling protocols" i.e. any tunnel that requires an outer IP h= eader. I general, I prefer to have all the info for a given topic in one doc. I am= sure they are many RFCs out there that do not follow this "guideline". But it will be great to have all ECN propagation rules and guidelines about= all IP-based tunneling protocols in 1 place i.e. in RFC 6040. I also think that having such consolidated IETF document will make it easie= r for 3GPP to updates their documents related to LTE traffic over GTP-U tun= nel and IPSec. I will take an action to discuss updates to GTPv1-U spec. I would prefer to= add a reference to a complete RFC 6040 as opposed to "re-invent the wheel"= in the GTPv1-U spec. For a 3GPP protocol (like GTP), the IETF doesn't have change authority over= it anyway. The 3GPP has to change the GTP spec. And once ecn-encap is publ= ished as an RFC it will give the 3GPP the necessary IETF reference to do th= at. However the standards ownership is a bit hard to unpick, because GTP is a c= onstruction of IP (=3DIETF) headers with a GTP header (=3D3GPP) in between.= So the 3GPP has to specify what values a GTP tunnel endpoint should put in= IP header fields, when the 3GPP doesn't actually have jurisdiction over IP= . That's why I'm trying to make it easy for 3GPP, giving them an IETF spec = to cite that says what the IETF would do in the general case. But in writin= g that, I have to be careful not to tread on the 3GPP's toes! Rather than state this rule only in ecn-encap (once it is an RFC), I would = also prefer to be able to tweak RFC6040 to widen the over-narrow scope I ga= ve it at the time. I will try, but RFCs can never be materially changed one= published, so the only ways to do that are: a) An erratum to RFC6040; b) A new RFC containing the whole text of RFC6040 verbatim, plus the extra = scope statement. c) Add an "Updates RFC6040" header to ecn-encap, so when it becomes RFC the= short section on tunnelling will update RFC6040. d) A very short new standards track RFC with the additional scope statement= for RFC6040, and a header that says Updates: RFC6040 which will then cause RFC6040 to be flagged as "Updated by RFCXXXX" (a) is only applicable to correct a non-technical error, so unlikely to be = acceptable to the IETF. (b) isn't the way the IETF normally works, because it opens up all the orig= inal debates on the wording of RFC6040 that were closed when it was publish= ed. (c) is not feasible, because ecn-encap is a BCP, which cannot update a Prop= osed Standard. Also, ecn-encap is long, and only one short paragraph would = update RFC6040, so I don't like this approach because it's messy and unclea= r (d) is likely to be the only way the IETF allows - it is the 'normal' way t= he IETF works. Altho (b) would be tidier, (d) is all that can happen. Regarding the aspect of having multiple IP-based tunnels terminating at the= same end node/device. For instance: inner IP/GTP-U/middle IP /ESP/outer IP (omitting UDP here) If ECN propagation is not successfully at the outer encapsulator, then I be= lieve the end node must inspect the middle IP header and propagate middle E= CN to inner IP as you have it defined in Figure 4 in RFC 6040. Therefore, in practice, I believe we will always need to inspect both middl= e and outer IP headers at the dual tunnel decapsulator . What does "ECN propagation is not successful at the outer encapsulator" act= ually mean? Actually you don't need to answer. Because I have realised that the ECN pro= pagation rules have to be applied to one pair of IP headers at a time, even= before one considers testing for all the illegal or CU (Currently Unused) = combinations of ECN fields in Fig 4 of RFC6040. A CE middle can legitimately be encapsulated by an ECT(0) outer if the tunn= el ingress is RFC3168-compliant (which is why this is a legitimate combinat= ion in Fig 4 in RFC6040). So the outer can legitimately be ECT(0) while the= middle is CE, and the inner is ECT(0) (say). So, it would be wrong for dec= ap to ignore the CE in the middle by just applying RFC6040 propagation rule= s between outer and inner. My second biggest concern is how to achieve "incremental deployment" withou= t negatively impacting the forwarding capacity of the tunnel encapsulators/= decapsulators. I suspect many existing tunnel encapsulators and decapsulators do not suppo= rt ECN field nor ECN propagation rules. For implementers who follow standards carefully, that should be rare for IP= sec hardware, because ECN was around (if experimental) when IPsec was defin= ed, and there was a lot of discussion with the security community about ECN= . However, even for standards-conscientious implementers, it's likely that ea= rly non-IPsec (IP-in-IP) tunnel hardware doesn't support ECN. And possibly = later hardware too, because RFC3168 omitted to flag in its headers that it = updated RFC2003. However when I noticed this I registered an erratum to RFC= 2003, so that at least it is flagged as updated by RFC3168. Nonetheless, I am also well-aware that a number of IPsec tunnel implementer= s are not standards-conscientious, and think they are entitled to ignore EC= N propagation (or invent their own way of doing it). Reasoning ranges from = i) not even being aware of ECN, through ii) "ECN isn't deployed yet" to iii= ) a belief that a security hat entitles you to ignore standards that do not= seem to be security-related (as I've said, information security people can= tend to be blind to traffic security issues). Do you expect the implementer to initial support the RFC 6040 ECN propagati= on rules in "software"? If so, I suspect it will cause reduction in forwarding capacity (?). Do you have any feedback or suggestion on this matter? I wouldn't expect support for RFC6040 to be universal yet because it's only= 5 years old, but it doesn't have to be universal - compliance with the ear= lier protocols that it consolidated (RFC3168 and/or RFC4301) would be suffi= cient for interoperability. However, I would have very little sympathy for an implementer that had fail= ed to comply with a 15-year-old standards-track change [RFC3168] to the mos= t important interoperability protocols in the world (IPv4 & IPv6). So if an= operator discovers it is operating boxes in its network that do not comply= with (say) RFC3168, it should check when it tendered for the box. IMO, if = this was less than 15 years ago, it would be perfectly entitled to go back = to the implementer and seek redress for a failure to comply with the IP sta= ndards in force at the time of tender (obviously depending on the exact wor= ding of the contracts and tenders). If all ECN-tunnelling standards have been ignored, I imagine the most likel= y behaviour will be: * copy inner to outer on encap (because the outer is usually constructed by= modifying a copy of the inner). [This would be RFC6040 compliant anyway] * ignore outer on decap [non-compliant] So the problem is only on decap. I think there is a temporary hardware solution for decap, by abbreviating t= he rules in Table 4 of RFC6040 to reduce the codepath: foreach packet { if (read(packet, ECN_outer) =3D=3D CE) { strip_outer(); remark(packet, ECN_inner) =3D CE; } else strip_outer(); } These three steps can be done by configuration of today's hardware. An oper= ator could temporarily use this hack as long as: a) it was doing no ECT(1) marking in its network (at the moment only PCN do= es that) b) it had deployed nothing in its network that relied on the drop behaviour= in Table 4 of RFC6040 Don't quote me on this! I'm not really advocating that operators don't need= to comply with RFC6040. The whole point of which was to ensure a single pr= edictable behaviour from all tunnel equipment. Nonetheless, if introducing the extra steps for CE-marked packets reduced p= erformance, it shouldn't be too bad, as long as CE packets were a small pro= portion of the aggregate (which would be typical initially, altho the intro= duction of scalable TCP hosts in a few year's time could change that). If the hardware couldn't keep up, it would merely drop some CE packets. On the other hand, if decap were left completely non-compliant, the result = would also be drops - but probably worse episodes of drop than might be cau= sed by very occasional processor overload due to one extra process step. Th= e drop would probably be worse, because, it would be caused by an oscillati= on of end-system load overrunning capacity. Explanation: if there were an E= CN router in the middle of such a tunnel, any congestion marking would get = discarded at egress, leading to the sender causing more and more severe con= gestion until drop started. That wouldn't be fatal, but it would lead to in= termittently high drop. Bob Thank you Bob Regards Steve Baillargeon From: Steve Baillargeon Sent: Thursday, December 03, 2015 11:52 AM To: 'Bob Briscoe' Cc: Ingemar Johansson S; John Kaippallimalil Subject: RE: RFC6040 Questions Hi Bob Thank you for the detailed response. Very helpful. Let me review your proposal i.e. ignore the intermediate header. I will investigate the main GTP-U and IPSec uses cases and it see if it hol= ds. I will also try to comment as you requested on https://tools.ietf.org/html= /draft-ietf-tsvwg-ecn-encap-guidelines-04#section-5.1 Regards Steve Baillargeon Ericsson -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_CE03DB3D7B45C245BCA0D243277949362334C936MX104CL02corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

> In case people missed this over the holiday per= iod, can anyone with experience of doing bis RFCs give advice

> on the least confusing way to do an RFC6040bis = out of options a-d below.

 

If this is the problem we are trying= to solve:

 

> But RFC 6040 states the doc is for IP-= in-IP tunnels (only).

 

with RFC 6040’s scope needing = to be widened for the ECN encapsulation draft, then c) is the best way to d= o it, IMHO:


> c) Add an "Updates RFC6040" header to ecn-encap, so when it = becomes RFC the short section on tunneling will update RFC6040.

The table of contents would need to = include a section called “Update to RFC 6040” or something like= that to make this change easy to find.  It’s also a good idea t= o summarize the update to RFC 6040 in the introduction (and possibly the abstract, but= this seems like a minor update that may not merit mention in the abstract)= .

 

> (c) is not feasible, because ec= n-encap is a BCP, which cannot update a Proposed Standard.

 

That sort of process issue is what A= Ds are for :-),   If the right thing to do is to use the ecn-enca= p draft to update RFC 6040, and there’s a process problem, then the WG chairs get to talk to our ADs about asking the IESG to grant the proces= s exception as part of evaluation/approval of the ecn-encap draft.  If= we go this route, the process exception would be explicitly called out as = part of the WG and IETF Last Calls.

 

> Also, ecn-encap is long, and on= ly one short paragraph would update RFC6040, so I don't like this approach = because it's messy and unclear

Between summarizing the update in th= e introduction and putting that paragraph in its own section with a clear t= itle that appears in the table of contents,  e.g., “Update to RFC 6040”, I think the result will be clear enough.

 

If the process exception proves infe= asible or unwise, then d) is the alternative:

 

> d) A very short new standards t= rack RFC with the additional scope statement for RFC6040, and a header that= says
>    Updates: RFC6040

 

This has been done in the past in ot= her contexts - here’s an example from the Security Area: https://tools.ietf.org/html= /rfc6685 .

 

One consequence of d) is that it cau= ses both Working Group and IETF Last Calls on the RFC 6040 scope change, wh= ereas c) subsumes the change into WG and IETF LCs for the ECN encapsulation draft - I’d be interested in opinions on whether t= his scope change is important enough that a separate draft should be used w= ith separate WG and IETF LCs to call attention to the change.

 

Thanks,
--David

 

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Bob Briscoe
Sent: Thursday, January 07, 2016 2:24 PM
To: Steve Baillargeon; tsvwg@ietf.org
Cc: Ingemar Johansson S
Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based t= unnels

 

tsvwg folks,

In case people missed this over the holiday period, can anyone with experie= nce of doing bis RFCs give advice on the least confusing way to do an RFC60= 40bis out of options a-d below.

Cheers


Bob

On 30/12/15 14:15, Steve Baillargeon wrote:

Adding IETF tsvwg list= .

 

-Steve B

 

From: Bob Briscoe [mailto:research@bobbriscoe.net]
Sent: Wednesday, December 23, 2015 6:49 PM
To: Steve Baillargeon
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: Re: RFC6040 Questions

 

Steve,

We should be having this conversation on the IETF tsvwg list. Then we would= get other people's views. I'm not sure of the IETF position on this.

Do you mind fwd'ing this thread to tsvwg?


Bob

On 23/12/15 18:27, Steve Baillargeon wrote:

Hi Bob

What about doing a RFC= 6040 bis?

RFC 6040 title is alre= ady generic enough to include all tunnels.

 

My view is the IP head= er of the GTP-U tunnel belongs to IETF and 3GPP must repeat or reduce its s= cope as needed within its 3GPP spec.

 

-Steve

 

 

From: Bob Briscoe [mailto:research@bobbriscoe.net]
Sent: Tuesday, December 22, 2015 8:16 PM
To: Steve Baillargeon
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: Re: RFC6040 Questions

 

Steve,

On 20/12/15 15:40, Steve Baillargeon wrote:

Hi Bob

I had the time to look= into ecn-encap draft.

At this point in timer= , my biggest concern is mostly how the information is organized.

 

ecn-encap states :

Therefore, in all s= uch tightly coupled IP-in-IP tunnelling protocols, the rules in [RFC6040] f= or propagating the ECN field between the two IP headers SHOULD be applied d= irectly.

 

But RFC 6040 states th= e doc is for IP-in-IP tunnels (only).

 

Yes I felt into the tr= ap and originally assumed RFC 6040 would apply to all “IP-based tunne= ling protocols” i.e. any tunnel that requires an outer IP header.

 

I general, I prefer to= have all the info for a given topic in one doc. I am sure they are many RF= Cs out there that do not follow this “guideline”.

But it will be great t= o have all ECN propagation rules and guidelines about all IP-based tunnelin= g protocols in 1 place i.e. in RFC 6040.

 

I also think that havi= ng such consolidated IETF document will make it easier for 3GPP to updates = their documents related to LTE traffic over GTP-U tunnel and IPSec.<= o:p>

I will take an action = to discuss updates to GTPv1-U spec. I would prefer to add a reference to a = complete RFC 6040 as opposed to “re-invent the wheel” in the GT= Pv1-U spec.

For a 3GPP protocol (like GTP), the = IETF doesn't have change authority over it anyway. The 3GPP has to change t= he GTP spec. And once ecn-encap is published as an RFC it will give the 3GPP the necessary IETF reference to do that.

However the standards ownership is a bit hard to unpick, because GTP is a c= onstruction of IP (=3DIETF) headers with a GTP header (=3D3GPP) in between.= So the 3GPP has to specify what values a GTP tunnel endpoint should put in= IP header fields, when the 3GPP doesn't actually have jurisdiction over IP. That's why I'm trying to make it easy = for 3GPP, giving them an IETF spec to cite that says what the IETF would do= in the general case. But in writing that, I have to be careful not to trea= d on the 3GPP's toes!

Rather than state this rule only in ecn-encap (once it is an RFC), I would = also prefer to be able to tweak RFC6040 to widen the over-narrow scope I ga= ve it at the time. I will try, but RFCs can never be materially changed one= published, so the only ways to do that are:
a) An erratum to RFC6040;
b) A new RFC containing the whole text of RFC6040 verbatim, plus the extra = scope statement.
c) Add an "Updates RFC6040" header to ecn-encap, so when it becom= es RFC the short section on tunnelling will update RFC6040.
d) A very short new standards track RFC with the additional scope statement= for RFC6040, and a header that says
    Updates: RFC6040
which will then cause RFC6040 to be flagged as "Updated by RFCXXXX&quo= t;

(a) is only applicable to correct a non-technical error, so unlikely to be = acceptable to the IETF.
(b) isn't the way the IETF normally works, because it opens up all the orig= inal debates on the wording of RFC6040 that were closed when it was publish= ed.
(c) is not feasible, because ecn-encap is a BCP, which cannot update a Prop= osed Standard. Also, ecn-encap is long, and only one short paragraph would = update RFC6040, so I don't like this approach because it's messy and unclea= r
(d) is likely to be the only way the IETF allows - it is the 'normal' way t= he IETF works.

Altho (b) would be tidier, (d) is all that can happen.




 

Regarding the aspect o= f having multiple IP-based tunnels terminating at the same end node/device.=

For instance: inner IP= /GTP-U/middle IP /ESP/outer IP (omitting UDP here)

If ECN propagation is = not successfully at the outer encapsulator, then I believe the end node mus= t inspect the middle IP header and propagate middle ECN to inner IP as you = have it defined in Figure 4 in RFC 6040.

Therefore, in practice= , I believe we will always need to inspect both middle and outer IP headers= at the dual tunnel decapsulator .

What does "ECN propagation is not successful at the outer encaps= ulator" actually mean?

Actually you don't need to answer. Because I have realised that the ECN pro= pagation rules have to be applied to one pair of IP headers at a time, even= before one considers testing for all the illegal or CU (Currently Unused) = combinations of ECN fields in Fig 4 of RFC6040.

A CE middle can legitimately be encapsulated by an ECT(0) outer if the tunn= el ingress is RFC3168-compliant (which is why this is a legitimate combinat= ion in Fig 4 in RFC6040). So the outer can legitimately be ECT(0) while the= middle is CE, and the inner is ECT(0) (say). So, it would be wrong for decap to ignore the CE in the midd= le by just applying RFC6040 propagation rules between outer and inner.




 

My second biggest conc= ern is how to achieve “incremental deployment” without negative= ly impacting the forwarding capacity of the tunnel encapsulators/decapsulat= ors.

I suspect many existin= g tunnel encapsulators and decapsulators do not support ECN field nor ECN p= ropagation rules.

For implementers who follow standard= s carefully, that should be rare for IPsec hardware, because ECN was around= (if experimental) when IPsec was defined, and there was a lot of discussion with the security community about ECN.

However, even for standards-conscientious implementers, it's likely that ea= rly non-IPsec (IP-in-IP) tunnel hardware doesn't support ECN. And possibly = later hardware too, because RFC3168 omitted to flag in its headers that it = updated RFC2003. However when I noticed this I registered an erratum to RFC2003, so that at least it is fl= agged as updated by RFC3168.

Nonetheless, I am also well-aware that a number of IPsec tunnel implementer= s are not standards-conscientious, and think they are entitled to ignore EC= N propagation (or invent their own way of doing it). Reasoning ranges from = i) not even being aware of ECN, through ii) "ECN isn't deployed yet" to iii) a belief that a sec= urity hat entitles you to ignore standards that do not seem to be security-= related (as I've said, information security people can tend to be blind to = traffic security issues).




Do you expect the impl= ementer to initial support the RFC 6040 ECN propagation rules in “sof= tware”?

If so, I suspect it wi= ll cause reduction in forwarding capacity (?).

Do you have any feedba= ck or suggestion on this matter?

I wouldn't expect support for RFC604= 0 to be universal yet because it's only 5 years old, but it doesn't have to= be universal - compliance with the earlier protocols that it consolidated (RFC3168 and/or RFC4301) would be sufficient for interoper= ability.

However, I would have very little sympathy for an implementer that had fail= ed to comply with a 15-year-old standards-track change [RFC3168] to the mos= t important interoperability protocols in the world (IPv4 & IPv6). So i= f an operator discovers it is operating boxes in its network that do not comply with (say) RFC3168, it should chec= k when it tendered for the box. IMO, if this was less than 15 years ago, it= would be perfectly entitled to go back to the implementer and seek redress= for a failure to comply with the IP standards in force at the time of tender (obviously depending on the ex= act wording of the contracts and tenders).

If all ECN-tunnelling standards have been ignored, I imagine the most likel= y behaviour will be:
* copy inner to outer on encap (because the outer is usually constructed by= modifying a copy of the inner). [This would be RFC6040 compliant anyway] * ignore outer on decap [non-compliant]
So the problem is only on decap.

I think there is a temporary hardware solution for decap, by abbreviating t= he rules in Table 4 of RFC6040 to reduce the codepath:
   foreach packet {
        if (read(packet, ECN_outer) =3D= =3D CE) {
            strip_outer();=
            remark(packet,= ECN_inner) =3D CE;
        } else strip_outer();
    }

These three steps can be done by configuration of today's hardware. An oper= ator could temporarily use this hack as long as:
a) it was doing no ECT(1) marking in its network (at the moment only PCN do= es that)
b) it had deployed nothing in its network that relied on the drop behaviour= in Table 4 of RFC6040

Don't quote me on this! I'm not really advocating that operators don't need= to comply with RFC6040. The whole point of which was to ensure a single pr= edictable behaviour from all tunnel equipment.

Nonetheless, if introducing the extra steps for CE-marked packets reduced p= erformance, it shouldn't be too bad, as long as CE packets were a small pro= portion of the aggregate (which would be typical initially, altho the intro= duction of scalable TCP hosts in a few year's time could change that).
If the hardware couldn't keep up, it would merely drop some CE packets.
On the other hand, if decap were left completely non-compliant, the result = would also be drops - but probably worse episodes of drop than might be cau= sed by very occasional processor overload due to one extra process step. Th= e drop would probably be worse, because, it would be caused by an oscillation of end-system load overrunni= ng capacity. Explanation: if there were an ECN router in the middle of such= a tunnel, any congestion marking would get discarded at egress, leading to= the sender causing more and more severe congestion until drop started. That wouldn't be fatal, but it would= lead to intermittently high drop.



Bob



 

Thank you Bob

 

Regards=

Steve B= aillargeon

 

 

 

 

 

From: Steve Baillargeon
Sent: Thursday, December 03, 2015 11:52 AM
To: 'Bob Briscoe'
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: RE: RFC6040 Questions

 

Hi Bob

Thank you for the deta= iled response. Very helpful.

 

Let me review your pro= posal i.e. ignore the intermediate header.

I will investigate the= main GTP-U and IPSec uses cases and it see if it holds.<= /p>

 

I will also try to com= ment as you requested on  https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidel= ines-04#section-5.1

 

 

Regards=

Steve B= aillargeon

Ericsso= n

 



-- 
________________________________________________________________<=
/o:p>
Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/
--_000_CE03DB3D7B45C245BCA0D243277949362334C936MX104CL02corpem_-- From nobody Thu Jan 7 16:11:14 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF0A1A8852 for ; Thu, 7 Jan 2016 16:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVJASx4u85is for ; Thu, 7 Jan 2016 16:11:11 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 167871A8844 for ; Thu, 7 Jan 2016 16:11:11 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u080B9cs011200 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 Jan 2016 19:11:09 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u080B9cs011200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1452211869; bh=FtbDexEHhJLPQhPWSA3GG5OCwi0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=wr9Cb2zZ9wPGZnvepLZSSUUuQKOFgdOYz/17Azphv5Xf0HCyg2lMlWcBPE2jjcibu JkZ/8ADVqvCLFcFfBwGgsMIrXWPW/7+jGqr1VPT/J01u8ugO2QIR2q4pdUpWlMxgBi FaUP4DcAH+mXO4xBxXKOZ5lw5OxZ5zXcJ7Zoxapg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u080B9cs011200 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Thu, 7 Jan 2016 19:10:32 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u080B0MH007809 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Jan 2016 19:11:01 -0500 Received: from MXHUB227.corp.emc.com (10.253.68.97) by mxhub10.corp.emc.com (10.254.92.105) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 7 Jan 2016 19:11:00 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB227.corp.emc.com ([10.253.68.97]) with mapi id 14.03.0266.001; Thu, 7 Jan 2016 19:10:59 -0500 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: 2nd WGLC: NAT Behavior Update draft Thread-Index: AdFJqQ1bFuJHKNuVRoOruze++7bs7g== Date: Fri, 8 Jan 2016 00:10:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] 2nd WGLC: NAT Behavior Update draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 00:11:12 -0000 Context - on December 21st, 2015, I wrote: =20 > And now, for the not-so-good news: >=20 > (2) Network Address Translation (NAT) Behavioral Requirements Updates > draft-ietf-tsvwg-behave-requirements-update-05 >=20 > The WGLC is over with no comments, and the draft is in good shape, but ..= . > ... an IPR Disclosure was discovered late in the process (due to a missin= g > updated-by relationship in the datatracker - with that relationship in pl= ace, > the IPR Disclosure is now shown as being on a related draft): >=20 > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-t= svwg-behave-requirements-update > https://datatracker.ietf.org/ipr/1917/ >=20 > It will be necessary to run an additional WGLC on this draft in January f= or > this reason. This email announces that additional Working Group Last call. It will run = through midnight US Eastern Time on Saturday January 16 (a week from this coming Sa= turday). The primary purpose of this 2nd WG Last Call is to determine whether the re= sults of the first WG Last Call (WG supports proceeding with publication of this dra= ft) are affected by the existence of the IPR Disclosure noted above. That said, ot= her comments are welcome, and the WG chairs would be very happy to see addition= al one or more additional detailed reviews of this draft. =20 Thanks, --David (tsvwg WG chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Fri Jan 8 10:08:10 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726A71A90F6 for ; Fri, 8 Jan 2016 10:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABK2Yc-0y9Fv for ; Fri, 8 Jan 2016 10:07:59 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AAD1B2AC1 for ; Fri, 8 Jan 2016 10:07:58 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f206so183491584wmf.0 for ; Fri, 08 Jan 2016 10:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=P6VZ0tC/IsGCyWKqGw8zlZ7P+zhKjc0IXQR9mrepCNY=; b=0JhGk3w29ZYRGcDGyrp2RqkQ0NdplRxiFAm1mjImQu/n70uiRl8D3hqp84q8Qbk5AA wY7pMdtQYoXmJh5e52pLptrogE0LS+KpnIMq5yDyn2IyGoRtn/kvoSjwTLmF/ZAdOg7c gsj6kez5bG7ZLDM3BuZ+dGkT8PkBG9YFbJCCAVwFPvJhwuUyuqMGE2qMmXy8B5ZwXOZY 2pR2nViC0JDSlOqsi6ycU6VLjlTCJEa0ka4T/WdPe02SWGFKgI4cAPk+Y+ITRdPoTnjW 4Qzgcd43wL/nj3Q6CdkyLBAc6KnihsVVJmRrok4TxJVf+1FRJg/WPse79GqDOszzIihY c3eA== MIME-Version: 1.0 X-Received: by 10.194.5.74 with SMTP id q10mr120515023wjq.138.1452276477414; Fri, 08 Jan 2016 10:07:57 -0800 (PST) Received: by 10.27.11.201 with HTTP; Fri, 8 Jan 2016 10:07:57 -0800 (PST) Date: Fri, 8 Jan 2016 10:07:57 -0800 Message-ID: From: Martin Duke To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary=047d7b45070e8d59930528d67743 Archived-At: Cc: Ian Swett , alyssar@google.com, rch@google.com Subject: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:08:04 -0000 --047d7b45070e8d59930528d67743 Content-Type: text/plain; charset=UTF-8 I've been toying with implementing parts of this draft while also trying to interact with the existing Chromium implementation, and beyond the obviously incomplete sections in the draft I think there are several items that are unclear, suboptimal, or not conformant with Chromium. This is a wonderful contribution with great promise, and many exceptional design features. But: 1) Section 5.1: I suggest that "the CHLO MUST fit in one packet; if need be, one that requires IP fragmentation." As ugly as that is, it's far superior to forcing the server to maintain state on incomplete CHLO. In another forum the authors have indicated that this is their intention. This also requires an exception to the preface of Section 6, which says to avoid IP fragmentation (though as I understand it we are a long way from CHLO having to be that long). 2) Section 5.1: "The next time the client sends a CHLO, it can use the cached credentials from the previous connection to immediately send encrypted requests to the server." I would appreciate wording that makes it clearer that, "upon receipt of an authenticated REJ, the client MUST generate a new connection ID for subsequent CHLO messages, with sequence number 1." This clarification is also important to making servers stateless pre-SHLO. 3) Section 5.1: Without veering into the Crypto documents area, I think it would be helpful to indicate the frames that MUST, SHOULD, or MAY be in CHLO, REJ, and SHLO messages. Obviously there will be STREAM frames for stream 1, but I can certainly imagine PADDING, WINDOW_UPDATE, and ACK messages required as well. And I imagine CONNECTION_CLOSE etc. MAY be present. But I'm not sure! The stream 1 fields may be in a crypto document but the frame list should be here. 4) Section 6.1: There is a little encryption ambiguity in the packets that the server receives from the client just after sending the SHLO. These packets could either use the initial key or the symmetric key, and with packet reordering they could be interleaved for while. As someone that implements server-side stuff for a living, it's irritating to potentially have to decrypt the packet twice, and to allocate space for two sets of keys in the PCB. There are two unused bits in the Public Flags. It appears that Chromium has already taken one for a "multipath" flag, currently undocumented. I propose that the second one be an indicator that the client has received the SHLO and is using the symmetric key. 5) Section 6.1: The Chromium implementation sometimes puts 12 authentication bits between public and private header. It would be good to make this explicit in the document, as the figure in Section 6.1 reasonably reads as having the private flags immediately follow the sequence number. 6) Section 6.5: Please provide the correct format for the CADR tag. 7) Section 8.3: I have read this section several times and cannot discern at all what the TCP timestamps are for, how many there should be, where they come from, and what format they are in. Are these echoes of some sender timestamp (and if, so where is that from) or are these local clock measurements? Obviously this has something to do with RTT calculation, but the mapping of the ACK frame fields to this calculation is really unclear. I tried to generate some psuedocode to generate an ACK frame and got nowhere. Regards, Martin --047d7b45070e8d59930528d67743 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been toying with implementing parts of this draft= while also trying to interact with the existing Chromium implementation, a= nd beyond the obviously incomplete sections in the draft I think there are = several items that are unclear, suboptimal, or not conformant with Chromium= .

This is a wonderful contribution with great promise, a= nd many exceptional design features. But:

1) Se= ction 5.1: I suggest that "the CHLO MUST fit in one packet; if need be= , one that requires IP fragmentation." As ugly as that is, it's fa= r superior to forcing the server to maintain state on incomplete CHLO. In a= nother forum the authors have indicated that this is their intention. This = also requires an exception to the preface of Section 6, which says to avoid= IP fragmentation (though as I understand it we are a long way from CHLO ha= ving to be that long).

2) Section 5.1: "The n= ext time the client sends a CHLO, it can use the cached credentials from th= e previous connection to immediately send encrypted requests to the server.= "

I would appreciate wording that makes it cl= earer that, "upon receipt of an authenticated REJ, the client MUST gen= erate a new connection ID for subsequent CHLO messages, with sequence numbe= r 1." This clarification is also important to making servers stateless= pre-SHLO.

3) Section 5.1: Without veering i= nto the Crypto documents area, I think it would be helpful to indicate the = frames that MUST, SHOULD, or MAY be in CHLO, REJ, and SHLO messages. Obviou= sly there will be STREAM frames for stream 1, but I can certainly imagine P= ADDING, WINDOW_UPDATE, and ACK messages required as well. And I imagine CON= NECTION_CLOSE etc. MAY be present. But I'm not sure! The stream 1 field= s may be in a crypto document but the frame list should be here.
=
4) Section 6.1: There is a little encryption ambiguity in th= e packets that the server receives from the client just after sending the S= HLO. These packets could either use the initial key or the symmetric key, a= nd with packet reordering they could be interleaved for while. As someone t= hat implements server-side stuff for a living, it's irritating to poten= tially have to decrypt the packet twice, and to allocate space for two sets= of keys in the PCB.

There are two unused bits in = the Public Flags. It appears that Chromium has already taken one for a &quo= t;multipath" flag, currently undocumented. I propose that the second o= ne be an indicator that the client has received the SHLO and is using the s= ymmetric key.

5) Section 6.1:=C2=A0The Chromium im= plementation sometimes puts 12 authentication bits between public and priva= te header. It would be good to make this explicit in the document, as the f= igure in Section 6.1 reasonably reads as having the private flags immediate= ly follow the sequence number.

6) Section 6.5: Ple= ase provide the correct format for the CADR tag.

7= ) Section 8.3: I have read this section several times and cannot discern at= all what the TCP timestamps are for, how many there should be, where they = come from, and what format they are in. Are these echoes of some sender tim= estamp (and if, so where is that from) or are these local clock measurement= s?

Obviously this has something to do with RTT cal= culation, but the mapping of the ACK frame fields to this calculation is re= ally unclear. I tried to generate some psuedocode to generate an ACK frame = and got nowhere.

Regards,
Martin

--047d7b45070e8d59930528d67743-- From nobody Fri Jan 8 22:30:40 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0811A1A7D for ; Fri, 8 Jan 2016 22:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOlgA49GpW-G for ; Fri, 8 Jan 2016 22:30:36 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60BD1A1A7E for ; Fri, 8 Jan 2016 22:30:36 -0800 (PST) Received: from [75.211.99.83] (83.sub-75-211-99.myvzw.com [75.211.99.83]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u096TMTB000648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jan 2016 22:29:24 -0800 (PST) To: Bob Briscoe , Steve Baillargeon , "tsvwg@ietf.org" References: <568EBB40.9030803@bobbriscoe.net> From: Joe Touch Message-ID: <5690A8C2.7000202@isi.edu> Date: Fri, 8 Jan 2016 22:29:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568EBB40.9030803@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Ingemar Johansson S , touch@isi.edu Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 06:30:39 -0000 It seems difficult to require that tunnels that use multiple layers also transfer signalling "over" intermediate headers that might not support that capabilities unless all the headers are added in a single location. I.e., I don't see a good way to *require* all IP-over-FOO-over-IP to support cross-layer signal translation. Joe On 1/7/2016 11:23 AM, Bob Briscoe wrote: > tsvwg folks, > > In case people missed this over the holiday period, can anyone with > experience of doing bis RFCs give advice on the least confusing way to > do an RFC6040bis out of options a-d below. > > Cheers > > > Bob > > On 30/12/15 14:15, Steve Baillargeon wrote: >> >> Adding IETF tsvwg list. >> >> >> >> -Steve B >> >> >> >> *From:*Bob Briscoe [mailto:research@bobbriscoe.net] >> *Sent:* Wednesday, December 23, 2015 6:49 PM >> *To:* Steve Baillargeon >> *Cc:* Ingemar Johansson S; John Kaippallimalil >> *Subject:* Re: RFC6040 Questions >> >> >> >> Steve, >> >> We should be having this conversation on the IETF tsvwg list. Then we >> would get other people's views. I'm not sure of the IETF position on this. >> >> Do you mind fwd'ing this thread to tsvwg? >> >> >> Bob >> >> On 23/12/15 18:27, Steve Baillargeon wrote: >> >> Hi Bob >> >> What about doing a RFC6040 bis? >> >> RFC 6040 title is already generic enough to include all tunnels. >> >> >> >> My view is the IP header of the GTP-U tunnel belongs to IETF and >> 3GPP must repeat or reduce its scope as needed within its 3GPP spec. >> >> >> >> -Steve >> >> >> >> >> >> *From:*Bob Briscoe [mailto:research@bobbriscoe.net] >> *Sent:* Tuesday, December 22, 2015 8:16 PM >> *To:* Steve Baillargeon >> *Cc:* Ingemar Johansson S; John Kaippallimalil >> *Subject:* Re: RFC6040 Questions >> >> >> >> Steve, >> >> On 20/12/15 15:40, Steve Baillargeon wrote: >> >> Hi Bob >> >> I had the time to look into ecn-encap draft. >> >> At this point in timer, my biggest concern is mostly how the >> information is organized. >> >> >> >> ecn-encap states : >> >> /Therefore, in all such tightly coupled IP-in-IP tunnelling >> protocols, the rules in [RFC6040] for propagating the ECN >> field between the two IP headers SHOULD be applied directly./ >> >> >> >> But RFC 6040 states the doc is for IP-in-IP tunnels (only). >> >> >> >> Yes I felt into the trap and originally assumed RFC 6040 would >> apply to all “IP-based tunneling protocols” i.e. any tunnel >> that requires an outer IP header. >> >> >> >> I general, I prefer to have all the info for a given topic in >> one doc. I am sure they are many RFCs out there that do not >> follow this “guideline”. >> >> But it will be great to have all ECN propagation rules and >> guidelines about all IP-based tunneling protocols in 1 place >> i.e. in RFC 6040. >> >> >> >> I also think that having such consolidated IETF document will >> make it easier for 3GPP to updates their documents related to >> LTE traffic over GTP-U tunnel and IPSec. >> >> I will take an action to discuss updates to GTPv1-U spec. I >> would prefer to add a reference to a complete RFC 6040 as >> opposed to “re-invent the wheel” in the GTPv1-U spec. >> >> For a 3GPP protocol (like GTP), the IETF doesn't have change >> authority over it anyway. The 3GPP has to change the GTP spec. And >> once ecn-encap is published as an RFC it will give the 3GPP the >> necessary IETF reference to do that. >> >> However the standards ownership is a bit hard to unpick, because >> GTP is a construction of IP (=IETF) headers with a GTP header >> (=3GPP) in between. So the 3GPP has to specify what values a GTP >> tunnel endpoint should put in IP header fields, when the 3GPP >> doesn't actually have jurisdiction over IP. That's why I'm trying >> to make it easy for 3GPP, giving them an IETF spec to cite that >> says what the IETF would do in the general case. But in writing >> that, I have to be careful not to tread on the 3GPP's toes! >> >> Rather than state this rule only in ecn-encap (once it is an RFC), >> I would also prefer to be able to tweak RFC6040 to widen the >> over-narrow scope I gave it at the time. I will try, but RFCs can >> never be materially changed one published, so the only ways to do >> that are: >> a) An erratum to RFC6040; >> b) A new RFC containing the whole text of RFC6040 verbatim, plus >> the extra scope statement. >> c) Add an "Updates RFC6040" header to ecn-encap, so when it >> becomes RFC the short section on tunnelling will update RFC6040. >> d) A very short new standards track RFC with the additional scope >> statement for RFC6040, and a header that says >> Updates: RFC6040 >> which will then cause RFC6040 to be flagged as "Updated by RFCXXXX" >> >> (a) is only applicable to correct a non-technical error, so >> unlikely to be acceptable to the IETF. >> (b) isn't the way the IETF normally works, because it opens up all >> the original debates on the wording of RFC6040 that were closed >> when it was published. >> (c) is not feasible, because ecn-encap is a BCP, which cannot >> update a Proposed Standard. Also, ecn-encap is long, and only one >> short paragraph would update RFC6040, so I don't like this >> approach because it's messy and unclear >> (d) is likely to be the only way the IETF allows - it is the >> 'normal' way the IETF works. >> >> Altho (b) would be tidier, (d) is all that can happen. >> >> >> >> >> >> Regarding the aspect of having multiple IP-based tunnels >> terminating at the same end node/device. >> >> For instance: inner IP/GTP-U/middle IP /ESP/outer IP (omitting UDP >> here) >> >> If ECN propagation is not successfully at the outer encapsulator, >> then I believe the end node must inspect the middle IP header and >> propagate middle ECN to inner IP as you have it defined in Figure >> 4 in RFC 6040. >> >> Therefore, in practice, I believe we will always need to inspect >> both middle and outer IP headers at the dual tunnel decapsulator . >> >> What does "ECN propagation is not successful at the outer >> encapsulator" actually mean? >> >> Actually you don't need to answer. Because I have realised that >> the ECN propagation rules have to be applied to one pair of IP >> headers at a time, even before one considers testing for all the >> illegal or CU (Currently Unused) combinations of ECN fields in Fig >> 4 of RFC6040. >> >> A CE middle can legitimately be encapsulated by an ECT(0) outer if >> the tunnel ingress is RFC3168-compliant (which is why this is a >> legitimate combination in Fig 4 in RFC6040). So the outer can >> legitimately be ECT(0) while the middle is CE, and the inner is >> ECT(0) (say). So, it would be wrong for decap to ignore the CE in >> the middle by just applying RFC6040 propagation rules between >> outer and inner. >> >> >> >> >> >> My second biggest concern is how to achieve “incremental >> deployment” without negatively impacting the forwarding capacity >> of the tunnel encapsulators/decapsulators. >> >> I suspect many existing tunnel encapsulators and decapsulators do >> not support ECN field nor ECN propagation rules. >> >> For implementers who follow standards carefully, that should be >> rare for IPsec hardware, because ECN was around (if experimental) >> when IPsec was defined, and there was a lot of discussion with the >> security community about ECN. >> >> However, even for standards-conscientious implementers, it's >> likely that early non-IPsec (IP-in-IP) tunnel hardware doesn't >> support ECN. And possibly later hardware too, because RFC3168 >> omitted to flag in its headers that it updated RFC2003. However >> when I noticed this I registered an erratum to RFC2003, so that at >> least it is flagged as updated by RFC3168. >> >> Nonetheless, I am also well-aware that a number of IPsec tunnel >> implementers are not standards-conscientious, and think they are >> entitled to ignore ECN propagation (or invent their own way of >> doing it). Reasoning ranges from i) not even being aware of ECN, >> through ii) "ECN isn't deployed yet" to iii) a belief that a >> security hat entitles you to ignore standards that do not seem to >> be security-related (as I've said, information security people can >> tend to be blind to traffic security issues). >> >> >> >> Do you expect the implementer to initial support the RFC 6040 ECN >> propagation rules in “software”? >> >> If so, I suspect it will cause reduction in forwarding capacity (?). >> >> Do you have any feedback or suggestion on this matter? >> >> I wouldn't expect support for RFC6040 to be universal yet because >> it's only 5 years old, but it doesn't have to be universal - >> compliance with the earlier protocols that it consolidated >> (RFC3168 and/or RFC4301) would be sufficient for interoperability. >> >> However, I would have very little sympathy for an implementer that >> had failed to comply with a 15-year-old standards-track change >> [RFC3168] to the most important interoperability protocols in the >> world (IPv4 & IPv6). So if an operator discovers it is operating >> boxes in its network that do not comply with (say) RFC3168, it >> should check when it tendered for the box. IMO, if this was less >> than 15 years ago, it would be perfectly entitled to go back to >> the implementer and seek redress for a failure to comply with the >> IP standards in force at the time of tender (obviously depending >> on the exact wording of the contracts and tenders). >> >> If all ECN-tunnelling standards have been ignored, I imagine the >> most likely behaviour will be: >> * copy inner to outer on encap (because the outer is usually >> constructed by modifying a copy of the inner). [This would be >> RFC6040 compliant anyway] >> * ignore outer on decap [non-compliant] >> So the problem is only on decap. >> >> I think there is a temporary hardware solution for decap, by >> abbreviating the rules in Table 4 of RFC6040 to reduce the codepath: >> foreach packet { >> if (read(packet, ECN_outer) == CE) { >> strip_outer(); >> remark(packet, ECN_inner) = CE; >> } else strip_outer(); >> } >> >> These three steps can be done by configuration of today's >> hardware. An operator could temporarily use this hack as long as: >> a) it was doing no ECT(1) marking in its network (at the moment >> only PCN does that) >> b) it had deployed nothing in its network that relied on the drop >> behaviour in Table 4 of RFC6040 >> >> Don't quote me on this! I'm not really advocating that operators >> don't need to comply with RFC6040. The whole point of which was to >> ensure a single predictable behaviour from all tunnel equipment. >> >> Nonetheless, if introducing the extra steps for CE-marked packets >> reduced performance, it shouldn't be too bad, as long as CE >> packets were a small proportion of the aggregate (which would be >> typical initially, altho the introduction of scalable TCP hosts in >> a few year's time could change that). >> If the hardware couldn't keep up, it would merely drop some CE >> packets. >> >> On the other hand, if decap were left completely non-compliant, >> the result would also be drops - but probably worse episodes of >> drop than might be caused by very occasional processor overload >> due to one extra process step. The drop would probably be worse, >> because, it would be caused by an oscillation of end-system load >> overrunning capacity. Explanation: if there were an ECN router in >> the middle of such a tunnel, any congestion marking would get >> discarded at egress, leading to the sender causing more and more >> severe congestion until drop started. That wouldn't be fatal, but >> it would lead to intermittently high drop. >> >> >> >> Bob >> >> >> >> >> Thank you Bob >> >> >> >> Regards >> >> Steve Baillargeon >> >> >> >> >> >> >> >> >> >> >> >> *From:*Steve Baillargeon >> *Sent:* Thursday, December 03, 2015 11:52 AM >> *To:* 'Bob Briscoe' >> *Cc:* Ingemar Johansson S; John Kaippallimalil >> *Subject:* RE: RFC6040 Questions >> >> >> >> Hi Bob >> >> Thank you for the detailed response. Very helpful. >> >> >> >> Let me review your proposal i.e. ignore the intermediate header. >> >> I will investigate the main GTP-U and IPSec uses cases and it see >> if it holds. >> >> >> >> I will also try to comment as you requested on >> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-04#section-5.1 >> >> >> >> >> >> Regards >> >> Steve Baillargeon >> >> Ericsson >> >> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > From nobody Mon Jan 11 06:25:57 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC161A010F for ; Mon, 11 Jan 2016 06:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtq3BvrRrHs2 for ; Mon, 11 Jan 2016 06:25:51 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 CFCCA1A0116 for ; Mon, 11 Jan 2016 06:25:50 -0800 (PST) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0BEP09Q017045 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jan 2016 09:25:01 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u0BEP09Q017045 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1452522301; bh=/LK9CwK1TVFGQxuIiwCLobGjBQU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KTMKFNvGN2413ZsOZUQE/zOs5OpNJPU5JaE/h5t+BB2qWNPkamhpN+1I2R5iknf4g 7x10Xzv6tEtWF2ufvIkIdwgO2QFjStkMQmLm0u/bqEvgjpNJh4bxAHxZi9WAxYxfH8 wH874pv8fnN8+XMORS3vsOoB5zt6/4rUj0AiNZXw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u0BEP09Q017045 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd01.lss.emc.com (RSA Interceptor); Mon, 11 Jan 2016 09:24:17 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0BEOoXo025344 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2016 09:24:50 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub32.corp.emc.com (128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 11 Jan 2016 09:24:50 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0266.001; Mon, 11 Jan 2016 09:24:49 -0500 From: "Black, David" To: Joe Touch , Bob Briscoe , "Steve Baillargeon" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Please expand RFC6040 to address all IP-based tunnels Thread-Index: AdFDDJdvp7oK4aa7SNaj6b/hI1fB2wGnj24AAEmJ1AAAaqxhwA== Date: Mon, 11 Jan 2016 14:24:49 +0000 Message-ID: References: <568EBB40.9030803@bobbriscoe.net> <5690A8C2.7000202@isi.edu> In-Reply-To: <5690A8C2.7000202@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.240.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Ingemar Johansson S Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:25:55 -0000 > I.e., I don't see a good way to *require* all IP-over-FOO-over-IP to > support cross-layer signal translation. Right, needs to be *optional* but how to do it right does deserve to be exp= lained ... Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Saturday, January 09, 2016 1:29 AM > To: Bob Briscoe; Steve Baillargeon; tsvwg@ietf.org > Cc: Ingemar Johansson S; touch@isi.edu > Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnel= s >=20 > It seems difficult to require that tunnels that use multiple layers also > transfer signalling "over" intermediate headers that might not support > that capabilities unless all the headers are added in a single location. >=20 > I.e., I don't see a good way to *require* all IP-over-FOO-over-IP to > support cross-layer signal translation. >=20 > Joe >=20 > On 1/7/2016 11:23 AM, Bob Briscoe wrote: > > tsvwg folks, > > > > In case people missed this over the holiday period, can anyone with > > experience of doing bis RFCs give advice on the least confusing way to > > do an RFC6040bis out of options a-d below. > > > > Cheers > > > > > > Bob > > > > On 30/12/15 14:15, Steve Baillargeon wrote: > >> > >> Adding IETF tsvwg list. > >> > >> > >> > >> -Steve B > >> > >> > >> > >> *From:*Bob Briscoe [mailto:research@bobbriscoe.net] > >> *Sent:* Wednesday, December 23, 2015 6:49 PM > >> *To:* Steve Baillargeon > >> *Cc:* Ingemar Johansson S; John Kaippallimalil > >> *Subject:* Re: RFC6040 Questions > >> > >> > >> > >> Steve, > >> > >> We should be having this conversation on the IETF tsvwg list. Then we > >> would get other people's views. I'm not sure of the IETF position on t= his. > >> > >> Do you mind fwd'ing this thread to tsvwg? > >> > >> > >> Bob > >> > >> On 23/12/15 18:27, Steve Baillargeon wrote: > >> > >> Hi Bob > >> > >> What about doing a RFC6040 bis? > >> > >> RFC 6040 title is already generic enough to include all tunnels. > >> > >> > >> > >> My view is the IP header of the GTP-U tunnel belongs to IETF and > >> 3GPP must repeat or reduce its scope as needed within its 3GPP spe= c. > >> > >> > >> > >> -Steve > >> > >> > >> > >> > >> > >> *From:*Bob Briscoe [mailto:research@bobbriscoe.net] > >> *Sent:* Tuesday, December 22, 2015 8:16 PM > >> *To:* Steve Baillargeon > >> *Cc:* Ingemar Johansson S; John Kaippallimalil > >> *Subject:* Re: RFC6040 Questions > >> > >> > >> > >> Steve, > >> > >> On 20/12/15 15:40, Steve Baillargeon wrote: > >> > >> Hi Bob > >> > >> I had the time to look into ecn-encap draft. > >> > >> At this point in timer, my biggest concern is mostly how the > >> information is organized. > >> > >> > >> > >> ecn-encap states : > >> > >> /Therefore, in all such tightly coupled IP-in-IP tunnelling > >> protocols, the rules in [RFC6040] for propagating the ECN > >> field between the two IP headers SHOULD be applied directly./ > >> > >> > >> > >> But RFC 6040 states the doc is for IP-in-IP tunnels (only). > >> > >> > >> > >> Yes I felt into the trap and originally assumed RFC 6040 would > >> apply to all "IP-based tunneling protocols" i.e. any tunnel > >> that requires an outer IP header. > >> > >> > >> > >> I general, I prefer to have all the info for a given topic in > >> one doc. I am sure they are many RFCs out there that do not > >> follow this "guideline". > >> > >> But it will be great to have all ECN propagation rules and > >> guidelines about all IP-based tunneling protocols in 1 place > >> i.e. in RFC 6040. > >> > >> > >> > >> I also think that having such consolidated IETF document will > >> make it easier for 3GPP to updates their documents related to > >> LTE traffic over GTP-U tunnel and IPSec. > >> > >> I will take an action to discuss updates to GTPv1-U spec. I > >> would prefer to add a reference to a complete RFC 6040 as > >> opposed to "re-invent the wheel" in the GTPv1-U spec. > >> > >> For a 3GPP protocol (like GTP), the IETF doesn't have change > >> authority over it anyway. The 3GPP has to change the GTP spec. And > >> once ecn-encap is published as an RFC it will give the 3GPP the > >> necessary IETF reference to do that. > >> > >> However the standards ownership is a bit hard to unpick, because > >> GTP is a construction of IP (=3DIETF) headers with a GTP header > >> (=3D3GPP) in between. So the 3GPP has to specify what values a GTP > >> tunnel endpoint should put in IP header fields, when the 3GPP > >> doesn't actually have jurisdiction over IP. That's why I'm trying > >> to make it easy for 3GPP, giving them an IETF spec to cite that > >> says what the IETF would do in the general case. But in writing > >> that, I have to be careful not to tread on the 3GPP's toes! > >> > >> Rather than state this rule only in ecn-encap (once it is an RFC), > >> I would also prefer to be able to tweak RFC6040 to widen the > >> over-narrow scope I gave it at the time. I will try, but RFCs can > >> never be materially changed one published, so the only ways to do > >> that are: > >> a) An erratum to RFC6040; > >> b) A new RFC containing the whole text of RFC6040 verbatim, plus > >> the extra scope statement. > >> c) Add an "Updates RFC6040" header to ecn-encap, so when it > >> becomes RFC the short section on tunnelling will update RFC6040. > >> d) A very short new standards track RFC with the additional scope > >> statement for RFC6040, and a header that says > >> Updates: RFC6040 > >> which will then cause RFC6040 to be flagged as "Updated by RFCXXXX= " > >> > >> (a) is only applicable to correct a non-technical error, so > >> unlikely to be acceptable to the IETF. > >> (b) isn't the way the IETF normally works, because it opens up all > >> the original debates on the wording of RFC6040 that were closed > >> when it was published. > >> (c) is not feasible, because ecn-encap is a BCP, which cannot > >> update a Proposed Standard. Also, ecn-encap is long, and only one > >> short paragraph would update RFC6040, so I don't like this > >> approach because it's messy and unclear > >> (d) is likely to be the only way the IETF allows - it is the > >> 'normal' way the IETF works. > >> > >> Altho (b) would be tidier, (d) is all that can happen. > >> > >> > >> > >> > >> > >> Regarding the aspect of having multiple IP-based tunnels > >> terminating at the same end node/device. > >> > >> For instance: inner IP/GTP-U/middle IP /ESP/outer IP (omitting UDP > >> here) > >> > >> If ECN propagation is not successfully at the outer encapsulator, > >> then I believe the end node must inspect the middle IP header and > >> propagate middle ECN to inner IP as you have it defined in Figure > >> 4 in RFC 6040. > >> > >> Therefore, in practice, I believe we will always need to inspect > >> both middle and outer IP headers at the dual tunnel decapsulator . > >> > >> What does "ECN propagation is not successful at the outer > >> encapsulator" actually mean? > >> > >> Actually you don't need to answer. Because I have realised that > >> the ECN propagation rules have to be applied to one pair of IP > >> headers at a time, even before one considers testing for all the > >> illegal or CU (Currently Unused) combinations of ECN fields in Fig > >> 4 of RFC6040. > >> > >> A CE middle can legitimately be encapsulated by an ECT(0) outer if > >> the tunnel ingress is RFC3168-compliant (which is why this is a > >> legitimate combination in Fig 4 in RFC6040). So the outer can > >> legitimately be ECT(0) while the middle is CE, and the inner is > >> ECT(0) (say). So, it would be wrong for decap to ignore the CE in > >> the middle by just applying RFC6040 propagation rules between > >> outer and inner. > >> > >> > >> > >> > >> > >> My second biggest concern is how to achieve "incremental > >> deployment" without negatively impacting the forwarding capacity > >> of the tunnel encapsulators/decapsulators. > >> > >> I suspect many existing tunnel encapsulators and decapsulators do > >> not support ECN field nor ECN propagation rules. > >> > >> For implementers who follow standards carefully, that should be > >> rare for IPsec hardware, because ECN was around (if experimental) > >> when IPsec was defined, and there was a lot of discussion with the > >> security community about ECN. > >> > >> However, even for standards-conscientious implementers, it's > >> likely that early non-IPsec (IP-in-IP) tunnel hardware doesn't > >> support ECN. And possibly later hardware too, because RFC3168 > >> omitted to flag in its headers that it updated RFC2003. However > >> when I noticed this I registered an erratum to RFC2003, so that at > >> least it is flagged as updated by RFC3168. > >> > >> Nonetheless, I am also well-aware that a number of IPsec tunnel > >> implementers are not standards-conscientious, and think they are > >> entitled to ignore ECN propagation (or invent their own way of > >> doing it). Reasoning ranges from i) not even being aware of ECN, > >> through ii) "ECN isn't deployed yet" to iii) a belief that a > >> security hat entitles you to ignore standards that do not seem to > >> be security-related (as I've said, information security people can > >> tend to be blind to traffic security issues). > >> > >> > >> > >> Do you expect the implementer to initial support the RFC 6040 ECN > >> propagation rules in "software"? > >> > >> If so, I suspect it will cause reduction in forwarding capacity (?= ). > >> > >> Do you have any feedback or suggestion on this matter? > >> > >> I wouldn't expect support for RFC6040 to be universal yet because > >> it's only 5 years old, but it doesn't have to be universal - > >> compliance with the earlier protocols that it consolidated > >> (RFC3168 and/or RFC4301) would be sufficient for interoperability. > >> > >> However, I would have very little sympathy for an implementer that > >> had failed to comply with a 15-year-old standards-track change > >> [RFC3168] to the most important interoperability protocols in the > >> world (IPv4 & IPv6). So if an operator discovers it is operating > >> boxes in its network that do not comply with (say) RFC3168, it > >> should check when it tendered for the box. IMO, if this was less > >> than 15 years ago, it would be perfectly entitled to go back to > >> the implementer and seek redress for a failure to comply with the > >> IP standards in force at the time of tender (obviously depending > >> on the exact wording of the contracts and tenders). > >> > >> If all ECN-tunnelling standards have been ignored, I imagine the > >> most likely behaviour will be: > >> * copy inner to outer on encap (because the outer is usually > >> constructed by modifying a copy of the inner). [This would be > >> RFC6040 compliant anyway] > >> * ignore outer on decap [non-compliant] > >> So the problem is only on decap. > >> > >> I think there is a temporary hardware solution for decap, by > >> abbreviating the rules in Table 4 of RFC6040 to reduce the codepat= h: > >> foreach packet { > >> if (read(packet, ECN_outer) =3D=3D CE) { > >> strip_outer(); > >> remark(packet, ECN_inner) =3D CE; > >> } else strip_outer(); > >> } > >> > >> These three steps can be done by configuration of today's > >> hardware. An operator could temporarily use this hack as long as: > >> a) it was doing no ECT(1) marking in its network (at the moment > >> only PCN does that) > >> b) it had deployed nothing in its network that relied on the drop > >> behaviour in Table 4 of RFC6040 > >> > >> Don't quote me on this! I'm not really advocating that operators > >> don't need to comply with RFC6040. The whole point of which was to > >> ensure a single predictable behaviour from all tunnel equipment. > >> > >> Nonetheless, if introducing the extra steps for CE-marked packets > >> reduced performance, it shouldn't be too bad, as long as CE > >> packets were a small proportion of the aggregate (which would be > >> typical initially, altho the introduction of scalable TCP hosts in > >> a few year's time could change that). > >> If the hardware couldn't keep up, it would merely drop some CE > >> packets. > >> > >> On the other hand, if decap were left completely non-compliant, > >> the result would also be drops - but probably worse episodes of > >> drop than might be caused by very occasional processor overload > >> due to one extra process step. The drop would probably be worse, > >> because, it would be caused by an oscillation of end-system load > >> overrunning capacity. Explanation: if there were an ECN router in > >> the middle of such a tunnel, any congestion marking would get > >> discarded at egress, leading to the sender causing more and more > >> severe congestion until drop started. That wouldn't be fatal, but > >> it would lead to intermittently high drop. > >> > >> > >> > >> Bob > >> > >> > >> > >> > >> Thank you Bob > >> > >> > >> > >> Regards > >> > >> Steve Baillargeon > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> *From:*Steve Baillargeon > >> *Sent:* Thursday, December 03, 2015 11:52 AM > >> *To:* 'Bob Briscoe' > >> *Cc:* Ingemar Johansson S; John Kaippallimalil > >> *Subject:* RE: RFC6040 Questions > >> > >> > >> > >> Hi Bob > >> > >> Thank you for the detailed response. Very helpful. > >> > >> > >> > >> Let me review your proposal i.e. ignore the intermediate header. > >> > >> I will investigate the main GTP-U and IPSec uses cases and it see > >> if it holds. > >> > >> > >> > >> I will also try to comment as you requested on > >> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines= - > 04#section-5.1 > >> > >> > >> > >> > >> > >> Regards > >> > >> Steve Baillargeon > >> > >> Ericsson > >> > >> > >> > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > From nobody Mon Jan 11 09:00:14 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC71A8ABC for ; Mon, 11 Jan 2016 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uBUwNpfVdlk for ; Mon, 11 Jan 2016 09:00:08 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 70D291A8AC2 for ; Mon, 11 Jan 2016 09:00:08 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0BH06HP010663 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Jan 2016 12:00:07 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u0BH06HP010663 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1452531607; bh=FXUle5Yk21tepHE57SMxDGMH5tY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gDwxktAnKoNf2DjtexlaazyLmXW1in5g82xhcRpDP30iOeQuj23dfpHNJ9tyc2dWp Sh0TXP6+Xhx15t0k4mZ2EXNXHpnZf6CTCzZTa+cJInxSFZ1sdAy79AOJPI7QpKFH/7 GzHX5oXpFmie5lNC68cyN8IseV5YFq8TyYfFJ49c= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u0BH06HP010663 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Mon, 11 Jan 2016 11:59:39 -0500 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0BGxlAP006634 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jan 2016 11:59:47 -0500 Received: from MXHUB204.corp.emc.com (10.253.68.30) by mxhub20.corp.emc.com (10.254.93.49) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 11 Jan 2016 11:59:47 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB204.corp.emc.com ([10.253.68.30]) with mapi id 14.03.0266.001; Mon, 11 Jan 2016 11:59:46 -0500 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: GRE/UDP and UDP Guidelines drafts: applicability terms Thread-Index: AdFMkXjjh0uyQspgQWa7UaKof+TKRw== Date: Mon, 11 Jan 2016 16:59:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.240.142] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] GRE/UDP and UDP Guidelines drafts: applicability terms X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 17:00:13 -0000 Both the GRE/UDP draft and the UDP Guidelines draft are defining and using terminology for a couple of applicability scenarios: GRE/UDP, section 1.1 (https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-08): - General IP Network: 1) Use of GRE-in-UDP in a general IP network including the Internet, - Well-Managed Operator IP Network 2) Use of GRE-in-UDP in a well-managed operator IP network, [this is about traffic management to avoid congestion, and about nature of the network or applications that enables safe use of zero UDP checksum for IPv6.] UDP Guidelines, section 3.6 (https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-07#section-3.6): - General Internet. By default, IETF specifications target deployment on the general Internet. Experience has shown that successful protocols developed in one specific context or for a particular application tends to become used in a wider range of contexts. - Controlled Environment A protocol/encapsulation/tunnel could be designed to be used only within a controlled environment. For example, an application designed for use by a network operator might only be deployed within the network of that single network operator or on networks of an adjacent set of cooperating network operators. There will be a new version of the GRE/UDP draft coming in the near future, and it would be good to get alignment on the above terminology in that version. The following are some initial "strawman" ideas for discussion, starting from a view that we may not need a total of 4 terms: a) "General IP Network" and "General Internet" appear to be the same concept, so we should pick one term. My initial suggestion is to use "General Network" and make the need to design for the Internet clear in the definition of the scenario. I'm concerned that use of the word "Internet" in the name of the could be misinterpreted as the scenario being public-Internet-only (NB: capitalized 'I'). b) Controlled Environment seems to be a superset of Well-Managed [IP] Network. I'd suggest using roughly those two terms: - Controlled Environment in the UDP Guidelines draft - Well Managed Network in the GRE/UDP draft, as an example (or subset) of a Controlled Environment. It feels like a good idea to also discuss this in the UDP Guidelines draft (which already has some text on this), but it's probably more productive to work out the details in the GRE/UDP draft first. I also don't think the "IP" acronym is essential as part of the name. Thoughts? Dead Cats/Rotten Tomatoes? :-). Seriously, please do comment - the results of this discussion should be reflected in the next version of the GRE/UDP draft, and we're likely to see significant usage of this terminology in drafts that use UDP-based encapsulations in the future. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Mon Jan 11 09:18:15 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE8E1A8AE8 for ; Mon, 11 Jan 2016 09:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v79cYNhldKGy for ; Mon, 11 Jan 2016 09:18:09 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC141A8AE4 for ; Mon, 11 Jan 2016 09:18:09 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u0BHG8bI026230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Jan 2016 09:16:09 -0800 (PST) To: "Black, David" , Bob Briscoe , Steve Baillargeon , "tsvwg@ietf.org" References: <568EBB40.9030803@bobbriscoe.net> <5690A8C2.7000202@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <5693E358.9020000@isi.edu> Date: Mon, 11 Jan 2016 09:16:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Ingemar Johansson S , touch@isi.edu Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 17:18:13 -0000 Agreed. My view would be: - when the info is available at the outermost layer of the received packet, AND can be supported as a signal in the set of headers added by encapsulation, then carrying that information cross-layer SHOULD be done - if there is only one layer added, then carrying the info MUST be done (i.e., if the adjacent headers both support the signal) (I say SHOULD for the first one because the system might be implemented using separate encapsulation mechanisms on separate devices, and thus the signal might have been lost by the imposition of an intermediate layer that doesn't have that support) - to note that encapsulation devices are NOT required to parse down into all headers beyond the outermost to find such signals (notably because they might not be able to, given certain types of encryption) So, overall, I would say the best that can be said here is: - MUST if the outermost received and encapsulation headers both support the same kind of signal - MAY if the outermost received header supports the signal AND any of the encapsulation layers added also support the same kind of signal Joe On 1/11/2016 6:24 AM, Black, David wrote: >> I.e., I don't see a good way to *require* all IP-over-FOO-over-IP to >> support cross-layer signal translation. > > Right, needs to be *optional* but how to do it right does deserve to be explained ... > > Thanks, > --David > > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Saturday, January 09, 2016 1:29 AM >> To: Bob Briscoe; Steve Baillargeon; tsvwg@ietf.org >> Cc: Ingemar Johansson S; touch@isi.edu >> Subject: Re: [tsvwg] Please expand RFC6040 to address all IP-based tunnels >> >> It seems difficult to require that tunnels that use multiple layers also >> transfer signalling "over" intermediate headers that might not support >> that capabilities unless all the headers are added in a single location. >> >> I.e., I don't see a good way to *require* all IP-over-FOO-over-IP to >> support cross-layer signal translation. >> >> Joe >> >> On 1/7/2016 11:23 AM, Bob Briscoe wrote: >>> tsvwg folks, >>> >>> In case people missed this over the holiday period, can anyone with >>> experience of doing bis RFCs give advice on the least confusing way to >>> do an RFC6040bis out of options a-d below. >>> >>> Cheers >>> >>> >>> Bob >>> >>> On 30/12/15 14:15, Steve Baillargeon wrote: >>>> >>>> Adding IETF tsvwg list. >>>> >>>> >>>> >>>> -Steve B >>>> >>>> >>>> >>>> *From:*Bob Briscoe [mailto:research@bobbriscoe.net] >>>> *Sent:* Wednesday, December 23, 2015 6:49 PM >>>> *To:* Steve Baillargeon >>>> *Cc:* Ingemar Johansson S; John Kaippallimalil >>>> *Subject:* Re: RFC6040 Questions >>>> >>>> >>>> >>>> Steve, >>>> >>>> We should be having this conversation on the IETF tsvwg list. Then we >>>> would get other people's views. I'm not sure of the IETF position on this. >>>> >>>> Do you mind fwd'ing this thread to tsvwg? >>>> >>>> >>>> Bob >>>> >>>> On 23/12/15 18:27, Steve Baillargeon wrote: >>>> >>>> Hi Bob >>>> >>>> What about doing a RFC6040 bis? >>>> >>>> RFC 6040 title is already generic enough to include all tunnels. >>>> >>>> >>>> >>>> My view is the IP header of the GTP-U tunnel belongs to IETF and >>>> 3GPP must repeat or reduce its scope as needed within its 3GPP spec. >>>> >>>> >>>> >>>> -Steve >>>> >>>> >>>> >>>> >>>> >>>> *From:*Bob Briscoe [mailto:research@bobbriscoe.net] >>>> *Sent:* Tuesday, December 22, 2015 8:16 PM >>>> *To:* Steve Baillargeon >>>> *Cc:* Ingemar Johansson S; John Kaippallimalil >>>> *Subject:* Re: RFC6040 Questions >>>> >>>> >>>> >>>> Steve, >>>> >>>> On 20/12/15 15:40, Steve Baillargeon wrote: >>>> >>>> Hi Bob >>>> >>>> I had the time to look into ecn-encap draft. >>>> >>>> At this point in timer, my biggest concern is mostly how the >>>> information is organized. >>>> >>>> >>>> >>>> ecn-encap states : >>>> >>>> /Therefore, in all such tightly coupled IP-in-IP tunnelling >>>> protocols, the rules in [RFC6040] for propagating the ECN >>>> field between the two IP headers SHOULD be applied directly./ >>>> >>>> >>>> >>>> But RFC 6040 states the doc is for IP-in-IP tunnels (only). >>>> >>>> >>>> >>>> Yes I felt into the trap and originally assumed RFC 6040 would >>>> apply to all "IP-based tunneling protocols" i.e. any tunnel >>>> that requires an outer IP header. >>>> >>>> >>>> >>>> I general, I prefer to have all the info for a given topic in >>>> one doc. I am sure they are many RFCs out there that do not >>>> follow this "guideline". >>>> >>>> But it will be great to have all ECN propagation rules and >>>> guidelines about all IP-based tunneling protocols in 1 place >>>> i.e. in RFC 6040. >>>> >>>> >>>> >>>> I also think that having such consolidated IETF document will >>>> make it easier for 3GPP to updates their documents related to >>>> LTE traffic over GTP-U tunnel and IPSec. >>>> >>>> I will take an action to discuss updates to GTPv1-U spec. I >>>> would prefer to add a reference to a complete RFC 6040 as >>>> opposed to "re-invent the wheel" in the GTPv1-U spec. >>>> >>>> For a 3GPP protocol (like GTP), the IETF doesn't have change >>>> authority over it anyway. The 3GPP has to change the GTP spec. And >>>> once ecn-encap is published as an RFC it will give the 3GPP the >>>> necessary IETF reference to do that. >>>> >>>> However the standards ownership is a bit hard to unpick, because >>>> GTP is a construction of IP (=IETF) headers with a GTP header >>>> (=3GPP) in between. So the 3GPP has to specify what values a GTP >>>> tunnel endpoint should put in IP header fields, when the 3GPP >>>> doesn't actually have jurisdiction over IP. That's why I'm trying >>>> to make it easy for 3GPP, giving them an IETF spec to cite that >>>> says what the IETF would do in the general case. But in writing >>>> that, I have to be careful not to tread on the 3GPP's toes! >>>> >>>> Rather than state this rule only in ecn-encap (once it is an RFC), >>>> I would also prefer to be able to tweak RFC6040 to widen the >>>> over-narrow scope I gave it at the time. I will try, but RFCs can >>>> never be materially changed one published, so the only ways to do >>>> that are: >>>> a) An erratum to RFC6040; >>>> b) A new RFC containing the whole text of RFC6040 verbatim, plus >>>> the extra scope statement. >>>> c) Add an "Updates RFC6040" header to ecn-encap, so when it >>>> becomes RFC the short section on tunnelling will update RFC6040. >>>> d) A very short new standards track RFC with the additional scope >>>> statement for RFC6040, and a header that says >>>> Updates: RFC6040 >>>> which will then cause RFC6040 to be flagged as "Updated by RFCXXXX" >>>> >>>> (a) is only applicable to correct a non-technical error, so >>>> unlikely to be acceptable to the IETF. >>>> (b) isn't the way the IETF normally works, because it opens up all >>>> the original debates on the wording of RFC6040 that were closed >>>> when it was published. >>>> (c) is not feasible, because ecn-encap is a BCP, which cannot >>>> update a Proposed Standard. Also, ecn-encap is long, and only one >>>> short paragraph would update RFC6040, so I don't like this >>>> approach because it's messy and unclear >>>> (d) is likely to be the only way the IETF allows - it is the >>>> 'normal' way the IETF works. >>>> >>>> Altho (b) would be tidier, (d) is all that can happen. >>>> >>>> >>>> >>>> >>>> >>>> Regarding the aspect of having multiple IP-based tunnels >>>> terminating at the same end node/device. >>>> >>>> For instance: inner IP/GTP-U/middle IP /ESP/outer IP (omitting UDP >>>> here) >>>> >>>> If ECN propagation is not successfully at the outer encapsulator, >>>> then I believe the end node must inspect the middle IP header and >>>> propagate middle ECN to inner IP as you have it defined in Figure >>>> 4 in RFC 6040. >>>> >>>> Therefore, in practice, I believe we will always need to inspect >>>> both middle and outer IP headers at the dual tunnel decapsulator . >>>> >>>> What does "ECN propagation is not successful at the outer >>>> encapsulator" actually mean? >>>> >>>> Actually you don't need to answer. Because I have realised that >>>> the ECN propagation rules have to be applied to one pair of IP >>>> headers at a time, even before one considers testing for all the >>>> illegal or CU (Currently Unused) combinations of ECN fields in Fig >>>> 4 of RFC6040. >>>> >>>> A CE middle can legitimately be encapsulated by an ECT(0) outer if >>>> the tunnel ingress is RFC3168-compliant (which is why this is a >>>> legitimate combination in Fig 4 in RFC6040). So the outer can >>>> legitimately be ECT(0) while the middle is CE, and the inner is >>>> ECT(0) (say). So, it would be wrong for decap to ignore the CE in >>>> the middle by just applying RFC6040 propagation rules between >>>> outer and inner. >>>> >>>> >>>> >>>> >>>> >>>> My second biggest concern is how to achieve "incremental >>>> deployment" without negatively impacting the forwarding capacity >>>> of the tunnel encapsulators/decapsulators. >>>> >>>> I suspect many existing tunnel encapsulators and decapsulators do >>>> not support ECN field nor ECN propagation rules. >>>> >>>> For implementers who follow standards carefully, that should be >>>> rare for IPsec hardware, because ECN was around (if experimental) >>>> when IPsec was defined, and there was a lot of discussion with the >>>> security community about ECN. >>>> >>>> However, even for standards-conscientious implementers, it's >>>> likely that early non-IPsec (IP-in-IP) tunnel hardware doesn't >>>> support ECN. And possibly later hardware too, because RFC3168 >>>> omitted to flag in its headers that it updated RFC2003. However >>>> when I noticed this I registered an erratum to RFC2003, so that at >>>> least it is flagged as updated by RFC3168. >>>> >>>> Nonetheless, I am also well-aware that a number of IPsec tunnel >>>> implementers are not standards-conscientious, and think they are >>>> entitled to ignore ECN propagation (or invent their own way of >>>> doing it). Reasoning ranges from i) not even being aware of ECN, >>>> through ii) "ECN isn't deployed yet" to iii) a belief that a >>>> security hat entitles you to ignore standards that do not seem to >>>> be security-related (as I've said, information security people can >>>> tend to be blind to traffic security issues). >>>> >>>> >>>> >>>> Do you expect the implementer to initial support the RFC 6040 ECN >>>> propagation rules in "software"? >>>> >>>> If so, I suspect it will cause reduction in forwarding capacity (?). >>>> >>>> Do you have any feedback or suggestion on this matter? >>>> >>>> I wouldn't expect support for RFC6040 to be universal yet because >>>> it's only 5 years old, but it doesn't have to be universal - >>>> compliance with the earlier protocols that it consolidated >>>> (RFC3168 and/or RFC4301) would be sufficient for interoperability. >>>> >>>> However, I would have very little sympathy for an implementer that >>>> had failed to comply with a 15-year-old standards-track change >>>> [RFC3168] to the most important interoperability protocols in the >>>> world (IPv4 & IPv6). So if an operator discovers it is operating >>>> boxes in its network that do not comply with (say) RFC3168, it >>>> should check when it tendered for the box. IMO, if this was less >>>> than 15 years ago, it would be perfectly entitled to go back to >>>> the implementer and seek redress for a failure to comply with the >>>> IP standards in force at the time of tender (obviously depending >>>> on the exact wording of the contracts and tenders). >>>> >>>> If all ECN-tunnelling standards have been ignored, I imagine the >>>> most likely behaviour will be: >>>> * copy inner to outer on encap (because the outer is usually >>>> constructed by modifying a copy of the inner). [This would be >>>> RFC6040 compliant anyway] >>>> * ignore outer on decap [non-compliant] >>>> So the problem is only on decap. >>>> >>>> I think there is a temporary hardware solution for decap, by >>>> abbreviating the rules in Table 4 of RFC6040 to reduce the codepath: >>>> foreach packet { >>>> if (read(packet, ECN_outer) == CE) { >>>> strip_outer(); >>>> remark(packet, ECN_inner) = CE; >>>> } else strip_outer(); >>>> } >>>> >>>> These three steps can be done by configuration of today's >>>> hardware. An operator could temporarily use this hack as long as: >>>> a) it was doing no ECT(1) marking in its network (at the moment >>>> only PCN does that) >>>> b) it had deployed nothing in its network that relied on the drop >>>> behaviour in Table 4 of RFC6040 >>>> >>>> Don't quote me on this! I'm not really advocating that operators >>>> don't need to comply with RFC6040. The whole point of which was to >>>> ensure a single predictable behaviour from all tunnel equipment. >>>> >>>> Nonetheless, if introducing the extra steps for CE-marked packets >>>> reduced performance, it shouldn't be too bad, as long as CE >>>> packets were a small proportion of the aggregate (which would be >>>> typical initially, altho the introduction of scalable TCP hosts in >>>> a few year's time could change that). >>>> If the hardware couldn't keep up, it would merely drop some CE >>>> packets. >>>> >>>> On the other hand, if decap were left completely non-compliant, >>>> the result would also be drops - but probably worse episodes of >>>> drop than might be caused by very occasional processor overload >>>> due to one extra process step. The drop would probably be worse, >>>> because, it would be caused by an oscillation of end-system load >>>> overrunning capacity. Explanation: if there were an ECN router in >>>> the middle of such a tunnel, any congestion marking would get >>>> discarded at egress, leading to the sender causing more and more >>>> severe congestion until drop started. That wouldn't be fatal, but >>>> it would lead to intermittently high drop. >>>> >>>> >>>> >>>> Bob >>>> >>>> >>>> >>>> >>>> Thank you Bob >>>> >>>> >>>> >>>> Regards >>>> >>>> Steve Baillargeon >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:*Steve Baillargeon >>>> *Sent:* Thursday, December 03, 2015 11:52 AM >>>> *To:* 'Bob Briscoe' >>>> *Cc:* Ingemar Johansson S; John Kaippallimalil >>>> *Subject:* RE: RFC6040 Questions >>>> >>>> >>>> >>>> Hi Bob >>>> >>>> Thank you for the detailed response. Very helpful. >>>> >>>> >>>> >>>> Let me review your proposal i.e. ignore the intermediate header. >>>> >>>> I will investigate the main GTP-U and IPSec uses cases and it see >>>> if it holds. >>>> >>>> >>>> >>>> I will also try to comment as you requested on >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines- >> 04#section-5.1 >>>> >>>> >>>> >>>> >>>> >>>> Regards >>>> >>>> Steve Baillargeon >>>> >>>> Ericsson >>>> >>>> >>>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>> > From nobody Tue Jan 12 08:30:51 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E180F1A1B82 for ; Tue, 12 Jan 2016 08:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3ZULd9MuGrO for ; Tue, 12 Jan 2016 08:30:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDD11ACC7F for ; Tue, 12 Jan 2016 08:30:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCV71111; Tue, 12 Jan 2016 16:30:44 +0000 (GMT) Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jan 2016 16:30:43 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jan 2016 16:30:43 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Tue, 12 Jan 2016 08:30:37 -0800 From: Lucy yong To: "Black, David" , "tsvwg@ietf.org" Thread-Topic: GRE/UDP and UDP Guidelines drafts: applicability terms Thread-Index: AdFMkXjjh0uyQspgQWa7UaKof+TKRwAwZN0g Date: Tue, 12 Jan 2016 16:30:37 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57235256@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.243] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56952A34.00C9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f9d4b163b69a3cc168b08fbaa6a83ed5 Archived-At: Subject: Re: [tsvwg] GRE/UDP and UDP Guidelines drafts: applicability terms X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:30:50 -0000 It is good for GRE/UDP draft to align with UDP Guidelines. UDP Guideline de= scribes two types of applicability that IETF applications utilizes UDP: Gen= eral Internet and Controlled Environment. The controlled environment means = within single administrative domain or bilaterally agreed connection betwee= n domains Controlled environment can be managed/operated to meet certain co= nditions, which the general Internet can't.=20 For GRE/UDP draft, it is better to define a well-managed operator network a= s a controlled environment that can avoid congestion; then address zero-udp= checksum for IPv6 as an additional special case for a well-managed operato= r network.=20 Thanks, Lucy -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David Sent: Monday, January 11, 2016 11:00 AM To: tsvwg@ietf.org Subject: [tsvwg] GRE/UDP and UDP Guidelines drafts: applicability terms Both the GRE/UDP draft and the UDP Guidelines draft are defining and using = terminology for a couple of applicability scenarios: GRE/UDP, section 1.1 (https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-08): - General IP Network: 1) Use of GRE-in-UDP in a general IP network including the Internet, - Well-Managed Operator IP Network 2) Use of GRE-in-UDP in a well-managed operator IP network, [this is about traffic management to avoid congestion, and about nature of the network or applications that enables safe use of zero UDP checksum for IPv6.] UDP Guidelines, section 3.6 (https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-07#section-3.6): - General Internet. By default, IETF specifications target deployment on the general Internet. Experience has shown that successful protocols developed in one specific context or for a particular application tends to become used in a wider range of contexts. - Controlled Environment A protocol/encapsulation/tunnel could be designed to be used only within a controlled environment. For example, an application designed for use by a network operator might only be deployed within the network of that single network operator or on networks of an adjacent set of cooperating network operators. There will be a new version of the GRE/UDP draft coming in the near future,= and it would be good to get alignment on the above terminology in that ver= sion. The following are some initial "strawman" ideas for discussion, starting fr= om a view that we may not need a total of 4 terms: a) "General IP Network" and "General Internet" appear to be the same concept, so we should pick one term. My initial suggestion is to use "General Network" and make the need to design for the Internet clear in the definition of the scenario. I'm concerned that use of the word "Internet" in the name of the could be misinterpreted as the scenario being public-Internet-only (NB: capitalized 'I'). b) Controlled Environment seems to be a superset of Well-Managed [IP] Network. I'd suggest using roughly those two terms: - Controlled Environment in the UDP Guidelines draft - Well Managed Network in the GRE/UDP draft, as an example (or subset) of a Controlled Environment. It feels like a good idea to also discuss this in the UDP Guidelines draft (which already has some text on this), but it's probably more productive to work out the details in the GRE/UDP draft first. I also don't think the "IP" acronym is essential as part of the name. Thoughts? Dead Cats/Rotten Tomatoes? :-). Seriously, please do comment - the results of this discussion should be ref= lected in the next version of the GRE/UDP draft, and we're likely to see si= gnificant usage of this terminology in drafts that use UDP-based encapsulat= ions in the future. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Tue Jan 12 09:11:13 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA811A90E6 for ; Tue, 12 Jan 2016 09:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEYMLC7cVORp for ; Tue, 12 Jan 2016 09:11:09 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 B449D1A1BDC for ; Tue, 12 Jan 2016 09:11:09 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g73so194909840ioe.3 for ; Tue, 12 Jan 2016 09:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bqswghUhgJVy34sNtEN0pxxxScHj1T18nRTKouI38bE=; b=QyoU6Md4s99lymUy+jRiSOlFLlCn4dQlaOGFWcpDrYbEvjDaCTvLRo3bNor4IQ4c9u V/6N6ehTnRp2C5H4sSczGUc04Owngvob0pCgICZKkmBwc08cLi5W7lSQfmc462CXMpNu UdcgnE5YqIOYzDKmsloo4vpcu07ZJkcAc4RPE5YvdSSklDiDdby9m1Eo4cY4DQb1lk42 H3KFwOW0wGiSFYoLx4nHfhLA7InzPSuPBKc66KYLYEqgELEt9gvreLSvWQVIi3uyu6Kw aUHF71CWR/K0rfjsE8Ty0MAYHFZrW8NMUspccG53mTLXRJnn5t0CQS5me4oA7D7ZnrAa YA7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bqswghUhgJVy34sNtEN0pxxxScHj1T18nRTKouI38bE=; b=OaGQNc7WsSwnUWjNn36PEznDzIES6c5aP4+Vx3SCiUYq73NgTRLYI8+d3yjS2FBuzw ilWOHiPFEpymz8LKGG9T9m5HzU7ntW4BIhYnwsm1sLnb5VVKdUyppqGXe0OxTYmtHgey KSS56+Ua+PgemRYuXrebIWnGaaTA4AZ4gUsjm0AXHRDO1+GKUIu2E9nZnvWJ34JaLnOV Hsq1fm4ywrxGgoDLPOqGmrnBdZiESE9nS4LAfeZoqLJuFkvd/+EjBcLOuufoSw1brPw/ fwZyPYTPSWGVuFaI7oV6W+/iSaA99IMPxbNoakBbUo50oAUO52ORPyuEz6Aq02WnG1Va 2A7A== X-Gm-Message-State: ALoCoQmOZGkd6dJhuh9+FT9cLw+FDbKtDSCa1bEwxujf4KLugqZr+Zu8FC1Jk7M/IIK1jjSbUkpVWyXA8wgCsIPxRHByxkt+sg== MIME-Version: 1.0 X-Received: by 10.107.18.71 with SMTP id a68mr136604985ioj.107.1452618669095; Tue, 12 Jan 2016 09:11:09 -0800 (PST) Received: by 10.107.140.150 with HTTP; Tue, 12 Jan 2016 09:11:09 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57235256@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D57235256@dfweml701-chm> Date: Tue, 12 Jan 2016 09:11:09 -0800 Message-ID: From: Tom Herbert To: Lucy yong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] GRE/UDP and UDP Guidelines drafts: applicability terms X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 17:11:11 -0000 On Tue, Jan 12, 2016 at 8:30 AM, Lucy yong wrote: > It is good for GRE/UDP draft to align with UDP Guidelines. UDP Guideline = describes two types of applicability that IETF applications utilizes UDP: G= eneral Internet and Controlled Environment. The controlled environment mean= s within single administrative domain or bilaterally agreed connection betw= een domains Controlled environment can be managed/operated to meet certain = conditions, which the general Internet can't. > > For GRE/UDP draft, it is better to define a well-managed operator network= as a controlled environment that can avoid congestion; then address zero-u= dp checksum for IPv6 as an additional special case for a well-managed opera= tor network. > I tend to agree. A well managed network is reasonable for relaxing the congestion control requirements, but does not necessarily imply the zero UDP6 checksum is acceptable. > Thanks, > Lucy > > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > Sent: Monday, January 11, 2016 11:00 AM > To: tsvwg@ietf.org > Subject: [tsvwg] GRE/UDP and UDP Guidelines drafts: applicability terms > > > > Both the GRE/UDP draft and the UDP Guidelines draft are defining and usin= g terminology for a couple of applicability scenarios: > > GRE/UDP, section 1.1 > (https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-08): > - General IP Network: > 1) Use of GRE-in-UDP in a general IP network including the Internet, > - Well-Managed Operator IP Network > 2) Use of GRE-in-UDP in a well-managed operator IP network, > [this is about traffic management to avoid congestion, and about > nature of the network or applications that enables safe u= se > of zero UDP checksum for IPv6.] > > UDP Guidelines, section 3.6 > (https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-07#section-3.6): > - General Internet. By default, IETF specifications target deployment > on the general Internet. Experience has shown that successful > protocols developed in one specific context or for a particular > application tends to become used in a wider range of contexts. > - Controlled Environment A protocol/encapsulation/tunnel could be > designed to be used only within a controlled environment. For > example, an application designed for use by a network operator > might only be deployed within the network of that single network > operator or on networks of an adjacent set of cooperating network > operators. > > There will be a new version of the GRE/UDP draft coming in the near futur= e, and it would be good to get alignment on the above terminology in that v= ersion. > > > > > The following are some initial "strawman" ideas for discussion, starting = from a view that we may not need a total of 4 terms: > > a) "General IP Network" and "General Internet" appear to be the same > concept, so we should pick one term. My initial suggestion is > to use "General Network" and make the need to design for the Inte= rnet > clear in the definition of the scenario. I'm concerned that use > of the word "Internet" in the name of the could be misinterpreted > as the scenario being public-Internet-only (NB: capitalized 'I'). > > b) Controlled Environment seems to be a superset of Well-Managed [IP] > Network. I'd suggest using roughly those two terms: > - Controlled Environment in the UDP Guidelines draft > - Well Managed Network in the GRE/UDP draft, as an example (or > subset) of a Controlled Environment. It feels like a goo= d > idea to also discuss this in the UDP Guidelines draft (wh= ich > already has some text on this), but it's probably more pr= oductive > to work out the details in the GRE/UDP draft first. I al= so > don't think the "IP" acronym is essential as part of the = name. > > Thoughts? Dead Cats/Rotten Tomatoes? :-). > > Seriously, please do comment - the results of this discussion should be r= eflected in the next version of the GRE/UDP draft, and we're likely to see = significant usage of this terminology in drafts that use UDP-based encapsul= ations in the future. > > > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > From nobody Tue Jan 12 09:21:47 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6551A00E3 for ; Tue, 12 Jan 2016 09:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_3v2pmlfsyB for ; Tue, 12 Jan 2016 09:21:43 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 A58421A00E0 for ; Tue, 12 Jan 2016 09:21:43 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0CHLW0Y004288 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jan 2016 12:21:32 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u0CHLW0Y004288 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1452619292; bh=q6BWm0gkUujH26XkwQYOlGig65c=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=S6ypeMYUk1cnrf04FF6/niGQ+1wUHA2O3Z0c2BqDZV1agiQRkstG+i6+c4W6Px1v5 cjdAVHkojj1EQY0RK5qIP/CpoJrm6SY0RzizNLZ+kJO4hu+/PzhUjvzQ1RJT1/zN2F ZIMEDf8rLHLaMeW4ITMorz0K4T1vZvpJomVs5/78= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u0CHLW0Y004288 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd04.lss.emc.com (RSA Interceptor); Tue, 12 Jan 2016 12:20:52 -0500 Received: from MXHUB108.corp.emc.com (MXHUB108.corp.emc.com [10.253.58.24]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0CHLM4K021846 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Jan 2016 12:21:23 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0266.001; Tue, 12 Jan 2016 12:21:22 -0500 From: "Black, David" To: Tom Herbert , Lucy yong Thread-Topic: [tsvwg] GRE/UDP and UDP Guidelines drafts: applicability terms Thread-Index: AdFMkXjjh0uyQspgQWa7UaKof+TKRwAwZN0gAAzF1YAACi/3AA== Date: Tue, 12 Jan 2016 17:21:22 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D57235256@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.52.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] GRE/UDP and UDP Guidelines drafts: applicability terms X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 17:21:46 -0000 V2l0aCA8V0cgY2hhaXIgaGF0IE9GRj4gSSBsaWtld2lzZSBhZ3JlZSAoc29ycnkgZm9yIG5vdCBt YWtpbmcgdGhpcyBjbGVhciBpbg0KdGhlIGluaXRpYWwgbWVzc2FnZSkuICBUaGFua3MsIC0tRGF2 aWQNCg0KPiBPbiBUdWUsIEphbiAxMiwgMjAxNiBhdCA4OjMwIEFNLCBMdWN5IHlvbmcgPGx1Y3ku eW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gPiBJdCBpcyBnb29kIGZvciBHUkUvVURQIGRyYWZ0 IHRvIGFsaWduIHdpdGggVURQIEd1aWRlbGluZXMuIFVEUCBHdWlkZWxpbmUNCj4gZGVzY3JpYmVz IHR3byB0eXBlcyBvZiBhcHBsaWNhYmlsaXR5IHRoYXQgSUVURiBhcHBsaWNhdGlvbnMgdXRpbGl6 ZXMgVURQOg0KPiBHZW5lcmFsIEludGVybmV0IGFuZCBDb250cm9sbGVkIEVudmlyb25tZW50LiBU aGUgY29udHJvbGxlZCBlbnZpcm9ubWVudCBtZWFucw0KPiB3aXRoaW4gc2luZ2xlIGFkbWluaXN0 cmF0aXZlIGRvbWFpbiBvciBiaWxhdGVyYWxseSBhZ3JlZWQgY29ubmVjdGlvbiBiZXR3ZWVuDQo+ IGRvbWFpbnMgQ29udHJvbGxlZCBlbnZpcm9ubWVudCBjYW4gYmUgbWFuYWdlZC9vcGVyYXRlZCB0 byBtZWV0IGNlcnRhaW4NCj4gY29uZGl0aW9ucywgd2hpY2ggdGhlIGdlbmVyYWwgSW50ZXJuZXQg Y2FuJ3QuDQo+ID4NCj4gPiBGb3IgR1JFL1VEUCBkcmFmdCwgaXQgaXMgYmV0dGVyIHRvIGRlZmlu ZSBhIHdlbGwtbWFuYWdlZCBvcGVyYXRvciBuZXR3b3JrIGFzDQo+IGEgY29udHJvbGxlZCBlbnZp cm9ubWVudCB0aGF0IGNhbiBhdm9pZCBjb25nZXN0aW9uOyB0aGVuIGFkZHJlc3MgemVyby11ZHAN Cj4gY2hlY2tzdW0gZm9yIElQdjYgYXMgYW4gYWRkaXRpb25hbCBzcGVjaWFsIGNhc2UgZm9yIGEg d2VsbC1tYW5hZ2VkIG9wZXJhdG9yDQo+IG5ldHdvcmsuDQo+ID4NCj4gSSB0ZW5kIHRvIGFncmVl LiBBIHdlbGwgbWFuYWdlZCBuZXR3b3JrIGlzIHJlYXNvbmFibGUgZm9yIHJlbGF4aW5nIHRoZQ0K PiBjb25nZXN0aW9uIGNvbnRyb2wgcmVxdWlyZW1lbnRzLCBidXQgZG9lcyBub3QgbmVjZXNzYXJp bHkgaW1wbHkgdGhlDQo+IHplcm8gVURQNiBjaGVja3N1bSBpcyBhY2NlcHRhYmxlLg0KPiANCj4g PiBUaGFua3MsDQo+ID4gTHVjeQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCbGFjaywgRGF2aWQNCj4gPiBTZW50OiBNb25kYXksIEphbnVhcnkgMTEsIDIwMTYgMTE6 MDAgQU0NCj4gPiBUbzogdHN2d2dAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbdHN2d2ddIEdSRS9V RFAgYW5kIFVEUCBHdWlkZWxpbmVzIGRyYWZ0czogYXBwbGljYWJpbGl0eSB0ZXJtcw0KPiA+DQo+ ID4gPFdHIGNoYWlyIGhhdCBPTj4NCj4gPg0KPiA+IEJvdGggdGhlIEdSRS9VRFAgZHJhZnQgYW5k IHRoZSBVRFAgR3VpZGVsaW5lcyBkcmFmdCBhcmUgZGVmaW5pbmcgYW5kIHVzaW5nDQo+IHRlcm1p bm9sb2d5IGZvciBhIGNvdXBsZSBvZiBhcHBsaWNhYmlsaXR5IHNjZW5hcmlvczoNCj4gPg0KPiA+ IEdSRS9VRFAsIHNlY3Rpb24gMS4xDQo+ID4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMDgpOg0KPiA+IC0gR2VuZXJhbCBJUCBO ZXR3b3JrOg0KPiA+ICAgIDEpIFVzZSBvZiBHUkUtaW4tVURQIGluIGEgZ2VuZXJhbCBJUCBuZXR3 b3JrIGluY2x1ZGluZyB0aGUgSW50ZXJuZXQsDQo+ID4gLSBXZWxsLU1hbmFnZWQgT3BlcmF0b3Ig SVAgTmV0d29yaw0KPiA+ICAgIDIpIFVzZSBvZiBHUkUtaW4tVURQIGluIGEgd2VsbC1tYW5hZ2Vk IG9wZXJhdG9yIElQIG5ldHdvcmssDQo+ID4gICAgICAgICBbdGhpcyBpcyBhYm91dCB0cmFmZmlj IG1hbmFnZW1lbnQgdG8gYXZvaWQgY29uZ2VzdGlvbiwgYW5kIGFib3V0DQo+ID4gICAgICAgICAg ICAgICAgIG5hdHVyZSBvZiB0aGUgbmV0d29yayBvciBhcHBsaWNhdGlvbnMgdGhhdCBlbmFibGVz IHNhZmUgdXNlDQo+ID4gICAgICAgICAgICAgICAgIG9mIHplcm8gVURQIGNoZWNrc3VtIGZvciBJ UHY2Ll0NCj4gPg0KPiA+IFVEUCBHdWlkZWxpbmVzLCBzZWN0aW9uIDMuNg0KPiA+IChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1yZmM1NDA1YmlzLTA3I3NlY3Rp b24tMy42KToNCj4gPiAtIEdlbmVyYWwgSW50ZXJuZXQuICBCeSBkZWZhdWx0LCBJRVRGIHNwZWNp ZmljYXRpb25zIHRhcmdldCBkZXBsb3ltZW50DQo+ID4gICAgICAgb24gdGhlIGdlbmVyYWwgSW50 ZXJuZXQuICBFeHBlcmllbmNlIGhhcyBzaG93biB0aGF0IHN1Y2Nlc3NmdWwNCj4gPiAgICAgICBw cm90b2NvbHMgZGV2ZWxvcGVkIGluIG9uZSBzcGVjaWZpYyBjb250ZXh0IG9yIGZvciBhIHBhcnRp Y3VsYXINCj4gPiAgICAgICBhcHBsaWNhdGlvbiB0ZW5kcyB0byBiZWNvbWUgdXNlZCBpbiBhIHdp ZGVyIHJhbmdlIG9mIGNvbnRleHRzLg0KPiA+IC0gQ29udHJvbGxlZCBFbnZpcm9ubWVudCAgQSBw cm90b2NvbC9lbmNhcHN1bGF0aW9uL3R1bm5lbCBjb3VsZCBiZQ0KPiA+ICAgICAgIGRlc2lnbmVk IHRvIGJlIHVzZWQgb25seSB3aXRoaW4gYSBjb250cm9sbGVkIGVudmlyb25tZW50LiAgRm9yDQo+ ID4gICAgICAgZXhhbXBsZSwgYW4gYXBwbGljYXRpb24gZGVzaWduZWQgZm9yIHVzZSBieSBhIG5l dHdvcmsgb3BlcmF0b3INCj4gPiAgICAgICBtaWdodCBvbmx5IGJlIGRlcGxveWVkIHdpdGhpbiB0 aGUgbmV0d29yayBvZiB0aGF0IHNpbmdsZSBuZXR3b3JrDQo+ID4gICAgICAgb3BlcmF0b3Igb3Ig b24gbmV0d29ya3Mgb2YgYW4gYWRqYWNlbnQgc2V0IG9mIGNvb3BlcmF0aW5nIG5ldHdvcmsNCj4g PiAgICAgICBvcGVyYXRvcnMuDQo+ID4NCj4gPiBUaGVyZSB3aWxsIGJlIGEgbmV3IHZlcnNpb24g b2YgdGhlIEdSRS9VRFAgZHJhZnQgY29taW5nIGluIHRoZSBuZWFyIGZ1dHVyZSwNCj4gYW5kIGl0 IHdvdWxkIGJlIGdvb2QgdG8gZ2V0IGFsaWdubWVudCBvbiB0aGUgYWJvdmUgdGVybWlub2xvZ3kg aW4gdGhhdA0KPiB2ZXJzaW9uLg0KPiA+DQo+ID4gPC9XRyBjaGFpciBoYXQgT04+DQo+ID4NCj4g PiA8V0cgY2hhaXIgaGF0IE9GRj4NCj4gPiBUaGUgZm9sbG93aW5nIGFyZSBzb21lIGluaXRpYWwg InN0cmF3bWFuIiBpZGVhcyBmb3IgZGlzY3Vzc2lvbiwgc3RhcnRpbmcNCj4gZnJvbSBhIHZpZXcg dGhhdCB3ZSBtYXkgbm90IG5lZWQgYSB0b3RhbCBvZiA0IHRlcm1zOg0KPiA+DQo+ID4gYSkgIkdl bmVyYWwgSVAgTmV0d29yayIgYW5kICJHZW5lcmFsIEludGVybmV0IiBhcHBlYXIgdG8gYmUgdGhl IHNhbWUNCj4gPiAgICAgICAgIGNvbmNlcHQsIHNvIHdlIHNob3VsZCBwaWNrIG9uZSB0ZXJtLiAg TXkgaW5pdGlhbCBzdWdnZXN0aW9uIGlzDQo+ID4gICAgICAgICB0byB1c2UgIkdlbmVyYWwgTmV0 d29yayIgYW5kIG1ha2UgdGhlIG5lZWQgdG8gZGVzaWduIGZvciB0aGUNCj4gSW50ZXJuZXQNCj4g PiAgICAgICAgIGNsZWFyIGluIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBzY2VuYXJpby4gIEknbSBj b25jZXJuZWQgdGhhdCB1c2UNCj4gPiAgICAgICAgIG9mIHRoZSB3b3JkICJJbnRlcm5ldCIgaW4g dGhlIG5hbWUgb2YgdGhlIGNvdWxkIGJlIG1pc2ludGVycHJldGVkDQo+ID4gICAgICAgICBhcyB0 aGUgc2NlbmFyaW8gYmVpbmcgcHVibGljLUludGVybmV0LW9ubHkgKE5COiBjYXBpdGFsaXplZCAn SScpLg0KPiA+DQo+ID4gYikgQ29udHJvbGxlZCBFbnZpcm9ubWVudCBzZWVtcyB0byBiZSBhIHN1 cGVyc2V0IG9mIFdlbGwtTWFuYWdlZCBbSVBdDQo+ID4gICAgICAgICBOZXR3b3JrLiAgSSdkIHN1 Z2dlc3QgdXNpbmcgcm91Z2hseSB0aG9zZSB0d28gdGVybXM6DQo+ID4gICAgICAgICAtIENvbnRy b2xsZWQgRW52aXJvbm1lbnQgaW4gdGhlIFVEUCBHdWlkZWxpbmVzIGRyYWZ0DQo+ID4gICAgICAg ICAtIFdlbGwgTWFuYWdlZCBOZXR3b3JrIGluIHRoZSBHUkUvVURQIGRyYWZ0LCBhcyBhbiBleGFt cGxlIChvcg0KPiA+ICAgICAgICAgICAgICAgICBzdWJzZXQpIG9mIGEgQ29udHJvbGxlZCBFbnZp cm9ubWVudC4gIEl0IGZlZWxzIGxpa2UgYSBnb29kDQo+ID4gICAgICAgICAgICAgICAgIGlkZWEg dG8gYWxzbyBkaXNjdXNzIHRoaXMgaW4gdGhlIFVEUCBHdWlkZWxpbmVzIGRyYWZ0ICh3aGljaA0K PiA+ICAgICAgICAgICAgICAgICBhbHJlYWR5IGhhcyBzb21lIHRleHQgb24gdGhpcyksIGJ1dCBp dCdzIHByb2JhYmx5IG1vcmUNCj4gcHJvZHVjdGl2ZQ0KPiA+ICAgICAgICAgICAgICAgICB0byB3 b3JrIG91dCB0aGUgZGV0YWlscyBpbiB0aGUgR1JFL1VEUCBkcmFmdCBmaXJzdC4gIEkgYWxzbw0K PiA+ICAgICAgICAgICAgICAgICBkb24ndCB0aGluayB0aGUgIklQIiBhY3JvbnltIGlzIGVzc2Vu dGlhbCBhcyBwYXJ0IG9mIHRoZQ0KPiBuYW1lLg0KPiA+DQo+ID4gVGhvdWdodHM/IERlYWQgQ2F0 cy9Sb3R0ZW4gVG9tYXRvZXM/IDotKS4NCj4gPg0KPiA+IFNlcmlvdXNseSwgcGxlYXNlIGRvIGNv bW1lbnQgLSB0aGUgcmVzdWx0cyBvZiB0aGlzIGRpc2N1c3Npb24gc2hvdWxkIGJlDQo+IHJlZmxl Y3RlZCBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBHUkUvVURQIGRyYWZ0LCBhbmQgd2UncmUg bGlrZWx5IHRvIHNlZQ0KPiBzaWduaWZpY2FudCB1c2FnZSBvZiB0aGlzIHRlcm1pbm9sb2d5IGlu IGRyYWZ0cyB0aGF0IHVzZSBVRFAtYmFzZWQNCj4gZW5jYXBzdWxhdGlvbnMgaW4gdGhlIGZ1dHVy ZS4NCj4gPg0KPiA+IDwvV0cgY2hhaXIgaGF0IE9GRj4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiAt LURhdmlkDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+IERhdmlkIEwuIEJsYWNrLCBEaXN0aW5ndWlzaGVkIEVuZ2luZWVyDQo+ID4g RU1DIENvcnBvcmF0aW9uLCAxNzYgU291dGggU3QuLCBIb3BraW50b24sIE1BICAwMTc0OA0KPiA+ ICsxICg1MDgpIDI5My03OTUzICAgICAgICAgICAgIEZBWDogKzEgKDUwOCkgMjkzLTc3ODYNCj4g PiBkYXZpZC5ibGFja0BlbWMuY29tICAgICAgICBNb2JpbGU6ICsxICg5NzgpIDM5NC03NzU0DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+DQo= From nobody Tue Jan 12 12:01:46 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6472A1A8821 for ; Tue, 12 Jan 2016 12:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwka7FmkgyAw for ; Tue, 12 Jan 2016 12:01:42 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 8D2371A882F for ; Tue, 12 Jan 2016 12:01:19 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id k206so80035262oia.1 for ; Tue, 12 Jan 2016 12:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KSvwGM/q9mw6DmQ6IicIt+oaNZ32LVn1CVrjbqILneM=; b=NdLtkPJnJACkNttc74fQOFO7gbSXfd4w7Y86FqoF8B7Qtq1+HVPTwfE2+4EBC4Zyjs 16OcArAjUfoOpDZ360Usr0SRBf3b4W85jk4Kk4619dhR3AW/gwUGKmfr7NnL+VQcj8SK ZpMN9H9kvg3Qfb8V3JpHoYVEZS1DNyyD+xK92yQYXdW/7uFMLtEgATdPMUJs/jwux7+S tt00id9M0Di9xQjWTn94Gw16v4spDRKIGa7TGfrb5XegC6b0ocnOQ2ugBXJiy2VBavKE P8cTXa8chY1Mw5dqFjR5e2mH2domhjCU2pX90n64oce52n6VBAEqPkeuKV51tosMd/bS VOFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KSvwGM/q9mw6DmQ6IicIt+oaNZ32LVn1CVrjbqILneM=; b=l0R0F+YKj+JtUT60oAE14VgN2MhpKzXLpRVzWRJcXACiPJ/RQHg4EkzyxX6W8LgLbh pBJe/KLOsyqt9tQnWcR3SqHqZX+l4rhxi4G2J4U/IIP/+6OQgiquQxPYrLwGtPw9tpMQ TCc6nIVMJBYw1IZh6I36dcrzC6M7LTkrNM+vkr6PBwd8PqWFpl1QXy66rUVr54/J6kAX 6vAJqbtlBBQpUuBwa6+07hkiHUBV/S9hrX6GSJ0Hxj9Pnp7XIcDuwI/OW2+OvjrFjVGB ZgjCWPxKozpPyPBXRlWCoSlRNZ0ROzgRmrhdxHXlIz6jzztKEHBoNo+EAXJg+kDBjC9n UOrg== X-Gm-Message-State: ALoCoQknI8e+yYifTcQPfW/aVQL71/EUPPzKpEsKfO+aVbsvWk2G+QBPLzT2cME41n22/1XBvITIT5iTJs9qH3i89bmd8QWx/ZRI6WYjhrsCsDRaZ9rwOFk= MIME-Version: 1.0 X-Received: by 10.202.88.65 with SMTP id m62mr15981979oib.36.1452628878734; Tue, 12 Jan 2016 12:01:18 -0800 (PST) Received: by 10.76.3.79 with HTTP; Tue, 12 Jan 2016 12:01:18 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Jan 2016 12:01:18 -0800 Message-ID: From: Jana Iyengar To: Martin Duke Content-Type: multipart/alternative; boundary=001a113d2c024f3f480529288411 Archived-At: Cc: Ian Swett , Alyssa Wilk , tsvwg , Ryan Hamilton Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 20:01:44 -0000 --001a113d2c024f3f480529288411 Content-Type: text/plain; charset=UTF-8 Hi Martin, Thanks so much for your comments and your interest! We're working on updating the draft -- this is decidedly a -01 draft at the moment -- so thank you for your text suggestions. Answers inline: 1) Section 5.1: I suggest that "the CHLO MUST fit in one packet; if need > be, one that requires IP fragmentation." As ugly as that is, it's far > superior to forcing the server to maintain state on incomplete CHLO. In > another forum the authors have indicated that this is their intention. This > also requires an exception to the preface of Section 6, which says to avoid > IP fragmentation (though as I understand it we are a long way from CHLO > having to be that long). > I've added text to say "Any CHLO packet must be sent as a single UDP datagram." There's no normative language in the draft at the moment. 2) Section 5.1: "The next time the client sends a CHLO, it can use the > cached credentials from the previous connection to immediately send > encrypted requests to the server." > > I would appreciate wording that makes it clearer that, "upon receipt of an > authenticated REJ, the client MUST generate a new connection ID for > subsequent CHLO messages, with sequence number 1." This clarification is > also important to making servers stateless pre-SHLO. > This gets into stateless vs non-stateless rejects. Though there is code to support stateless rejects, the current intention is to support both stateless and stateful rejects going forward. The documentation needs more information to properly describe stateless rejects, which will happen once we have more experience with stateless rejects. 3) Section 5.1: Without veering into the Crypto documents area, I think it > would be helpful to indicate the frames that MUST, SHOULD, or MAY be in > CHLO, REJ, and SHLO messages. Obviously there will be STREAM frames for > stream 1, but I can certainly imagine PADDING, WINDOW_UPDATE, and ACK > messages required as well. And I imagine CONNECTION_CLOSE etc. MAY be > present. But I'm not sure! The stream 1 fields may be in a crypto document > but the frame list should be here. > Good suggestion. We'll work this in in a future revision. > 4) Section 6.1: There is a little encryption ambiguity in the packets that > the server receives from the client just after sending the SHLO. These > packets could either use the initial key or the symmetric key, and with > packet reordering they could be interleaved for while. As someone that > implements server-side stuff for a living, it's irritating to potentially > have to decrypt the packet twice, and to allocate space for two sets of > keys in the PCB. > There are two unused bits in the Public Flags. It appears that Chromium has > already taken one for a "multipath" flag, currently undocumented. I propose > that the second one be an indicator that the client has received the SHLO > and is using the symmetric key. > This is an interesting idea. To be clear, this interleaving should only really happen for ~1 roundtrip after the SHLO is sent, and soon after the first forward secure packet is received, the server should be able to drop the initial encryption key. At this point, we do trial decryption, and this bit could be a nice optimization. That said, since the path for the QUIC handshake is to integrate with TLS1.3, we are not making optimizations to QUIC's handshake at this point. If I remember correctly, TLS1.3 could benefit from such a bit; this may be a good suggestion for TLS1.3. And thanks for the note on the multipath bit -- we didn't have it when the earlier version of the draft went out, but we've documented it in the upcoming rev of the draft. 5) Section 6.1: The Chromium implementation sometimes puts 12 > authentication bits between public and private header. It would be good to > make this explicit in the document, as the figure in Section 6.1 reasonably > reads as having the private flags immediately follow the sequence number. > This is the auth hash and is part of the 'NULL' encryption algorithm formatting... effectively, you're looking at an encrypted packet which has public_header followed by the auth hash, followed by the encrypted body. This is not the QUIC wire format, but the output of the NULL encrypter... the plaintext QUIC packet format still has private flags following the sequence number. I don't think it makes sense to change the QUIC (plaintext) packet format. 6) Section 6.5: Please provide the correct format for the CADR tag. > Currently this is for debug purposes only (comment added to this effect) and is optional, and the formatting is somewhat awkward... it may make sense to document a more standard version of this. Nevertheless, this should probably be considered optional for now. 7) Section 8.3: I have read this section several times and cannot discern > at all what the TCP timestamps are for, how many there should be, where > they come from, and what format they are in. Are these echoes of some > sender timestamp (and if, so where is that from) or are these local clock > measurements? > > Obviously this has something to do with RTT calculation, but the mapping > of the ACK frame fields to this calculation is really unclear. I tried to > generate some psuedocode to generate an ACK frame and got nowhere. > Apologies, that timestamp section was extremely confusing. The wording has been substantially updated, which hopefully make it clearer -- let us know if you are still stuck, and we're happy to help! Thanks again for your comments! Ian and Jana --001a113d2c024f3f480529288411 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks so much for your comm= ents and your interest! We're working on updating the draft -- this is = decidedly a -01 draft at the moment -- so thank you for your text suggestio= ns. Answers inline:

1) Sect= ion 5.1: I suggest that "the CHLO MUST fit in one packet; if need be, = one that requires IP fragmentation." As ugly as that is, it's far = superior to forcing the server to maintain state on incomplete CHLO. In ano= ther forum the authors have indicated that this is their intention. This al= so requires an exception to the preface of Section 6, which says to avoid I= P fragmentation (though as I understand it we are a long way from CHLO havi= ng to be that long).

I've added text to say "Any CHLO packet must be sent as a single UDP datagram." There's= no normative language in the draft at the moment.

2) Section 5.1: "T= he next time the client sends a CHLO, it can use the cached credentials fro= m the previous connection to immediately send encrypted requests to the ser= ver."

I would appreciate wording that makes i= t clearer that, "upon receipt of an authenticated REJ, the client MUST= generate a new connection ID for subsequent CHLO messages, with sequence n= umber 1." This clarification is also important to making servers state= less pre-SHLO.

This= gets into stateless vs non-stateless rejects.=C2=A0 Though there is code t= o support stateless rejects, the current intention is to support both state= less and stateful rejects going forward.=C2=A0 The documentation needs more= information to properly describe stateless rejects, which will happen once= we have more experience with stateless rejects.

3) Section 5.1: Without veering i= nto the Crypto documents area, I think it would be helpful to indicate the = frames that MUST, SHOULD, or MAY be in CHLO, REJ, and SHLO messages. Obviou= sly there will be STREAM frames for stream 1, but I can certainly imagine P= ADDING, WINDOW_UPDATE, and ACK messages required as well. And I imagine CON= NECTION_CLOSE etc. MAY be present. But I'm not sure! The stream 1 field= s may be in a crypto document but the frame list should be here.

Good suggestion. We'll work thi= s in in a future revision.
=C2=A0
4) Section 6.1: There is a little encryption ambiguity i= n the packets that the server receives from the client just after sending t= he SHLO. These packets could either use the initial key or the symmetric ke= y, and with packet reordering they could be interleaved for while. As someo= ne that implements server-side stuff for a living, it's irritating to p= otentially have to decrypt the packet twice, and to allocate space for two = sets of keys in the PCB.
There are two unused bits in the Public Flags. It a= ppears that Chromium has already taken one for a "multipath" flag= , currently undocumented. I propose that the second one be an indicator tha= t the client has received the SHLO and is using the symmetric key.

This is an interesting idea. To b= e clear, this interleaving should only really happen for ~1 roundtrip after= the SHLO is sent, and soon after the first forward secure packet is receiv= ed, the server should be able to drop the initial encryption key.=C2=A0At t= his point, we do trial decryption, and this bit could be a nice optimizatio= n.=C2=A0

That said, since the path for the QUIC ha= ndshake is to integrate with TLS1.3, we are not making optimizations to QUI= C's handshake at this point. If I remember correctly, TLS1.3 could bene= fit from such a bit; this may be a good suggestion for TLS1.3.
And thanks for the note on the multipath bit -- we didn't = have it when the earlier version of the draft went out, but we've docum= ented it in the upcoming rev of the draft.

5) Section 6.1:=C2=A0The Chromium implement= ation sometimes puts 12 authentication bits between public and private head= er. It would be good to make this explicit in the document, as the figure i= n Section 6.1 reasonably reads as having the private flags immediately foll= ow the sequence number.

<= span style=3D"font-size:12.8px">This is the auth hash and is part of the &#= 39;NULL' encryption algorithm formatting... effectively, you're loo= king at an encrypted packet which has public_header followed by the auth ha= sh, followed by the encrypted body. This is not the QUIC wire format, but t= he output of the NULL encrypter... the plaintext QUIC packet format still h= as private flags following the sequence number. I don't think it makes = sense to change the QUIC (plaintext) packet format.

6) Section 6.5: Please provide the= correct format for the CADR tag.

Currently this is for debug purpo= ses only (comment added to this effect) and is optional, and the formatting= is somewhat awkward... it may make sense to document a more standard versi= on of this. Nevertheless, this should probably be considered optional for n= ow.

=
7) Section 8.3: I have read this section several times and cannot disc= ern at all what the TCP timestamps are for, how many there should be, where= they come from, and what format they are in. Are these echoes of some send= er timestamp (and if, so where is that from) or are these local clock measu= rements?

Obviously this has something to do with R= TT calculation, but the mapping of the ACK frame fields to this calculation= is really unclear. I tried to generate some psuedocode to generate an ACK = frame and got nowhere.

Apologies, that timestamp section was extrem= ely confusing.=C2=A0 The wording has been substantially updated, which hope= fully make it clearer -- let us know if you are still stuck, and we're = happy to help!

Thanks again for your commen= ts!
Ian and Jana

--001a113d2c024f3f480529288411-- From nobody Tue Jan 12 13:06:30 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16281A88C5; Tue, 12 Jan 2016 13:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjc9gogu7caH; Tue, 12 Jan 2016 13:06:27 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 266851A1AA1; Tue, 12 Jan 2016 13:06:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 65C5718000F; Tue, 12 Jan 2016 13:05:39 -0800 (PST) To: nmalykh@gmail.com, mallman@bbn.com, floyd@icir.org, craig@bbn.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160112210539.65C5718000F@rfc-editor.org> Date: Tue, 12 Jan 2016 13:05:39 -0800 (PST) Archived-At: Cc: mls.ietf@gmail.com, rfc-editor@rfc-editor.org, iesg@ietf.org, tsvwg@ietf.org Subject: [tsvwg] [Errata Verified] RFC3390 (4569) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:06:29 -0000 The following errata report has been verified for RFC3390, "Increasing TCP's Initial Window". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4569 -------------------------------------- Status: Verified Type: Technical Reported by: Nikolai Malykh Date Reported: 2015-12-22 Verified by: Martin Stiemerling (IESG) Section: 8.1 Original Text ------------- A second set of experiments explored TCP performance over dialup modem links. In experiments over a 28.8 bps dialup channel [All97a, AHO98], a four-segment initial window decreased the transfer time of a 16KB file by roughly 10%, with no accompanying increase in the drop rate. A simulation study [RFC2416] investigated the effects of using a larger initial window on a host connected by a slow modem link and a router with a 3 packet buffer. The study concluded that for the scenario investigated, the use of larger initial windows was not harmful to TCP performance. Corrected Text -------------- A second set of experiments explored TCP performance over dialup modem links. In experiments over a 28.8 kbps dialup channel [All97a, AHO98], a four-segment initial window decreased the transfer time of a 16KB file by roughly 10%, with no accompanying increase in the drop rate. A simulation study [RFC2416] investigated the effects of using a larger initial window on a host connected by a slow modem link and a router with a 3 packet buffer. The study concluded that for the scenario investigated, the use of larger initial windows was not harmful to TCP performance. Notes ----- Error bit rate - kbps instead of bps. -------------------------------------- RFC3390 (draft-ietf-tsvwg-initwin-04) -------------------------------------- Title : Increasing TCP's Initial Window Publication Date : October 2002 Author(s) : M. Allman, S. Floyd, C. Partridge Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Jan 18 08:08:05 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0125B1B386A; Mon, 18 Jan 2016 08:08:04 -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.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160118160804.4118.96244.idtracker@ietfa.amsl.com> Date: Mon, 18 Jan 2016 08:08:04 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-behave-requirements-update-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 16:08:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Network Address Translation (NAT) Behavioral Requirements Updates Authors : Reinaldo Penno Simon Perreault Mohamed Boucadair Senthil Sivakumar Kengo Naito Filename : draft-ietf-tsvwg-behave-requirements-update-06.txt Pages : 13 Date : 2016-01-18 Abstract: This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAT44. This document updates RFC4787, RFC5382 and RFC5508. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-behave-requirements-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-behave-requirements-update-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-behave-requirements-update-06 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 19 15:34:43 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177E81B37D0 for ; Tue, 19 Jan 2016 15:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKlT5onvgYbm for ; Tue, 19 Jan 2016 15:34:40 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C171B37CF for ; Tue, 19 Jan 2016 15:34:40 -0800 (PST) Received: from [128.9.184.116] ([128.9.184.116]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u0JNYDYC022302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jan 2016 15:34:14 -0800 (PST) References: <20160119232423.16115.18241.idtracker@ietfa.amsl.com> To: tsvwg From: Joe Touch X-Forwarded-Message-Id: <20160119232423.16115.18241.idtracker@ietfa.amsl.com> Message-ID: <569EC7F4.9000804@isi.edu> Date: Tue, 19 Jan 2016 15:34:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160119232423.16115.18241.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 23:34:42 -0000 FYI. This version includes: - optional option checksum (separate from the UDP checksum) - description for use similar to UDP-Lite (for un-checksummed data) It also includes a few more ASCII pictures of headers to explain what's going on more clearly, as well as a new section on interaction with legacy devices. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-02.txt Date: Tue, 19 Jan 2016 15:24:23 -0800 From: internet-drafts@ietf.org To: Joe Touch , Dr. Joseph D. Touch A new version of I-D, draft-touch-tsvwg-udp-options-02.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 02 Title: Transport Options for UDP Document date: 2016-01-19 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-02.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-02 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jan 21 10:15:52 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AF81A6FB2 for ; Thu, 21 Jan 2016 10:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjhCX6nFwwzK for ; Thu, 21 Jan 2016 10:15:50 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B4B1A8954 for ; Thu, 21 Jan 2016 10:15:50 -0800 (PST) Received: from [128.9.184.225] ([128.9.184.225]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u0LIFJ5B009862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Jan 2016 10:15:20 -0800 (PST) To: Martin Duke , tsvwg@ietf.org References: From: Joe Touch Message-ID: <56A12036.9020607@isi.edu> Date: Thu, 21 Jan 2016 10:15:18 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Ian Swett , alyssar@google.com, rch@google.com, touch@isi.edu Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:15:51 -0000 On 1/8/2016 10:07 AM, Martin Duke wrote: > I've been toying with implementing parts of this draft while also trying > to interact with the existing Chromium implementation, and beyond the > obviously incomplete sections in the draft I think there are several > items that are unclear, suboptimal, or not conformant with Chromium. > > This is a wonderful contribution with great promise, and many > exceptional design features. But: > > 1) Section 5.1: I suggest that "the CHLO MUST fit in one packet; if need > be, one that requires IP fragmentation." As ugly as that is, it's far > superior to forcing the server to maintain state on incomplete CHLO. FWIW, I disagree. One feature of TCP is its intent that all segments fit inside unfragmented IP packets - that's why it tracks MTU. IMO, TCP signalling needs to support that feature, not subvert it for mere convenience (TCP is stateful anyway). Joe From nobody Thu Jan 21 10:19:58 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6B11A896A for ; Thu, 21 Jan 2016 10:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuhFq1OjCBbX for ; Thu, 21 Jan 2016 10:19:56 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBB61A8965 for ; Thu, 21 Jan 2016 10:19:56 -0800 (PST) Received: from [128.9.184.225] ([128.9.184.225]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u0LIJLBH010492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Jan 2016 10:19:21 -0800 (PST) To: Martin Duke , tsvwg@ietf.org References: <56A12036.9020607@isi.edu> From: Joe Touch Message-ID: <56A12128.9@isi.edu> Date: Thu, 21 Jan 2016 10:19:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A12036.9020607@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Ian Swett , alyssar@google.com, rch@google.com, touch@isi.edu Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:19:57 -0000 On 1/21/2016 10:15 AM, Joe Touch wrote: > > > On 1/8/2016 10:07 AM, Martin Duke wrote: >> I've been toying with implementing parts of this draft while also trying >> to interact with the existing Chromium implementation, and beyond the >> obviously incomplete sections in the draft I think there are several >> items that are unclear, suboptimal, or not conformant with Chromium. >> >> This is a wonderful contribution with great promise, and many >> exceptional design features. But: >> >> 1) Section 5.1: I suggest that "the CHLO MUST fit in one packet; if need >> be, one that requires IP fragmentation." As ugly as that is, it's far >> superior to forcing the server to maintain state on incomplete CHLO. > > FWIW, I disagree. One feature of TCP is its intent that all segments fit > inside unfragmented IP packets - that's why it tracks MTU. IMO, TCP > signalling needs to support that feature, not subvert it for mere > convenience (TCP is stateful anyway). To clarify: QUIC is stateful. If intended to be used where TCP is used, it should follow TCP's principles when it comes to MTUs - stay inside the detected MTU and address multi-segment state the same way it manages any other state. Any protocol that deliberately sends messages larger than the known MTU - except for detecting MTUs itself - is asking for trouble. Joe From nobody Fri Jan 22 01:06:28 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D7F1ACE0A for ; Fri, 22 Jan 2016 01:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OKFS46NBsLM for ; Fri, 22 Jan 2016 01:06:25 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064151ACE09 for ; Fri, 22 Jan 2016 01:06:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,330,1449561600"; d="asc'?scan'208";a="89796194" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx142-out.netapp.com with ESMTP; 22 Jan 2016 01:05:24 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 22 Jan 2016 01:05:24 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::78c4:b507:6e5a:d63c%21]) with mapi id 15.00.1130.005; Fri, 22 Jan 2016 01:05:24 -0800 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 Thread-Index: AQHRSj+S3X783xcETU6NALAzEr/+pJ8G4PoAgAABIQCAAPeQAA== Date: Fri, 22 Jan 2016 09:05:23 +0000 Message-ID: <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> In-Reply-To: <56A12128.9@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_B6FB2292-1CDB-467A-90AA-97E827B09DB7"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Ian Swett , "rch@google.com" , "tsvwg@ietf.org" , "alyssar@google.com" Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 09:06:26 -0000 --Apple-Mail=_B6FB2292-1CDB-467A-90AA-97E827B09DB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-01-21, at 19:19, Joe Touch wrote: > Any protocol that deliberately sends messages larger than the known = MTU > - except for detecting MTUs itself - is asking for trouble. +1 We also recommend such message size limit for general UDP use in RFC5405 = and 5405bis. Lars --Apple-Mail=_B6FB2292-1CDB-467A-90AA-97E827B09DB7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWofDVAAoJEFS1wwm/cMFXOycP/iTw2bNvjl6Qt5wwqgPNm6fD xsUsmMPxXmSj2IVeDmmcrU4H+hmDyNsolPEvqrVGTKfASQxIWkW9q/wW6HNtLJC6 Uc7TTd3YHiC1Y1LR/v1lSJpr35Y6ZSUaMebMnZlU5dKfgLfZ8AQZ/KVdMq9pZ0MH YXnjAvjZGP7EFBP95YxYJ627Bs1IL7S0ciqzM4jFTvMFgKNHrQlsoQZttIfQt+Q9 bSHX72UiQk9leVnQWAVsW1Utmgts/WKdsRgMXFSdpC84cTe7HRb4boUhBtcDPJx5 A5L1/USLsYug62uALuzdLbBpggnC3D079RGP8mFiB4aninjQhhDzG59nmQ6UhTWx XLH8QZS7M3FQ8+eHFbogNIKmpzZEM+gkz8n8p3GNvZTTDbth+r/7y5dTMadc7CYh UTBTSf44cBJU9d6STP0pNnV8ezQlg9aJXwU09qfDXxYb3IFPsvGi93HZigXwnJq9 pAReeQeb1ujujt8YfARBWbZua+Hrvlk0vhA6sXIlcRD4L4xCWc+bYJXhdQ91sU60 Wvklm/Qg4o2LysmeJ9c6FThxKQAxdPbNMKYjrynhxVtXOuIHT2biFZkMZzSOqNBq MqS7Wk8BcMGoXSTBHaXIOo6jSjTjC8RvKeF6/WpLkSrE+L6tyXkP/Xt3SJ/NuMcy grWnRq9+HiAjVGwQyYSy =FPsu -----END PGP SIGNATURE----- --Apple-Mail=_B6FB2292-1CDB-467A-90AA-97E827B09DB7-- From nobody Fri Jan 22 10:14:13 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CBC1B2B56 for ; Fri, 22 Jan 2016 10:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqlXbPBa0i3p for ; Fri, 22 Jan 2016 10:14:02 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A710A1B2B50 for ; Fri, 22 Jan 2016 10:14:02 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id w75so52201966oie.0 for ; Fri, 22 Jan 2016 10:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bw90v5XjXdy0AsV1cA+xLsGnGZf7IdaP5earxiYBvm8=; b=CgqnHggBBvv/2auPry0omx0uIYhLXkdA/w7nf1h4TyRIgB9NjgsVvgCWI+NLJpnkP3 9t7h1ay+o8paeyt8mvK9YDqxwE6+GfwnN60e7wuSDQY/zeiWQqejdluLJ9OJns4NnZnM jVAlv5DpT6YiNZ11HTphUwvOPRvSfNqteO6BtWmxDphkTP+ebsze1XyF4KYFewa6OWzg bG8rX1+pIKZzCVbIOM0hLe7qZuBU6TvPr0aBD5S/hTi6604EGdFqqrP+M4Kk4yN0ENYu dIN0Rcxti8ilmQ2kRwfE8dZcxZdRW+K+r0UwqZ6fcNRGaKXTusGDnacoYMwnkKLe3OvN XZew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bw90v5XjXdy0AsV1cA+xLsGnGZf7IdaP5earxiYBvm8=; b=Qad6J8PICJWCsRGPnQDEYD+IYwTIWGKZOUtB2f3zPb5HbGheX38y668KIuD0ZUPL9i ie94+5EUmiZYYQ1UcgJVtcIAV+4Oa6cyhNI9lLNvhSNXg6vKAxjDIKy8yA0ZH+OrJMgl 7UgaqQ0yz8vnJbrF+EpKPtt0r1hkajPV1EuTjYAoK0DEHycZABGALdu9yJARg0au1VX1 l6d2HgsFJ1eWu1cJtdwklcgp+OojM23BNC4sOSjp7dfRKT9KjFdvDx3HaFhR10UN30h4 2f9/V2VVvTrOZ0y+EkGOM56NdGK23FjtgGCaQnUSGW1OkeAsEqxkwaJamxlRXSqM6Cf/ nGUw== X-Gm-Message-State: AG10YOSvHCsE87v7BvnKJXNrc+eX0o+CaBF1XPG9xdozdv/jbFmbNwc6ulkRZaxuawJtNs7YQvUR+mpZkN6t3pfJ MIME-Version: 1.0 X-Received: by 10.202.73.69 with SMTP id w66mr3372050oia.85.1453486441514; Fri, 22 Jan 2016 10:14:01 -0800 (PST) Received: by 10.76.3.79 with HTTP; Fri, 22 Jan 2016 10:14:01 -0800 (PST) In-Reply-To: <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> Date: Fri, 22 Jan 2016 10:14:01 -0800 Message-ID: From: Jana Iyengar To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a113dc1000890ab0529f02f8b Archived-At: Cc: "alyssar@google.com" , Ian Swett , "rch@google.com" , "tsvwg@ietf.org" , Joe Touch Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 18:14:04 -0000 --001a113dc1000890ab0529f02f8b Content-Type: text/plain; charset=UTF-8 Yes, agreed. It is absolutely the intention (and current practice) that all QUIC packets, including handshake packets, fit within a PMTU to avoid fragmentation. On Fri, Jan 22, 2016 at 1:05 AM, Eggert, Lars wrote: > On 2016-01-21, at 19:19, Joe Touch wrote: > > Any protocol that deliberately sends messages larger than the known MTU > > - except for detecting MTUs itself - is asking for trouble. > > +1 > > We also recommend such message size limit for general UDP use in RFC5405 > and 5405bis. > > Lars > > --001a113dc1000890ab0529f02f8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, agreed. It is absolutely the intention (and current p= ractice) that all QUIC packets, including handshake packets, fit within a P= MTU to avoid fragmentation.

=
On Fri, Jan 22, 2016 at 1:05 AM, Eggert, Lar= s <lars@netapp.com> wrote:
<= span class=3D"">On 2016-01-21, at 19:19, Joe Touch <touch@isi.edu> wrote:
> Any protocol that deliberately sends messages larger than the known MT= U
> - except for detecting MTUs itself - is asking for trouble.

+1

We also recommend such message size limit for general UDP use in RFC5405 an= d 5405bis.

Lars


--001a113dc1000890ab0529f02f8b-- From nobody Fri Jan 22 10:21:55 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1C1B2B6F for ; Fri, 22 Jan 2016 10:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESe3HyECR5-m for ; Fri, 22 Jan 2016 10:21:52 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 09F281B2B66 for ; Fri, 22 Jan 2016 10:21:51 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id mw1so59856152igb.1 for ; Fri, 22 Jan 2016 10:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fjAgPrLS0hCRWf5L5wnAflByoHKGyuqwkDO0/V5TNGs=; b=TtTo4JplUIbf8PRdNPYpUKBdcuJBgLYpvfHr9YLj8t/zm/Y/3oxwg8pN9NomHyV6GW HphztCg3KzH1m6grtTSD08xolx6w/P+L2YAPukGHudLuRsZGBTuvMD88We+VFAgNApyT SDsgSK/+FoIF3d93MSjG06d4HE/phGBqtS8stj6HqxIw4m9/OlVAicmKG4enqydlf4aX qWJdnfmNnUbljAvQ8XfQ7AUu9m2lmBIhp+ZotyieuilBIFrcAOmf4dI3U8EE4UDbE//1 5OF+IsWs0RkRMkbKmJlKBvT18KFNqzRvwdc62GwKotuLx4DHP5j+meIm1QsXlx9286Gv fZAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fjAgPrLS0hCRWf5L5wnAflByoHKGyuqwkDO0/V5TNGs=; b=hzUVKaCLGlOXL/StMi4JYpuhN0EsoC28F+BI3R0pM7tl2sR7DSpfd68XDSeeu0JXE6 neSEkemGoMuQ8tKlJ1SOJX+sO5l0GyDqGKgcfsaOW51JgDljucpnCM6fegFj0mmQgZdZ 0FxyKmTzxZVL09bI/jYWcGyML6vkRaw1M0Rr+zRGUVamltW5ubA8jnxwgBe0YSm2U5cA yIbMUMhzNjygRDvb8mYEAs21mqFbyLe/ZerNaMKzz0RwRoHDAecORRV6XKVyYQWKui70 qxdEkfgfBOFgUn7/bo8C8PPEJtxpipD3PdbJYaNnX+SQDFJS8gFuSzczyFmK0PNhZmaO ZUXA== X-Gm-Message-State: AG10YOTNnLOVUWpexjqM49pLCmdD3VtCLif5KcanQfUBmdko9Zl/roJ2I90RLGSQw2Mr+z82lWu9h+aIcXWHbA== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr5184247igt.94.1453486911326; Fri, 22 Jan 2016 10:21:51 -0800 (PST) Received: by 10.107.140.150 with HTTP; Fri, 22 Jan 2016 10:21:51 -0800 (PST) In-Reply-To: References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> Date: Fri, 22 Jan 2016 10:21:51 -0800 Message-ID: From: Tom Herbert To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tsvwg@ietf.org" , Joe Touch , Ian Swett , "rch@google.com" , "alyssar@google.com" Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 18:21:53 -0000 On Fri, Jan 22, 2016 at 10:14 AM, Jana Iyengar wrote: > Yes, agreed. It is absolutely the intention (and current practice) that all > QUIC packets, including handshake packets, fit within a PMTU to avoid > fragmentation. > PMTU discovery should work on UDP sockets (Linux at least). The udp man page describes it. Tom > > On Fri, Jan 22, 2016 at 1:05 AM, Eggert, Lars wrote: >> >> On 2016-01-21, at 19:19, Joe Touch wrote: >> > Any protocol that deliberately sends messages larger than the known MTU >> > - except for detecting MTUs itself - is asking for trouble. >> >> +1 >> >> We also recommend such message size limit for general UDP use in RFC5405 >> and 5405bis. >> >> Lars >> > From nobody Fri Jan 22 10:23:37 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880321B2B6F for ; Fri, 22 Jan 2016 10:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nMhvDTHv914 for ; Fri, 22 Jan 2016 10:23:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC24C1B2B6D for ; Fri, 22 Jan 2016 10:23:32 -0800 (PST) Received: from [128.9.184.164] ([128.9.184.164]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u0MIN7ZL002008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2016 10:23:08 -0800 (PST) To: Jana Iyengar , "Eggert, Lars" References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> From: Joe Touch Message-ID: <56A2738A.9080901@isi.edu> Date: Fri, 22 Jan 2016 10:23:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "alyssar@google.com" , Ian Swett , "rch@google.com" , "tsvwg@ietf.org" , touch@isi.edu Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 18:23:34 -0000 OK, then I'm confused about the note about the particular protocol message that won't then... Joe On 1/22/2016 10:14 AM, Jana Iyengar wrote: > Yes, agreed. It is absolutely the intention (and current practice) that > all QUIC packets, including handshake packets, fit within a PMTU to > avoid fragmentation. > > > On Fri, Jan 22, 2016 at 1:05 AM, Eggert, Lars > wrote: > > On 2016-01-21, at 19:19, Joe Touch > wrote: > > Any protocol that deliberately sends messages larger than the known MTU > > - except for detecting MTUs itself - is asking for trouble. > > +1 > > We also recommend such message size limit for general UDP use in > RFC5405 and 5405bis. > > Lars > > From nobody Fri Jan 22 10:54:16 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D0C1B2C02 for ; Fri, 22 Jan 2016 10:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRdKZAJFWDOQ for ; Fri, 22 Jan 2016 10:54:11 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 CB74C1B2BF4 for ; Fri, 22 Jan 2016 10:54:11 -0800 (PST) Received: by mail-pa0-x22e.google.com with SMTP id ho8so45697013pac.2 for ; Fri, 22 Jan 2016 10:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=wv4AiM1TLay/BJDUVY9yhoWQGkDnyJytHLQW1lU8+lU=; b=QiLJmykAe56wy7GReBuLZdWx2xsb05Utb2GWo7XLgKTLxxvzddLflJ9v+yVCWoS2E4 /VHJWTgidwtaw35fhpwGKE92cqCgLFj07sgqaBzyUIlYQnH9nH7QPIlHh8Std3upe+hm c/sBtQ7kZl9RdN2G3rUTb7cVkSrBPMSye8Lgh6FaunY3qEq+cDaqepfNdQVBvIUyTf9B 9M7iBITHGTxYnYdDS3FK65wkBaXPwYWvNaTsg1Ug2GBgGexAHeVzzpLBOlakT2RkGjMh QPhYAfWeHnPyImQqej6le4l1F6/HxEmUq4Z1KAhi37/ZtwHoCtxhvntzmq0GH55Y8vsx Y5cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=wv4AiM1TLay/BJDUVY9yhoWQGkDnyJytHLQW1lU8+lU=; b=Ed6XgwVZcOFVM8tvtJk8ecTbBhLsMdEVYThjMzd8fFTgrxyiW0hs7REkRUrVYHftdk pHNQkTCeR0fscc0cPQqnTf3krh1A4qc/4Nmh+G0SrMrlXsZ/MhaK4fEpM1bE4xSsdTm1 Ruxbh6uxJZ4d+91MQryc0chQL2OYoHq+e9YmVSf/nbHhEI47IvzmnZbIpyMLjSZVuEaL olxFCKwFwDvQy4uIgU+vCafYsw2iYS8/agAtrMyj6NOfTRW27wE4kgd+vc/c2fmiQnT9 OtEyc06ighJ6k/4R5ZlvQjJKZcjrVi30aZuwKBHpJM+IQ/V6jTYy7P+Y7HTeoEcFPcSw zYCQ== X-Gm-Message-State: AG10YOQXUl+/EEeL8lOpLGQZZrvWeOuGqt/yX67QlxcJz1M5xpgCemuybudh7+LKyXuELQ== X-Received: by 10.66.144.5 with SMTP id si5mr6585422pab.51.1453488851381; Fri, 22 Jan 2016 10:54:11 -0800 (PST) Received: from ?IPv6:2406:e007:7e5d:1:28cc:dc4c:9703:6781? ([2406:e007:7e5d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id fi16sm11409873pac.12.2016.01.22.10.54.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 10:54:09 -0800 (PST) To: Tom Herbert , Jana Iyengar References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A27ADA.5030108@gmail.com> Date: Sat, 23 Jan 2016 07:54:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "alyssar@google.com" , Ian Swett , "rch@google.com" , "tsvwg@ietf.org" , Joe Touch Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 18:54:14 -0000 On 23/01/2016 07:21, Tom Herbert wrote: > On Fri, Jan 22, 2016 at 10:14 AM, Jana Iyengar wrote: >> Yes, agreed. It is absolutely the intention (and current practice) that all >> QUIC packets, including handshake packets, fit within a PMTU to avoid >> fragmentation. >> > PMTU discovery should work on UDP sockets (Linux at least). The udp > man page describes it. You are joking, right? PMTUD is notoriously unreliable in the actual Internet in the actual real world, (which is why we have RFC 4821) and not all computers run Linux. In any case, as others have said, relying on fragmentation is poor design. Brian > > Tom > >> >> On Fri, Jan 22, 2016 at 1:05 AM, Eggert, Lars wrote: >>> >>> On 2016-01-21, at 19:19, Joe Touch wrote: >>>> Any protocol that deliberately sends messages larger than the known MTU >>>> - except for detecting MTUs itself - is asking for trouble. >>> >>> +1 >>> >>> We also recommend such message size limit for general UDP use in RFC5405 >>> and 5405bis. >>> >>> Lars >>> >> > > From nobody Fri Jan 22 11:00:59 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0020B1B2C34 for ; Fri, 22 Jan 2016 11:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJlTovHIGMvc for ; Fri, 22 Jan 2016 11:00:57 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31801B2C30 for ; Fri, 22 Jan 2016 11:00:56 -0800 (PST) Received: from [128.9.184.164] ([128.9.184.164]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u0MJ0a5E011044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2016 11:00:37 -0800 (PST) To: Brian E Carpenter , Tom Herbert , Jana Iyengar References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> <56A27ADA.5030108@gmail.com> From: Joe Touch Message-ID: <56A27C53.3050803@isi.edu> Date: Fri, 22 Jan 2016 11:00:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A27ADA.5030108@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "alyssar@google.com" , Ian Swett , "rch@google.com" , "tsvwg@ietf.org" , touch@isi.edu Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 19:00:58 -0000 On 1/22/2016 10:54 AM, Brian E Carpenter wrote: > On 23/01/2016 07:21, Tom Herbert wrote: >> On Fri, Jan 22, 2016 at 10:14 AM, Jana Iyengar wrote: >>> Yes, agreed. It is absolutely the intention (and current practice) that all >>> QUIC packets, including handshake packets, fit within a PMTU to avoid >>> fragmentation. >>> >> PMTU discovery should work on UDP sockets (Linux at least). The udp >> man page describes it. > > You are joking, right? > > PMTUD is notoriously unreliable in the actual Internet in the actual real world, > (which is why we have RFC 4821) and not all computers run Linux. +1. QUIC should be using PLMTUD. Joe From nobody Fri Jan 22 11:16:26 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A421B2C76 for ; Fri, 22 Jan 2016 11:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CCHOcW2ulPz for ; Fri, 22 Jan 2016 11:16:22 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 76EAC1A8999 for ; Fri, 22 Jan 2016 11:16:22 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id 1so97897071ion.1 for ; Fri, 22 Jan 2016 11:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KEF8ROZus4JFFjjA8kZUnGJP71X771gJXixyeRgj1X4=; b=hFpRpzPfp4X594Y+he44VLdr9lOlerMg7EuFE1sVrV8WHBVzHzF+9biFintz+jys0C 1oa8ZIEzriAMDyS6h4CXexUz0yS6LgfJWoq+c87ncLOq0ZvFdvt4lJFcxsDtKspEMPox AUFjBBW8Zo/XepRnp3otdV7ht3+Yb1qqzXy87QDmnJQZ7NF8vbFMRwHz5tBA+d41z2EN l+lkxfBnrgdSGBcQ1jaOIDuheukAlYO7Sxj2lxXPjlH2ePN4y8ERYDrtvgGShLKs4e90 pskqFEs/XLtXuOEAKU0jYxFRUw4W5eT/H+YNHLQSj0uAFG/MAGIZluMYg2DWWredA8G9 4eJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KEF8ROZus4JFFjjA8kZUnGJP71X771gJXixyeRgj1X4=; b=NP980aK/Z2PzWOJ7v4Gr6PdMpcWINsB6DH05E1Y/MKKQ/+9ZfCzf3+HDrlb8F8PKJy 7sZNZgI5atibjdcxcxNObDwycCwLeIpSRGJwavcuDYnjWjEPgjvZRi39yP32gz/w2+aW pAP9sWdAtyvT/DPiLi0YCQy+jUn1hIVhRX7lCA5Jpu+ydO4AGIwvsBx5k9w3glAWSDDu nr8qoBl+FFG8Rycbmnn60gS7a+3vLXwYQDLqqn6PuWUlhojV/grJlrqfaNJvbtk78Oak YDqhjHTjFteENJcREHykr+NxFiYDnghXWonep7RDCShAlJSgwcR8AwWAspzblGjgK6qU xx+A== X-Gm-Message-State: AG10YOSmmrbxHvBiWruYWFaUnV3rKvjDVIe0nwhamvJXthmeX9msfHQQrWLHcSNY5LDn6tJotcQa+e/8xiw4CQ== MIME-Version: 1.0 X-Received: by 10.107.18.71 with SMTP id a68mr5829950ioj.107.1453490181910; Fri, 22 Jan 2016 11:16:21 -0800 (PST) Received: by 10.107.140.150 with HTTP; Fri, 22 Jan 2016 11:16:21 -0800 (PST) In-Reply-To: <56A27ADA.5030108@gmail.com> References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> <56A27ADA.5030108@gmail.com> Date: Fri, 22 Jan 2016 11:16:21 -0800 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tsvwg@ietf.org" , Joe Touch , Ian Swett , "alyssar@google.com" , "rch@google.com" Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 19:16:24 -0000 On Fri, Jan 22, 2016 at 10:54 AM, Brian E Carpenter wrote: > On 23/01/2016 07:21, Tom Herbert wrote: >> On Fri, Jan 22, 2016 at 10:14 AM, Jana Iyengar wrote: >>> Yes, agreed. It is absolutely the intention (and current practice) that all >>> QUIC packets, including handshake packets, fit within a PMTU to avoid >>> fragmentation. >>> >> PMTU discovery should work on UDP sockets (Linux at least). The udp >> man page describes it. > > You are joking, right? > No, and I am not advocating that as the solution. My point is that QUIC running on Linux (which I assume is not an insignificant number of hosts) is already probably using PMTUD and is subject to whatever problems or benefits that entails. That is not to say it is good or bad, but QUIC developers should be aware of this. If you get an EMSGSIZE error on a UDP write operation there is a good chance it is because of PMTUD. > PMTUD is notoriously unreliable in the actual Internet in the actual real world, > (which is why we have RFC 4821) and not all computers run Linux. > > In any case, as others have said, relying on fragmentation is poor design. > > Brian > >> >> Tom >> >>> >>> On Fri, Jan 22, 2016 at 1:05 AM, Eggert, Lars wrote: >>>> >>>> On 2016-01-21, at 19:19, Joe Touch wrote: >>>>> Any protocol that deliberately sends messages larger than the known MTU >>>>> - except for detecting MTUs itself - is asking for trouble. >>>> >>>> +1 >>>> >>>> We also recommend such message size limit for general UDP use in RFC5405 >>>> and 5405bis. >>>> >>>> Lars >>>> >>> >> >> From nobody Fri Jan 22 11:21:00 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CD71B2C87 for ; Fri, 22 Jan 2016 11:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHdub49iqeu4 for ; Fri, 22 Jan 2016 11:20:52 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F81F1B2C85 for ; Fri, 22 Jan 2016 11:20:52 -0800 (PST) Received: from [128.9.184.164] ([128.9.184.164]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u0MJKIvR018468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2016 11:20:18 -0800 (PST) To: Tom Herbert , Brian E Carpenter References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> <56A27ADA.5030108@gmail.com> From: Joe Touch Message-ID: <56A280F1.80204@isi.edu> Date: Fri, 22 Jan 2016 11:20:17 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u0MJKIvR018468 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsvwg@ietf.org" , touch@isi.edu, Ian Swett , "alyssar@google.com" , "rch@google.com" Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 19:20:55 -0000 On 1/22/2016 11:16 AM, Tom Herbert wrote: > On Fri, Jan 22, 2016 at 10:54 AM, Brian E Carpenter > wrote: >> On 23/01/2016 07:21, Tom Herbert wrote: >>> On Fri, Jan 22, 2016 at 10:14 AM, Jana Iyengar wrote: >>>> Yes, agreed. It is absolutely the intention (and current practice) that all >>>> QUIC packets, including handshake packets, fit within a PMTU to avoid >>>> fragmentation. >>>> >>> PMTU discovery should work on UDP sockets (Linux at least). The udp >>> man page describes it. >> >> You are joking, right? >> > No, and I am not advocating that as the solution. My point is that > QUIC running on Linux (which I assume is not an insignificant number > of hosts) is already probably using PMTUD and is subject to whatever > problems or benefits that entails. That is not to say it is good or > bad, but QUIC developers should be aware of this. If you get an > EMSGSIZE error on a UDP write operation there is a good chance it is > because of PMTUD. Certainly. But you are also vulnerable to black holing, where the use of larger messages might result in a silent drop - forever. Unless the layer above UDP adapts to that, the blackhole will persist. Joe From nobody Fri Jan 22 12:07:20 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C3F1B2D04 for ; Fri, 22 Jan 2016 12:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwYCTNkXk70Z for ; Fri, 22 Jan 2016 12:07:17 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEB61ACDA2 for ; Fri, 22 Jan 2016 12:07:17 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g73so101444765ioe.3 for ; Fri, 22 Jan 2016 12:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LpKKYXSx2Ws+8wyAXOZ0DhPAFFhYkzlYEEr2QXe7xzo=; b=wKDXUrd+sbpaORKduyCTv46LblJw8qfg/Udri2yYijs3XXRc3ouLEKTQxV/GCv9AxW 1XGgrphpOLofebApiyXY7cQd2ew4c9DvKBXI/Nii9QqNDH1Po8swQNhGxF2mz9cnV8V0 lJyd2c9ygBkXbfroxXRBHyWVXRDvyZ5RDbDCLV0vfw0M/s2gsdTLcRtd9n5B3fDXnSPU qPfgpEevDZHLkjn5cb6L1hg1VGlvXQGxQ9X8bVJpUfhkowNTnlVbQv6eDKx33bZfZrhh hCx8ikJGItvcUwCw6mp+rkM3NqJUB0ZV2KSn2dhQWk7d7Jk1ESWWX7UASPaQKT92NJnt WJ1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LpKKYXSx2Ws+8wyAXOZ0DhPAFFhYkzlYEEr2QXe7xzo=; b=WaaCeY6XFF1VmptZKa2zb3rRE0D07HLuP5HNGhjbAFNIuVemCH8vN42QoamSpHnMGC FpnDsAhGdp4GB7coMqZGY+D1MPmsZBe4+iTc/qhEE6wGY423IwVlIpquxhqybjgPXG41 k/lzYisDeUoCHlDBy2L4sh4j5XP0asmu4kFgsFQDO//ZAB41bJvA/fZ+GAZlVVk8ZOYM qAPFuN7pi7UhRtM8qj+XCvQCpaDWbZ4POb54CQMIVmN+N2RyIOieLw43Of74qlRFxq5j kjA4WJuRBTXB8rX8JoZtqfOvnD5H7/5vVWVIR9qdu7RxoqdKxjb764MxlYcHPkVYmq4V 3PGQ== X-Gm-Message-State: AG10YOT2dM+3RJbVrR6vJOBL3YAn3zR6C6nvB7xjs0kxKyRxNpYVh6XwNi6ZIwtQNBOMB1yv3dNU+TX9X+22mQ== MIME-Version: 1.0 X-Received: by 10.107.152.142 with SMTP id a136mr5514323ioe.84.1453493236799; Fri, 22 Jan 2016 12:07:16 -0800 (PST) Received: by 10.107.140.150 with HTTP; Fri, 22 Jan 2016 12:07:16 -0800 (PST) In-Reply-To: <56A280F1.80204@isi.edu> References: <56A12036.9020607@isi.edu> <56A12128.9@isi.edu> <03B15272-D2B3-4753-8347-FC702E044897@netapp.com> <56A27ADA.5030108@gmail.com> <56A280F1.80204@isi.edu> Date: Fri, 22 Jan 2016 12:07:16 -0800 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tsvwg@ietf.org" , Ian Swett , "alyssar@google.com" , "rch@google.com" Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 20:07:18 -0000 On Fri, Jan 22, 2016 at 11:20 AM, Joe Touch wrote: > > > On 1/22/2016 11:16 AM, Tom Herbert wrote: >> On Fri, Jan 22, 2016 at 10:54 AM, Brian E Carpenter >> wrote: >>> On 23/01/2016 07:21, Tom Herbert wrote: >>>> On Fri, Jan 22, 2016 at 10:14 AM, Jana Iyengar wrote: >>>>> Yes, agreed. It is absolutely the intention (and current practice) that all >>>>> QUIC packets, including handshake packets, fit within a PMTU to avoid >>>>> fragmentation. >>>>> >>>> PMTU discovery should work on UDP sockets (Linux at least). The udp >>>> man page describes it. >>> >>> You are joking, right? >>> >> No, and I am not advocating that as the solution. My point is that >> QUIC running on Linux (which I assume is not an insignificant number >> of hosts) is already probably using PMTUD and is subject to whatever >> problems or benefits that entails. That is not to say it is good or >> bad, but QUIC developers should be aware of this. If you get an >> EMSGSIZE error on a UDP write operation there is a good chance it is >> because of PMTUD. > > Certainly. But you are also vulnerable to black holing, where the use of > larger messages might result in a silent drop - forever. Unless the > layer above UDP adapts to that, the blackhole will persist. > Right, that's why we also have TCP probing (RFC4821). Presumably, that can be implemented for QUIC, but since QUIC is contained in the application it may require more work. For instance, PMTU is a path property that we can discover on the basis of packets in one flow. A userspace application is restricted in it's interaction with L3 (routing) so there's no way it can inform other applications or the networking stack about the PMTU, so discovery may need to be done multiple times to the same destination. PTB error is something we can apply to the cached path characterisitcs though. > Joe > From nobody Fri Jan 22 12:58:16 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C45BF1A8888; Fri, 22 Jan 2016 12:58:13 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160122205813.7643.55016.idtracker@ietfa.amsl.com> Date: Fri, 22 Jan 2016 12:58:13 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-08.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 20:58:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : DSCP and other packet markings for WebRTC QoS Authors : Subha Dhesikan Cullen Jennings Dan Druta Paul E. Jones Filename : draft-ietf-tsvwg-rtcweb-qos-08.txt Pages : 10 Date : 2016-01-22 Abstract: Many networks, such as service provider and enterprise networks, can provide treatment for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 23 14:34:11 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0AB1B2A10; Sat, 23 Jan 2016 14:34:09 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160123223409.32638.392.idtracker@ietfa.amsl.com> Date: Sat, 23 Jan 2016 14:34:09 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 22:34:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : DSCP and other packet markings for WebRTC QoS Authors : Subha Dhesikan Cullen Jennings Dan Druta Paul E. Jones Filename : draft-ietf-tsvwg-rtcweb-qos-09.txt Pages : 10 Date : 2016-01-23 Abstract: Many networks, such as service provider and enterprise networks, can provide treatment for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 24 17:29:42 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 035421B36A0; Sun, 24 Jan 2016 17:29:39 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160125012939.13718.11585.idtracker@ietfa.amsl.com> Date: Sun, 24 Jan 2016 17:29:39 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 01:29:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : DSCP and other packet markings for WebRTC QoS Authors : Subha Dhesikan Cullen Jennings Dan Druta Paul E. Jones Filename : draft-ietf-tsvwg-rtcweb-qos-10.txt Pages : 10 Date : 2016-01-24 Abstract: Many networks, such as service provider and enterprise networks, can provide treatment for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 25 23:30:40 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DFE1A6F47; Mon, 25 Jan 2016 23:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEabALuj4Tpo; Mon, 25 Jan 2016 23:30:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3171A6F49; Mon, 25 Jan 2016 23:30:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDL54950; Tue, 26 Jan 2016 07:30:32 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 07:30:30 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.62]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Tue, 26 Jan 2016 15:30:25 +0800 From: Youjianjie To: "tsvwg@ietf.org" , "spud@ietf.org" Thread-Topic: One bit for latency bandwidth tradeoff Thread-Index: AdFYC2ufEvZMvnA6QRuvgZ56n6lDIQ== Date: Tue, 26 Jan 2016 07:30:24 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.235] Content-Type: multipart/alternative; boundary="_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A72099.0054, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.62, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 60752dacd129d1fb7f98335c7d1ae800 Archived-At: Subject: [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 07:30:38 -0000 --_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Existing work shows that having a latency-bandwidth trade-off decision woul= d be useful. For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D9= 23942 http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2= 008.pdf SPUD describes this as one of its use cases. https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 We wonder: how should this be specified? Could we, for example, use the DSC= P? If so, how - can we use an existing value, or should we define a new one= ? Regards, Jianjie --_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Existing work shows that hav= ing a latency-bandwidth trade-off decision would be useful.

For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942

http://p= eople.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf<= /a>

 

SPUD describes this as one o= f its use cases.

https://tools.ietf= .org/html/draft-kuehlewind-spud-use-cases-00#section-4

 

We wonder: how should this b= e specified? Could we, for example, use the DSCP? If so, how - can we use a= n existing value, or should we define a new one?

 

Regards,

Jianjie

 

--_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_-- From nobody Tue Jan 26 01:54:40 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5528D1A88D3; Tue, 26 Jan 2016 01:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxtexOvyF83w; Tue, 26 Jan 2016 01:54:36 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id EB56A1A88CF; Tue, 26 Jan 2016 01:54:35 -0800 (PST) Received: from public-docking-cx-1556.ethz.ch (public-docking-pat-cx-mapped-0004.ethz.ch [195.176.111.5]) by trammell.ch (Postfix) with ESMTPSA id 93B6B1A026F; Tue, 26 Jan 2016 10:54:04 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: Date: Tue, 26 Jan 2016 10:54:03 +0100 Message-Id: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> References: To: Youjianjie X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 09:54:38 -0000 --Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jianjie, Our thinking on this in the context of the prototype is either (a) that = the latency tradeoff be bound to a tube (which would require (1) more = than one bit to encode the tradeoff and (2) that the forwarding/queueing = decision also always do a lookup on the tube ID, which is not optimal), = or (b) that one of the reserved bits in cmd/flags be used for this. It does not appear that the current definitions of the DSCP codepoints = would allow compatible reuse of either a single bit or any of the = codepoints as a signal for this tradeoff. One could perhaps go to the = effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for = "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone = with some DSCP expertise to say how difficult this would be. Cheers, Brian > On 26 Jan 2016, at 08:30, Youjianjie wrote: >=20 > Hi, >=20 > Existing work shows that having a latency-bandwidth trade-off decision = would be useful. > For example: = http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942 > = http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_= 2008.pdf >=20 > SPUD describes this as one of its use cases. > = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >=20 > We wonder: how should this be specified? Could we, for example, use = the DSCP? If so, how - can we use an existing value, or should we define = a new one? >=20 > Regards, > Jianjie --Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWp0I8AAoJEIoSt78L6kajhegQAJBd5DwIj/zDxuMRQ9s1jSqD Usmf5f5/fKcwGkVcgu+tq9A6uRsI1Xv6Lx1ZEeGqJvKRWMHaTtSihVlf8a1TGZnP MIZi25jz48vNhbG9buyc5gDL06JCB1DHYeL0vPzPNi9A85N9noy5XO2xUW4sVDE4 bDgl+FqLBjjHIG7FKk8hdPi23IoAEIbOfFsg9QSI+L31dFW9DgTd2917aUB2NEBv cJ0Gqdg9MEfdBcyMH3RloXGJ5jnwAMZuXI1aQcnZFE/imzgKZJ1NwyOz9DMeT+1O 0bCTryDz5fsFVanBe+YKi1mLu+jeVl5p2yw3gt5XXfHLxj0Jdhd+QNgmtDa/iidt rkeDtuqvyGP6UXmFGwSpBVtCAaKUjCBKH2mJ3hk/bvx6s69t7DWU1DCq6EVB+CII /hqQyGsFnOxtJ+eNW5Z/JQdJRWlU7uy8QZS9cXv//6pSHDR+O0I20mEFMmwDtl/c Ljc72yHyeUSDHIjrGSChlX6viRoZ8Zcn1ziLNLe9b8JQ67WBoujQpNaP54N6skw4 t8zoBegW7vL5PBFIeDhMf7u7fmxbLXFundxcxYDOSiCBelZ61WweKbPec0WP5Ybf aAd3mIEoYnxN0x9VSkq4njTBk5a8roTnfvxEWXiUjid5wxP5ZzmifnSwJcywIbgi 9V9k273Cu0fsVOIv0iB4 =o7NG -----END PGP SIGNATURE----- --Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445-- From nobody Tue Jan 26 01:59:35 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B671A88EF; Tue, 26 Jan 2016 01:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjd44tTvlBoC; Tue, 26 Jan 2016 01:59:31 -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 6319C1A88ED; Tue, 26 Jan 2016 01:59:31 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aO0PD-0000N7-JB; Tue, 26 Jan 2016 10:59:23 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aO0PD-0000Gb-5Z; Tue, 26 Jan 2016 10:59:23 +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: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> Date: Tue, 26 Jan 2016 10:59:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 8 sum rcpts/h 16 sum msgs/h 10 total rcpts 37510 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E4EDEB33E7C8810D31313402164B74DE20E601E9 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 8986 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 09:59:33 -0000 > On 26 Jan 2016, at 10:54, Brian Trammell wrote: >=20 > hi Jianjie, >=20 > Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >=20 > It does not appear that the current definitions of the DSCP codepoints = would allow compatible reuse of either a single bit or any of the = codepoints as a signal for this tradeoff. One could perhaps go to the = effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for = "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone = with some DSCP expertise to say how difficult this would be. +1 - this is exactly Jianjie and I are asking about... how difficult it = would be, and if folks would consider this reasonable Cheers, Michael From nobody Tue Jan 26 02:10:32 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072551A8940; Tue, 26 Jan 2016 02:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk1sgHcwzsy0; Tue, 26 Jan 2016 02:10:28 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 337521A88F7; Tue, 26 Jan 2016 02:10:28 -0800 (PST) Received: from [IPv6:2001:67c:10ec:52c7:8000::38e] (unknown [IPv6:2001:67c:10ec:52c7:8000::38e]) by trammell.ch (Postfix) with ESMTPSA id 5AA9E1A0023; Tue, 26 Jan 2016 11:09:57 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: Date: Tue, 26 Jan 2016 11:09:56 +0100 Message-Id: <1CDC8606-31D2-4A60-B035-346F5A466B58@trammell.ch> References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 10:10:30 -0000 --Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 26 Jan 2016, at 10:59, Michael Welzl wrote: >=20 >=20 >> On 26 Jan 2016, at 10:54, Brian Trammell wrote: >>=20 >> hi Jianjie, >>=20 >> Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >>=20 >> It does not appear that the current definitions of the DSCP = codepoints would allow compatible reuse of either a single bit or any of = the codepoints as a signal for this tradeoff. One could perhaps go to = the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, = for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of = someone with some DSCP expertise to say how difficult this would be. >=20 > +1 - this is exactly Jianjie and I are asking about... how difficult = it would be, and if folks would consider this reasonable I consider it extremely reasonable, but have no idea how difficult it = is. :) Indeed, since a lot of how we're thinking about how tube properties get = implemented by in-network functionality involves things like translating = tube information down to DSCP, MPLS labels, etc, having an explicit DSCP = *in addition to* a SPUD flag for this tradeoff is a win for everyone = IMO. Even if we designate 0b111101 as "latency sensitive / loss tradeoff" and = 0b011101 as "loss sensitive / latency tradeoff", it'll be a (long) while = before you get border devices deployed that would strip AF and EF = codepoints but let these tradeoff codepoints through. For a lot of = platforms I expect you'd need a new configuration language to even be = able to tell your firewall to do that. So I still think we need bits in = both places for a while. Cheers, Brian --Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWp0X1AAoJEIoSt78L6kajJtwP+wYKKw5BkRYpsUS3chE+vaRL zO1BBHuhGfKN7HZxtP8fLyCEOepRjYh+sSUAv23UsAXSWgPJtzoPjTnnew40+Wbh Dv4EEq/kBLfgvr9i2lwNAnQdbVrv90ofpe34thQBmFNMAIDJ/pT5a9GKTwFgMmkU NXSCBjv1+iZSjR7HR3BKHou+nizc9NB+03zc4BdS5qd2bpDD3MQmqv7SkRTa21rT J1osrzYZVQu61y12HQ3jYfdLS27Lzu7dIePkw4iMxK5KE5sFsDu6rIhcN8SMpJxB jEmPi9Uv2FOz62gzozDe2kaUGpDWo6d01ba3gxDzlA2Ej/vclGPM47WnRkeJlwT3 TXjgL+lQ0qORHBiIoCALCrMTuRYGIuWdSqHHnTCGinBUXef35Jc6lfcJNlaM1zzS tkSAbQEgwUvOFbHSt2UdpGqCPE1R3xqbxqq1c20CmHNZN7AJTYJgH/vCOZttOjUH k8p7QhxBDFQZPEp7aUsOS2UqDBefQOTLlf9qbGgplzOcKDILusg6q+XNiv5Vx5dY HRw12a+fezUAU5Oe2i3u3WY3Ny/0VaQiAk7/urDsFje4ZCnKaUGK5cZK2FIbPkI0 +e89cRkB2iW2YV1aXvI1A54z9A3k6vxtURrDD5eaKDyWoYkT72IPzwW1RHonL7mH NBlYcwxZSapSDeJYopBB =9jFH -----END PGP SIGNATURE----- --Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21-- From nobody Tue Jan 26 03:14:25 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210051AD0B8; Tue, 26 Jan 2016 03:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJgucP82xHxy; Tue, 26 Jan 2016 03:14:21 -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 BD01B1AD06F; Tue, 26 Jan 2016 03:14:20 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aO1Zh-0004Iz-W1; Tue, 26 Jan 2016 12:14:17 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aO1Zh-0006yR-Ek; Tue, 26 Jan 2016 12:14:17 +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: <1CDC8606-31D2-4A60-B035-346F5A466B58@trammell.ch> Date: Tue, 26 Jan 2016 12:14:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A63816A-8DC5-4138-BCAE-FC0CEBEC5A25@ifi.uio.no> References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> <1CDC8606-31D2-4A60-B035-346F5A466B58@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 12 sum msgs/h 6 total rcpts 37514 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E8AADADB93553E7166FE59C740E59A3D75089B4C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 8987 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 11:14:23 -0000 > On 26 Jan 2016, at 11:09, Brian Trammell wrote: >=20 >=20 >> On 26 Jan 2016, at 10:59, Michael Welzl wrote: >>=20 >>=20 >>> On 26 Jan 2016, at 10:54, Brian Trammell wrote: >>>=20 >>> hi Jianjie, >>>=20 >>> Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >>>=20 >>> It does not appear that the current definitions of the DSCP = codepoints would allow compatible reuse of either a single bit or any of = the codepoints as a signal for this tradeoff. One could perhaps go to = the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, = for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of = someone with some DSCP expertise to say how difficult this would be. >>=20 >> +1 - this is exactly Jianjie and I are asking about... how difficult = it would be, and if folks would consider this reasonable >=20 > I consider it extremely reasonable, but have no idea how difficult it = is. :) >=20 > Indeed, since a lot of how we're thinking about how tube properties = get implemented by in-network functionality involves things like = translating tube information down to DSCP, MPLS labels, etc, having an = explicit DSCP *in addition to* a SPUD flag for this tradeoff is a win = for everyone IMO. >=20 > Even if we designate 0b111101 as "latency sensitive / loss tradeoff" = and 0b011101 as "loss sensitive / latency tradeoff", it'll be a (long) = while before you get border devices deployed that would strip AF and EF = codepoints but let these tradeoff codepoints through. For a lot of = platforms I expect you'd need a new configuration language to even be = able to tell your firewall to do that. So I still think we need bits in = both places for a while. I agree with everything here. Cheers Michael From nobody Tue Jan 26 09:11:43 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2513F1A904F; Tue, 26 Jan 2016 09:11:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160126171140.25174.25823.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 09:11:40 -0800 Archived-At: Cc: tsvwg-chairs@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-circuit-breaker@ietf.org Subject: [tsvwg] Last Call: (Network Transport Circuit Breakers) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:11:40 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Network Transport Circuit Breakers' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document explains what is meant by the term "network transport Circuit Breaker" (CB). It describes the need for circuit breakers for network tunnels and applications when using non-congestion- controlled traffic, and explains where circuit breakers are, and are not, needed. It also defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jan 26 11:20:08 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D01D1B2BD4; Tue, 26 Jan 2016 11:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6n_OWlcyyzS; Tue, 26 Jan 2016 11:20:01 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696B21B2BD2; Tue, 26 Jan 2016 11:20:01 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id q63so106260488pfb.1; Tue, 26 Jan 2016 11:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=mG//Rm+F/C7dgOzH7JDHlTBAr4vnIivowPaUtU0T69w=; b=QV5RJg3Kk5HTnXlww76MhOAes4bc3noR9cedViQs1VPmQUCJfnIsVtgtMVENoe0Lmy +zLR+NmyvMtNvuugwwmMeYzKuxti7DtNFskS8Zo/yvXQ6YobE5tO/tf+8/j8G+uMU4A6 aM9MnQeogUvg0eazdG2FGHlI+me6z3Z3iZzUEGdWYrGsylqFIY6Dlcf2BNj1FMjG8Kp7 5pu6NHX8/h5SF7H1AfnFdJpqP9fN43o546Mv5mTVUziW17uIO6I/8MHzIXyc6ziQZzpQ kdV1o7pOE6v4XRfR8aSpe9XSVPcPwHD0/TLJFM/6ANfHwREuYeH+7rhTJ5wYJEfCs/CM 4uZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=mG//Rm+F/C7dgOzH7JDHlTBAr4vnIivowPaUtU0T69w=; b=mizIqcn+iOmRAMM788AXuFMTHko/4yHxtyBMO4JhZGjxOdMS1cvZl+Y5HEdITqoLOg +r/ic4qO/4+lVFVjawo7D1tTRgYhOukjx5I3XH510m3xAkgmcCvSv5wKhED3DMaPXfHh gbEeN7aTdeFPKX1kiGR+NiaQiF+GziKQF7caMl3yAyZ2i3o5iJ6wPPJ8hDB24JZbOhQj g4C1RbaMPr6qd5jih8X89/l3HLdc6NXvRhHJ9B08Y7Z7PsrpVxsVKZujgi6Ywl3LhfrR CarIUG+glDZI9k0FrEaYyWrpuyhJXcQvqIaa+qocleirxcTiKtHfF8I3qWXpY+9WEfVB AVEQ== X-Gm-Message-State: AG10YOQLXcSyGBXXqfqwJZwezBUeIY2a0Vg6kEdoO7KHz6Dqf8ChwzqSqMfep7kdDlNizg== X-Received: by 10.98.66.74 with SMTP id p71mr36177055pfa.105.1453836001096; Tue, 26 Jan 2016 11:20:01 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m75sm3549351pfj.38.2016.01.26.11.19.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 11:19:59 -0800 (PST) To: Brian Trammell , Youjianjie References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A7C6E2.40401@gmail.com> Date: Wed, 27 Jan 2016 08:20:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:20:04 -0000 On 26/01/2016 22:54, Brian Trammell wrote: > hi Jianjie, > > Our thinking on this in the context of the prototype is either (a) that the latency tradeoff be bound to a tube (which would require (1) more than one bit to encode the tradeoff and (2) that the forwarding/queueing decision also always do a lookup on the tube ID, which is not optimal), or (b) that one of the reserved bits in cmd/flags be used for this. > > It does not appear that the current definitions of the DSCP codepoints would allow compatible reuse of either a single bit or any of the codepoints as a signal for this tradeoff. One could perhaps go to the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone with some DSCP expertise to say how difficult this would be. Can you define the relevant per-hop behaviours precisely? That's the only formal requirement of RFC2474 section 5. Are they implementable at line speed? BTW, the choice between EF and not-EF is to a large extent a latency/throughput choice. EF is supposed to provide bounded latency and jitter within bounded throughput. RFC 3248 and RFC 3246 are all about bounded latency. Low latency, low jitter, high throughput: pick any two. Brian C > > Cheers, > > Brian > > > >> On 26 Jan 2016, at 08:30, Youjianjie wrote: >> >> Hi, >> >> Existing work shows that having a latency-bandwidth trade-off decision would be useful. >> For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942 >> http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf >> >> SPUD describes this as one of its use cases. >> https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >> >> We wonder: how should this be specified? Could we, for example, use the DSCP? If so, how - can we use an existing value, or should we define a new one? >> >> Regards, >> Jianjie > From nobody Tue Jan 26 12:20:42 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F11B2CCA; Tue, 26 Jan 2016 12:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HybhKTVsdvwl; Tue, 26 Jan 2016 12:20:37 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id AC4EE1B2CC1; Tue, 26 Jan 2016 12:20:36 -0800 (PST) Received: from [10.0.27.116] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 4F5F61A026F; Tue, 26 Jan 2016 21:20:35 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: <56A7C6E2.40401@gmail.com> Date: Tue, 26 Jan 2016 21:20:34 +0100 Message-Id: <112CE360-529A-4076-8E52-B7758798EC62@trammell.ch> References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> <56A7C6E2.40401@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [tsvwg] [Spud] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 20:20:39 -0000 --Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian (C), > On 26 Jan 2016, at 20:20, Brian E Carpenter = wrote: >=20 > On 26/01/2016 22:54, Brian Trammell wrote: >> hi Jianjie, >>=20 >> Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >>=20 >> It does not appear that the current definitions of the DSCP = codepoints would allow compatible reuse of either a single bit or any of = the codepoints as a signal for this tradeoff. One could perhaps go to = the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, = for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of = someone with some DSCP expertise to say how difficult this would be. >=20 > Can you define the relevant per-hop behaviours precisely? That's the = only formal > requirement of RFC2474 section 5. There are a couple of possible definitions. The simplest I can think of, = which probably has issues in the margins due to the fact that it has to = be evaluated per-hop without any accumulated path information: (1) if the Latency Tradeoff codepoint is set, the device should drop the = packet if it would otherwise impart more than N (configurable?) queueing = delay. (This is the "don't bufferbloat me!" codepoint, and is the = default for hypothetical devices with very short queues and no AQM) (2) if the Loss Tradeoff codepoint is set, the device should queue the = packet for as long as it has buffer capacity. (This is the "please = bufferbloat me!" codepoint, and indeed the default for devices with a = single big queue and no AQM). The simplest way to implement this is with two queues: one with a very = short queue, one with a much longer queue, with a transmission algorithm = that tends to drain the short one first, but does not assign strict = priority to the short one. Lots of proposals in this space (indeed, I = think discussed in TSV) that would point the way toward the right = configuration here. > Are they implementable at line speed? Since in the two-queue case it's merely a queueing decision, yes. > BTW, the choice between EF and not-EF is to a large extent a = latency/throughput choice. > EF is supposed to provide bounded latency and jitter within bounded = throughput. > RFC 3248 and RFC 3246 are all about bounded latency. Thanks for the reply... I briefly looked over these before answering and = EF seemed also to request low loss for defined throughput, which is... = not really the same thing. Cheers, Brian (T) > Low latency, low jitter, high throughput: pick any two. >=20 > Brian C >=20 >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>=20 >>> On 26 Jan 2016, at 08:30, Youjianjie wrote: >>>=20 >>> Hi, >>>=20 >>> Existing work shows that having a latency-bandwidth trade-off = decision would be useful. >>> For example: = http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942 >>> = http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_= 2008.pdf >>>=20 >>> SPUD describes this as one of its use cases. >>> = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>>=20 >>> We wonder: how should this be specified? Could we, for example, use = the DSCP? If so, how - can we use an existing value, or should we define = a new one? >>>=20 >>> Regards, >>> Jianjie >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWp9UTAAoJEIoSt78L6kajZ88P/2/xqV8U2XUpoyWmdY1o2VbV m7gSlP5YHna7nOxo0MscWwvZ0lT0iOMq7A7AEX/krNo1C9f4iuzjLTJ37+OmlaNk KxQzBje0g6/HiC00q8jgGcbYVLz8GXUh/Xw6HM0dogvVRpvKS7QAZf8Ez8uBenQk LKe2BhdQAHPNeH+PwsYMjqUkQyBfm2ow2cSY0pu9lciwaKVIA/lGqsgEQ4CFBbBI Twv/Ck+hFdoUqu7jrO3mjl1hMNW/8CaCpDUMea7YeeJgsiHdWdoQ3dY2KoqFaZIK 1atwbHT8H/IdPM7dKFElY7jAwQOBOBbCyrXXJa0BxJqPhB3nA515qMkaHap/A+Tt FllMWtBVTx6j+QPEl+MYwus3XeQgiA7u43n5T1tOb63ItynSv/0WM1LwrHyrpbxa 1xgQjYhnRAZFzK5x/WFk+a/ThJVrXyvNCr/TKzz3oaD4WZ6vsNG7jau2YW94+jvQ kK1R/Wro7C8Te96lNDHd+/QjUkviLYNJFl5LElEoRL9a8HDZYMMCcmOcNKAzq1Ab WvzxAX5vARl3f0XuxAcI7ZktoFusdbQnNsgyz/Nd6FI7J3FSVqU8u/yWKJ9RQlu1 MedmmXuAf9P/vPkIYzPEoek87lVvgsCoHPuvRA/xVlRl83SeuYQs52I5c28VreP8 UzXIWY5HzSZDJJ4fUd44 =dP5N -----END PGP SIGNATURE----- --Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61-- From nobody Tue Jan 26 16:21:08 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F231A039F; Tue, 26 Jan 2016 16:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZL0I0dcCcL8; Tue, 26 Jan 2016 16:21:05 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 275F11A03A2; Tue, 26 Jan 2016 16:21:05 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id ho8so105649695pac.2; Tue, 26 Jan 2016 16:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=O+hDWVCTiAHt1TdVAEysKqRaJFd2lCX2dj8WF0Y20xI=; b=NYLDEERgwKVdosYdT4CJTTCHhX4p4rWI783mCk3GS9TD/6uT/2H3ZS9RvbNq0gEjMd QVKyTIrf61EuN1sRRmKqKw6WnoblUkSe1hWd5hxHQ70sKBoBue/Z+1+1/THErcw42iqf TNjWxGDGmq1NKf2A7kHSvTfXRgeTXw86GjTvi4NkPOyOel+GrzaxVl4993F9uULkeXx4 WyeRMujhBwYfcMkjfS12fRA4J0bLoPgSzqWCpKNkeUZ4d4EvO4yMKWWE3pHQawcpSenh uIMpHU0Y/84KKV2o7izeZmbeUAnJ2t1pSWl3iXNXGJyBnym4lsJEN9/uhUqOB15bOb61 aj/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=O+hDWVCTiAHt1TdVAEysKqRaJFd2lCX2dj8WF0Y20xI=; b=gFt8EaggKoq9H9EfdQLzLG4ZXgeXlikw0nfGbOO9O2K2fvjSCB/nyxpGtLsUgZOZeu Oc5bM58zPNxkNjpwzRVxKmhl/ogVmXBSL+e6ur0LrFlR8uSnKvD16uu4TbjBZ6GJ7EGG YXnyTOsw3s7IDblVeddFPSdMnBk0j2AHO+3lS7xrzoAR+hUP4ClArriHC+Y2A/MszwB1 MLDmH31ocfSCGu5/9SCTP6U9UF+69sFaVrbWfPhr3yvmczgmAQhAmtpA5pjqS2AUTIx7 V+zykpkbDASVbID/wjvHaZhDEzhmJiaY2grNyRyGsG6snkq2tyEO+AcgIJ4NzEEyfec0 r4nA== X-Gm-Message-State: AG10YOSFC6eUV3QewwuCvOf6XwKe/X/SPSoVkpuyjlDXMgaMWqv00dM5UlbGnRWWlCGrzQ== X-Received: by 10.67.6.67 with SMTP id cs3mr38256580pad.143.1453854064788; Tue, 26 Jan 2016 16:21:04 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z3sm4312716par.17.2016.01.26.16.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 16:21:03 -0800 (PST) To: Brian Trammell References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> <56A7C6E2.40401@gmail.com> <112CE360-529A-4076-8E52-B7758798EC62@trammell.ch> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A80D72.5020000@gmail.com> Date: Wed, 27 Jan 2016 13:21:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <112CE360-529A-4076-8E52-B7758798EC62@trammell.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [tsvwg] [Spud] One bit for latency bandwidth tradeoff X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:21:07 -0000 On 27/01/2016 09:20, Brian Trammell wrote: > Hi Brian (C), > >> On 26 Jan 2016, at 20:20, Brian E Carpenter wrote: >> >> On 26/01/2016 22:54, Brian Trammell wrote: >>> hi Jianjie, >>> >>> Our thinking on this in the context of the prototype is either (a) that the latency tradeoff be bound to a tube (which would require (1) more than one bit to encode the tradeoff and (2) that the forwarding/queueing decision also always do a lookup on the tube ID, which is not optimal), or (b) that one of the reserved bits in cmd/flags be used for this. >>> >>> It does not appear that the current definitions of the DSCP codepoints would allow compatible reuse of either a single bit or any of the codepoints as a signal for this tradeoff. One could perhaps go to the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone with some DSCP expertise to say how difficult this would be. >> >> Can you define the relevant per-hop behaviours precisely? That's the only formal >> requirement of RFC2474 section 5. > > There are a couple of possible definitions. The simplest I can think of, which probably has issues in the margins due to the fact that it has to be evaluated per-hop without any accumulated path information: > > (1) if the Latency Tradeoff codepoint is set, the device should drop the packet if it would otherwise impart more than N (configurable?) queueing delay. (This is the "don't bufferbloat me!" codepoint, and is the default for hypothetical devices with very short queues and no AQM) > > (2) if the Loss Tradeoff codepoint is set, the device should queue the packet for as long as it has buffer capacity. (This is the "please bufferbloat me!" codepoint, and indeed the default for devices with a single big queue and no AQM). I don't see any intrinsic issue in writing PHB specifications for that. Of course, getting IETF standards track consensus is another matter. > The simplest way to implement this is with two queues: one with a very short queue, one with a much longer queue, with a transmission algorithm that tends to drain the short one first, but does not assign strict priority to the short one. Lots of proposals in this space (indeed, I think discussed in TSV) that would point the way toward the right configuration here. > >> Are they implementable at line speed? > > Since in the two-queue case it's merely a queueing decision, yes. Right, which is what I've always seen as the hallmark of deployable diffserv. > >> BTW, the choice between EF and not-EF is to a large extent a latency/throughput choice. >> EF is supposed to provide bounded latency and jitter within bounded throughput. >> RFC 3248 and RFC 3246 are all about bounded latency. > > Thanks for the reply... I briefly looked over these before answering and EF seemed also to request low loss for defined throughput, which is... not really the same thing. True, EF wants a lot (which is why we always assumed it would only be granted a smallish fraction of link capacity, so that its other requirements would leave plenty of space-time for other flows). Brian > > Cheers, > > Brian (T) > >> Low latency, low jitter, high throughput: pick any two. >> >> Brian C >> >>> >>> Cheers, >>> >>> Brian >>> >>> >>> >>>> On 26 Jan 2016, at 08:30, Youjianjie wrote: >>>> >>>> Hi, >>>> >>>> Existing work shows that having a latency-bandwidth trade-off decision would be useful. >>>> For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942 >>>> http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf >>>> >>>> SPUD describes this as one of its use cases. >>>> https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>>> >>>> We wonder: how should this be specified? Could we, for example, use the DSCP? If so, how - can we use an existing value, or should we define a new one? >>>> >>>> Regards, >>>> Jianjie >>> >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud > From nobody Tue Jan 26 17:49:14 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC381B313B; Tue, 26 Jan 2016 17:49:11 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127014911.16455.25548.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 17:49:11 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 01:49:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : GRE-in-UDP Encapsulation Authors : Edward Crabbe Lucy Yong Xiaohu Xu Tom Herbert Filename : draft-ietf-tsvwg-gre-in-udp-encap-09.txt Pages : 24 Date : 2016-01-26 Abstract: This document describes a method of encapsulating network protocol packets within GRE and UDP headers. In this encapsulation, the source UDP port can be used as an entropy field for purposes of load balancing, while the protocol of the encapsulated packet in the GRE payload is identified by the GRE Protocol Type. This document specifies requirements for two applicability scenarios for this encapsulation: (1) General Internet and (2) well-managed operator networks; less restrictive requirements apply to the latter scenario by comparison to the former. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 26 22:40:22 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D61ACE50; Tue, 26 Jan 2016 22:40:18 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127064018.2645.55140.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 22:40:18 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 06:40:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : DSCP and other packet markings for WebRTC QoS Authors : Paul E. Jones Subha Dhesikan Cullen Jennings Dan Druta Filename : draft-ietf-tsvwg-rtcweb-qos-11.txt Pages : 10 Date : 2016-01-26 Abstract: Many networks, such as service provider and enterprise networks, can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-11 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 Wed Jan 27 08:38:33 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FDE1A8AE7; Wed, 27 Jan 2016 08:38:31 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127163831.2916.20456.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 08:38:31 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-15.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 16:38:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : SCTP-PF: Quick Failover Algorithm in SCTP Authors : Yoshifumi Nishida Preethi Natarajan Armando Caro Paul D. Amer Karen E. E. Nielsen Filename : draft-ietf-tsvwg-sctp-failover-15.txt Pages : 21 Date : 2016-01-27 Abstract: SCTP supports multi-homing. However, when the failover operation specified in RFC4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. To overcome this problem this document specifies a quick failover algorithm (SCTP-PF) based on the introduction of a Potentially Failed (PF) state in SCTP Path Management. The document also specifies a dormant state operation of SCTP. This dormant state operation is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard RFC4960 SCTP implementation. Additionally, the document introduces an alternative switchback operation mode called Primary Path Switchover that will be beneficial in certain situations. This mode of operation applies to both a standard RFC4960 SCTP implementation as well as to a SCTP-PF implementation. The procedures defined in the document require only minimal modifications to the RFC4960 specification. The procedures are sender-side only and do not impact the SCTP receiver. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-failover-15 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 Wed Jan 27 09:04:19 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF651ACD95 for ; Wed, 27 Jan 2016 09:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw63Ecss6On9 for ; Wed, 27 Jan 2016 09:04:14 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16831ACD97 for ; Wed, 27 Jan 2016 09:04:13 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id u0RH45rH019803 for ; Wed, 27 Jan 2016 18:04:05 +0100 From: "Jose Saldana" To: References: <20160127165924.23207.45260.idtracker@ietfa.amsl.com> In-Reply-To: <20160127165924.23207.45260.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 18:04:22 +0100 Message-ID: <02c801d15924$c4f4fe60$4edefb20$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFt3EKAm4Ji/r26Z6jYh6sz8JkFN5/Wj8xw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: Subject: [tsvwg] New Version Notification for draft-saldana-tsvwg-simplemux-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 17:04:17 -0000 Hi all, A new version of the Simplemux draft has been uploaded. https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/ In addition, you can find a research paper explaining it here:=20 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D7363105 An implementation (https://github.com/TCM-TF/simplemux) has been used to = carry out some tests with real traffic, showing significant = improvements: 46% of the bandwidth can be saved when compressing voice = traffic. And the reduction in terms of packets per second in an Internet = trace can be up to 50%. In wireless networks, packet grouping results in = a significantly improved use of air time. Best regards, Jose > -----Mensaje original----- > De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Enviado el: mi=C3=A9rcoles, 27 de enero de 2016 17:59 > Para: Jose Saldana > Asunto: New Version Notification for = draft-saldana-tsvwg-simplemux-04.txt >=20 >=20 > A new version of I-D, draft-saldana-tsvwg-simplemux-04.txt > has been successfully submitted by Jose Saldana and posted to the IETF > repository. >=20 > Name: draft-saldana-tsvwg-simplemux > Revision: 04 > Title: Simplemux. A generic multiplexing protocol > Document date: 2016-01-27 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-saldana-tsvwg-simplemux- > 04.txt > Status: = https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/ > Htmlized: = https://tools.ietf.org/html/draft-saldana-tsvwg-simplemux-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-tsvwg-simplemux-04 >=20 > Abstract: > The low efficiency caused by the high amount of small packets = present > in the network can be alleviated by means of packet aggregation. > There are some situations in which multiplexing a number of small > packets into a bigger one is desirable. For example, a number of > small packets can be sent together between a pair of machines if = they > share a common network path. Thus, the traffic profile can be > shifted from small to larger packets, reducing the network overhead > and the number of packets per second to be managed by intermediate > routers. >=20 > This document describes Simplemux, a protocol able to encapsulate a > number of packets belonging to different protocols into a single > packet. It includes the "Protocol" field on each multiplexing > header, thus allowing the inclusion of a number of packets = belonging > to different protocols (multiplexed packets) on a packet of another > protocol (tunneling protocol). >=20 > In order to reduce the overhead, the size of the multiplexing = headers > is kept very low (it may be a single byte when multiplexing small > packets). >=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 From nobody Wed Jan 27 10:48:10 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143941B2B0C for ; Wed, 27 Jan 2016 10:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0WjAJJ7EZMj for ; Wed, 27 Jan 2016 10:48:07 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8619F1B2B0B for ; Wed, 27 Jan 2016 10:48:07 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id ik10so87578731igb.1 for ; Wed, 27 Jan 2016 10:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B5ZdUtQpNrmg0iQaQT5dOxMiyp1A7NwVAdpJc2IXX/U=; b=IVVodBxas4utFsMTlOY/KnCTvDC5ccLndOIo7EFn/p1/QmmuBm4Vc+5zly3JX33EQB 9zD1g+Hg3jOoOZCSNz8R9+e0dP2cEu8J+Q0euBm8UpeqmxpQV27GhN5vkvXX43jEULme QTwS/iVU1k68NbFvUP1CCh1/szGX+j5VJk/FIGPWYTzNK1of6O4jCt27kKpWcVQSdw6J YdhW3V/p0FEDvQCkMsA5lXYBzjH63LNybiropmhllFJ2/2UZEh9lcslSdAT0R96JRJkc UQQ+72tY3yWCBvOt9mlh4j6VnSv51ATYp6+FZMA2qe6BKmzQnhXEoId/lTkZl+JR6dy5 iTrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B5ZdUtQpNrmg0iQaQT5dOxMiyp1A7NwVAdpJc2IXX/U=; b=TMcQB+40YSr+zZDvv+Pkl9WSXGC4SWjjy11/bGccWsScZ+GhO8vs4l7bi1VWPapcEu wsKU7cDka6urywyFDzh9uMQFuKIIRNjOptDZLddFb9mWmwwt7+Jl2HiJdxZr5rnPGZCj KcutC6NpfVlBhNRKgT/ilGWpt+hxW1xG/Rcs6ciAvAUKYKcB6ZOC55QjFJ/YYFe5wLVa q7jP+VhkwSC7JTUjmCu6qx23XyusFdOYc0H6+1KKP0Mct3tAcEwYPjqgSGfekCGIdO6w JMzMhT7RS/5IMaIth1MTW/kV+/jyeXzO9Mb8EVtFeWuq2HYGMQeRtvs++gh7Zx/Ldh70 Abzw== X-Gm-Message-State: AG10YOQS4ndzkfV2Z9/DhRVzo6XxZm7dgVwyTnRWMOmmGEUsVUy4HzILsvRiWgaGXof1+kxfxz6SRuN/D7GvdQ== MIME-Version: 1.0 X-Received: by 10.50.29.5 with SMTP id f5mr31955116igh.65.1453920486627; Wed, 27 Jan 2016 10:48:06 -0800 (PST) Received: by 10.107.140.150 with HTTP; Wed, 27 Jan 2016 10:48:06 -0800 (PST) In-Reply-To: <02c801d15924$c4f4fe60$4edefb20$@unizar.es> References: <20160127165924.23207.45260.idtracker@ietfa.amsl.com> <02c801d15924$c4f4fe60$4edefb20$@unizar.es> Date: Wed, 27 Jan 2016 10:48:06 -0800 Message-ID: From: Tom Herbert To: Jose Saldana Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tsvwg Subject: Re: [tsvwg] New Version Notification for draft-saldana-tsvwg-simplemux-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 18:48:09 -0000 On Wed, Jan 27, 2016 at 9:04 AM, Jose Saldana wrote: > Hi all, > > A new version of the Simplemux draft has been uploaded. > https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/ > > In addition, you can find a research paper explaining it here: > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D7363105 > > An implementation (https://github.com/TCM-TF/simplemux) has been used to = carry out some tests with real traffic, showing significant improvements: 4= 6% of the bandwidth can be saved when compressing voice traffic. And the re= duction in terms of packets per second in an Internet trace can be up to 50= %. In wireless networks, packet grouping results in a significantly improve= d use of air time. > Hi Jose, Have considered the effect this will have on packet ordering (i.e. will this create rampant OOO packets at a receiver)? You also might want to look at implementing this within an existing encapsulation, such as GUE, which already provides basic encapsulation features like checksum, flow entropy, and compatibility with network HW since it is UDP. Although, if this does become an IP protocol it would already be compatible with GUE since protocol field takes an IP protocol number. Thanks, Tom > Best regards, > > Jose > >> -----Mensaje original----- >> De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Enviado el: mi=C3=A9rcoles, 27 de enero de 2016 17:59 >> Para: Jose Saldana >> Asunto: New Version Notification for draft-saldana-tsvwg-simplemux-04.tx= t >> >> >> A new version of I-D, draft-saldana-tsvwg-simplemux-04.txt >> has been successfully submitted by Jose Saldana and posted to the IETF >> repository. >> >> Name: draft-saldana-tsvwg-simplemux >> Revision: 04 >> Title: Simplemux. A generic multiplexing protocol >> Document date: 2016-01-27 >> Group: Individual Submission >> Pages: 14 >> URL: https://www.ietf.org/internet-drafts/draft-saldana-tsvwg= -simplemux- >> 04.txt >> Status: https://datatracker.ietf.org/doc/draft-saldana-tsvwg-sim= plemux/ >> Htmlized: https://tools.ietf.org/html/draft-saldana-tsvwg-simplemu= x-04 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-tsvwg-= simplemux-04 >> >> Abstract: >> The low efficiency caused by the high amount of small packets present >> in the network can be alleviated by means of packet aggregation. >> There are some situations in which multiplexing a number of small >> packets into a bigger one is desirable. For example, a number of >> small packets can be sent together between a pair of machines if they >> share a common network path. Thus, the traffic profile can be >> shifted from small to larger packets, reducing the network overhead >> and the number of packets per second to be managed by intermediate >> routers. >> >> This document describes Simplemux, a protocol able to encapsulate a >> number of packets belonging to different protocols into a single >> packet. It includes the "Protocol" field on each multiplexing >> header, thus allowing the inclusion of a number of packets belonging >> to different protocols (multiplexed packets) on a packet of another >> protocol (tunneling protocol). >> >> In order to reduce the overhead, the size of the multiplexing headers >> is kept very low (it may be a single byte when multiplexing small >> packets). >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion until >> the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > From nobody Wed Jan 27 12:51:54 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D491A930A for ; Wed, 27 Jan 2016 12:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uXWOcgznZx6 for ; Wed, 27 Jan 2016 12:51:49 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 39F761A9301 for ; Wed, 27 Jan 2016 12:51:49 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id n5so44922593wmn.0 for ; Wed, 27 Jan 2016 12:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y0dlYcY+lQ8UdAUSGuqy3SnqztuQ1ACk/pGONljFu10=; b=FM0smluWcEmQ8m5KxQW2cJaiE6uvYepDEp9X+1xJH9GRI61l3dA+MzGIG7bjI7PrDZ 6w407Yex5xY1CSjtR5nUXaUH/fzfT5x8ZwiqFZrP/t6V6cBoYvRXBMHpvPhIC/1c0pSV TZnK1ImjiNvQI9FmePeq/qvFspShyFaoIV9FyyqJT+2y/Wi0XG87UHl0ik4gg/zBpGxv ZnA8bIX0e1VzUuGLucSh9MnxRdE0bDsQrYRmUCg5M2ocw/V7qsG5mGVrEC8mbxYI/TrC Wb3q2I3lBhBMd3Qqhypo9XIaW9MAVQRvpZJqc5m5ZEQ8ssMwYEaxKmRf7nTODuP/pOwi s5dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y0dlYcY+lQ8UdAUSGuqy3SnqztuQ1ACk/pGONljFu10=; b=B+lmhTxrIJm7H/H7r8WF3YIHX+ZWaVOdZcjDGgLXJQiGegGivXohPz95+JF4cS/Jt0 Wj9/r/tnFiqyN9cyK9edXnZc5hbBOQfcSAGzldRiy6OU9xGc9FfyAYT6WhvE+M94ztad 6nAug1TPTIyZtgObmZ1N1RDzcRxJtgqor6t/+upQEinAggFpUlNuiG5WwHoe3k97MgdI +jDLygNQDmz7/OUxuTU5+GpON6ZY9dVLKIN3QXI17UI6RZLC4KL2jr+xGU6qzSJKurXw WWHf5SavJJpey5gYg+nIJCYF7m2SFrPo81aQwfxZwP3OjUkP2P6AibRzAvSANlXvoP+M VDaw== X-Gm-Message-State: AG10YOSqldq3DuLcEkrBW1vlA/u0y4VRgnkrGGuK2a42H0YZQI7r8J6ia2SLoGZgGAJMmFalfzdxa6VYVeJwPw== MIME-Version: 1.0 X-Received: by 10.194.24.164 with SMTP id v4mr30762009wjf.138.1453927907826; Wed, 27 Jan 2016 12:51:47 -0800 (PST) Received: by 10.27.11.88 with HTTP; Wed, 27 Jan 2016 12:51:47 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2016 12:51:47 -0800 Message-ID: From: Martin Duke To: Jana Iyengar Content-Type: multipart/alternative; boundary=047d7b5d587279a070052a56f8e8 Archived-At: Cc: Ian Swett , Alyssa Wilk , tsvwg , Ryan Hamilton Subject: Re: [tsvwg] Comments on draft-tsvwg-quic-protocol-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 20:51:53 -0000 --047d7b5d587279a070052a56f8e8 Content-Type: text/plain; charset=UTF-8 Hello Ian and Jana, I appreciate your responses to my comments.In the cases where you've declined my advice, I think the reasoning is sound and I withdraw the comment. In particular I bow to the wisdom of the crowd on fragmentation. Regarding the timestamp issue, are you referring to the text in -02? I agree that you've clarified the wire spec a bit, so that I can actually extract the values or encode them. But I'm still not sure about how the sender fills the fields and how the receiver uses them. As I see no timestamp with data, I gather this is not a RFC 1323-like echo-based mechanism. So what is the *data sender* going to do with the time differential between connection start and the arrival time of any given packet at the data receiver? It's not sufficient, in itself, to determine the RTT, so what other timing mechanism is implied? Is the data receiver supposed to return one timestamp per received packet, or at some other rate? Martin On Tue, Jan 12, 2016 at 12:01 PM, Jana Iyengar wrote: > Hi Martin, > > Thanks so much for your comments and your interest! We're working on > updating the draft -- this is decidedly a -01 draft at the moment -- so > thank you for your text suggestions. Answers inline: > > 1) Section 5.1: I suggest that "the CHLO MUST fit in one packet; if need >> be, one that requires IP fragmentation." As ugly as that is, it's far >> superior to forcing the server to maintain state on incomplete CHLO. In >> another forum the authors have indicated that this is their intention. This >> also requires an exception to the preface of Section 6, which says to avoid >> IP fragmentation (though as I understand it we are a long way from CHLO >> having to be that long). >> > > I've added text to say "Any CHLO packet must be sent as a single UDP > datagram." There's no normative language in the draft at the moment. > > 2) Section 5.1: "The next time the client sends a CHLO, it can use the >> cached credentials from the previous connection to immediately send >> encrypted requests to the server." >> >> I would appreciate wording that makes it clearer that, "upon receipt of >> an authenticated REJ, the client MUST generate a new connection ID for >> subsequent CHLO messages, with sequence number 1." This clarification is >> also important to making servers stateless pre-SHLO. >> > > This gets into stateless vs non-stateless rejects. Though there is code > to support stateless rejects, the current intention is to support both > stateless and stateful rejects going forward. The documentation needs more > information to properly describe stateless rejects, which will happen once > we have more experience with stateless rejects. > > 3) Section 5.1: Without veering into the Crypto documents area, I think it >> would be helpful to indicate the frames that MUST, SHOULD, or MAY be in >> CHLO, REJ, and SHLO messages. Obviously there will be STREAM frames for >> stream 1, but I can certainly imagine PADDING, WINDOW_UPDATE, and ACK >> messages required as well. And I imagine CONNECTION_CLOSE etc. MAY be >> present. But I'm not sure! The stream 1 fields may be in a crypto document >> but the frame list should be here. >> > > Good suggestion. We'll work this in in a future revision. > > >> 4) Section 6.1: There is a little encryption ambiguity in the packets >> that the server receives from the client just after sending the SHLO. These >> packets could either use the initial key or the symmetric key, and with >> packet reordering they could be interleaved for while. As someone that >> implements server-side stuff for a living, it's irritating to potentially >> have to decrypt the packet twice, and to allocate space for two sets of >> keys in the PCB. >> > There are two unused bits in the Public Flags. It appears that Chromium >> has already taken one for a "multipath" flag, currently undocumented. I >> propose that the second one be an indicator that the client has received >> the SHLO and is using the symmetric key. >> > > This is an interesting idea. To be clear, this interleaving should only > really happen for ~1 roundtrip after the SHLO is sent, and soon after the > first forward secure packet is received, the server should be able to drop > the initial encryption key. At this point, we do trial decryption, and this > bit could be a nice optimization. > > That said, since the path for the QUIC handshake is to integrate with > TLS1.3, we are not making optimizations to QUIC's handshake at this point. > If I remember correctly, TLS1.3 could benefit from such a bit; this may be > a good suggestion for TLS1.3. > > And thanks for the note on the multipath bit -- we didn't have it when the > earlier version of the draft went out, but we've documented it in the > upcoming rev of the draft. > > 5) Section 6.1: The Chromium implementation sometimes puts 12 >> authentication bits between public and private header. It would be good to >> make this explicit in the document, as the figure in Section 6.1 reasonably >> reads as having the private flags immediately follow the sequence number. >> > > This is the auth hash and is part of the 'NULL' encryption algorithm > formatting... effectively, you're looking at an encrypted packet which has > public_header followed by the auth hash, followed by the encrypted body. > This is not the QUIC wire format, but the output of the NULL encrypter... > the plaintext QUIC packet format still has private flags following the > sequence number. I don't think it makes sense to change the QUIC > (plaintext) packet format. > > 6) Section 6.5: Please provide the correct format for the CADR tag. >> > > Currently this is for debug purposes only (comment added to this effect) > and is optional, and the formatting is somewhat awkward... it may make > sense to document a more standard version of this. Nevertheless, this > should probably be considered optional for now. > > 7) Section 8.3: I have read this section several times and cannot discern >> at all what the TCP timestamps are for, how many there should be, where >> they come from, and what format they are in. Are these echoes of some >> sender timestamp (and if, so where is that from) or are these local clock >> measurements? >> >> Obviously this has something to do with RTT calculation, but the mapping >> of the ACK frame fields to this calculation is really unclear. I tried to >> generate some psuedocode to generate an ACK frame and got nowhere. >> > > Apologies, that timestamp section was extremely confusing. The wording > has been substantially updated, which hopefully make it clearer -- let us > know if you are still stuck, and we're happy to help! > > Thanks again for your comments! > Ian and Jana > > --047d7b5d587279a070052a56f8e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ian and Jana,

I appreciate your r= esponses to my comments.In the cases where you've declined my advice, I= think the reasoning is sound and I withdraw the comment. In particular I b= ow to the wisdom of the crowd on fragmentation.

Re= garding the timestamp issue, are you referring to the text in -02? I agree = that you've clarified the wire spec a bit, so that I can actually extra= ct the values or encode them. But I'm still not sure about how the send= er fills the fields and how the receiver uses them.

As I see no timestamp with data, I gather this is not a RFC 1323-like ech= o-based mechanism. So what is the data sender going to do with the t= ime differential between connection start and the arrival time of any given= packet at the data receiver? It's not sufficient, in itself, to determ= ine the RTT, so what other timing mechanism is implied?

Is the data receiver supposed to return one timestamp per received pa= cket, or at some other rate?

Martin

On Tue, Jan 12, 2016= at 12:01 PM, Jana Iyengar <jri@google.com> wrote:
Hi Martin,

Thanks= so much for your comments and your interest! We're working on updating= the draft -- this is decidedly a -01 draft at the moment -- so thank you f= or your text suggestions. Answers inline:

=
1) Section 5.1: I suggest that "the CH= LO MUST fit in one packet; if need be, one that requires IP fragmentation.&= quot; As ugly as that is, it's far superior to forcing the server to ma= intain state on incomplete CHLO. In another forum the authors have indicate= d that this is their intention. This also requires an exception to the pref= ace of Section 6, which says to avoid IP fragmentation (though as I underst= and it we are a long way from CHLO having to be that long).

I've added text to say = "Any CHLO packet must be se= nt as a single UDP datagram." There's no normative language in the= draft at the moment.

2) Section 5.1: "The next time= the client sends a CHLO, it can use the cached credentials from the previo= us connection to immediately send encrypted requests to the server."

I would appreciate wording that makes it clearer th= at, "upon receipt of an authenticated REJ, the client MUST generate a = new connection ID for subsequent CHLO messages, with sequence number 1.&quo= t; This clarification is also important to making servers stateless pre-SHL= O.

This gets= into stateless vs non-stateless rejects.=C2=A0 Though there is code to sup= port stateless rejects, the current intention is to support both stateless = and stateful rejects going forward.=C2=A0 The documentation needs more info= rmation to properly describe stateless rejects, which will happen once we h= ave more experience with stateless rejects.
=
3) Section 5.1: Witho= ut veering into the Crypto documents area, I think it would be helpful to i= ndicate the frames that MUST, SHOULD, or MAY be in CHLO, REJ, and SHLO mess= ages. Obviously there will be STREAM frames for stream 1, but I can certain= ly imagine PADDING, WINDOW_UPDATE, and ACK messages required as well. And I= imagine CONNECTION_CLOSE etc. MAY be present. But I'm not sure! The st= ream 1 fields may be in a crypto document but the frame list should be here= .

Good suggestion.= We'll work this in in a future revision.
= =C2=A0
4) Section 6.1: The= re is a little encryption ambiguity in the packets that the server receives= from the client just after sending the SHLO. These packets could either us= e the initial key or the symmetric key, and with packet reordering they cou= ld be interleaved for while. As someone that implements server-side stuff f= or a living, it's irritating to potentially have to decrypt the packet = twice, and to allocate space for two sets of keys in the PCB.
There are two = unused bits in the Public Flags. It appears that Chromium has already taken= one for a "multipath" flag, currently undocumented. I propose th= at the second one be an indicator that the client has received the SHLO and= is using the symmetric key.

<= /span>
This is an interesting idea. To be clear, this interleaving shou= ld only really happen for ~1 roundtrip after the SHLO is sent, and soon aft= er the first forward secure packet is received, the server should be able t= o drop the initial encryption key.=C2=A0At this point, we do trial decrypti= on, and this bit could be a nice optimization.=C2=A0

That said, since the path for the QUIC handshake is to integrate with TL= S1.3, we are not making optimizations to QUIC's handshake at this point= . If I remember correctly, TLS1.3 could benefit from such a bit; this may b= e a good suggestion for TLS1.3.

And thanks for the= note on the multipath bit -- we didn't have it when the earlier versio= n of the draft went out, but we've documented it in the upcoming rev of= the draft.

5) Section 6.1:=C2=A0The Chromium implementation sometim= es puts 12 authentication bits between public and private header. It would = be good to make this explicit in the document, as the figure in Section 6.1= reasonably reads as having the private flags immediately follow the sequen= ce number.

This is the auth hash and is part of the 'NUL= L' encryption algorithm formatting... effectively, you're looking a= t an encrypted packet which has public_header followed by the auth hash, fo= llowed by the encrypted body. This is not the QUIC wire format, but the out= put of the NULL encrypter... the plaintext QUIC packet format still has pri= vate flags following the sequence number. I don't think it makes sense = to change the QUIC (plaintext) packet format.

6) Section 6.5: Pleas= e provide the correct format for the CADR tag.

Currently thi= s is for debug purposes only (comment added to this effect) and is optional= , and the formatting is somewhat awkward... it may make sense to document a= more standard version of this. Nevertheless, this should probably be consi= dered optional for now.

7) Section 8.3: I have read this s= ection several times and cannot discern at all what the TCP timestamps are = for, how many there should be, where they come from, and what format they a= re in. Are these echoes of some sender timestamp (and if, so where is that = from) or are these local clock measurements?

Obvio= usly this has something to do with RTT calculation, but the mapping of the = ACK frame fields to this calculation is really unclear. I tried to generate= some psuedocode to generate an ACK frame and got nowhere.

A= pologies, that timestamp section was extremely confusing.=C2=A0 The wording= has been substantially updated, which hopefully make it clearer -- let us = know if you are still stuck, and we're happy to help!
=
Thanks again for your comments!
Ian and Jana
=


--047d7b5d587279a070052a56f8e8-- From nobody Wed Jan 27 14:13:50 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9991B2C2E; Wed, 27 Jan 2016 14:13:47 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127221347.29673.92759.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 14:13:47 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:13:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : DSCP and other packet markings for WebRTC QoS Authors : Paul E. Jones Subha Dhesikan Cullen Jennings Dan Druta Filename : draft-ietf-tsvwg-rtcweb-qos-12.txt Pages : 10 Date : 2016-01-27 Abstract: Many networks, such as service provider and enterprise networks, can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-12 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 Wed Jan 27 15:36:46 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FFB1B38E5 for ; Wed, 27 Jan 2016 15:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnIAKCjUhaBB for ; Wed, 27 Jan 2016 15:36:37 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6317E1B38DF for ; Wed, 27 Jan 2016 15:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1038; q=dns/txt; s=iport; t=1453937797; x=1455147397; h=date:from:to:subject:message-id:mime-version; bh=GILe0hYGSwbbV/ofQLNv3wwMu6qvvYYtTJawYRdhuVg=; b=DHfGZ/NKt4ddi4CaDQfsDY8969xnjbOar9n9GOmdXqRCKuF90IBYYciF IOlmDer6NxYW5l1aH5QHffaaBXh0Rm9BUlRKhUzqfug2cUS8i+bwONePI ynT0QyXLVgrrgYSXDtkdlrSvaM7FkqUFNVg6u48JKxXgNt/5JxyFAASEh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGBQA2VKlW/4gNJK1egzqKFrMnh1k7E?= =?us-ascii?q?QEBAQEBAQGBCoUCezQFiHefbZ5yAQEIAQEBAQEbjz+CX4EPBY4YiFaNQwmOcY4?= =?us-ascii?q?9NiyECxuIcgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,356,1449532800"; d="scan'208";a="230357315" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jan 2016 23:36:36 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u0RNaaSH004346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jan 2016 23:36:36 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u0RNaZlW004380 for ; Wed, 27 Jan 2016 15:36:35 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u0RNaZ8R004379 for tsvwg@ietf.org; Wed, 27 Jan 2016 15:36:35 -0800 Date: Wed, 27 Jan 2016 15:36:35 -0800 From: Toerless Eckert To: tsvwg@ietf.org Message-ID: <20160127233635.GA4023@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 23:36:39 -0000 Are there any drats/RFC that would give me guidance if i wanted to design packet exchanges hop-by-hop between eg: routers/switches, with traffic patterns lets say like a routing protocol. I see even new protocols like Babel run on top of datagram and have all their own retransmission/ultimate-consistency schemes, and i was wondering what opinions TSVWG has about this. Or let me turn this around: I'd rather like to build a protocol that just uses hop-by-hop TCP and not reinvent all the transport aspects that go along with that (including remote adjacencies/tunnels across stupidly bad internet adjacencies with jitter and loss). But the ongoing reality of protocols like this does not seem to indicate that there's any evolving wisdom that this would be a good thing. And then the IOT space says TCP is bad, use CoAP, but then i don't even have messagee exchanges anymore but put would ahve to reinvent it on top of something like PUT/GET primitives... ? *sigh* So, really wondering. Thanks! Toerless From nobody Wed Jan 27 16:55:29 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409D91B39A1 for ; Wed, 27 Jan 2016 16:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S7Eg40Xi1vj for ; Wed, 27 Jan 2016 16:55:27 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 206D11A3BA1 for ; Wed, 27 Jan 2016 16:55:26 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0S0tPmT015635 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 27 Jan 2016 19:55:25 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u0S0tPmT015635 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1453942526; bh=hfu9C61hUiUFIAhqddc2kftjYH4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=G4drXOFCh0Q/Heig9VcwQO5PiE5D3N+P5tpFC23R69B3kRwaFyh5vnVWdqTUZ4zyD btD5VerkmIuk3EXWyk/qNbuE6nbJ5Fqxe1b2HC710gQKLAHuId4QiMGmIlB3hzfY5X k4aUT1WGQndwyb/Dg9CQOJBaahPB/n7Sfx/8LvB8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u0S0tPmT015635 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd54.lss.emc.com (RSA Interceptor) for ; Wed, 27 Jan 2016 19:54:57 -0500 Received: from MXHUB107.corp.emc.com (MXHUB107.corp.emc.com [10.253.50.23]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0S0tAgM019879 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 Jan 2016 19:55:11 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB107.corp.emc.com ([10.253.50.23]) with mapi id 14.03.0266.001; Wed, 27 Jan 2016 19:55:10 -0500 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: Draft status updates Thread-Index: AdFZZolaFRI4Hdg0QZalO9KkKmgIdA== Date: Thu, 28 Jan 2016 00:55:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] Draft status updates X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 00:55:28 -0000 For those who have noticed the recent flurry of draft submissions, here's a= summary of what's going on: 1) draft-ietf-tsvwg-behave-requirements-update-06 Network Address Translation (NAT) Behavioral Requirements Updates This draft has now been submitted to the IESG for publication as a Best Cu= rrent Practice. There's a new writeup in the datatracker if anyone's interested. 2) draft-ietf-tsvwg-circuit-breaker-11 Network Transport Circuit Breakers This draft is now in IETF Last Call for Best Current Practice, through Feb= ruary 9. 3) draft-ietf-tsvwg-gre-in-udp-encap-09 GRE-in-UDP Encapsulation This draft is almost ready for WG Last Call. Lucy will post a message in = the next few days describing the small open items that need WG attention prior to WGLC.= One more revision is expected before WGLC. 4) draft-ietf-tsvwg-rfc5405bis-07 UDP Usage Guidelines WGLC is complete, this draft is waiting on a check against the encapsulati= on draft in RTGWG to make sure that anything that should be said in this draft is included. 5) draft-ietf-tsvwg-rtcweb-qos-12 DSCP and other packet markings for WebRTC QoS Much has been done to align this draft (primarily its terminology) with ot= her WebRTC drafts. WG Last Call should start in the next couple of days. 6) draft-ietf-tsvwg-sctp-failover-15 SCTP-PF: Quick Failover Algorithm in SCTP IETF Last Call is complete - this draft is on the Feb 4 IESG telechat agen= da. Thanks, --David & Gorry (yes ... we've been busy ...) From nobody Thu Jan 28 02:50:45 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5364A1B34EC for ; Thu, 28 Jan 2016 02:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDSJ6UBuDL-z for ; Thu, 28 Jan 2016 02:50:40 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6BD1B34E7 for ; Thu, 28 Jan 2016 02:50:39 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id u0SAoToN001920; Thu, 28 Jan 2016 11:50:34 +0100 From: "Jose Saldana" To: "'Tom Herbert'" References: <20160127165924.23207.45260.idtracker@ietfa.amsl.com> <02c801d15924$c4f4fe60$4edefb20$@unizar.es> In-Reply-To: Date: Thu, 28 Jan 2016 11:50:42 +0100 Message-ID: <011d01d159b9$bf64a140$3e2de3c0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFt3EKAm4Ji/r26Z6jYh6sz8JkFNwJm3x8gApJx2tCfr+qUAA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: Cc: 'tsvwg' Subject: Re: [tsvwg] New Version Notification for draft-saldana-tsvwg-simplemux-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 10:50:44 -0000 Hi Tom, Thanks a lot for your comments. Regarding packet ordering, this would introduce a certain jitter in the = network (some packets will experience more delay than others). However, = the idea is that you should not multiplex packets from a single user, = but from a number of them, so you will be able to send e.g. 30 packets = from different users adding a small delay. We have explored this in some = research papers. See e.g. this one of IEEE Communications Magazine: = http://diec.unizar.es/~jsaldana/personal/yoda_commag_2013.pdf Regarding integration with GUE = (https://tools.ietf.org/html/draft-ietf-nvo3-gue-02), I agree with you: = the idea of Simplemux is that it can be integrated with many = encapsulation methods. In fact, we are currently about to start building = an experimental implementation of LISP+Simplemux. Perhaps integrating = with GUE could also be interesting. BR, Jose > -----Mensaje original----- > De: Tom Herbert [mailto:tom@herbertland.com] > Enviado el: mi=C3=A9rcoles, 27 de enero de 2016 19:48 > Para: Jose Saldana > CC: tsvwg > Asunto: Re: [tsvwg] New Version Notification for = draft-saldana-tsvwg-simplemux- > 04.txt >=20 > On Wed, Jan 27, 2016 at 9:04 AM, Jose Saldana = wrote: > > Hi all, > > > > A new version of the Simplemux draft has been uploaded. > > https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/ > > > > In addition, you can find a research paper explaining it here: > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D7363105 > > > > An implementation (https://github.com/TCM-TF/simplemux) has been = used to > carry out some tests with real traffic, showing significant = improvements: 46% of the > bandwidth can be saved when compressing voice traffic. And the = reduction in terms > of packets per second in an Internet trace can be up to 50%. In = wireless networks, > packet grouping results in a significantly improved use of air time. > > > Hi Jose, >=20 > Have considered the effect this will have on packet ordering (i.e. > will this create rampant OOO packets at a receiver)? You also might = want to look at > implementing this within an existing encapsulation, such as GUE, which = already > provides basic encapsulation features like checksum, flow entropy, and > compatibility with network HW since it is UDP. Although, if this does = become an IP > protocol it would already be compatible with GUE since protocol field = takes an IP > protocol number. >=20 > Thanks, > Tom >=20 > > Best regards, > > > > Jose > > > >> -----Mensaje original----- > >> De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Enviado el: mi=C3=A9rcoles, 27 de enero de 2016 17:59 > >> Para: Jose Saldana > >> Asunto: New Version Notification for > >> draft-saldana-tsvwg-simplemux-04.txt > >> > >> > >> A new version of I-D, draft-saldana-tsvwg-simplemux-04.txt > >> has been successfully submitted by Jose Saldana and posted to the > >> IETF repository. > >> > >> Name: draft-saldana-tsvwg-simplemux > >> Revision: 04 > >> Title: Simplemux. A generic multiplexing protocol > >> Document date: 2016-01-27 > >> Group: Individual Submission > >> Pages: 14 > >> URL: = https://www.ietf.org/internet-drafts/draft-saldana-tsvwg-simplemux- > >> 04.txt > >> Status: = https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/ > >> Htmlized: = https://tools.ietf.org/html/draft-saldana-tsvwg-simplemux-04 > >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-tsvwg-simplemux-04 > >> > >> Abstract: > >> The low efficiency caused by the high amount of small packets = present > >> in the network can be alleviated by means of packet aggregation. > >> There are some situations in which multiplexing a number of = small > >> packets into a bigger one is desirable. For example, a number = of > >> small packets can be sent together between a pair of machines if = they > >> share a common network path. Thus, the traffic profile can be > >> shifted from small to larger packets, reducing the network = overhead > >> and the number of packets per second to be managed by = intermediate > >> routers. > >> > >> This document describes Simplemux, a protocol able to = encapsulate a > >> number of packets belonging to different protocols into a single > >> packet. It includes the "Protocol" field on each multiplexing > >> header, thus allowing the inclusion of a number of packets = belonging > >> to different protocols (multiplexed packets) on a packet of = another > >> protocol (tunneling protocol). > >> > >> In order to reduce the overhead, the size of the multiplexing = headers > >> is kept very low (it may be a single byte when multiplexing = small > >> packets). > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at = tools.ietf.org. > >> > >> The IETF Secretariat > > > > From nobody Thu Jan 28 07:24:42 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FAD1A88E4 for ; Thu, 28 Jan 2016 07:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_9wNn7F1Mrx for ; Thu, 28 Jan 2016 07:24:39 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 8D1D81A88D9 for ; Thu, 28 Jan 2016 07:24:39 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0SFOb96008308 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Jan 2016 10:24:38 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u0SFOb96008308 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1453994678; bh=FvXzK0xA9herz9yqlRU0Bs8nveQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=VrPr/jN+h430k/BBOFqt8vEkpydvxJEXlVMzzVJunrpmBIsqCc+WgpeTOZKFmcZqM iwLpQHNKra5RKe9vQvMG1kjT/khpmDxoJT/MFDHXRklX0xLep6kyphtGbexpClTQkd H4XPY42bZpLYou9sqrbVwNSJT+aQofdKKdODbe+s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u0SFOb96008308 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor) for ; Thu, 28 Jan 2016 10:24:07 -0500 Received: from MXHUB204.corp.emc.com (MXHUB204.corp.emc.com [10.253.68.30]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0SFOLOk032272 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Thu, 28 Jan 2016 10:24:22 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB204.corp.emc.com ([10.253.68.30]) with mapi id 14.03.0266.001; Thu, 28 Jan 2016 10:24:21 -0500 From: "Black, David" To: "Black, David" , "tsvwg@ietf.org" Thread-Topic: 2nd WGLC: NAT Behavior Update draft Thread-Index: AdFJqQ1bFuJHKNuVRoOruze++7bs7gQNkkMA Date: Thu, 28 Jan 2016 15:24:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.124] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] 2nd WGLC: NAT Behavior Update draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:24:41 -0000 It looks like I neglected to inform the list of the outcome of this WGLC, s= o here goes ... There were no comments on the IPR disclosure, hence the conclusion of this = 2nd WGLC is that there is no change to the outcome of the first WGLC, namely to proc= eed with RFC publication of this draft. That publication request has been submitted= . During this 2nd WGLC, we did get an additional review from Dan Wing, which = resulted in some minor editorial changes to the draft. I want to thank Dan for the = review, and the authors for quickly making the associated changes. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > Sent: Thursday, January 07, 2016 7:11 PM > To: tsvwg@ietf.org > Subject: [tsvwg] 2nd WGLC: NAT Behavior Update draft >=20 > Context - on December 21st, 2015, I wrote: >=20 > > And now, for the not-so-good news: > > > > (2) Network Address Translation (NAT) Behavioral Requirements Updates > > draft-ietf-tsvwg-behave-requirements-update-05 > > > > The WGLC is over with no comments, and the draft is in good shape, but = ... > > ... an IPR Disclosure was discovered late in the process (due to a miss= ing > > updated-by relationship in the datatracker - with that relationship in = place, > > the IPR Disclosure is now shown as being on a related draft): > > > > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -tsvwg- > behave-requirements-update > > https://datatracker.ietf.org/ipr/1917/ > > > > It will be necessary to run an additional WGLC on this draft in January= for > > this reason. >=20 > This email announces that additional Working Group Last call. It will ru= n through > midnight US Eastern Time on Saturday January 16 (a week from this coming > Saturday). >=20 > The primary purpose of this 2nd WG Last Call is to determine whether the = results > of > the first WG Last Call (WG supports proceeding with publication of this d= raft) are > affected by the existence of the IPR Disclosure noted above. That said, = other > comments are welcome, and the WG chairs would be very happy to see > additional one > or more additional detailed reviews of this draft. >=20 > Thanks, > --David (tsvwg WG chair) > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Thu Jan 28 07:42:49 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96CA1A8A41 for ; Thu, 28 Jan 2016 07:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqGFtHiwKq1d for ; Thu, 28 Jan 2016 07:42:45 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 B6FEC1A8A45 for ; Thu, 28 Jan 2016 07:42:42 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0SFgfLH022189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Jan 2016 10:42:41 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u0SFgfLH022189 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1453995761; bh=ymhg9kv/gIXWF5z7dRpUVhUKVXk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LmP9J+uQwaS2uJ8xonadu+bxIxrQl62eVjQy8ed6R4YVVuxJySAqyKAW1i21AWtJI L6DhUpNzQWUoQN2Wml37iDfx2aCY1W2HwD8t5ZTklo7aJICcx1eIlp0kM0xmgC+NCM QhkYZ14JitSywClgPLnnV6fLZFgeWxopdJnaDlA4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u0SFgfLH022189 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Thu, 28 Jan 2016 10:42:12 -0500 Received: from MXHUB214.corp.emc.com (MXHUB214.corp.emc.com [10.253.68.84]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u0SFgHVY003709 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Thu, 28 Jan 2016 10:42:17 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.79]) by MXHUB214.corp.emc.com ([10.253.68.84]) with mapi id 14.03.0266.001; Thu, 28 Jan 2016 10:42:17 -0500 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13 Thread-Index: AdFZ4nVTQE/lRchFSuuhhf7QDC5o9w== Date: Thu, 28 Jan 2016 15:42:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.124] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:42:47 -0000 This email announces a TSVWG Working Group Last Call (WGLC) on: DSCP and other packet markings for WebRTC QoS draft-ietf-tsvwg-rtcweb-qos-12 This WGLC will be for about 2 weeks, ending at midnight US Eastern Time on Saturday, February 13. Comments should be sent to the tsvwg@ietf.org list, although purely editorial comments may be sent directly to the author= s at draft-ietf-tsvwg-rtcweb-qos@ietf.org - if doing that, please cc: the WG = chairs at tsvwg-chairs@ietf.org. The WG chairs express our thanks to Michael Tuex= en for recently reviewing the SCTP aspects of this draft. The related transports draft in the rtcweb WG (draft-ietf-rtcweb-transports= -11) has recently been updated for consistency with this TSVWG rtcweb-qos draft, so it's important that only the latest version of that rtcweb-transports dr= aft be consulted for the WGLC on this tsvwg-rtcweb-qos draft. Thanks, --David & Gorry ---------------------------------------------------- David L. Black, Distinguished Engineer EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0=20 ---------------------------------------------------- From nobody Thu Jan 28 07:47:55 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3661A905C for ; Thu, 28 Jan 2016 07:47:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128154754.9808.97072.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 07:47:54 -0800 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:47:54 -0000 Changed milestone "Submit 'Behavioral Requirements Updates'Â’ as a BCP RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/tsvwg/charter/ From nobody Thu Jan 28 15:41:58 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297221B2A91 for ; Thu, 28 Jan 2016 15:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g3QsB54ue1t for ; Thu, 28 Jan 2016 15:41:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684D41B2A90 for ; Thu, 28 Jan 2016 15:41:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHP86899; Thu, 28 Jan 2016 23:41:49 +0000 (GMT) Received: from LHREML705-CAH.china.huawei.com (10.201.5.168) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 28 Jan 2016 23:41:47 +0000 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 28 Jan 2016 23:41:47 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Thu, 28 Jan 2016 15:41:42 -0800 From: Lucy yong To: "tsvwg@ietf.org" , "draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-09.txt Thread-Index: AQHRWKUJ8L1krBuKeEiW5S1S8J/PD58RjtMA Date: Thu, 28 Jan 2016 23:41:41 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57239942@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56AAA73E.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: db0148552274d9984679310fa229ecf6 Archived-At: Cc: "gorry@erg.abdn.ac.uk" Subject: [tsvwg] FW: I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 23:41:56 -0000 SGkgQWxsLA0KDQpUaGlzIHZlcnNpb24gaGFzIHF1aXRlIGVkaXRpbmcgY2hhbmdlcyB3aGljaCB3 ZXJlIHN1Z2dlc3RlZCBieSB0aGUgY2hhaXIgKERhdmlkIEJsYWNrKSBhbmQgYmV0dGVyIGFsaWdu cyB3aXRoIDU0MDViaXMuIFRoZSBkcmFmdCBzcGVjaWZpZXMgZ3JlL3VkcCB0dW5uZWwgdXNhZ2Ug aW4gdHdvIGVudmlyb25tZW50czogZ2VuZXJhbCBJbnRlcm5ldCBhbmQgd2VsbC1tYW5hZ2VkIG9w ZXJhdG9yIG5ldHdvcmsgKFdNT04pLCBhbmQgbmFtZXMgdGhlIHR3byBhcHBsaWNhdGlvbnMgYXMg RGVmYXVsdCBHUkUtaW4tVURQIFR1bm5lbCBhbmQgV01PTiBHUkUtaW4tVURQIFR1bm5lbCwgcmVz cGVjdGl2ZWx5LiBJdCBzcGVjaWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgZWFjaCB0eXBlIG9m IHR1bm5lbHMuIA0KDQpUaGUgZHJhZnQgZnVydGhlciBkZWZpbmVzIGEgd2VsbC1tYW5hZ2VkIG9w ZXJhdG9yIG5ldHdvcmsgYXMgb2YgYW4gSVAgbmV0d29yayB0aGF0IGlzIHRyYWZmaWMtZW5naW5l ZXJlZCBhbmQvb3Igb3RoZXJ3aXNlDQptYW5hZ2VkIChlLmcuLCB2aWEgdXNlIG9mIHRyYWZmaWMg cmF0ZSBsaW1pdGVycykgdG8gYXZvaWQgY29uZ2VzdGlvbi4gVW5kZXIgYSB3ZWxsLW1hbmFnZWQg b3BlcmF0b3IgbmV0d29yaywgYSBncmUvdWRwIHR1bm5lbCBpcyBsZXNzIHJlc3RyaWN0aXZlIGNv bXBhcmluZyB0byBiZSB1c2VkIGluIGdlbmVyYWwgSW50ZXJuZXQuDQoNClRoZSBkcmFmdCBoYXMg YWRkcmVzc2VkIGFsbCBjb21tZW50cyBmcm9tIHRoZSBtZWV0aW5ncyBhbmQgbWFpbHMuIE9uZSBj YXZpYXIgaXM6DQoNClVzZSBvZiBVRFAgc3JjIHBvcnQgZm9yIGVudHJvcHkgbWF5IGltcGFjdCB3 aXRoIG1pZGRsZWJveCBiZWhhdmlvciAoc2VlIGRyYWZ0KS4gVG8gYWRkcmVzcyB0aGlzIGNvbmZs aWN0LCB0aGUgZHJhZnQgcmVjb21tZW5kczoNCg0KICAgSWYgYSBHUkUtaW4tVURQIHR1bm5lbCBp cyBleHBlY3RlZCB0byBwYXNzIGEgbWlkZGxlYm94LCB0byBhdm9pZCB0aGUNCiAgIGltcGFjdCwg dGhlIG9wZXJhdG9yIGVpdGhlciBkaXNhYmxlIFVEUCBzb3VyY2UgcG9ydCBmb3IgZW50cm9weSBv cg0KICAgY29uZmlndXJlIHRoZSBtaWRkbGVib3ggdG8gZGVhbCB3aXRoIHRoZSBVRFAgc291cmNl IHBvcnQgdmFyaWF0aW9uLg0KDQpUaGlzIG9wZXJhdGlvbiBjYW4gYmUgZG9uZSBlYXNpbHkgZm9y IGEgd2VsbC1tYW5hZ2VkIG9wZXJhdG9yIG5ldHdvcmsuIE1heWJlIGhhcmQgaW4gZ2VuZXJhbCBJ bnRlcm5ldC4gTGlrZSB0byBnZXQgdGhlIGNvbW11bml0eSBmZWVkYmFjayBpZiB0aGlzIHdpbGwg YmUgYSBjb25jZXJuIG9yIG5vdC4gSWYgeWVzLCB3aGF0IGlzIHRoZSBiZXR0ZXIgYWx0ZXJuYXRp dmU/DQoNCldlIGxpa2UgdG8gdGhhbmsgRGF2aWQgQmxhY2sgYSBsb3QgZm9yIHRoZSBkZXRhaWwg cmV2aWV3IGFuZCBzdWdnZXN0aW9ucy4gDQoNClRoYW5rcywNCkx1Y3kNCg0KDQoNCg0KDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpT ZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI2LCAyMDE2IDc6NDkgUE0NClRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNCkNjOiB0c3Z3Z0BpZXRmLm9yZw0KU3ViamVjdDogW3RzdndnXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMDkudHh0DQoNCg0KQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRyYW5zcG9y dCBBcmVhIFdvcmtpbmcgR3JvdXAgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAg ICBUaXRsZSAgICAgICAgICAgOiBHUkUtaW4tVURQIEVuY2Fwc3VsYXRpb24NCiAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogRWR3YXJkIENyYWJiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBM dWN5IFlvbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgWGlhb2h1IFh1DQogICAgICAgICAg ICAgICAgICAgICAgICAgIFRvbSBIZXJiZXJ0DQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi10c3Z3Zy1ncmUtaW4tdWRwLWVuY2FwLTA5LnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDI0DQoJ RGF0ZSAgICAgICAgICAgIDogMjAxNi0wMS0yNg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIGEgbWV0aG9kIG9mIGVuY2Fwc3VsYXRpbmcgbmV0d29yayBwcm90b2NvbA0K ICAgcGFja2V0cyB3aXRoaW4gR1JFIGFuZCBVRFAgaGVhZGVycy4gSW4gdGhpcyBlbmNhcHN1bGF0 aW9uLCB0aGUNCiAgIHNvdXJjZSBVRFAgcG9ydCBjYW4gYmUgdXNlZCBhcyBhbiBlbnRyb3B5IGZp ZWxkIGZvciBwdXJwb3NlcyBvZiBsb2FkDQogICBiYWxhbmNpbmcsIHdoaWxlIHRoZSBwcm90b2Nv bCBvZiB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldCBpbiB0aGUgR1JFDQogICBwYXlsb2FkIGlzIGlk ZW50aWZpZWQgYnkgdGhlIEdSRSBQcm90b2NvbCBUeXBlLiBUaGlzIGRvY3VtZW50DQogICBzcGVj aWZpZXMgcmVxdWlyZW1lbnRzIGZvciB0d28gYXBwbGljYWJpbGl0eSBzY2VuYXJpb3MgZm9yIHRo aXMNCiAgIGVuY2Fwc3VsYXRpb246ICgxKSBHZW5lcmFsIEludGVybmV0IGFuZCAoMikgd2VsbC1t YW5hZ2VkIG9wZXJhdG9yDQogICBuZXR3b3JrczsgbGVzcyByZXN0cmljdGl2ZSByZXF1aXJlbWVu dHMgYXBwbHkgdG8gdGhlIGxhdHRlciBzY2VuYXJpbw0KICAgYnkgY29tcGFyaXNvbiB0byB0aGUg Zm9ybWVyLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3 Zy1ncmUtaW4tdWRwLWVuY2FwLw0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2 YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndn LWdyZS1pbi11ZHAtZW5jYXAtMDkNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC0wOQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From nobody Thu Jan 28 16:48:24 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD6D1B3005 for ; Thu, 28 Jan 2016 16:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPWFGQTdyGAU for ; Thu, 28 Jan 2016 16:48:22 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DCF1B3004 for ; Thu, 28 Jan 2016 16:48:22 -0800 (PST) Received: from [128.9.184.187] ([128.9.184.187]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u0T0lpKD003269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jan 2016 16:47:53 -0800 (PST) To: Toerless Eckert , tsvwg@ietf.org References: <20160127233635.GA4023@cisco.com> From: Joe Touch Message-ID: <56AAB6B6.2040306@isi.edu> Date: Thu, 28 Jan 2016 16:47:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160127233635.GA4023@cisco.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: Cc: touch@isi.edu Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 00:48:23 -0000 On 1/27/2016 3:36 PM, Toerless Eckert wrote: > Or let me turn this around: I'd rather like to build a protocol that > just uses hop-by-hop TCP and not reinvent all the transport aspects > that go along with that (including remote adjacencies/tunnels across stupidly > bad internet adjacencies with jitter and loss). Isn't that basically e-mail routing? (which, IMO, is a very reasonable replacement for the bulk of the mechanisms underlying DTN). Joe From nobody Thu Jan 28 20:26:16 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6201B38A4 for ; Thu, 28 Jan 2016 20:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAH_yGyLRswk for ; Thu, 28 Jan 2016 20:26:06 -0800 (PST) Received: from nm42-vm4.bullet.mail.gq1.yahoo.com (nm42-vm4.bullet.mail.gq1.yahoo.com [67.195.87.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2B61B389F for ; Thu, 28 Jan 2016 20:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1454041565; bh=SSAnGtzZVjIl2PlEsgkD7689kWMSFKimjP79YJzzqcQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=QlW6yELSM5+kBGUKn33hKr0gHQg0VMBFZMBJulVvrejs8kmq5GDbgp1B4m1mmjm3N2rucTCr1EoNrJ004OyX6GYQcwi6oEp5ntIYj4BqOEb4Y1pEEI9gD96KdXOdfaRM4TqMKSyFNrOXzuHXw1jpB6StaqlHhfTsin70QiQ+k4RqEXBKN1DG09Uipr791WLkhvbobLPJ4sEC/7GSGECoNBd+LVWfWpul153yBOpkA5Q0LL3UjU1mXFLvboeuj74euA0T18vPKyIfa7SRjsINxNMIJRJgHklWpwELJls2Y403e86cxKdgNXxVMr2jOhQ2FRBORZhKtYpeRuwW3A+nMg== Received: from [127.0.0.1] by nm42.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jan 2016 04:26:05 -0000 Received: from [98.137.12.55] by nm42.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jan 2016 04:23:12 -0000 Received: from [212.82.98.50] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jan 2016 04:23:11 -0000 Received: from [212.82.98.81] by tm3.bullet.mail.ir2.yahoo.com with NNFMP; 29 Jan 2016 04:23:11 -0000 Received: from [127.0.0.1] by omp1018.mail.ir2.yahoo.com with NNFMP; 29 Jan 2016 04:23:11 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 249563.15563.bm@omp1018.mail.ir2.yahoo.com X-YMail-OSG: kFUe.GYVM1mWOof1COJuhvmzZpT5P8by9qRT4gx7Zxmu_RRHhVPQxdG5Dx3Y4ie 3A_5_2c21g08jfMATdpkReJm6HhQaADfT73H8TZFyLna7aNX8oG7ivnxFZt5gsATl6jOKJEn4pOL 563kCpFgyaM8QRa1eYAKlNCCRQ6gtA8cQ.a17YNhNsgDNKBMyNMW42gyIT9l9jWVlA1BBm4KGubZ Nkd9.5P1W98bh4UuXiTsQ8dX.TsND5ZiPw.OZznYkQVrWEjB3DLHphpU0auSlPPK8npoLbM.gN6D R95_Vja1YRVupLHIxzb1_15Z8HTGMVK0chlurWc_RJ8UHVkWknly2ULbHqWK9d2R.aFNL6fDHE9Z GtMgz4xxwa77P6E.7mPpfsOvVW12qTBfYvW.uQyOODBkvs75SXvG9OOpWC.4m0U_3zYb7k0YZdQU QDScKoUMNoB7aizQtM57ba.6wzxyNQXmQ43GDtJcvWUybpzG2_KgM2OBOboGXKX3fDOj4dSQrsJ_ MF2_Djh._TjGyClqB_x4FwdsSW1X3uDqJhtv9Ww-- Received: by 212.82.98.120; Fri, 29 Jan 2016 04:23:10 +0000 Date: Fri, 29 Jan 2016 04:23:10 +0000 (UTC) From: To: Joe Touch , Toerless Eckert , "tsvwg@ietf.org" Message-ID: <1509081676.2987988.1454041390230.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <56AAB6B6.2040306@isi.edu> References: <56AAB6B6.2040306@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2987986_769837834.1454041390223" Archived-At: Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lloyd.wood@yahoo.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 04:26:11 -0000 ------=_Part_2987986_769837834.1454041390223 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We attempted to leverage hop-by-hop TCP, and avoid reinventing=C2=A0all the= transport aspects, with HTTP-DTN: http://http-dtn.sourceforge.net/ (The DTN bundling crowd wasn't interested, which suggests it's a good idea.= ..)=C2=A0Lloyd Woodhttp://sat-net.com/L.Wood/dtn =20 From: Joe Touch To: Toerless Eckert ; tsvwg@ietf.org=20 Cc: touch@isi.edu Sent: Friday, 29 January 2016, 11:47 Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols= " =20 On 1/27/2016 3:36 PM, Toerless Eckert wrote: > Or let me turn this around: I'd rather like to build a protocol that > just uses hop-by-hop TCP and not reinvent all the transport aspects > that go along with that (including remote adjacencies/tunnels across stup= idly > bad internet adjacencies with jitter and loss). Isn't that basically e-mail routing? (which, IMO, is a very reasonable replacement for the bulk of the mechanisms underlying DTN). Joe ------=_Part_2987986_769837834.1454041390223 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We attempted to leverage hop-by-hop TCP, and avoid reinve= nting all the transport aspects, with HTTP-DTN:

http://http-dtn.sourceforge.net/<= /div>

(The DTN bundling crowd= wasn't interested, which suggests it's a good idea...)
 
Lloyd Wood
http://sat-net.com/L.Wood/dt= n



= From: Joe Touch <touch@isi.= edu>
To: Toerless E= ckert <eckert@cisco.com>; tsvwg@ietf.org
Cc: touch@isi.edu
Sent: Friday, 29 January 2016, 11:47
Subject: Re: [tsvwg] : Q: transport rec= ommendations for "routing protocols"


<= div class=3D"yqt7938635899" id=3D"yqtfd08013">
On 1/27/20= 16 3:36 PM, Toerless Eckert wrote:
> Or let me turn th= is around: I'd rather like to build a protocol that
> = just uses hop-by-hop TCP and not reinvent all the transport aspects
> that go along with that (including remote adjacencies/tunne= ls across stupidly
> bad internet adjacencies with jit= ter and loss).


Isn't that basica= lly e-mail routing?

(which, IMO, is a = very reasonable replacement for the bulk of the
mechanism= s underlying DTN).

Joe


=

------=_Part_2987986_769837834.1454041390223-- From nobody Thu Jan 28 21:27:40 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E7F1B3DFC for ; Thu, 28 Jan 2016 21:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3bW1rZr1P8u for ; Thu, 28 Jan 2016 21:27:32 -0800 (PST) Received: from nm32-vm0.bullet.mail.ne1.yahoo.com (nm32-vm0.bullet.mail.ne1.yahoo.com [98.138.229.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F6D1B3DFB for ; Thu, 28 Jan 2016 21:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1454045251; bh=DyjokSXUor9lO4wzmuNQV8XEUI2iN2x+/sUhFD5BLYs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=gGRCIAgQ5/sF6tdnnTFMM6DRuKqVRzOYJuqqOLfAsp29DyO6tyivKbsScYRhAsiMfZRfD+uNztD8nSPdnfNLSt47qSMgZrwyI8/I8o7RxWk2TJsMadJxubSO1+pIzYKzOhGQ8AV+B074WqE3ql6BYmKhOw0tNUY+9ThHEB68p1D9zH3VXL9kSh0zNex5B3Txr0iwVk0q+zs8LT7+gpJe3lXZTwVrcl3v0nZE4v4Gu7+JkLDZgTYEEGqZ9ms+NIa508IBDXIrE6NRKbXI58o2kz9i5xBSQWE89lxN92LpilB7P4j51VXh8Rlw+97RrKSddw0Uam6YNiQoG70bCzufrA== Received: from [127.0.0.1] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2016 05:27:31 -0000 Received: from [98.138.100.117] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2016 05:24:31 -0000 Received: from [212.82.98.50] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2016 05:24:31 -0000 Received: from [212.82.98.113] by tm3.bullet.mail.ir2.yahoo.com with NNFMP; 29 Jan 2016 05:24:31 -0000 Received: from [127.0.0.1] by omp1050.mail.ir2.yahoo.com with NNFMP; 29 Jan 2016 05:24:31 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 433124.76555.bm@omp1050.mail.ir2.yahoo.com X-YMail-OSG: JA_eYOoVM1mbUSDmOyAtxNL5hvXOXlyMs.g17A0xP7TaOxkPh6qDuaCBbzJ3dzd cSjqZtJGOUf3aN4r1H8E66xSGUPbujqpOA2qRUXez_UGs0byhQkamvfs9eHmoGtyOYeTk4ejr6Ji _PoE7cBbgz_QpdquYGZYdSM2oylluvXMl4OtcM29YvNjJV7LMohEnxwBKRByinfJeMwfnypUpaca aKDmw27WzRY_ijJB5lIad_.JDw6ZDrdj3kRLdfd2IV7XB51y4kdcBR.R8F5bvChc89wvCw8P1lyq ZITLfYBp3ooXlFfOlx96xzQXPfMgAwHS8N7KYgSu10HRKMuXrfvPKNoGd.xuCJ67CrIecBwyRGHE 0uiXM7bLhgunjXYoScVuZnGJa9UCIIVFlsaR8RVwG4nSiCTKtx2Rjv7ZEVz8ULM6tuNwYPX0Wolx yoVQnFUQUPj7VozrL4Y3fePN4BoQK_STMu7FTUIXIfcV8yaUrii5gVBkFu6R9Je58iQWZmfpu_Pm yr34Ya9HTwRmf0vyTtM2j8NQ5bgRoDzA5kSCHxQ-- Received: by 217.12.9.11; Fri, 29 Jan 2016 05:24:31 +0000 Date: Fri, 29 Jan 2016 05:24:26 +0000 (UTC) From: To: Toerless Eckert , "tsvwg@ietf.org" Message-ID: <911516196.2957832.1454045066713.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20160127233635.GA4023@cisco.com> References: <20160127233635.GA4023@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lloyd.wood@yahoo.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 05:27:34 -0000 > And then the IOT space says TCP is bad, use CoAP, but then i don't even > have messagee exchanges anymore but put would ahve to reinvent it on top > of something like PUT/GET primitives... ? *sigh* I know. That's why we came up with http-dtn. http://http-dtn.sourceforge.net/ Then you could do RESTful exchanges, M2M with SOAP etc., on top of HTTP/TCP. Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood ________________________________ From: Toerless Eckert To: tsvwg@ietf.org Sent: Thursday, 28 January 2016, 10:36 Subject: [tsvwg] : Q: transport recommendations for "routing protocols" Are there any drats/RFC that would give me guidance if i wanted to design packet exchanges hop-by-hop between eg: routers/switches, with traffic patterns lets say like a routing protocol. I see even new protocols like Babel run on top of datagram and have all their own retransmission/ultimate-consistency schemes, and i was wondering what opinions TSVWG has about this. Or let me turn this around: I'd rather like to build a protocol that just uses hop-by-hop TCP and not reinvent all the transport aspects that go along with that (including remote adjacencies/tunnels across stupidly bad internet adjacencies with jitter and loss). But the ongoing reality of protocols like this does not seem to indicate that there's any evolving wisdom that this would be a good thing. And then the IOT space says TCP is bad, use CoAP, but then i don't even have messagee exchanges anymore but put would ahve to reinvent it on top of something like PUT/GET primitives... ? *sigh* So, really wondering. Thanks! Toerless From nobody Fri Jan 29 04:44:49 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF641A906E for ; Fri, 29 Jan 2016 04:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnYk5BgICLic for ; Fri, 29 Jan 2016 04:44:45 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CCF1A9044 for ; Fri, 29 Jan 2016 04:44:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,364,1449561600"; d="asc'?scan'208";a="93817857" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 29 Jan 2016 04:39:40 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 29 Jan 2016 04:39:40 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::78c4:b507:6e5a:d63c%21]) with mapi id 15.00.1130.005; Fri, 29 Jan 2016 04:39:40 -0800 From: "Eggert, Lars" To: Toerless Eckert Thread-Topic: [tsvwg] : Q: transport recommendations for "routing protocols" Thread-Index: AQHRWVuX4PEP9WXGmkiiXl0g+vTqKp8S96AA Date: Fri, 29 Jan 2016 12:39:39 +0000 Message-ID: References: <20160127233635.GA4023@cisco.com> In-Reply-To: <20160127233635.GA4023@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_2DE0476F-F257-4FC6-938B-85B0A002FA48"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 12:44:46 -0000 --Apple-Mail=_2DE0476F-F257-4FC6-938B-85B0A002FA48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-01-28, at 0:36, Toerless Eckert wrote: >=20 > Are there any drats/RFC that would give me guidance if i wanted to = design > packet exchanges hop-by-hop between eg: routers/switches, with traffic > patterns lets say like a routing protocol. >=20 > I see even new protocols like Babel run on top of datagram and have > all their own retransmission/ultimate-consistency schemes, and i was > wondering what opinions TSVWG has about this. RFC5405 and 5405bis (which is past WGLC) It focuses on UDP, but that obviously generalizes mostly to arbitrary = datagram communication. 5405bis also now discusses multicast. Lars --Apple-Mail=_2DE0476F-F257-4FC6-938B-85B0A002FA48 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWq12LAAoJEFS1wwm/cMFXQKoQAIKnjbWEN2TiwZGIa149PsLK PGsP0RqgV2/R3T1BtiEnQsSMavk7NgXMt/rKx5iX6EvsNQ0QuBFe4OcFOQAGIxff 2wprEk6wjlXqCiogkFb1pTIZjTTFbpb0VHiPvfipgmvV+XHotquTdxDEFLazila6 UsshbQ22u/0um2zw6ewQer6xJZAvqhMyOBNjTiqcV+KbQb/KcYrf4ZC20yz8Ks9c regeZuIPcgqhSrlGYoax8kQgxuSHT0VdWiotx8S/IYlaj6QIrxE4TO7DYckZY1Wu X6um19noimSDKqZAxovJadcKcA7I8sASTTWWuuRYpxJf9RcRLCZJMTlz10bgfKr4 p/Ztiywn1TerzZd+seBj5yWPJy2A2NNcbfLE8z4jiwkdbRCIFGoUZb975dS8Dw0b hOJR5miCPx44eVyckZuM4XC6vVv39utniyLRCIpK70JYLnuhM/GTeDUksPg7szTL yBzxrGqgCeSzgH/V9N1OvzFdcmkmS0eYZ9Tbf8E+Ga1+UBCRem0539kRJIkIcriO UDYGk7NFQ+3OmXj51BItkUWHuQqHw2GJDviNl9h2JH9khSbXBEfLrrCsxSyFF9Ce 8OLZT2AK7fXSEsIWkOnlEFBuOJBPhjYgpDlXBQAcnCyvx4p0cnkjePtED6PD/mds 6qiQm5JoCD6tAn51RnV+ =fZdf -----END PGP SIGNATURE----- --Apple-Mail=_2DE0476F-F257-4FC6-938B-85B0A002FA48-- From nobody Fri Jan 29 16:43:47 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7EE1B29FE for ; Fri, 29 Jan 2016 16:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saUBHngr-UU7 for ; Fri, 29 Jan 2016 16:43:44 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAC21B29FC for ; Fri, 29 Jan 2016 16:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2050; q=dns/txt; s=iport; t=1454114624; x=1455324224; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wMvX7RniMGLm52Z9o1oBkZxHMcZldW2rGIL7xThOHhY=; b=gTTttMYQYs4eoJez7qoY2jHCLXI2obAdY98ulD0BAgCoRWU1YUi79FVW 41zOAqY6H9e/yLjlPiosL2z7eEoHpV6GtVlkDMNQ9MjHKHSD4Y7AkTKQy RzBVOVV05yNS0PK2waEK35x6kCFbEDaPH0lbYv3Mr14fja8WoGfljDGl1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQBZBqxW/49dJa1egzqBP4hYsTYBD?= =?us-ascii?q?YFjhg8CgTA4FAEBAQEBAQGBCoRCAQEEOj8QCxgJJQ8FSRMZiALAVgEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBARWKRIddgQ8FjhiIVo1CCYFbh2eFL4psg1EeAQFChA0bL?= =?us-ascii?q?oh9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,367,1449532800"; d="scan'208";a="72126884" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2016 00:43:43 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0U0hg8m020929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2016 00:43:43 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u0U0hgco023578; Fri, 29 Jan 2016 16:43:42 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u0U0hfh1023577; Fri, 29 Jan 2016 16:43:41 -0800 Date: Fri, 29 Jan 2016 16:43:41 -0800 From: Toerless Eckert To: "Eggert, Lars" Message-ID: <20160130004341.GA23065@cisco.com> References: <20160127233635.GA4023@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 00:43:45 -0000 Thanks Lars. I was aware of those documents. I guess everybody can read different things between the lines of this document. I for once read it in a way: Thanks for reading this UDP document. You thought you want to do UDP in your protocol/app because you think it simplifies life. Well, let us tell you all the things you really need to do that TCP is already doing for you anyhow, so building something on UDP is by far not as easy as you hoped unless you fail to comply with these requirements. (reading for unicast only of course ;-) But i am past this point. I was hoping there is some RFC document that even say: Do not bother with UDP, just use TCP, there is nothing bad about it. Is there any ? IOT folks for once still seem to claim that you can build significantly more lightweight protocol stacks over UDP than TCP. How true is that ? How small would a device have to be so that i would need to start worrying about TCP as a choice. I'd be happy too if the recommendation was SCTP Maybe better ? My requirements are so lame that i can't see how any of its improvements would make a difference. But i haven't gotten a good review if SCTP could be more lightweight even than TCP. Cheers Toerless On Fri, Jan 29, 2016 at 12:39:39PM +0000, Eggert, Lars wrote: > On 2016-01-28, at 0:36, Toerless Eckert wrote: > > > > Are there any drats/RFC that would give me guidance if i wanted to design > > packet exchanges hop-by-hop between eg: routers/switches, with traffic > > patterns lets say like a routing protocol. > > > > I see even new protocols like Babel run on top of datagram and have > > all their own retransmission/ultimate-consistency schemes, and i was > > wondering what opinions TSVWG has about this. > > RFC5405 and 5405bis (which is past WGLC) > > It focuses on UDP, but that obviously generalizes mostly to arbitrary datagram communication. 5405bis also now discusses multicast. > > Lars -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Jan 29 18:33:24 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D46E1B2E74 for ; Fri, 29 Jan 2016 18:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPZVrtHWUjyj for ; Fri, 29 Jan 2016 18:33:21 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A270A1B2E73 for ; Fri, 29 Jan 2016 18:33:21 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id cy9so50502072pac.0 for ; Fri, 29 Jan 2016 18:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XKbdoviEKPrPMEGQN/DNT7SR15tZ50LCsYEF9zJXcw4=; b=uxaknt21JCbzjul2eVFyVTCvNPEbXJ7/zIusJmsQql88rZV0QtF1o19AEKxV6NbYpU aXgz7IMOMxxaRLXzpfzgnx4hKVXmSQPIjloYFraThKrpkhXZ4Ov8dIvRbgpakPBNR969 Hh7+pXCa+0XdGBllOg21LUYY4M1AYqWVESROIAip6hB3mR+NmjPB30Tfuu+aRWeixVGo 91CdRBlkMuCcseANFzY5nNcb1OGLqI+kru0t0YjavgeRxZreG5xpAJfaHQttuZ3tqrLe hgBnaae3NT/lVZzDxCO7byArcTSHixF2VvdaANaYhT8eyolG5VSWLMD5SaSvBj5Nlx95 EVbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XKbdoviEKPrPMEGQN/DNT7SR15tZ50LCsYEF9zJXcw4=; b=TllewOafg4eyL/DvB0Q5AnWOuKP9iUQEeWAVKgvmW8XkN8XM6wCW/tBx6igPvc3S2M LyJ8nQpDOMavaVQLJJ41SB3mMEVJJwIpy++KTPFMEcMX7S7iUVsxGjLRID0CHzjGsbCX YQIQI5E6B7zt4TheL5tmn635DpSRZSa60URktaUWcZkw05a8wFVNNdK2TD/wQ3TpPo5G O7hz4gZyLUO0GdflM4GNqSFv6aRBAOlk47gL6D0VNeikVf6fPxKbP4FpUY009ayy3ypA uNWSEj5TTufWOVbAeOthOsi9RUZix/QURx8Ih0t8V8168VpC3vWEspKrdP7YZZJr00eL /ZnA== X-Gm-Message-State: AG10YOTpr6nTg+BEJOfns8r3fvRufI9KBFuvVhmxj1j+eD9oakAoYTqAXZ6EHDQsjEEIWQ== X-Received: by 10.66.101.3 with SMTP id fc3mr18669361pab.2.1454121201233; Fri, 29 Jan 2016 18:33:21 -0800 (PST) Received: from ?IPv6:2406:e007:7d4b:1:28cc:dc4c:9703:6781? ([2406:e007:7d4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id xa9sm26380395pab.44.2016.01.29.18.33.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 18:33:19 -0800 (PST) To: Toerless Eckert , "Eggert, Lars" References: <20160127233635.GA4023@cisco.com> <20160130004341.GA23065@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56AC20FA.9000500@gmail.com> Date: Sat, 30 Jan 2016 15:33:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160130004341.GA23065@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 02:33:23 -0000 On 30/01/2016 13:43, Toerless Eckert wrote: > Thanks Lars. I was aware of those documents. > > I guess everybody can read different things between the lines of > this document. I for once read it in a way: > > Thanks for reading this UDP document. You thought you want to > do UDP in your protocol/app because you think it simplifies > life. Well, let us tell you all the things you really need to do > that TCP is already doing for you anyhow, so building something > on UDP is by far not as easy as you hoped unless you fail to > comply with these requirements. (reading for unicast only of course ;-) > > But i am past this point. I was hoping there is some RFC document > that even say: Do not bother with UDP, just use TCP, there is nothing > bad about it. Is there any ? IOT folks for once still seem to claim > that you can build significantly more lightweight protocol stacks over > UDP than TCP. How true is that ? How small would a device have to be > so that i would need to start worrying about TCP as a choice. I dunno. I just had to worry about this choice in some prototype code, and to think about all the things I'd have to code to deal with UDP. The answer was: too many for my poor little head, and why bother? If somebody can provide a userland package that does for me what SOCK_STREAM does, that would be fine. But I do not want to know anything about checksums, out-of-order packets, lost packets, retransmission, fragmentation, or reassembly. > I'd be happy too if the recommendation was SCTP Maybe better ? My > requirements are so lame that i can't see how any of its improvements would > make a difference. But i haven't gotten a good review if SCTP could be more > lightweight even than TCP. If you want real robustness, why not MPTCP? Brian > > Cheers > Toerless > > On Fri, Jan 29, 2016 at 12:39:39PM +0000, Eggert, Lars wrote: >> On 2016-01-28, at 0:36, Toerless Eckert wrote: >>> >>> Are there any drats/RFC that would give me guidance if i wanted to design >>> packet exchanges hop-by-hop between eg: routers/switches, with traffic >>> patterns lets say like a routing protocol. >>> >>> I see even new protocols like Babel run on top of datagram and have >>> all their own retransmission/ultimate-consistency schemes, and i was >>> wondering what opinions TSVWG has about this. >> >> RFC5405 and 5405bis (which is past WGLC) >> >> It focuses on UDP, but that obviously generalizes mostly to arbitrary datagram communication. 5405bis also now discusses multicast. >> >> Lars > > > From nobody Fri Jan 29 22:11:26 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20A51A8861 for ; Fri, 29 Jan 2016 22:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqliI2qwhj7B for ; Fri, 29 Jan 2016 22:11:24 -0800 (PST) Received: from nm50-vm1.bullet.mail.gq1.yahoo.com (nm50-vm1.bullet.mail.gq1.yahoo.com [67.195.87.241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C85D1A7015 for ; Fri, 29 Jan 2016 22:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1454134283; bh=VxpeouyTNRf+SiYxSS8LTF5SoTIzoMpdboI0lwj0rf8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=ATqYJP4rx9JYWau4mRPdwrrGbqAGpAoTo11ViKPImT5kNCTrfsZNvgjHqfy59i93oVd8CdxbDUTQ2lOQtS28VijhfjFmdUNGU2dA7v5LYGUJrTko6tLELIivA3JvjXoZwyhmI2bb4f/D4uePGMjkDBQY7DnNPVXlgVxVw0zpvE0ZVL24qbBLBSH9lTRZ83H6UGtK/NX8Tp4d1ImmjnjVqr34Qau42xiZxgHoh+Vbi/h/5eG0TvOSTVEKXHJrJN0Ee006UdA1gC17gVC4xBXCj7q24Z4GvIlYh5ITUv0absq66whpTMb6b5K49YpoZRJWk8tSdHtVY7BGLbPWxmIEOA== Received: from [127.0.0.1] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jan 2016 06:11:23 -0000 Received: from [98.137.12.55] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jan 2016 06:08:22 -0000 Received: from [212.82.98.55] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jan 2016 06:08:22 -0000 Received: from [212.82.98.108] by tm8.bullet.mail.ir2.yahoo.com with NNFMP; 30 Jan 2016 06:08:22 -0000 Received: from [127.0.0.1] by omp1045.mail.ir2.yahoo.com with NNFMP; 30 Jan 2016 06:08:22 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 161667.27411.bm@omp1045.mail.ir2.yahoo.com X-YMail-OSG: Wf6wXCkVM1kHyzUZQpzShr6NOZqD1dH939VilodpgZC8NkxzL6lJ9F3Xy4OMzjj 7Lx7cUtSna5dEVMlvZutWMUZK0LFeB92ZC9uQGVwPuQ1m1WGsFPhdKW6fgoKACCXnMT5blJ0gqZs OrKHY.qi1UET29nU45nFe9A3cKDmm2mKAFtO1tCqjWyhGIIGOaMRPSMGMXi_OjW6zaAXSEaZNZxe DyS1puS6aH.yHX5JOhKV3Izep6UNR7OTf.1JYbnZj4W7zqOskT6UC1v396FVcKhuKsSpUdHo6j.h 8W9bC9S9cpZRp5gMEy2wXQ63mAwXGczEe7tGjkMM1RgSvoLjLEVrgz9M0lGrpREmsVyGXJcbYZzQ AfESKtBZw4_DktO_mcnk5mmehDMCzH00ysfLfRdAoQ6S3xg_TcGAvswllWRzAFy_dGfk1uvVLfjT 2Spbog6tJ_AKPjS4mEGOX8667BK6r5pcyAa_6W1SdKEXeSiNbH7Oo_w.s1HMnRCGr2lqoWBNvQIT rL6kBqfFvNse9sxP4G0WT2as_CYwPIFSFNiiO Received: by 212.82.98.115; Sat, 30 Jan 2016 06:08:21 +0000 Date: Sat, 30 Jan 2016 06:08:21 +0000 (UTC) From: To: Toerless Eckert , Tsvwg IETF List Message-ID: <1053519652.3754180.1454134101081.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20160130004737.GB23065@cisco.com> References: <20160130004737.GB23065@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lloyd.wood@yahoo.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 06:11:25 -0000 To me, "message exchange" is at a higher layer than exchanging binary frames. It's XML interaction or better. If I understand you right, you want your own messaging, but you don't want to have to reinvent transport and reliable message delivery. But you'll still have to reinvent the messaging stack above that. Good luck with that. CoAP translates to http rather like WAP did, with binary substitution and proxying to http; limited binary http equivalence is of limited use. Adopting http as much as possible makes more sense to me longterm. Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood ----- Original Message ----- From: Toerless Eckert To: lloyd.wood@yahoo.co.uk Sent: Saturday, 30 January 2016, 11:47 Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" Thanks, Lloyd, but i was rather trying to avoid some undesired layer on top of TCP/SCTP. Rather continue my own choice of (reliable) message exchanges. Maybe i do not understand well why i need to be interested in http-dtn... Can you maybe rephrase ? Cheers Toerless On Fri, Jan 29, 2016 at 05:24:26AM +0000, lloyd.wood@yahoo.co.uk wrote: > > And then the IOT space says TCP is bad, use CoAP, but then i don't even > > have messagee exchanges anymore but put would ahve to reinvent it on top > > of something like PUT/GET primitives... ? *sigh* > > I know. > > That's why we came up with http-dtn. > > http://http-dtn.sourceforge.net/ > > Then you could do RESTful exchanges, M2M with SOAP etc., on top of HTTP/TCP. > > Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood > > > > > ________________________________ > From: Toerless Eckert > To: tsvwg@ietf.org > Sent: Thursday, 28 January 2016, 10:36 > Subject: [tsvwg] : Q: transport recommendations for "routing protocols" > > > Are there any drats/RFC that would give me guidance if i wanted to design > packet exchanges hop-by-hop between eg: routers/switches, with traffic > patterns lets say like a routing protocol. > > I see even new protocols like Babel run on top of datagram and have > all their own retransmission/ultimate-consistency schemes, and i was > wondering what opinions TSVWG has about this. > > Or let me turn this around: I'd rather like to build a protocol that > just uses hop-by-hop TCP and not reinvent all the transport aspects > that go along with that (including remote adjacencies/tunnels across stupidly > bad internet adjacencies with jitter and loss). But the ongoing reality of > protocols like this does not seem to indicate that there's any evolving > wisdom that this would be a good thing. > > And then the IOT space says TCP is bad, use CoAP, but then i don't even > have messagee exchanges anymore but put would ahve to reinvent it on top > of something like PUT/GET primitives... ? *sigh* > > So, really wondering. > > Thanks! > Toerless -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Jan 29 23:13:21 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A521A0025 for ; Fri, 29 Jan 2016 23:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lAx2L2w9Z8O for ; Fri, 29 Jan 2016 23:13:17 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D5A1A0024 for ; Fri, 29 Jan 2016 23:13:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,368,1449561600"; d="asc'?scan'208";a="95214655" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx144-out.netapp.com with ESMTP; 29 Jan 2016 23:12:45 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 29 Jan 2016 23:12:45 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::78c4:b507:6e5a:d63c%21]) with mapi id 15.00.1130.005; Fri, 29 Jan 2016 23:12:45 -0800 From: "Eggert, Lars" To: Toerless Eckert Thread-Topic: [tsvwg] : Q: transport recommendations for "routing protocols" Thread-Index: AQHRWVuX4PEP9WXGmkiiXl0g+vTqKp8S96AAgADKTICAAGyzAA== Date: Sat, 30 Jan 2016 07:12:45 +0000 Message-ID: <54322698-E540-4CB5-821D-F83E37A6232D@netapp.com> References: <20160127233635.GA4023@cisco.com> <20160130004341.GA23065@cisco.com> In-Reply-To: <20160130004341.GA23065@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_E83F9070-6F56-4382-99C1-0EDDBA969F3E"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 07:13:19 -0000 --Apple-Mail=_E83F9070-6F56-4382-99C1-0EDDBA969F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2016-01-30, at 1:43, Toerless Eckert wrote: >=20 > Thanks Lars. I was aware of those documents. >=20 > I guess everybody can read different things between the lines of > this document. I for once read it in a way: >=20 > Thanks for reading this UDP document. You thought you want to > do UDP in your protocol/app because you think it simplifies > life. Well, let us tell you all the things you really need to do > that TCP is already doing for you anyhow, so building something > on UDP is by far not as easy as you hoped unless you fail to > comply with these requirements. (reading for unicast only of course = ;-) that is the gist of it, yes. (Although for very simple/specialized uses = without much future evolution, UDP can be a good starting point.) > But i am past this point. I was hoping there is some RFC document > that even say: Do not bother with UDP, just use TCP, there is nothing > bad about it. Is there any ? I don't think so, and I the reason is probably that this sentiment is = certainly not a consensus the IETF has. UDP does have its uses, but = requires much more clue to use correctly. (Every time I read something along the lines saying "we chose UDP, = because it's lightweight" I immediately begin to think the authors don't = fully grok the complexities. If I read something that says "we don't = need and don't foresee to need features X, Y and Z of TCP, and therefore = build on UDP like this" I feel more confident of the proposed design.) > IOT folks for once still seem to claim > that you can build significantly more lightweight protocol stacks over > UDP than TCP. How true is that ? How small would a device have to be > so that i would need to start worrying about TCP as a choice. The CORE WG has discussed this, and the claim is that there is a class = of devices at the very low end for which TCP will remain prohibitive. = (Because even if the more capable devices become cheaper, as an IoT = customer you'd then rather spend your money on more nodes rather than = the same number of more capable nodes.) Ask on the CORE or T2TRG lists? > I'd be happy too if the recommendation was SCTP Maybe better ? My > requirements are so lame that i can't see how any of its improvements = would > make a difference. But i haven't gotten a good review if SCTP could be = more > lightweight even than TCP. I don't think the footprint is much different. Lars >=20 > Cheers > Toerless >=20 > On Fri, Jan 29, 2016 at 12:39:39PM +0000, Eggert, Lars wrote: >> On 2016-01-28, at 0:36, Toerless Eckert wrote: >>>=20 >>> Are there any drats/RFC that would give me guidance if i wanted to = design >>> packet exchanges hop-by-hop between eg: routers/switches, with = traffic >>> patterns lets say like a routing protocol. >>>=20 >>> I see even new protocols like Babel run on top of datagram and have >>> all their own retransmission/ultimate-consistency schemes, and i was >>> wondering what opinions TSVWG has about this. >>=20 >> RFC5405 and 5405bis (which is past WGLC) >>=20 >> It focuses on UDP, but that obviously generalizes mostly to arbitrary = datagram communication. 5405bis also now discusses multicast. >>=20 >> Lars >=20 >=20 >=20 > -- > --- > Toerless Eckert, eckert@cisco.com --Apple-Mail=_E83F9070-6F56-4382-99C1-0EDDBA969F3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIbBAEBCAAGBQJWrGJsAAoJEFS1wwm/cMFXhD8P8wcBsCkGvu7+/T08n3DTc3AP shXoFSGK4FL0PzLP8GvtzE7gJGjOX1RLNznYL5KHO+SzwO1w8XHuOxnDT6lAbVa4 g/AFg4FCv+YPOnmQOyjHGK08B/Fyd/NoHOJDLGbiXyCh6KPEE4cP64nNFf+Tylnj voKifMMAV3B52il11lcdsTlzQdNlGTyoUKTCJfmdcO0CcTguAjVECAc8rwbPj27v +gbe1yydaoRK/KIIFGw6dYPEy+SWefzKKr4pJOXC7zejF5m7fRkWr2ra3zW39Ttf 8SHVyknRu9k6P3IF3DPpzf89BnTcw63e9tNM2w/oEs6O8DBP9gbSDX1KqP1OPbaX 146g8yN+q6gujOJX69HOC2DkSmpbXQGd84DaYOSlY+4EMuoWrz1y9lzXoCmVipR2 C+VsgtlFK7BFhb5WHJtZSbycItb2gqhY0IuO5jYoQ/TAgBEaKFGXNTGn+/6fw2/c EMcan2yQBuFvfn9S2TWtpZsUSGnb+gTrI7LPKtHVYTVdXb7f93KpF9dEcVPY7h+5 idc/o9JPB3MGsvfniKFQGU9reaWSI5M5SAx5Uqs+un1dV8o8MiE4ztbUfPnZImcC n8Z8is6VuC1h/ZgIih0Twg+bZO8NmFw28KDQP4pO4bu0IPB3uuleHw7oZXsDorao cCMos+SW94QibhH5jrQ= =zO1a -----END PGP SIGNATURE----- --Apple-Mail=_E83F9070-6F56-4382-99C1-0EDDBA969F3E-- From nobody Sat Jan 30 03:56:00 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6870B1A0267 for ; Sat, 30 Jan 2016 03:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcEP8KRK5siz for ; Sat, 30 Jan 2016 03:55:55 -0800 (PST) Received: from nm49-vm9.bullet.mail.ne1.yahoo.com (nm49-vm9.bullet.mail.ne1.yahoo.com [98.138.121.137]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A7E1A0263 for ; Sat, 30 Jan 2016 03:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1454154955; bh=CauwsUyrgEO6oWQi4VEQQ6HsqohC9LhMIbt+3BotJb0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=TnFDiVo6uf+S9GLXukqUlXjfOHmy+AXgGc2wTuiKfLDN7uFPvGxztpcf+gzgFxz/sknw95Kjv6hYVnGSDmtlqi1BwpNbkDpsmzRn2XhNZURuwbDnvKH7LzffgpL887qEiNRJPQq2ysitN+bB4NanZAiZjT9z2raSDGMWvijB8INGtivY9SH8gAG6l+zRM0w8Hfm3ygLVbmvX1dsK/E8YOEShbB/WMkJ+MmUCkKLORHc8j/RZ0vvDME97yDoLTEwjNug7JxTG9coCwIqujBbRiq+NYupRFdVc/O6MCNKe5XDyYtQoSeoauhFrRrQi+htGPD7UGuHZKaPsy0q08QpM3A== Received: from [127.0.0.1] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jan 2016 11:55:55 -0000 Received: from [98.138.100.118] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jan 2016 11:53:01 -0000 Received: from [212.82.98.58] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jan 2016 11:53:01 -0000 Received: from [212.82.98.69] by tm11.bullet.mail.ir2.yahoo.com with NNFMP; 30 Jan 2016 11:53:00 -0000 Received: from [127.0.0.1] by omp1006.mail.ir2.yahoo.com with NNFMP; 30 Jan 2016 11:53:00 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 900197.86518.bm@omp1006.mail.ir2.yahoo.com X-YMail-OSG: 2XBpoUgVM1nC5bLFHlLXpaDPdSWQDRR1o2TGNbO1aX6.vhB.RWYWtZ8hTf..xuq 69rDD4CRzYBgxLFh3dUwCYI41wwvlU9FPvFSCJJA4XylLDP99RtZVuLE1vBHIT14IHDP5euRrjr6 h_E11Yja_oiR9fqViUdv4cWuezL7e5.dyDkqaYh4itQWYCuxXOFyEhp64MR9CnQ_pHelJcmVweDE 9pEwrqmRKpa5ufu5_FPc2CU7KKDIKxxbyoVkTLHBfaO_qBRNKHg7KWEAHPJp4NBu20fAnucvZDq6 FvXofU6Fc7ninpD.lYdeJmsR1LHwgiKEwK_JMvGKF.NL7hc6vVEgjb_yfg.fewe_IsaJYsyR2ZEx RE48cCwhRXbMXxLvkiUiM8fw6sN8vv3WNbU7Pai90vYTs5vnRP5MCP5EL0LtXHZVzIIBEUbkyZUr hVZ6TNdlNCJkStYIYzEiAtV_7hvpcEgQRVR7ivYI3thp3Jsf68pC6ESE9bWxDmipgeh6joIZxNm9 islXHVVS47Vp_DwuE52f_TN1Mzrc- Received: by 217.12.9.11; Sat, 30 Jan 2016 11:53:00 +0000 Date: Sat, 30 Jan 2016 11:52:54 +0000 (UTC) From: To: "Eggert, Lars" , Toerless Eckert Message-ID: <847152985.3866280.1454154774751.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <54322698-E540-4CB5-821D-F83E37A6232D@netapp.com> References: <54322698-E540-4CB5-821D-F83E37A6232D@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lloyd.wood@yahoo.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 11:55:57 -0000 > But i haven't gotten a good review if SCTP could be more > lightweight even than TCP. SCTP is heavier. More complex. Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood ----- Original Message ----- From: "Eggert, Lars" To: Toerless Eckert Cc: "tsvwg@ietf.org" Sent: Saturday, 30 January 2016, 18:12 Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" Hi, On 2016-01-30, at 1:43, Toerless Eckert wrote: > > Thanks Lars. I was aware of those documents. > > I guess everybody can read different things between the lines of > this document. I for once read it in a way: > > Thanks for reading this UDP document. You thought you want to > do UDP in your protocol/app because you think it simplifies > life. Well, let us tell you all the things you really need to do > that TCP is already doing for you anyhow, so building something > on UDP is by far not as easy as you hoped unless you fail to > comply with these requirements. (reading for unicast only of course ;-) that is the gist of it, yes. (Although for very simple/specialized uses without much future evolution, UDP can be a good starting point.) > But i am past this point. I was hoping there is some RFC document > that even say: Do not bother with UDP, just use TCP, there is nothing > bad about it. Is there any ? I don't think so, and I the reason is probably that this sentiment is certainly not a consensus the IETF has. UDP does have its uses, but requires much more clue to use correctly. (Every time I read something along the lines saying "we chose UDP, because it's lightweight" I immediately begin to think the authors don't fully grok the complexities. If I read something that says "we don't need and don't foresee to need features X, Y and Z of TCP, and therefore build on UDP like this" I feel more confident of the proposed design.) > IOT folks for once still seem to claim > that you can build significantly more lightweight protocol stacks over > UDP than TCP. How true is that ? How small would a device have to be > so that i would need to start worrying about TCP as a choice. The CORE WG has discussed this, and the claim is that there is a class of devices at the very low end for which TCP will remain prohibitive. (Because even if the more capable devices become cheaper, as an IoT customer you'd then rather spend your money on more nodes rather than the same number of more capable nodes.) Ask on the CORE or T2TRG lists? > I'd be happy too if the recommendation was SCTP Maybe better ? My > requirements are so lame that i can't see how any of its improvements would > make a difference. But i haven't gotten a good review if SCTP could be more > lightweight even than TCP. I don't think the footprint is much different. Lars > > Cheers > Toerless > > On Fri, Jan 29, 2016 at 12:39:39PM +0000, Eggert, Lars wrote: >> On 2016-01-28, at 0:36, Toerless Eckert wrote: >>> >>> Are there any drats/RFC that would give me guidance if i wanted to design >>> packet exchanges hop-by-hop between eg: routers/switches, with traffic >>> patterns lets say like a routing protocol. >>> >>> I see even new protocols like Babel run on top of datagram and have >>> all their own retransmission/ultimate-consistency schemes, and i was >>> wondering what opinions TSVWG has about this. >> >> RFC5405 and 5405bis (which is past WGLC) >> >> It focuses on UDP, but that obviously generalizes mostly to arbitrary datagram communication. 5405bis also now discusses multicast. >> >> Lars > > > > -- > --- > Toerless Eckert, eckert@cisco.com From nobody Sat Jan 30 07:58:17 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7094C1B3B65 for ; Sat, 30 Jan 2016 07:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.603 X-Spam-Level: X-Spam-Status: No, score=-12.603 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2DBRa76JrWB for ; Sat, 30 Jan 2016 07:58:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FEC1B3B64 for ; Sat, 30 Jan 2016 07:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2528; q=dns/txt; s=iport; t=1454169495; x=1455379095; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=afRBzDQW1L3YfxM/JvDejndpK+7tT+Onb4gOmDLGs/0=; b=TZrqez4nmQjKCDeB7FnHG2k3umiRqmn6EWiASxsSRoMNkFiLZF8pn//p w+/Ms+ISKuoT5NgXH/zTFzaXsNgDMpSq3+hIcACEZ/Lfzc+7VnBBn1C0V S87/KhlTLnOzAv+60zXbLmQy6hA73K+zPTB5DVBt+tgD9iuGMXjiAGK+Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcBQBC3KxW/5BdJa1dgzqBP4QshCyxR?= =?us-ascii?q?YFjhg8CgSg6EgEBAQEBAQGBCoRBAQEBAwE6PxALGAklDwVJE4gTCL47AQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBFYpGh12BDwWOGYhWjUIJgVuNFYpsg1InATqCAhmBc?= =?us-ascii?q?hsuiH0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,370,1449532800"; d="scan'208";a="68496043" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2016 15:58:13 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0UFwCuu026963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2016 15:58:13 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u0UFwCkq012203; Sat, 30 Jan 2016 07:58:12 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u0UFwCJ5012201; Sat, 30 Jan 2016 07:58:12 -0800 Date: Sat, 30 Jan 2016 07:58:12 -0800 From: Toerless Eckert To: "Eggert, Lars" Message-ID: <20160130155812.GA7568@cisco.com> References: <20160127233635.GA4023@cisco.com> <20160130004341.GA23065@cisco.com> <54322698-E540-4CB5-821D-F83E37A6232D@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54322698-E540-4CB5-821D-F83E37A6232D@netapp.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 15:58:16 -0000 On Sat, Jan 30, 2016 at 07:12:45AM +0000, Eggert, Lars wrote: > > IOT folks for once still seem to claim > > that you can build significantly more lightweight protocol stacks over > > UDP than TCP. How true is that ? How small would a device have to be > > so that i would need to start worrying about TCP as a choice. > > The CORE WG has discussed this, and the claim is that there is a class of devices at the very low end for which TCP will remain prohibitive. (Because even if the more capable devices become cheaper, as an IoT customer you'd then rather spend your money on more nodes rather than the same number of more capable nodes.) Ask on the CORE or T2TRG lists? CORE WG did IMHO develop an end-to-end flattened/simplified transport + session + presentation (arguably) stack with COAP. I think they drew their decisions from different requirement than what i am looking for. Or let me phrase it more succinctly: Once the IETF forces RPL(bis) to run on top of CoAP, i am persuaded to use CoAP for this purpose. > > I'd be happy too if the recommendation was SCTP Maybe better ? My > > requirements are so lame that i can't see how any of its improvements would > > make a difference. But i haven't gotten a good review if SCTP could be more > > lightweight even than TCP. > > I don't think the footprint is much different. Yepp. I am mostly worried about constrained devices intelligent enough to allow/use one reliable transport, but then trying to save space by consttraing it to ONLY one. Cheers Toerless > > Lars > > > > > Cheers > > Toerless > > > > On Fri, Jan 29, 2016 at 12:39:39PM +0000, Eggert, Lars wrote: > >> On 2016-01-28, at 0:36, Toerless Eckert wrote: > >>> > >>> Are there any drats/RFC that would give me guidance if i wanted to design > >>> packet exchanges hop-by-hop between eg: routers/switches, with traffic > >>> patterns lets say like a routing protocol. > >>> > >>> I see even new protocols like Babel run on top of datagram and have > >>> all their own retransmission/ultimate-consistency schemes, and i was > >>> wondering what opinions TSVWG has about this. > >> > >> RFC5405 and 5405bis (which is past WGLC) > >> > >> It focuses on UDP, but that obviously generalizes mostly to arbitrary datagram communication. 5405bis also now discusses multicast. > >> > >> Lars > > > > > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > -- --- Toerless Eckert, eckert@cisco.com From nobody Sat Jan 30 08:03:28 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558A41B3B7F for ; Sat, 30 Jan 2016 08:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7pxIFk84e3E for ; Sat, 30 Jan 2016 08:03:25 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8462C1B3B7E for ; Sat, 30 Jan 2016 08:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4671; q=dns/txt; s=iport; t=1454169805; x=1455379405; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=GUrA3WQ00kVmBk+FFqcNJ9HUyhrS6AUhVOiVhN5USdU=; b=TUlztJ9A/jNzk6Txy3auF82RvQlGyHlj3+9HQ9iKmAHfIbumClnXUDzH hUjQpOlou+37TfQyf8fJXDu+0KXRv3mhFssM+4hTHgNNAXLzuwBN1p0uq sbKynfuCK7KZkJymALYlFhAkmBjoSm3TuwG+5IzlPeXHSDNpRgR7kQp+E 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbBQAK3qxW/4MNJK1dgzpSZwaIWLFFg?= =?us-ascii?q?WMehXECgSg6EgEBAQEBAQGBCoRBAQEBBDo/DAQLEQQBAQEJJQ8FOyEZh20DEgm?= =?us-ascii?q?+MAEBAQEBAQEBAQEBAQEBAQEBAQEBARWKRoI3hSaBDwWGFAyHeYhWhUeGF4FkC?= =?us-ascii?q?YFbSocdhS6GfQEQg16DUicCOYQNGy6IfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,370,1449532800"; d="scan'208";a="231334296" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2016 16:03:24 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0UG3NSP029886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2016 16:03:24 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u0UG3LNa012437; Sat, 30 Jan 2016 08:03:21 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u0UG3JBX012432; Sat, 30 Jan 2016 08:03:19 -0800 Date: Sat, 30 Jan 2016 08:03:19 -0800 From: Toerless Eckert To: lloyd.wood@yahoo.co.uk Message-ID: <20160130160319.GB7568@cisco.com> References: <54322698-E540-4CB5-821D-F83E37A6232D@netapp.com> <847152985.3866280.1454154774751.JavaMail.yahoo@mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <847152985.3866280.1454154774751.JavaMail.yahoo@mail.yahoo.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 16:03:27 -0000 On Sat, Jan 30, 2016 at 11:52:54AM +0000, lloyd.wood@yahoo.co.uk wrote: > > But i haven't gotten a good review if SCTP could be more > > lightweight even than TCP. > > SCTP is heavier. More complex. > Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood In your opinion: How about SCTP compared to MPTCP ? Of course, that does not answer the question if SCTP could be stripped down to TCP size if one would only need TCP features - and even if possible, when that would make sense. I was guessing size is comparable when you compare same feature sets. More so than code size, i wonder about memory required for connection buffers. I have not looked into this for eternities, so i do not know what options implementations today offer to dynamically tune connections to minimum memory requirements (based on expected burst size etc..). Pointers welcome. Cheers Toerless > ----- Original Message ----- > From: "Eggert, Lars" > To: Toerless Eckert > Cc: "tsvwg@ietf.org" > Sent: Saturday, 30 January 2016, 18:12 > Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" > > Hi, > > On 2016-01-30, at 1:43, Toerless Eckert wrote: > > > > Thanks Lars. I was aware of those documents. > > > > I guess everybody can read different things between the lines of > > this document. I for once read it in a way: > > > > Thanks for reading this UDP document. You thought you want to > > do UDP in your protocol/app because you think it simplifies > > life. Well, let us tell you all the things you really need to do > > that TCP is already doing for you anyhow, so building something > > on UDP is by far not as easy as you hoped unless you fail to > > comply with these requirements. (reading for unicast only of course ;-) > > that is the gist of it, yes. (Although for very simple/specialized uses without much future evolution, UDP can be a good starting point.) > > > But i am past this point. I was hoping there is some RFC document > > that even say: Do not bother with UDP, just use TCP, there is nothing > > bad about it. Is there any ? > > I don't think so, and I the reason is probably that this sentiment is certainly not a consensus the IETF has. UDP does have its uses, but requires much more clue to use correctly. > > (Every time I read something along the lines saying "we chose UDP, because it's lightweight" I immediately begin to think the authors don't fully grok the complexities. If I read something that says "we don't need and don't foresee to need features X, Y and Z of TCP, and therefore build on UDP like this" I feel more confident of the proposed design.) > > > IOT folks for once still seem to claim > > that you can build significantly more lightweight protocol stacks over > > UDP than TCP. How true is that ? How small would a device have to be > > so that i would need to start worrying about TCP as a choice. > > The CORE WG has discussed this, and the claim is that there is a class of devices at the very low end for which TCP will remain prohibitive. (Because even if the more capable devices become cheaper, as an IoT customer you'd then rather spend your money on more nodes rather than the same number of more capable nodes.) Ask on the CORE or T2TRG lists? > > > I'd be happy too if the recommendation was SCTP Maybe better ? My > > requirements are so lame that i can't see how any of its improvements would > > make a difference. But i haven't gotten a good review if SCTP could be more > > lightweight even than TCP. > > I don't think the footprint is much different. > > > Lars > > > > > Cheers > > Toerless > > > > On Fri, Jan 29, 2016 at 12:39:39PM +0000, Eggert, Lars wrote: > >> On 2016-01-28, at 0:36, Toerless Eckert wrote: > >>> > >>> Are there any drats/RFC that would give me guidance if i wanted to design > >>> packet exchanges hop-by-hop between eg: routers/switches, with traffic > >>> patterns lets say like a routing protocol. > >>> > >>> I see even new protocols like Babel run on top of datagram and have > >>> all their own retransmission/ultimate-consistency schemes, and i was > >>> wondering what opinions TSVWG has about this. > >> > >> RFC5405 and 5405bis (which is past WGLC) > >> > >> It focuses on UDP, but that obviously generalizes mostly to arbitrary datagram communication. 5405bis also now discusses multicast. > >> > >> Lars > > > > > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com -- --- Toerless Eckert, eckert@cisco.com From nobody Sat Jan 30 11:35:01 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462EF1A884E for ; Sat, 30 Jan 2016 11:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM4DMyjjcv6x for ; Sat, 30 Jan 2016 11:34:57 -0800 (PST) Received: from nm37-vm9.bullet.mail.ir2.yahoo.com (nm37-vm9.bullet.mail.ir2.yahoo.com [212.82.97.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7101A8849 for ; Sat, 30 Jan 2016 11:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1454182495; bh=mqa1PUuF8rOFD3H8wNF1Ft0Gg1UP2p8I0f0kj128tZw=; h=Date:From:To:Subject:References:From:Subject; b=kFkfsmzqb/eroqOw0REhkOyc48nMVhdMi4XqOEpBTGbipZNG65hGpjPCHI5G+5v4SrwLaJEbd/36Wq/dV1P9PzHAzINQA0/WmdZuAqbRHiJFP0hDFwiYm0v4v9Y4Q+2V6tZ10T3KXrtdbRqNUIwgRz+jnSeDqkXBDCJfDat/WZcyOSEQPOFWNS44FcKQH/jjrUUUYqQQkw8snC09k6wERcmsCDkCBKppkK5Ewt4euyHY901tcVO94hZ/r8425FxyKcl7gajVCOUFdzi1dZYjGTs62cZhswjO6v1d6FdY5N11gvURfxDPLtrI/ckjgImK7reCFaxdeNGEv4qHTZ8Isw== Received: from [212.82.98.61] by nm37.bullet.mail.ir2.yahoo.com with NNFMP; 30 Jan 2016 19:34:55 -0000 Received: from [212.82.98.74] by tm14.bullet.mail.ir2.yahoo.com with NNFMP; 30 Jan 2016 19:34:54 -0000 Received: from [127.0.0.1] by omp1011.mail.ir2.yahoo.com with NNFMP; 30 Jan 2016 19:34:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 968959.61824.bm@omp1011.mail.ir2.yahoo.com X-YMail-OSG: CJ.nOXkVM1m.KYeNngay8BrNlVrKTFb.xtFr89vfHKSGQNBJQ2yxUJu0weq7zrE qUnFNUJPPQmRO1R7_1yxUMpHkRdvc3Vb3u9JZKz1ugyc59Q_QoSaTWzZvHhQNNjOtXM22c6S5u22 HzwpsH4.tVtb3cZdgihsBAo7m2a_8DJTjapksYZkXxsxXW5UOfYP8I9OzHkanoK6xeebwV4gTMfa YS54n49MB6znSqLAWDQtKmIy58Yz7fc6.kCFNs6bTVCjW6XI7ixsB7Dl22d8adIKGfe6SbKXQnFv Lk94Rsm3PGOmtubZbqdvQRJOisbSleWGAfoaswvCQZ02z5uB0.gU8RHWdd88XhaZHMoNZ8ZI6U9C ukyX9ntFdV6t_xzcpxP6ugcwaDBexArwdRqBBnHiI4GA4_89konSECdlmH8IU1aI9B_mhWqZ2Nx6 1Ag78SoiIRpBL6xhGxMekXbp2GTF6PZ7w14UukMY9Eu1XvpzN.JQksCfp0aPZzWV3u0IC7078VqW NOMbT44FGZxJmRLbMwsgfGMfr7w-- Received: by 217.12.9.14; Sat, 30 Jan 2016 19:34:54 +0000 Date: Sat, 30 Jan 2016 19:34:51 +0000 (UTC) From: Lloyd Wood To: Toerless Eckert , Tsvwg IETF List Message-ID: <801952257.4127155.1454182491767.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4127154_220217444.1454182491729" References: <801952257.4127155.1454182491767.JavaMail.yahoo.ref@mail.yahoo.com> Archived-At: Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 19:34:59 -0000 ------=_Part_4127154_220217444.1454182491729 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px = #715FFA solid !important; padding-left:1ex !important; background-color:wh= ite !important; } Toeless,To me, "message exchange" is at a higher layer th= an exchanging=C2=A0binary frames. It's XML interaction or better.If I under= stand you right, you want your own messaging, but=C2=A0you don't want to ha= ve to reinvent transport and reliable=C2=A0message delivery. But you'll sti= ll have to reinvent the messaging=C2=A0stack above that. Good luck with tha= t. CoAP translates to http rather like WAP did, with binary=C2=A0substitution = and proxying to http; limited binary=C2=A0http equivalence is of limited us= e. As such, it might do=C2=A0as well longterm as WAP did. Adopting http as = much=C2=A0as possible makes more sense to me longterm, and that's what we w= ere suggesting with http-dtn.Lloyd Wood=C2=A0lloyd.wood@yahoo.co.uk http://= about.me/lloydwood=20 ----- Original Message ----- From: Toerless Eckert To: lloyd.wood@yahoo.co.uk Sent: Saturday, 30 January 2016, 11:47 Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols" Thanks, Lloyd, but i was rather trying to avoid some undesired layer on top of TCP/SCTP. Rather continue my own choice of (reliable) message exchanges. Maybe i do not understand well why i need to be interested in http-dtn... Can you maybe rephrase ? Cheers =C2=A0 =C2=A0 Toerless On Fri, Jan 29, 2016 at 05:24:26AM +0000, lloyd.wood@yahoo.co.uk wrote: > > And then the IOT space says TCP is bad, use CoAP, but then i don't even= =20 > > have messagee exchanges anymore but put would ahve to reinvent it on to= p=20 > > of something like PUT/GET primitives... ? *sigh* >=20 > I know. >=20 > That's why we came up with http-dtn. >=20 > http://http-dtn.sourceforge.net/ >=20 > Then you could do RESTful exchanges, M2M with SOAP etc., on top of HTTP/T= CP. >=C2=A0=20 > Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood=20 >=20 >=20 >=20 >=20 > ________________________________ > From: Toerless Eckert > To: tsvwg@ietf.org=20 > Sent: Thursday, 28 January 2016, 10:36 > Subject: [tsvwg] : Q: transport recommendations for "routing protocols" >=20 >=20 > Are there any drats/RFC that would give me guidance if i wanted to design > packet exchanges hop-by-hop between eg: routers/switches, with traffic > patterns lets say like a routing protocol. >=20 > I see even new protocols like Babel run on top of datagram and have > all their own retransmission/ultimate-consistency schemes, and i was > wondering what opinions TSVWG has about this. >=20 > Or let me turn this around: I'd rather like to build a protocol that > just uses hop-by-hop TCP and not reinvent all the transport aspects > that go along with that (including remote adjacencies/tunnels across stup= idly > bad internet adjacencies with jitter and loss). But the ongoing reality o= f > protocols like this does not seem to indicate that there's any evolving > wisdom that this would be a good thing. >=20 > And then the IOT space says TCP is bad, use CoAP, but then i don't even > have messagee exchanges anymore but put would ahve to reinvent it on top > of something like PUT/GET primitives... ? *sigh* >=20 > So, really wondering. >=20 > Thanks! >=C2=A0 =C2=A0 Toerless --=20 --- Toerless Eckert, eckert@cisco.com ------=_Part_4127154_220217444.1454182491729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Toeless,
To me, "m= essage exchange" is at a higher layer than exchanging binary frames. It's XML interaction = or better.
If I understand you right, you want your own messaging, bu= t you don't want to have to reinvent transport and reliable messa= ge delivery. But you'll still have to reinvent the messaging stack abo= ve that. Good luck with that.

CoAP tra= nslates to http rather like WAP did, with binary substitution and prox= ying to http; limited binary http equivalence is of limited use. As su= ch, it might do as wel= l longterm as WAP did. Adopting http as much as possible makes more sense to me longterm, = and that's what we were suggesting with http-dtn.
Lloyd Wood 

----- Original Message -----
From: T= oerless Eckert <eckert@cisco.com>
To: lloyd.wood@yahoo.co.uk
Sent: Saturday, 30 Ja= nuary 2016, 11:47
Subject: Re: [tsvwg] : Q: transport rec= ommendations for "routing protocols"

T= hanks, Lloyd, but i was rather trying to avoid some undesired
layer on top of TCP/SCTP. Rather continue my own choice of (reliable)<= br clear=3D"none">message exchanges. Maybe i do not understand well why i n= eed to
be interested in http-dtn... Can you maybe rephras= e ?

Cheers
  &n= bsp; Toerless

On Fri, Jan 29, 2016 at = 05:24:26AM +0000, lloyd.wood@yahoo.co.uk wrote:
> > And then the IOT space says TCP is bad, use CoAP, but then= i don't even
> > have messagee exchanges anymore = but put would ahve to reinvent it on top
> > of so= mething like PUT/GET primitives... ? *sigh*
>
> I know.
>
> That= 's why we came up with http-dtn.
>
= > http= ://http-dtn.sourceforge.net/
>
> Then you could do RESTful exchanges, M2M with SOAP etc., on top of= HTTP/TCP.
> 
> Lloyd Wood = lloyd.wood@yahoo.co.uk http://about.me/lloydwood
> =
>
>
> > ________________________________
>= ; From: Toerless Eckert <eckert@cisco.com>
> To: tsvwg@ietf.org
> Sent: Thursday, 2= 8 January 2016, 10:36
> Subject: [tsvwg] : Q: transpor= t recommendations for "routing protocols"
>
>
> Are there any drats/RFC that would g= ive me guidance if i wanted to design
> packet exchang= es hop-by-hop between eg: routers/switches, with traffic
= > patterns lets say like a routing protocol.
>
> I see even new protocols like Babel run on top of datag= ram and have
> all their own retransmission/ultimate-c= onsistency schemes, and i was
> wondering what opinion= s TSVWG has about this.
>
> Or l= et me turn this around: I'd rather like to build a protocol that
> just uses hop-by-hop TCP and not reinvent all the transport = aspects
> that go along with that (including remote ad= jacencies/tunnels across stupidly
> bad internet adjac= encies with jitter and loss). But the ongoing reality of
= > protocols like this does not seem to indicate that there's any evolvin= g
> wisdom that this would be a good thing.
>
> And then the IOT space says TCP is b= ad, use CoAP, but then i don't even
> have messagee ex= changes anymore but put would ahve to reinvent it on top
= > of something like PUT/GET primitives... ? *sigh*
>= ;
> So, really wondering.
>
> Thanks!

> =   Toerless

--
---
Toerless Eckert, eckert@cisco.com
------=_Part_4127154_220217444.1454182491729--