From nobody Thu Mar 1 08:09:49 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2C512EADB for ; Thu, 1 Mar 2018 08:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-b2w9tgKzB0 for ; Thu, 1 Mar 2018 08:09:41 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 A204212EAD8 for ; Thu, 1 Mar 2018 08:09:41 -0800 (PST) X-AuditID: 12074423-e3bff70000003a70-98-5a9825c2e747 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.45.14960.3C5289A5; Thu, 1 Mar 2018 11:09:39 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w21G9YGv026945 for ; Thu, 1 Mar 2018 11:09:36 -0500 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (OC11EXEDGE4.EXCHANGE.MIT.EDU [18.9.3.27]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id w21G9M9f012355 for ; Thu, 1 Mar 2018 11:09:34 -0500 Received: from W92EXHUB12.exchange.mit.edu (18.7.73.21) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 1 Mar 2018 11:08:40 -0500 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.111]) by W92EXHUB12.exchange.mit.edu ([18.7.73.21]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 11:09:15 -0500 From: Samuel DeLaughter To: "tsvwg@ietf.org" Thread-Topic: Seeking SCTP Deployment Data Thread-Index: AQHTsXekZJN3+afRhk6jp1+LJuEDAQ== Date: Thu, 1 Mar 2018 16:09:15 +0000 Message-ID: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [73.69.184.22] Content-Type: multipart/signed; boundary="Apple-Mail=_82104828-08F3-4643-B3D7-87E8E9B25193"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAJsWRmVeSWpSXmKPExsUixG6nrntYdUaUwdSjphbH3txlc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs+jM9kKPmhWnFpg0cDYqdrFyMEhIWAisfuvfBcjF4eQwGIm icXH+9m7GDmBnCuMEj/2C0AkbjNKLHzewwbhbGOUuLDtCQuEs4pRovPLTEaQUWwCahL311WA dIsIqEpc7ljLBGILA9mN364yQsS1JKa9nMEGYetJbL/3ngXEZhFQkfh0fzIriM0rYCUx7+1F sCsYBcQkvp9aAzaHWUBc4taT+WC2hICIxMOLp9kgbDGJf7seQtkKEudXn2eHqJ/BKDF3li3E TEGJkzOfsExgFJmFZNQsJGWzkJRBxJMkVnx+zA5ha0ssW/iaeRbQl8wCOhKTFzKiCkPYH88f gRopL7H97RyouKXE+h2foMbYSqxb9x5qvIHEnObJTAsYeVYxyqbkVunmJmbmFKcm6xYnJ+bl pRbpmunlZpbopaaUbmIER7KL8g7Gl33ehxgFOBiVeHh3cM6IEmJNLCuuzD3EKMnBpCTKW/9q epQQX1J+SmVGYnFGfFFpTmrxIUYVoF2PNqy+wCjFkpefl6okwnt6+7QoId6UxMqq1KJ8mDJp DhYlcV4PE+0oIYH0xJLU7NTUgtQimKwMB4eSBO9VFaCdgkWp6akVaZk5JQhpJg7OQ4wSHDxA w+tBaniLCxJzizPTIfKnGC05tjx62cbMcQBM3njxuo1ZCOwaKXHeoyANAiANGaV5cDPBCZuT WfoVozjQu8K8Z0CqeIDJHm7qK6CFTEALj3yeArKwJBEhJdXAyLxN3FmptLfmT2fEbqavlyVW 6111Wah8YYXHbm+xqARHzaNMNi/+pkyRFNWStPBdPI1HzXbhrfOMPLfeb9z2ZpmShId2KGNe tb/Jex2323OPv2uadeKb05+JZZPFvvEsuFgfeHKpwaTcVZ0Xph78H9a1Nc361JFg0a/hkfX6 xyrPmoj9NrPLVGIpzkg01GIuKk4EAEyHdnazAwAA Archived-At: Subject: [tsvwg] Seeking SCTP Deployment Data X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 16:09:48 -0000 --Apple-Mail=_82104828-08F3-4643-B3D7-87E8E9B25193 Content-Type: multipart/alternative; boundary="Apple-Mail=_324A5D3D-9595-4A6A-9DA4-5BEE49095DCB" --Apple-Mail=_324A5D3D-9595-4A6A-9DA4-5BEE49095DCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, I am doing some research on SCTP and am trying to find data on the = current scope of its deployment. Does anyone here have information that = they may be able to share? Perhaps you run a network that has seen some = SCTP traffic, or you work on an application that uses SCTP. To my = knowledge the only major application that currently utilizes it is = WebRTC, does anyone know of others? Any help would be greatly = appreciated. Thank You, Sam -- -- Samuel DeLaughter Doctoral Student & Research Assistant Advanced Network Architecture Group MIT Computer Science and Artificial Intelligence Laboratory --Apple-Mail=_324A5D3D-9595-4A6A-9DA4-5BEE49095DCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

I = am doing some research on SCTP and am trying to find data on the current = scope of its deployment.  Does anyone here have information that = they may be able to share?  Perhaps you run a network that has seen = some SCTP traffic, or you work on an application that uses SCTP. =  To my knowledge the only major application that currently utilizes = it is WebRTC, does anyone know of others?  Any help would be = greatly appreciated.

Thank You,
Sam

--
--
Samuel DeLaughter
Doctoral Student & Research = Assistant
Advanced Network = Architecture Group
MIT Computer Science = and Artificial Intelligence Laboratory

= --Apple-Mail=_324A5D3D-9595-4A6A-9DA4-5BEE49095DCB-- --Apple-Mail=_82104828-08F3-4643-B3D7-87E8E9B25193 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzVV5wJZhlKuvYCcIIU7A6i0OOlgFAlqYJagACgkQIU7A6i0O OliztxAAhfsPPVbZIY2OJasruf8REP30t4zn19o4NSmY6QyBf/6GOeJlCpoYaoHi 8S8tr4H7nrRHi7TsitqaL99rW+UkWqGKzWVCeWrdOq0YiGcefPe0BDFj3xbn0Ed8 0fgDwPyRdiJjYVD7wIRC1c5L3NADMMQTbhJ983m3S2zQpLyw4AK/XEkemdqoVFg+ istAvBbJs7d88tGjGNbG4dg91VpdtmNbiLdxgLOKxSnZvG7t/OmhcnVP1Fs98w3n fXnXmhwAwcq0GwsiaF1crgai0uWIE+Cw4dLQIT6fBkBH98H3JJirtbNaQBS1TZH3 CiYiFOEjxruSLpM/I8ep54sixbS0bKxJBCvaJdr3ZJa+NM3ZpklYeceCNxnMh7XW 5E/dioQUlWos0R/RtgqhwYVb5kYHtPGQCog7XAc6mjzWZwE19gS8t/SmlVS/ruvh Dm0qcjpwEfwbmJJv7PlCLw9TkMb33vJpDsfoiphJYnLIK7GcndP4151sHsqPxy5F 9rBMbIdO8E5hTRsLq1cLUHDFXJGif9+9i4s879SdYhlWMANOw3+OBggTc5f6T2q3 ufNFRsM6xjnFNXNhneLJjNGioKCYFNK1PpgvOXFqCb8q72V0CS396+YIEQr3Sbr8 pm6EjyKdZ6SUBx9eVl+MvvVImCgJA1lDqAlDXYbdWpwJypeIZuA= =szg5 -----END PGP SIGNATURE----- --Apple-Mail=_82104828-08F3-4643-B3D7-87E8E9B25193-- From nobody Thu Mar 1 09:21:03 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B87012EAC1 for ; Thu, 1 Mar 2018 09:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkxTPA_UAztu for ; Thu, 1 Mar 2018 09:21:00 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C86D12D7F2 for ; Thu, 1 Mar 2018 09:21:00 -0800 (PST) Received: from [IPv6:2003:cd:6bf1:8000:9cc0:c016:b94c:31c5] (p200300CD6BF180009CC0C016B94C31C5.dip0.t-ipconnect.de [IPv6:2003:cd:6bf1:8000:9cc0:c016:b94c:31c5]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id B688C721E281E; Thu, 1 Mar 2018 18:20:57 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> Date: Thu, 1 Mar 2018 18:20:56 +0100 Cc: "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1A56E101-CF91-4FA7-BA7D-E3C28310BD60@lurchi.franken.de> References: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> To: Samuel DeLaughter X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] Seeking SCTP Deployment Data X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:21:01 -0000 > On Mar 1, 2018, at 5:09 PM, Samuel DeLaughter wrote: >=20 > Hi All, >=20 > I am doing some research on SCTP and am trying to find data on the = current scope of its deployment. Does anyone here have information that = they may be able to share? Perhaps you run a network that has seen some = SCTP traffic, or you work on an application that uses SCTP. To my = knowledge the only major application that currently utilizes it is = WebRTC, does anyone know of others? Any help would be greatly = appreciated. It is used in telephony signaling networks, where it is originally = designed for. This includes mobile networks, but it is not limited to them. Best regards Michael >=20 > Thank You, > Sam >=20 > -- > -- > Samuel DeLaughter > Doctoral Student & Research Assistant > Advanced Network Architecture Group > MIT Computer Science and Artificial Intelligence Laboratory >=20 From nobody Thu Mar 1 10:34:57 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF7812EC70 for ; Thu, 1 Mar 2018 10:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4IQOGEsGXAc for ; Thu, 1 Mar 2018 10:34:53 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EFE12EC69 for ; Thu, 1 Mar 2018 10:34:52 -0800 (PST) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1erT2X-0002km-69; Thu, 01 Mar 2018 19:34:49 +0100 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.4]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.90_1) (envelope-from ) id 1erT2V-0000xY-FB; Thu, 01 Mar 2018 19:34:49 +0100 From: Michael Welzl Message-Id: <18A4FE76-6463-4873-838C-C992DB321B5B@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_26B3E1F1-5D2D-4936-8F70-8EDBFEF76DB9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 1 Mar 2018 19:34:35 +0100 In-Reply-To: <1A56E101-CF91-4FA7-BA7D-E3C28310BD60@lurchi.franken.de> Cc: Samuel DeLaughter , "tsvwg@ietf.org" To: Michael Tuexen References: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> <1A56E101-CF91-4FA7-BA7D-E3C28310BD60@lurchi.franken.de> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.4]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AFD6645C0F0E50D85686DE62214797DE369CDDE2 Archived-At: Subject: Re: [tsvwg] Seeking SCTP Deployment Data X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 18:34:56 -0000 --Apple-Mail=_26B3E1F1-5D2D-4936-8F70-8EDBFEF76DB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I can=E2=80=99t resist using this opportunity for a commercial break: Negative views around SCTP that I heard (=E2=80=9Ccan=E2=80=99t be = deployed=E2=80=9D =E2=80=A6 =E2=80=9Cnot used by anyone=E2=80=9D =E2=80=A6= ) motivated me to start rolling the ball that became the TAPS WG, = several years ago. The logic was: - If you just replace TCP with SCTP, you don=E2=80=99t normally get much = benefit (more resilience from multihoming, and not much else). - So, app programmers would have to explicitly write programs against = it, to make use of its features to benefit from it. - They won=E2=80=99t, because it=E2=80=99s not used much, and rumors say = that it doesn=E2=80=99t work (of course it traverses the Internet just = fine above UDP, and while NATs naturally create problems, it seems to = often work fine natively in non-NATed networks) - so this is an effort = that is often in vain, and then you=E2=80=99d have to add all this = machinery to try if it works, fall back in case it doesn=E2=80=99t work, = map the requested services onto other protocols, etc. As a result, you get a self-fulfilling prophecy of non-deployment, just = because of a design flaw of the Internet=E2=80=99s transport layer that = binds applications to protocols instead of services. =3D> this machinery should not be the app programmer=E2=80=99s job. It = should be what the transport layer does for apps. Hence, go TAPS ! :) The open source TAPS implementation NEAT provides easy access to SCTP to = people, including all the machinery mentioned above: https://www.neat-project.org https://github.com/NEAT-project/neat = The point of TAPS is of course to not be tied to SCTP - it=E2=80=99s = about replaceable protocols in general. But, our code gives you SCTP if = you want to play with it (please do !). Cheers, Michael > On Mar 1, 2018, at 6:20 PM, Michael Tuexen = wrote: >=20 >> On Mar 1, 2018, at 5:09 PM, Samuel DeLaughter wrote: >>=20 >> Hi All, >>=20 >> I am doing some research on SCTP and am trying to find data on the = current scope of its deployment. Does anyone here have information that = they may be able to share? Perhaps you run a network that has seen some = SCTP traffic, or you work on an application that uses SCTP. To my = knowledge the only major application that currently utilizes it is = WebRTC, does anyone know of others? Any help would be greatly = appreciated. > It is used in telephony signaling networks, where it is originally = designed for. > This includes mobile networks, but it is not limited to them. >=20 > Best regards > Michael >>=20 >> Thank You, >> Sam >>=20 >> -- >> -- >> Samuel DeLaughter >> Doctoral Student & Research Assistant >> Advanced Network Architecture Group >> MIT Computer Science and Artificial Intelligence Laboratory >>=20 >=20 --Apple-Mail=_26B3E1F1-5D2D-4936-8F70-8EDBFEF76DB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I can=E2=80=99t resist using this opportunity for a = commercial break:

Negative views around SCTP that I heard (=E2=80=9Ccan=E2=80=99t= be deployed=E2=80=9D =E2=80=A6 =E2=80=9Cnot used by anyone=E2=80=9D = =E2=80=A6) motivated me to start rolling the ball that became the TAPS = WG, several years ago. The logic was:

- If you just replace TCP with SCTP, = you don=E2=80=99t normally get much benefit (more resilience from = multihoming, and not much else).

- So, app programmers would have to = explicitly write programs against it, to make use of its features to = benefit from it.

- They won=E2=80=99t, because it=E2=80=99s not used much, and = rumors say that it doesn=E2=80=99t work (of course it traverses the = Internet just fine above UDP, and while NATs naturally create problems, = it seems to often work fine natively in non-NATed networks) - so this is = an effort that is often in vain, and then you=E2=80=99d have to add all = this machinery to try if it works, fall back in case it doesn=E2=80=99t = work, map the requested services onto other protocols, etc.

As a result, you get a = self-fulfilling prophecy of non-deployment, just because of a design = flaw of the Internet=E2=80=99s transport layer that binds applications = to protocols instead of services.

=3D> this machinery should not be = the app programmer=E2=80=99s job. It should be what the transport layer = does for apps.

Hence, go TAPS !  :)
The open = source TAPS implementation NEAT provides easy access to SCTP to people, = including all the machinery mentioned above:

The point of TAPS is of = course to not be tied to SCTP - it=E2=80=99s about replaceable protocols = in general. But, our code gives you SCTP if you want to play with it = (please do !).

Cheers,
Michael


On Mar 1, 2018, at 6:20 PM, = Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

On Mar 1, 2018, at 5:09 = PM, Samuel DeLaughter <samd@mit.edu> wrote:

Hi = All,

I am doing some research on SCTP and = am trying to find data on the current scope of its deployment. =  Does anyone here have information that they may be able to share? =  Perhaps you run a network that has seen some SCTP traffic, or you = work on an application that uses SCTP.  To my knowledge the only = major application that currently utilizes it is WebRTC, does anyone know = of others?  Any help would be greatly appreciated.
It is used in telephony signaling networks, = where it is originally designed for.
This includes mobile = networks, but it is not limited to them.

Best= regards
Michael

Thank You,
Sam

--
--
Samuel DeLaughter
Doctoral Student & Research Assistant
Advanced Network Architecture Group
MIT = Computer Science and Artificial Intelligence Laboratory



= --Apple-Mail=_26B3E1F1-5D2D-4936-8F70-8EDBFEF76DB9-- From nobody Thu Mar 1 12:42:20 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7931712FAE7 for ; Thu, 1 Mar 2018 12:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS4FcEMYttYW for ; Thu, 1 Mar 2018 12:42:08 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 3002912FAAA for ; Thu, 1 Mar 2018 12:42:08 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id u8-v6so2645500ybo.10 for ; Thu, 01 Mar 2018 12:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H5hl6/q6PL+I3ylw0z7uIk0Ejsziknnss0L9nFRPo+I=; b=PzbmxVRJPwf3APs82S/0MXwOfiFyF6PS0VQc1zm1EyJ09hF/3SZNP/XNkkdDYVGUiO WW8HwnkAVF6A9A/fjth6VfK0wcQEjg7d4813+40w6FplwNVxVAHm2ClTx+cYLaXyvPdV xhQAAWwrqtWz9lvVZI1z1DiCSFAazsNtK3ktFRVL3R12N21n55g67Fcw1x0q3od6xGRY 54+jG+jwetXQsurJpJG6DwBYkugziL68sscg9Cut3eMGDqD5SFUFbi0XSB9eTjuK4uue MA1Nq68uOQxMmozhHJN8ZgogXmh6x0JSCk3MqxrdLYWZf5q/d9+IbMYn4oVrYRerOAN7 ii7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H5hl6/q6PL+I3ylw0z7uIk0Ejsziknnss0L9nFRPo+I=; b=ufws9KofMpbWVyBPWPkD1c6naRxsaeYx/GyMd1SDVT0NAfX/SBsK2WwF/ss42kaAMZ iymfKUhirFgcCrUOeyaFF6WL766gVLaZSSvZcyWGJxWnvRtHU3NaUuCdEUnY8Snhk2NS sYZ9dn1MI2lOAvx2yWeSHq4+IrYgWJmDP5xQiNbeNl8BShiakXz+5QstWG6EAMvjI9is vlZPy0aYlRmVmPfw4ZBIxu+M9zgxpsg1raH9fUhaQ1lIZNFISPU0DM866P4dQtNAVyIA HtdvcyF05qsD166qRHfgMpPiKx0OHaCiN5uihwwrtP+JXulW+PCUYX5KRgFsJvTpV/p8 COPg== X-Gm-Message-State: APf1xPACAeSL7R+p7FBbYANwFRD2n+5NvOvDNaa+ViKLPxCMGQ+vK37Y upPAgNCzNGDVwigFs+fEkRqesfIeNAYQbV1BN8c= X-Google-Smtp-Source: AG47ELs8AcsKN0jduoDHAujg1r5s9kdoYM78w07wb85VQVK70GicAS5h0ui0Y1UxCoTHY4JzS+85pkY3qfr8N7KAxn8= X-Received: by 2002:a25:a32a:: with SMTP id d39-v6mr2248272ybi.286.1519936927226; Thu, 01 Mar 2018 12:42:07 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:15c9:0:0:0:0:0 with HTTP; Thu, 1 Mar 2018 12:42:06 -0800 (PST) In-Reply-To: <18A4FE76-6463-4873-838C-C992DB321B5B@ifi.uio.no> References: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> <1A56E101-CF91-4FA7-BA7D-E3C28310BD60@lurchi.franken.de> <18A4FE76-6463-4873-838C-C992DB321B5B@ifi.uio.no> From: Spencer Dawkins at IETF Date: Thu, 1 Mar 2018 14:42:06 -0600 Message-ID: To: Michael Welzl Cc: Michael Tuexen , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a0e85005665fe4b9" Archived-At: Subject: Re: [tsvwg] Seeking SCTP Deployment Data X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 20:42:11 -0000 --000000000000a0e85005665fe4b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With my apologies to the US political/election system ... On Thu, Mar 1, 2018 at 12:34 PM, Michael Welzl wrote: > I can=E2=80=99t resist using this opportunity for a commercial break: > > Negative views around SCTP that I heard (=E2=80=9Ccan=E2=80=99t be deploy= ed=E2=80=9D =E2=80=A6 =E2=80=9Cnot used > by anyone=E2=80=9D =E2=80=A6) motivated me to start rolling the ball that= became the TAPS > WG, several years ago. The logic was: > > - If you just replace TCP with SCTP, you don=E2=80=99t normally get much = benefit > (more resilience from multihoming, and not much else). > > - So, app programmers would have to explicitly write programs against it, > to make use of its features to benefit from it. > > - They won=E2=80=99t, because it=E2=80=99s not used much, and rumors say = that it doesn=E2=80=99t > work (of course it traverses the Internet just fine above UDP, and while > NATs naturally create problems, it seems to often work fine natively in > non-NATed networks) - so this is an effort that is often in vain, and the= n > you=E2=80=99d have to add all this machinery to try if it works, fall bac= k in case > it doesn=E2=80=99t work, map the requested services onto other protocols,= etc. > > As a result, you get a self-fulfilling prophecy of non-deployment, just > because of a design flaw of the Internet=E2=80=99s transport layer that b= inds > applications to protocols instead of services. > > =3D> this machinery should not be the app programmer=E2=80=99s job. It sh= ould be > what the transport layer does for apps. > > Hence, go TAPS ! :) > The open source TAPS implementation NEAT provides easy access to SCTP to > people, including all the machinery mentioned above: > https://www.neat-project.org > https://github.com/NEAT-project/neat > > The point of TAPS is of course to not be tied to SCTP - it=E2=80=99s abou= t > replaceable protocols in general. But, our code gives you SCTP if you wan= t > to play with it (please do !). > "I'm Spencer Dawkins, one of the Transport Area Directors, and I approve of this message" :-) Spencer --000000000000a0e85005665fe4b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With my apologies to the US political/election system ...<= div class=3D"gmail_extra">
On Thu, Mar 1, 201= 8 at 12:34 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
I can= =E2=80=99t resist using this opportunity for a commercial break:

Negative views around SCTP that I heard (=E2=80=9Ccan=E2=80=99t be= deployed=E2=80=9D =E2=80=A6 =E2=80=9Cnot used by anyone=E2=80=9D =E2=80=A6= ) motivated me to start rolling the ball that became the TAPS WG, several y= ears ago. The logic was:

- If you just replace TCP= with SCTP, you don=E2=80=99t normally get much benefit (more resilience fr= om multihoming, and not much else).

- So, app prog= rammers would have to explicitly write programs against it, to make use of = its features to benefit from it.

- They won=E2=80= =99t, because it=E2=80=99s not used much, and rumors say that it doesn=E2= =80=99t work (of course it traverses the Internet just fine above UDP, and = while NATs naturally create problems, it seems to often work fine natively = in non-NATed networks) - so this is an effort that is often in vain, and th= en you=E2=80=99d have to add all this machinery to try if it works, fall ba= ck in case it doesn=E2=80=99t work, map the requested services onto other p= rotocols, etc.

As a result, you get a self-fulfill= ing prophecy of non-deployment, just because of a design flaw of the Intern= et=E2=80=99s transport layer that binds applications to protocols instead o= f services.

=3D> this machinery should not be t= he app programmer=E2=80=99s job. It should be what the transport layer does= for apps.

Hence, go TAPS ! =C2=A0:)
The= open source TAPS implementation NEAT provides easy access to SCTP to peopl= e, including all the machinery mentioned above:
https://www.neat-project.org<= /div>

Th= e point of TAPS is of course to not be tied to SCTP - it=E2=80=99s about re= placeable protocols in general. But, our code gives you SCTP if you want to= play with it (please do !).

"I'm Spencer Dawkins, one of the Transport Area Directors, and I= approve of this message" :-)

Spencer=C2=A0
--000000000000a0e85005665fe4b9-- From nobody Thu Mar 1 15:44:35 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114E7127078 for ; Thu, 1 Mar 2018 15:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk 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 2rDnYIj_Kknn for ; Thu, 1 Mar 2018 15:44:32 -0800 (PST) Received: from sonic301-22.consmr.mail.ir2.yahoo.com (sonic301-22.consmr.mail.ir2.yahoo.com [77.238.176.99]) (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 3ED9E127076 for ; Thu, 1 Mar 2018 15:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1519947870; bh=3D0cK8JtZzcH/7nNud0PpZG4sWji69BmUeqFfJ6kSiI=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=jjcV9ZHCV2vXFkl/PgBPmEoJdxe1m7Il3orTW11jmzpbkUJ68p46EBTNDqyd1cMfy6YeZWJ0VnM1QNecWn1NeFX9g5DSMwvT/RM1sU0aHOeLJI4NPAcJ4Xk0u7GKB3xvOT55npUodRlfzso8egA9rqVCJYAXxgPtPcNjdhLo5+ynG/VKrSbRyWkU8JBX1dI92N+DV9uT4iL+OHeRgztSsw8AjAXc/sUnrba2fHteqOSDfF/s2sUzeDLxh9u2m3EmRAERGfGQLq74QkEgCJRGB7oqPQMzp2qKik6yV4TsTcpDjm9tbp21GvZOka+zVhWOgYeTTWcWeSla+9x6K3dCdA== X-YMail-OSG: UyG1w24VM1lWHhfJWFGnoWmNK5BjkKrJs_2uG1iDPKf6VFPQRgLLXyS3IXxPsz_ muxbiPtQ9d7sz9JnbuRuKgJ0VmfqT6nasyi0YiQfkFsou8PFGgbCkxe0ik2oc9PWfU.FMz_DlqaX zcrLlPEKq9FneVx47LmkI_jrQRXokrqasgZCdzyTl3JCf6UYXuUR20mFSgWbyIcHw4R30qiAR1P7 A3ksMCqvE_HzJC_pKv3elPwJw9g4tGArnCCe31HYt_0etYs0fqnxQ52U0TQ5tB.YAjTa0vkDEYaZ nB8F.XBCundkLkfncfnjkGHzpFXCagVfpOzoRA_HSpYK3p_JtqD4.uv04uRUMLN6SujGtCvoy6Su N2j6961WzXIY6GYOjuE0u3fGd12Newk66TghMLCoaV61MUi27g4PI.FLNgEUz_tgNb25CiC4ODP7 QMAq1r2pScJo2RTvyrJZ5szcUYdzTMYZSsLqiJ3u7.sahLDGYqdrhAZNyV9kpq1kvG1lZPrA48D2 k_VyiAQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ir2.yahoo.com with HTTP; Thu, 1 Mar 2018 23:44:30 +0000 Date: Thu, 1 Mar 2018 23:44:08 +0000 (UTC) From: Lloyd Wood Reply-To: Lloyd Wood To: Samuel DeLaughter , "tsvwg@ietf.org" Message-ID: <1512030807.13030518.1519947848505@mail.yahoo.com> In-Reply-To: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> References: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.11419 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36 Archived-At: Subject: Re: [tsvwg] Seeking SCTP Deployment Data X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 23:44:34 -0000 Cisco used SCTP as the transport mechanism between its NCE accelerators. SCTP was also used in its RBSCP software accelerator, which is less widely used. (Many other accelerators use SCPS variants or custom protocols; I'm not aware of other use of SCTP.) Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood ________________________________ From: Samuel DeLaughter To: "tsvwg@ietf.org" Sent: Friday, 2 March 2018, 3:09 Subject: [tsvwg] Seeking SCTP Deployment Data Hi All, I am doing some research on SCTP and am trying to find data on the current scope of its deployment. Does anyone here have information that they may be able to share? Perhaps you run a network that has seen some SCTP traffic, or you work on an application that uses SCTP. To my knowledge the only major application that currently utilizes it is WebRTC, does anyone know of others? Any help would be greatly appreciated. Thank You, Sam -- -- Samuel DeLaughter Doctoral Student & Research Assistant Advanced Network Architecture Group MIT Computer Science and Artificial Intelligence Laboratory From nobody Fri Mar 2 02:25:24 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F45B127136 for ; Fri, 2 Mar 2018 02:25:22 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyPx1yd5_Fpy for ; Fri, 2 Mar 2018 02:25:20 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6924120725 for ; Fri, 2 Mar 2018 02:25:20 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 2CCED2D50B7; Fri, 2 Mar 2018 10:25:20 +0000 (UTC) Date: Fri, 2 Mar 2018 10:25:20 +0000 From: Derek Fawcus To: "tsvwg@ietf.org" Message-ID: <20180302102520.GE83910@accordion.employees.org> References: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> <1512030807.13030518.1519947848505@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512030807.13030518.1519947848505@mail.yahoo.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Seeking SCTP Deployment Data X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 10:25:22 -0000 On Thu, Mar 01, 2018 at 11:44:08PM +0000, Lloyd Wood wrote: > Cisco used SCTP as the transport mechanism between its NCE accelerators. > SCTP was also used in its RBSCP software accelerator, which is less widely used. Wasn't it also an option on the cisco boxes for exporting NetFlow records? It is also available as a match criteria in some routers ACLs / Firewalls, but for some vendors only as a 3 tuple match. I've used it when configuring filter rules. DF From nobody Fri Mar 2 03:43:05 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B6C12778D; Fri, 2 Mar 2018 03:43:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhZBQb0kzLAQ; Fri, 2 Mar 2018 03:43:02 -0800 (PST) Received: from visuela.unizar.es (visuela.unizar.es [155.210.1.100]) (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 3BBCC120721; Fri, 2 Mar 2018 03:43:01 -0800 (PST) Received: from gtc1pc12.cps.unizar.es ([155.210.158.17] helo=usuarioPC) by visuela.unizar.es with esmtpa (Exim 4.84_2) (envelope-from ) id 1erj5X-0008FC-RG; Fri, 02 Mar 2018 12:42:59 +0100 From: "Jose Saldana" To: Cc: References: <151999032141.15885.6981250048910407372.idtracker@ietfa.amsl.com> In-Reply-To: <151999032141.15885.6981250048910407372.idtracker@ietfa.amsl.com> Date: Fri, 2 Mar 2018 12:42:55 +0100 Message-ID: <01ad01d3b21b$9ddc2db0$d9948910$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGKWrSsP6FW/5niFkmWjw3BNTRic6RPgBGg Content-Language: es Archived-At: Subject: [tsvwg] RV: New Version Notification for draft-saldana-tsvwg-simplemux-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 11:43:04 -0000 Hi again, We have just submitted a new version of the Simplemux draft. We have added a text saying that it could be interesting for covering = the problem of QUIC fallback, as stated in = https://tools.ietf.org/html/draft-ietf-quic-applicability-01#section-2 Simplemux is a generic multiplexing protocol, i.e. it can be used to aggregate a number of packets belonging to a protocol, on a single packet belonging to other (or the same) protocol. One example of this is the fallback from QUIC to TLS over TCP [I-D.ietf-quic-applicability], which requires stream multiplexing. This is not provided by TCP, and could be implemented in other layers. We have also added some security considerations. Simplemux protocol has been developed in such a way that packet=09 aggregation and security can be simultaneously applied to the same=09 traffic flows, i.e. a single security header could protect a number=09 of packets belonging to different flows.=09 =09 As a consequence, the overall efficiency could be improved, as the=09 number of security headers could be reduced from N (being N the=09 number of multiplexed packets) to 1. Best regards, Jose > -----Mensaje original----- > De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Enviado el: viernes, 2 de marzo de 2018 12:32 > Para: Jose Mas ; Julian Navajas ; = Julian > Fernandez Navajas ; Jose Ruiz Mas = ; Jose > Saldana > Asunto: New Version Notification for = draft-saldana-tsvwg-simplemux-09.txt >=20 >=20 > A new version of I-D, draft-saldana-tsvwg-simplemux-09.txt > has been successfully submitted by Jose Saldana and posted to the IETF > repository. >=20 > Name: draft-saldana-tsvwg-simplemux > Revision: 09 > Title: Simplemux. A generic multiplexing protocol > Document date: 2018-03-02 > Group: Individual Submission > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-saldana-tsvwg-simplemux- > 09.txt > Status: = https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/ > Htmlized: = https://tools.ietf.org/html/draft-saldana-tsvwg-simplemux-09 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-saldana-tsvwg-simplemux- > 09 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-tsvwg-simplemux-09 >=20 > Abstract: > The high amount of small packets present in nowaday's networks > results in a low efficiency, as the size of the headers and the > payload of these packets can be in the same order of magnitude. In > some situations, multiplexing a number of small packets into a = bigger > one is desirable in order to improve the efficiency. 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. Small headers (separators) are added at the beginning of > each multiplexed packet, including some flags, the packet length = and > a "Protocol" field. This allows the inclusion of a number of = packets > belonging to different protocols (the "multiplexed packets") on a > packet of another protocol (the "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 Fri Mar 2 08:18:43 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6B12D77C for ; Fri, 2 Mar 2018 08:18:42 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UiTBGRI_T47 for ; Fri, 2 Mar 2018 08:18:39 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id B66BA12D7ED for ; Fri, 2 Mar 2018 08:18:39 -0800 (PST) Received: from dhcp-207-156.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:f186:2ce9:e6fd:f6f]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2245C1B00083; Fri, 2 Mar 2018 16:18:38 +0000 (GMT) Reply-To: gorry@erg.abdn.ac.uk To: tsvwg WG Cc: tsvwg chair From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <9cf4b6ba-b60d-b2d5-5917-5b435bd7c3e7@erg.abdn.ac.uk> Date: Fri, 2 Mar 2018 16:18:37 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] *** Draft *** Agenda for TSVWG at IETF-101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 16:18:42 -0000 Please see below an advance copy of the current working agenda. Please send comments/corrections to the WG Chairs, Gorry (TSVWG Co-Chair) --- The timing and day of this meeting will be later confirmed by the IETF Secretariat. The Agenda will be confirmed by the Chairs. Thursday 1550-1750 Afternoon Session II (TBC) 1. Chairs Update: (15 min) RFC's completed: RFC 8325 RFC 8311 Milestone updates and review of WG Progress Feedback on draft-ietf-tsvwg-tunnel-congestion-feedback 2. Announcements and Heads-Up (15 mins) << to be determined, including IEEE Liaison >>> 3. Transport and Network Gorry Fairhurst: IANA Action for DSCP Pools (10 min) draft-ietf-tsvwg-iana-dscp-registry (In WGLC) TBD - Lower Effort PHB (15 min) draft-ietf-tsvwg-le-phb (Reviews) Anais Finzi: Priority Switching Scheduler (20 min) draft-finzi-priority-switching-scheduler ECN (To be Determined) draft-ietf-tsvwg-rfc6040update-shim draft-ietf-tsvwg-ecn-l4s-id draft-ietf-tsvwg-l4s-arch 4. Other presentations / New Work << as needed >> Thursday 1750-1810 Beverage Break 1810-1910 Afternoon Session III (TBC) 5. Transport Protocols and Mechanisms Vincent Rocca: FEC drafts (10 min) draft-ietf-tsvwg-fecframe-ext draft-ietf-tsvwg-rlc-fec-scheme Tom Jones: UDP Options Implementation (10 Min) draft-ietf-tsvwg-udp-options - Tom Jones : Datagram PLPMTUD (15 min) draft-ietf-tsvwg-plpmtud Michael Tuexen: RFC4960 Errata (15 min) draft-ietf-tsvwg-rfc4960-errata From nobody Sat Mar 3 06:05:00 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEC4127876 for ; Sat, 3 Mar 2018 06:04:58 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLaXO0SWiZJF for ; Sat, 3 Mar 2018 06:04:57 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0CE120721 for ; Sat, 3 Mar 2018 06:04:57 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id A062C2D5048; Sat, 3 Mar 2018 14:04:56 +0000 (UTC) Date: Sat, 3 Mar 2018 14:04:56 +0000 From: Derek Fawcus To: tsvwg@ietf.org Message-ID: <20180303140456.GA39320@accordion.employees.org> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151641832182.3163.5991614599671930276@ietfa.amsl.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 14:04:59 -0000 On Fri, Jan 19, 2018 at 07:18:41PM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group WG of the IETF. Two of the points raised before adoption were: a) if the OCS field should be optional b) if the checksum over the otions (which OCS provides) should be 16 bits see this thread: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14926.html This effectively got deferred until after adoption. I was proposing that the current OCS option be discarded, and replaced with a fixed length 16 bit checksum field at the start of the surplus area. This would then use the usual internet checksum algorithm, such that the whole of the surplus area, including this checksum, should sum to zero. I also suggested how this would work when the FRAG mechanism was in use. The main reason for this was simplicity for implementors, in that they'd not have to write and verify a new checksum routine, but could use their existing algorithm. It would also be simpler to implement in that the checksum would be in a known fixed location, hence verification would be simpler. In theory, if one did not wish to use a checksum, one could store the 0x0000 value there, and always use 0xffff to represent a 1's complement value of zero. The cost of the above is that one always consumes 2 bytes from the surplus area to represent this, even if one does not wish to checksum the options area. Whereas if one does wish to checksum the options, it consumes the same space as the current scheme. I'd argue that for robustness reasons, one would almost always wish to checksum the options area. I'd suggest that the above scheme is actually simpler than the current one. So I am again proposing: 1) Remove the OCS option. 2) Add a fixed length 16 bit checksum field at a known location (The start of the surplus area). 3) Potentially allow one to store 0x0000 in that field to indicate the options themselves are not protected by a checksum. How do others view this? DF From nobody Sat Mar 3 06:19:21 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4676124E15 for ; Sat, 3 Mar 2018 06:19:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf116iB_YJXD for ; Sat, 3 Mar 2018 06:19:19 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E14F120721 for ; Sat, 3 Mar 2018 06:19:19 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 5EC2A2D5048; Sat, 3 Mar 2018 14:19:19 +0000 (UTC) Resent-From: Derek Fawcus Resent-Date: Sat, 3 Mar 2018 14:19:19 +0000 Resent-Message-ID: <20180303141919.GC39320@accordion.employees.org> Resent-To: tsvwg@ietf.org Date: Sat, 3 Mar 2018 14:18:05 +0000 From: Derek Fawcus To: tsvwg@ietf.org Message-ID: <20180303141805.GB39320@accordion.employees.org> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180303140456.GA39320@accordion.employees.org> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 14:19:20 -0000 On Sat, Mar 03, 2018 at 02:04:56PM +0000, Derek Fawcus wrote: > I also suggested how this would work when the FRAG mechanism was in use. That is a typo, it should have said LITE header, not FRAG mechanism. DF From nobody Sat Mar 3 06:55:15 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8786126CE8 for ; Sat, 3 Mar 2018 06:55:13 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=f5.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfxZmsku_2AT for ; Sat, 3 Mar 2018 06:55:12 -0800 (PST) Received: from mail15.f5.com (mail15.f5.com [104.219.106.14]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE181267BB for ; Sat, 3 Mar 2018 06:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=f5; t=1520088912; x=1551624912; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=KLnoTDHrg59pWm/BcmfhcqOZu/zAeM2nnOWbSDTcWC4=; b=SsMGBDbYT2ewcz9ihqeNwm5kNySlAELxdzm5GWmygM+IT/iOr9jWPawR ZYoL7/K4VWY0eQWx/hnu5wzma78EUQavkypmvT1TtJtuPnyixDnrceO03 /MpRy1pHLPEEm2FJfzaHdHQPwkx/Rl3eYhoLDGeJkRiKdxERzX8SKYkLj fHXnl7fnB81U1uIGaTUrPzIznItoChO/ObjoqR290kWLiTPjbpuoPooDF +rIqzWHd2f9FabHIJvX26OyKj+znguB4gjndt3wDV7D+NwAi7bShbosC3 5Gh4VKdRoh+ZU2OX74/PAa5kmuKOdO76g1P76wLkAgPVJqWxBYoiEeSF/ A==; X-IronPort-AV: E=McAfee;i="5900,7806,8820"; a="37763080" X-IronPort-AV: E=Sophos;i="5.47,418,1515484800"; d="scan'208";a="37763080" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from seadev21.olympus.f5net.com ([192.168.180.71]) by mail.f5net.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2018 06:55:11 -0800 Received: from seadev21.olympus.f5net.com (localhost [127.0.0.1]) by seadev21.olympus.f5net.com (8.14.4/8.12.11) with ESMTP id w23EtB5B009664; Sat, 3 Mar 2018 06:55:11 -0800 Received: (from aesmith@localhost) by seadev21.olympus.f5net.com (8.14.4/8.14.4/Submit) id w23EtBs0009647; Sat, 3 Mar 2018 06:55:11 -0800 X-Authentication-Warning: seadev21.olympus.f5net.com: aesmith set sender to AE.Smith@f5.com using -f Date: Sat, 3 Mar 2018 06:55:11 -0800 From: Astrid Smith To: Samuel DeLaughter Cc: "tsvwg@ietf.org" Message-ID: <20180303145511.GR21548@seadev21.f5.com> References: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <7BAC92FB-96BD-4E59-903A-2A584E6AD083@mit.edu> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [tsvwg] Seeking SCTP Deployment Data X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 14:55:14 -0000 Hello Sam, I'm not sure how much I can say publicly, but SCTP is an actively supported protocol at F5 and we have a number of customers using it in production. =46rom what I can tell these deployments don't generally face the public internet. Rather, they tend to be internal to the customer's network, or used to interface with another organization's network. One example I see a lot of is Diameter communication links within and between telecoms, using SCTP as a transport protocol for LTE signalling (roaming, billing, access, that sort of thing). I'd guess that nearly all Diameter messages travel over an SCTP link at some point in their lifetime. These deployments are in a controlled network environment, so the SCTP doesn't need to be sat on top of UDP in order to transit the commodity internet intact (particularly, the home "plastic routers" which cause so much heartache). Also, being invisible to people who aren't inside a telco, it can be easy to overlook :) I've seen other protocols run over SCTP, but rarely. Most application protocols aren't designed to use the services that SCTP has on offer, and so they expend effort to create the functions they need in a TCP or UDP environment, often partially duplicating what SCTP can already do. Taking one of these and putting SCTP under it doesn't make a lot of business sense, even as much as I personally like SCTP and would like to see more of it in the wild. --=20 astrid smith ------------------- --<[ c y b e r | s o f t w a r e | e n g i n e e r ]>-- ------------ ------------------ On Thu, Mar 01, 2018 at 04:09:15PM +0000, Samuel DeLaughter wrote: > Hi All, >=20 > I am doing some research on SCTP and am trying to find data on the > current scope of its deployment. Does anyone here have information > that they may be able to share? Perhaps you run a network that has > seen some SCTP traffic, or you work on an application that uses > SCTP. To my knowledge the only major application that currently > utilizes it is WebRTC, does anyone know of others? Any help would > be greatly appreciated. >=20 > Thank You, > Sam >=20 > -- > -- > Samuel DeLaughter > Doctoral Student & Research Assistant > Advanced Network Architecture Group > MIT Computer Science and Artificial Intelligence Laboratory >=20 From nobody Sat Mar 3 08:25:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC01267BB for ; Sat, 3 Mar 2018 08:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoE4JlBTBKGD for ; Sat, 3 Mar 2018 08:25:36 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAEB1200B9 for ; Sat, 3 Mar 2018 08:25:36 -0800 (PST) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B4A901B0013B; Sat, 3 Mar 2018 16:25:34 +0000 (GMT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 9C30B20A7B; Sat, 3 Mar 2018 11:25:31 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Sat, 03 Mar 2018 11:25:31 -0500 X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 0165424608; Sat, 3 Mar 2018 11:25:30 -0500 (EST) Date: Sat, 3 Mar 2018 16:25:28 +0000 From: Tom Jones To: Derek Fawcus Cc: tsvwg@ietf.org Message-ID: <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180303140456.GA39320@accordion.employees.org> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 16:25:39 -0000 Hi Derek, I have an implementation for FreeBSD (and 3 others to support that work) comments inline On Sat, Mar 03, 2018 at 02:04:56PM +0000, Derek Fawcus wrote: > On Fri, Jan 19, 2018 at 07:18:41PM -0800, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Transport Area Working Group WG of the IETF. > > Two of the points raised before adoption were: > a) if the OCS field should be optional > b) if the checksum over the otions (which OCS provides) should be 16 bits > see this thread: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14926.html > > This effectively got deferred until after adoption. > > I was proposing that the current OCS option be discarded, and replaced with > a fixed length 16 bit checksum field at the start of the surplus area. > This would then use the usual internet checksum algorithm, such that the > whole of the surplus area, including this checksum, should sum to zero. > I also suggested how this would work when the FRAG mechanism was in use. > > The main reason for this was simplicity for implementors, in that they'd not > have to write and verify a new checksum routine, but could use their > existing algorithm. The existing 16 bit routines I have looked at are tuned assembly available for all platforms. The draft suggests "folding over" the result of a 16 bit calculation which is probably a similar amount of code to writing an 8 bit sum. > It would also be simpler to implement in that the checksum would be in > a known fixed location, hence verification would be simpler. > > In theory, if one did not wish to use a checksum, one could store the > 0x0000 value there, and always use 0xffff to represent a 1's complement > value of zero. > > The cost of the above is that one always consumes 2 bytes from the surplus > area to represent this, even if one does not wish to checksum the options > area. Whereas if one does wish to checksum the options, it consumes the > same space as the current scheme. I'd argue that for robustness reasons, > one would almost always wish to checksum the options area. I'd suggest > that the above scheme is actually simpler than the current one. > I am against allowing 0 checksums for the option space. I see the option space overhead as always being 3 bytes (OCS+EOL) and most of the time being 4 bytes (OCS+NOP+EOL). > So I am again proposing: > > 1) Remove the OCS option. > 2) Add a fixed length 16 bit checksum field at a known location > (The start of the surplus area). I am happy with this suggestion. I would prefer using the already implemented 16 bit checksums, less code is better. > 3) Potentially allow one to store 0x0000 in that field to indicate the > options themselves are not protected by a checksum. I do not think a 0 checksum a good idea. - [tj] From nobody Sat Mar 3 08:40:07 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335C4124BAC for ; Sat, 3 Mar 2018 08:40:05 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e9W_9M4pBSC for ; Sat, 3 Mar 2018 08:40:03 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811821204DA for ; Sat, 3 Mar 2018 08:40:03 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id A25592D50D0; Sat, 3 Mar 2018 16:40:02 +0000 (UTC) Date: Sat, 3 Mar 2018 16:40:02 +0000 From: Derek Fawcus To: Tom Jones Cc: tsvwg@ietf.org Message-ID: <20180303164002.GD39320@accordion.employees.org> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 16:40:05 -0000 On Sat, Mar 03, 2018 at 04:25:28PM +0000, Tom Jones wrote: > On Sat, Mar 03, 2018 at 02:04:56PM +0000, Derek Fawcus wrote: > > > > In theory, if one did not wish to use a checksum, one could store the > > 0x0000 value there, and always use 0xffff to represent a 1's complement > > value of zero. > > I am against allowing 0 checksums for the option space. I'd tend to agree, but had to mention it in case someone else believes there is a sensible case for sending packets sans OCS in the current scheme. > I see the option space overhead as always being 3 bytes (OCS+EOL) and > most of the time being 4 bytes (OCS+NOP+EOL). > > > So I am again proposing: > > > > 1) Remove the OCS option. > > 2) Add a fixed length 16 bit checksum field at a known location > > (The start of the surplus area). > > I am happy with this suggestion. > > I would prefer using the already implemented 16 bit checksums, less code > is better. I had in mind simply using the well known 1's complement of the 1's complement sum of the data; as used in the IPv4 header, UDP header, TCP header etc. DF From nobody Sat Mar 3 08:53:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32072124BAC for ; Sat, 3 Mar 2018 08:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBVhweG7IGt1 for ; Sat, 3 Mar 2018 08:53:24 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 2711D1204DA for ; Sat, 3 Mar 2018 08:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/k75pQNL7t436beXrG96owPmUkjmFkIEskXLNl5Xz+k=; b=CZNqUSXb8SVGcArBI6PIf0V+G fGyKmshpej2fBFkjwlYpjt84qzYqpOjYgDKaFVOIaDIWeBAGGRA6qF/aI3DHTkQWRVJfEa8ChwVQN liJDIHqkPEhh7dIl7om9aBVP7vVsgXfqaADSohgiBYHVh/tgvWHhQdxNuZ0X3seJkkjxNohydi12h p6g8ALU/L7pzeNsC/+XlZE2+/nteqa/c3h8YVP6q9DsxKznhvxrmSwS97RGMO/4I9vFGR26G6iu7M Mk4JDhQjyCUnKSjSIQkVIiz/QQWvTxFT030ojly1RRDVilKcJ5mmvHwIwBVQEbyVtHjgzgLdVgAdF 9fe98v84w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64093 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esAPM-003lsd-Az; Sat, 03 Mar 2018 11:53:18 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180303140456.GA39320@accordion.employees.org> Date: Sat, 3 Mar 2018 08:53:15 -0800 Cc: tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8EF7F637-A3A4-40C6-B9BF-750A454D0517@strayalpha.com> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 16:53:26 -0000 HI, Derek, As I mentioned, there are queued updates not yet applied to the = currently posted version. They will be incorporated in the next release. Joe > On Mar 3, 2018, at 6:04 AM, Derek Fawcus = wrote: >=20 > On Fri, Jan 19, 2018 at 07:18:41PM -0800, internet-drafts@ietf.org = wrote: >>=20 >> 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 WG of = the IETF. >=20 > Two of the points raised before adoption were: > a) if the OCS field should be optional > b) if the checksum over the otions (which OCS provides) should be 16 = bits > see this thread: = https://www.ietf.org/mail-archive/web/tsvwg/current/msg14926.html >=20 > This effectively got deferred until after adoption. >=20 > I was proposing that the current OCS option be discarded, and replaced = with > a fixed length 16 bit checksum field at the start of the surplus area. > This would then use the usual internet checksum algorithm, such that = the > whole of the surplus area, including this checksum, should sum to = zero. > I also suggested how this would work when the FRAG mechanism was in = use. >=20 > The main reason for this was simplicity for implementors, in that = they'd not > have to write and verify a new checksum routine, but could use their > existing algorithm. It would also be simpler to implement in that the > checksum would be in a known fixed location, hence verification would = be > simpler. >=20 > In theory, if one did not wish to use a checksum, one could store the > 0x0000 value there, and always use 0xffff to represent a 1's = complement > value of zero. >=20 > The cost of the above is that one always consumes 2 bytes from the = surplus > area to represent this, even if one does not wish to checksum the = options > area. Whereas if one does wish to checksum the options, it consumes = the > same space as the current scheme. I'd argue that for robustness = reasons, > one would almost always wish to checksum the options area. I'd = suggest > that the above scheme is actually simpler than the current one. >=20 > So I am again proposing: >=20 > 1) Remove the OCS option. > 2) Add a fixed length 16 bit checksum field at a known location > (The start of the surplus area). > 3) Potentially allow one to store 0x0000 in that field to indicate the > options themselves are not protected by a checksum. >=20 > How do others view this? >=20 > DF >=20 From nobody Sat Mar 3 08:54:44 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCCC124BAC for ; Sat, 3 Mar 2018 08:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqP9aXIlrRH5 for ; Sat, 3 Mar 2018 08:54:41 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 3D6B81204DA for ; Sat, 3 Mar 2018 08:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=h5nyrSa4r57s9MKN96QWbDheQOpaHivsHiuigz6Vjhs=; b=XSmN4VrzvtAC9R/iS76LBXYFX G1zfDib4dbUVAN+8rVaiXnQ7NMD92DZVWBlWhFMlFiHOpU2ddWXpxhT2XUOF4E2u74CCeX/gM0oGo S7/xkBYD3bnSoudVeHzPxm6uP0dKyrCxYsZbn39g2ToVPulkEyponkTw4ZECnOewdxP3gig4V4f8T VFlPV1wLZ7iyiyhAToKA65Dygp+t1bfy/3lGibgW9Jrn/Bl3enrGS2IlpgKnBNYki1Z7Lb6tltuGx QOU/yfRETFC4abPGh/BYOWUI8ml5FAoiUboYcaE0vuLl/dADkb7VdnBm35M/4jEf+ugbPn8+VpqxG u1fGMiTpA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64096 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esAQQ-003n2B-PB; Sat, 03 Mar 2018 11:54:24 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F8D1D718-B029-4ED0-9478-D4FC6EAEBF12" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> Date: Sat, 3 Mar 2018 08:54:21 -0800 Cc: Derek Fawcus , tsvwg@ietf.org Message-Id: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> To: Tom Jones X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 16:54:43 -0000 --Apple-Mail=_F8D1D718-B029-4ED0-9478-D4FC6EAEBF12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, > On Mar 3, 2018, at 8:25 AM, Tom Jones wrote: ... >=20 > The draft suggests "folding over" the result of a 16 bit calculation > which is probably a similar amount of code to writing an 8 bit sum. It is the following operation: // sum here is the 16 bit value sum =3D ((sum && 0xff00) >> 8) + (sum && 0x00ff); // first foldover, but it might have a carry, so do it one more = time sum =3D ((sum && 0xff00) >> 8) + (sum && 0x00ff); // second foldover is done It should compile to roughly an additional 6 opcodes that in 2-way = parallelism could be computed in 4 instruction cycles. (I can add that to the doc) >> It would also be simpler to implement in that the checksum would be = in >> a known fixed location, hence verification would be simpler. >>=20 >> In theory, if one did not wish to use a checksum, one could store the >> 0x0000 value there, and always use 0xffff to represent a 1's = complement >> value of zero. >>=20 >> The cost of the above is that one always consumes 2 bytes from the = surplus >> area to represent this, even if one does not wish to checksum the = options >> area. Whereas if one does wish to checksum the options, it consumes = the >> same space as the current scheme. I'd argue that for robustness = reasons, >> one would almost always wish to checksum the options area. I'd = suggest >> that the above scheme is actually simpler than the current one. >>=20 >=20 > I am against allowing 0 checksums for the option space. =20 At best, the default should be that the checksum is used. >=20 >> So I am again proposing: >>=20 >> 1) Remove the OCS option. >> 2) Add a fixed length 16 bit checksum field at a known location >> (The start of the surplus area). >=20 > I am happy with this suggestion.=20 The use of a fixed location is just the typical trade-off between space = and complexity. Using an optional checksum allows its removal to save = space. I don=E2=80=99t have a strong position as to how to pick between the = two. The primary reason for the foldover, FWIW, was to save space (by adding = a few opcodes and weakening the sum). > I would prefer using the already implemented 16 bit checksums, less = code > is better. Others raised concerns about using the existing IP checksum, but it = would have the benefit of potential support using existing accelerator = hardware. >=20 >> 3) Potentially allow one to store 0x0000 in that field to indicate = the >> options themselves are not protected by a checksum. >=20 > I do not think a 0 checksum a good idea. IMO, the sum needs to be optional, regardless of mechanism. Even with IPv6 we see many places where UDP checksums are disabled = (largely tunnel uses). Not having that potential here would be = problematic for some intended users. Joe= --Apple-Mail=_F8D1D718-B029-4ED0-9478-D4FC6EAEBF12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

On Mar 3, 2018, at 8:25 AM, Tom Jones <tom@erg.abdn.ac.uk> = wrote:
...

The draft suggests "folding = over" the result of a 16 bit calculation
which is probably a similar = amount of code to writing an 8 bit sum.

It is the = following operation:

// sum = here is the 16 bit value
sum =3D ((sum && 0xff00) = >> 8) + (sum && 0x00ff);
// first = foldover, but it might have a carry, so do it one more = time
sum =3D ((sum && 0xff00) >> 8) + (sum = && 0x00ff);
// second foldover is = done

It should = compile to roughly an additional 6 opcodes that in 2-way parallelism = could be computed in 4 instruction cycles.

(I can add that to the doc)

It would also be simpler to = implement in that the checksum would be in
a known fixed = location, hence verification would be simpler.

In theory, if one did not wish to use a checksum, one could = store the
0x0000 value there, and always use 0xffff to = represent a 1's complement
value of zero.

The cost of the above is that one always consumes 2 bytes = from the surplus
area to represent this, even if one does = not wish to checksum the options
area.  Whereas if = one does wish to checksum the options, it consumes the
same = space as the current scheme.  I'd argue that for robustness = reasons,
one would almost always wish to checksum the = options area.  I'd suggest
that the above scheme is = actually simpler than the current one.


I am against allowing 0 checksums for the = option space.  

At best, = the default should be that the checksum is used.


So I am again proposing:

1) Remove the OCS option.
2) Add = a fixed length 16 bit checksum field at a known location
  (The start of the surplus area).

I am happy with this suggestion. 

The use of = a fixed location is just the typical trade-off between space and = complexity. Using an optional checksum allows its removal to save = space.
I don=E2=80=99t have a strong position as to how to = pick between the two.

The = primary reason for the foldover, FWIW, was to save space (by adding a = few opcodes and weakening the sum).

I would prefer using the already implemented 16 = bit checksums, less code
is better.

Others = raised concerns about using the existing IP checksum, but it would have = the benefit of potential support using existing accelerator = hardware.


3) Potentially allow one to store 0x0000 in that field to = indicate the
  options themselves are not = protected by a checksum.

I do not think a 0 checksum a good = idea.

IMO, the sum needs to be optional, regardless of = mechanism.

Even with IPv6 we see = many places where UDP checksums are disabled (largely tunnel uses). Not = having that potential here would be problematic for some intended = users.

Joe
= --Apple-Mail=_F8D1D718-B029-4ED0-9478-D4FC6EAEBF12-- From nobody Sat Mar 3 09:00:28 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF66126DED for ; Sat, 3 Mar 2018 09:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahujDhjVVh8b for ; Sat, 3 Mar 2018 09:00:24 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 7D841126CD6 for ; Sat, 3 Mar 2018 09:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QeZQQPSgHPCajokXEw8y3se68L9gMnZr/19zzJvjboA=; b=LXSy3nLRmShH6yBeMnU7WhXet XLhsDUx2OSpPwqV8Vo/wKvTTMYi8rr6U70UlVzXtUZ4sRVPH7zEnN+CFWYe6BnvHFPtAEv5mKGCMa bO6E5Qw/AxSz7YhKugqEZ38/Uf3UyTIx0dK9XLCYZw+KQZaK0INkM565eQQeAGriSDOTtuagTBBpJ wVQzBrqbzJGKA9UtPkbqJL9lRctkeqzYAUIZTgIem3wX2hiHuQdSuY1vjTzdDVmfdyk+l841xUQDX yfWK2ml3MKE/T6wjGQ/vIZTqEVPKZcovPcFuWf1SK542LMCBOL1jDCORG0PXOFuoGtZL3xejf8Hr7 wliEAMC1w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64146 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esAW6-003td9-FW; Sat, 03 Mar 2018 12:00:22 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A4DBA44-1D96-499B-88A4-F64B4FFCEED4" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180303164002.GD39320@accordion.employees.org> Date: Sat, 3 Mar 2018 09:00:13 -0800 Cc: Tom Jones , tsvwg@ietf.org Message-Id: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <20180303164002.GD39320@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 17:00:26 -0000 --Apple-Mail=_2A4DBA44-1D96-499B-88A4-F64B4FFCEED4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 3, 2018, at 8:40 AM, Derek Fawcus = wrote: >=20 >> I would prefer using the already implemented 16 bit checksums, less = code >> is better. >=20 > I had in mind simply using the well known 1's complement of > the 1's complement sum of the data; as used in the IPv4 header, UDP = header, > TCP header etc. OCS as described in the current code *is* that checksum, except as = follows: 1) it wasn=E2=80=99t inverted after the end of the sum 2) it was folded over to help the OCS option maintain 16-bit alignment, = and because the additional power of the 16-bit value is not needed All of that is =E2=80=9Cpost processing=E2=80=9D; even existing code or = hardware can be used by simply inverting the result and then folding the = result over. Inverting the *final* result is required if the OCS field is required = but its use is optional. Here=E2=80=99s how it would work with existing code: ics =3D internetsum(data) ics =3D ~ics ics =3D foldover(ics) // see previous email for code) ics =3D ~ics Joe= --Apple-Mail=_2A4DBA44-1D96-499B-88A4-F64B4FFCEED4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 3, 2018, at 8:40 AM, Derek Fawcus <dfawcus+lists-tsvwg@employees.org> wrote:

I would prefer using the = already implemented 16 bit checksums, less code
is = better.

I had in mind simply using the = well known 1's complement of
the 1's complement sum of the = data; as used in the IPv4 header, UDP header,
TCP header = etc.

OCS as described in the current code *is* that checksum, = except as follows:

1) it wasn=E2=80=99t inverted after the end of the = sum
2) it was folded over to help the OCS option = maintain 16-bit alignment, and because the additional power of the = 16-bit value is not needed

All of that is =E2=80=9Cpost processing=E2=80=9D; even = existing code or hardware can be used by simply inverting the result and = then folding the result over.

Inverting the *final* result is = required if the OCS field is required but its use is optional.

Here=E2=80=99s how it = would work with existing code:
= ics =3D internetsum(data)
ics =3D = ~ics
ics =3D foldover(ics)  // see = previous email for code)
ics =3D = ~ics

Joe
= --Apple-Mail=_2A4DBA44-1D96-499B-88A4-F64B4FFCEED4-- From nobody Sat Mar 3 12:53:04 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D72D126C22 for ; Sat, 3 Mar 2018 12:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvbVR6APzykN for ; Sat, 3 Mar 2018 12:53:01 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 BAC3E124217 for ; Sat, 3 Mar 2018 12:53:00 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id a23so16117022qtn.0 for ; Sat, 03 Mar 2018 12:53:00 -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:from:date:message-id:subject:to :cc; bh=0ApCs2bohP8BnQYSl1lqakcqyTu4WlHBBMetMVVDLU4=; b=KJNF2RsdRe4yWHP12URWoU8yMMEhuqKyhpTwBOxRetEn+lhTXxAufSGhCjdsLTNkwl +OPRBMQzEc/ksEMHZwZoJlQvVWUzGgvYZra4g2CUqvlRhDDMS/S/kkhM/BNMpg/ugQe7 Liidk7pZ/UGicNwIl9eQwf5373meSRiVNXC7iDbvc7DEAo7y4NJTu+G76c9+ff60baf3 z7KjbIsu4ca+QKJ3wGqN8/0v0UAeBNfdrSPQesFidC4uEaPcVzbFiAwQdV9F7youEOyE Ni52u4qY8q9mzMDjsjrzhszWqKtWm8yHxf/8EKfPnk0fizCZBPyB3m1DIE3I8JeOq0o6 OosA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ApCs2bohP8BnQYSl1lqakcqyTu4WlHBBMetMVVDLU4=; b=p1MmJH+Tzn/OO44+tUqT6xc0m7P0TW9+fvc23BePW0RPLK+UBS0xTeE5sTIEQfxykM 7uJL8zmGtjvMNuQzs76FfpkgyeUxCk6R5KNl6GeV/sdpzOHBZp7waAwfiUq1NW3stO5F o8vhpqNUhTEKnqWDorziYUT11zSJGQawvE5OLhjEAI8sf8ZOiNX3v94XHrQPIfg+Cg/g RsotCnYcszUUYdVmWxrs0YGNFPACweuRKJmzTHWU6cfWipnDnlM8A371bUo7KpIjD4hf FDYFeqg8ukbgry+Gdw4y7EDlEc5agpUY9iMbcckk8qUCBLEKxe2EDw1fVhU9kduLaV+5 15UA== X-Gm-Message-State: AElRT7H2eBSlDU39+Cos8iGn7qiBfRNT0YcSWvE/4hWR0CT7J/04pvxU PhRn/tzR14qcaNd21+t7q+JRWexY6tfmjZC7h/sqeA== X-Google-Smtp-Source: AG47ELuGX8UyzOYu56bSbnKOxi2rbUua512xfC+rNTB0fuSjgPNBnu9JuC9zPIwTXlg9BfIO7RLOFmfJU2bnnB6Ij20= X-Received: by 10.200.1.142 with SMTP id x14mr14396291qtf.142.1520110379614; Sat, 03 Mar 2018 12:52:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 12:52:58 -0800 (PST) Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 12:52:58 -0800 (PST) In-Reply-To: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> From: Tom Herbert Date: Sat, 3 Mar 2018 12:52:58 -0800 Message-ID: To: Joe Touch Cc: Tom Jones , tsvwg Content-Type: multipart/alternative; boundary="f403045e7cfa325da505668847c7" Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 20:53:02 -0000 --f403045e7cfa325da505668847c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mar 3, 2018 8:54 AM, "Joe Touch" wrote: Hi, all, On Mar 3, 2018, at 8:25 AM, Tom Jones wrote: ... The draft suggests "folding over" the result of a 16 bit calculation which is probably a similar amount of code to writing an 8 bit sum. It is the following operation: // sum here is the 16 bit value sum =3D ((sum && 0xff00) >> 8) + (sum && 0x00ff); // first foldover, but it might have a carry, so do it one more time sum =3D ((sum && 0xff00) >> 8) + (sum && 0x00ff); // second foldover is done It should compile to roughly an additional 6 opcodes that in 2-way parallelism could be computed in 4 instruction cycles. (I can add that to the doc) It would also be simpler to implement in that the checksum would be in a known fixed location, hence verification would be simpler. In theory, if one did not wish to use a checksum, one could store the 0x0000 value there, and always use 0xffff to represent a 1's complement value of zero. The cost of the above is that one always consumes 2 bytes from the surplus area to represent this, even if one does not wish to checksum the options area. Whereas if one does wish to checksum the options, it consumes the same space as the current scheme. I'd argue that for robustness reasons, one would almost always wish to checksum the options area. I'd suggest that the above scheme is actually simpler than the current one. I am against allowing 0 checksums for the option space. At best, the default should be that the checksum is used. So I am again proposing: 1) Remove the OCS option. 2) Add a fixed length 16 bit checksum field at a known location (The start of the surplus area). I am happy with this suggestion. The use of a fixed location is just the typical trade-off between space and complexity. Using an optional checksum allows its removal to save space. I don=E2=80=99t have a strong position as to how to pick between the two. The primary reason for the foldover, FWIW, was to save space (by adding a few opcodes and weakening the sum). I would prefer using the already implemented 16 bit checksums, less code is better. Others raised concerns about using the existing IP checksum, but it would have the benefit of potential support using existing accelerator hardware. The benefit is more likely from using optimized routines to do checksum that HW offload. Checksum offload probably doesn't help to compute the options checksum, but it will need to be considered. For instance, if NIC returns checksum over IP packet in rx, the host will need to compute csum over options to verify udp csum regardless of whether csum is enabled in options. Tom 3) Potentially allow one to store 0x0000 in that field to indicate the options themselves are not protected by a checksum. I do not think a 0 checksum a good idea. IMO, the sum needs to be optional, regardless of mechanism. Even with IPv6 we see many places where UDP checksums are disabled (largely tunnel uses). Not having that potential here would be problematic for some intended users. Joe --f403045e7cfa325da505668847c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mar 3, 2018 8:54 AM, "Joe Touch" <touch@strayalpha.com> wrote:
Hi, all,

On Mar 3, 2018, at 8:25 AM, Tom Jones <tom@erg.abdn.ac.uk> wrote:
...


The draft suggests "folding over" the= result of a 16 bit calculation
w= hich is probably a similar amount of code to writing an 8 bit sum.

It is the following operation:

// sum here is the 16 bit value
sum =3D ((sum && 0xff00) >> 8) + (sum &= amp;& 0x00ff);
// first foldover, but it migh= t have a carry, so do it one more time
sum =3D ((= sum && 0xff00) >> 8) + (sum && 0x00ff);
// second foldover is done

It should = compile to roughly an additional 6 opcodes that in 2-way parallelism could = be computed in 4 instruction cycles.

(I can add th= at to the doc)

It would also be simpler to implemen= t in that the checksum would be in
a known fixed location, hence verific= ation would be simpler.

In theory, if one did not wish to use a chec= ksum, one could store the
0x0000 value there, and always use 0xffff to r= epresent a 1's complement
value of zero.

The cost of the abov= e is that one always consumes 2 bytes from the surplus
area to represent= this, even if one does not wish to checksum the options
area.=C2=A0 Whe= reas if one does wish to checksum the options, it consumes the
same spac= e as the current scheme.=C2=A0 I'd argue that for robustness reasons,one would almost always wish to checksum the options area.=C2=A0 I'd = suggest
that the above scheme is actually simpler than the current one.<= br>

I am against allowi= ng 0 checksums for the option space. =C2=A0
At best, the default should be that the checksum is used= .


So I am again proposing:

1) Remove the OCS option= .
2) Add a fixed length 16 bit checksum field at a known location
=C2= =A0=C2=A0(The start of the surplus area).

I am happy with this suggestion.=C2=A0

The use of a fixed location is just the typical tra= de-off between space and complexity. Using an optional checksum allows its = removal to save space.
I don=E2=80=99t have a strong position as = to how to pick between the two.

The primary reason= for the foldover, FWIW, was to save space (by adding a few opcodes and wea= kening the sum).

I would prefer usi= ng the already implemented 16 bit checksums, less code
is better.

Others raised concerns about using the existing IP checksum, but it= would have the benefit of potential support using existing accelerator har= dware.
The benefit is more likely from using optimized r= outines to do checksum that HW offload. Checksum offload probably doesn'= ;t help to compute the options checksum, but it will need to be considered.= For instance, if NIC returns checksum over IP packet in rx, the host will = need to compute csum over options to verify udp csum regardless of whether = csum is enabled in options.

Tom



3) Poten= tially allow one to store 0x0000 in that field to indicate the
=C2=A0=C2= =A0options themselves are not protected by a checksum.

I do not think a 0 checksum a good idea.

IMO, the sum needs to be op= tional, regardless of mechanism.

Even with IPv6 we= see many places where UDP checksums are disabled (largely tunnel uses). No= t having that potential here would be problematic for some intended users.<= /div>

Joe

--f403045e7cfa325da505668847c7-- From nobody Sat Mar 3 12:58:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9294C1270A7 for ; Sat, 3 Mar 2018 12:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANZx5vZ6SwM5 for ; Sat, 3 Mar 2018 12:58:38 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 14696126C22 for ; Sat, 3 Mar 2018 12:58:38 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id c7so16115704qtn.3 for ; Sat, 03 Mar 2018 12:58:38 -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:from:date:message-id:subject:to :cc; bh=Xw7JrYCsfP6REeLD81a5VZNV1U2c8hhrEBnDo6Icc7Q=; b=zQ/XKTrfTgA63rB96pHrE4mEq2Ck2CnsQK9c0AvkhtF/vmGYDLzwi7Y8LGuPZ2WuE4 eSeSNY3WpPG3olHjBwBeAZIvxjvAC+o/rQO0P5DY+D4YpbmEmzAVE/5RoAc/F1bfHTum SPVvbwFhg6lQ14LUmoW705r+c+gUbP431ZgxM8R1SsUHse5e8aAHBBIZOEpcDWmQOIV+ wX+QodjCHTEL+WEM2c7JerFCSQNvwXx2sEAcV4vjq3ULr3F4PmmLmvVpGQUZ6+o1EFjm EJSAWFJjzxwNBGryKAeOoWrLr2lsN4dx8a172XlJ3zpzP2cQ53tCmWaGqr0IVKgjCP9/ UkPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xw7JrYCsfP6REeLD81a5VZNV1U2c8hhrEBnDo6Icc7Q=; b=qhcj/lhNVP9meKIPxKJeyZ46F6G6haHFTdCzHmem21WFk/EoQgh3HTmLwi1LKB7U8v ytRltoIb9k4i3J+IfOR35yuTedFgLWShKjCf9xYBqf1BPhTOJ/h1CuPENCZl4cEJsIIM rzGWp9Bsd6E8dgixmHxwg2UnCagI4hFsskd28WGCTsY5+2vWah1+6CgxKzl7J1/RSD2y 2AhFYWCBOwhM18LRtrGqY6cZ/qWF6YjsedfQRHn+Nnk8KR+VoBnfHHrWk2C+ivO+Nuf2 aAYGLntfr7eVO1bJB3Qj7c3qR6uZoJuCJoCq/mBlnXq0cDUbyW0ZHvP2or4aRWkS3oca uH3g== X-Gm-Message-State: AElRT7FQd7TkfcvVPT9DJv25W2db/fz/rrRR9GP8FQ3g7fQKi0XPCW+s 88AQkSPAmrAkITXFnH6yMYJiaFusuUDpGVik6KsdKg== X-Google-Smtp-Source: AG47ELtaDDNrr5OeV6eUrXdI0sy30mDakDp/FsPElS4MR7K7+5PNdXvwHgkHf4gExGP6k8x2BkWTs07zdClH7OcEsW0= X-Received: by 10.200.42.15 with SMTP id k15mr15574915qtk.101.1520110717102; Sat, 03 Mar 2018 12:58:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 12:58:36 -0800 (PST) Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 12:58:36 -0800 (PST) In-Reply-To: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> From: Tom Herbert Date: Sat, 3 Mar 2018 12:58:36 -0800 Message-ID: To: Joe Touch Cc: Tom Jones , tsvwg Content-Type: multipart/alternative; boundary="001a1140d79c4ffd680566885bf6" Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 20:58:40 -0000 --001a1140d79c4ffd680566885bf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mar 3, 2018 8:54 AM, "Joe Touch" wrote: Hi, all, On Mar 3, 2018, at 8:25 AM, Tom Jones wrote: ... The draft suggests "folding over" the result of a 16 bit calculation which is probably a similar amount of code to writing an 8 bit sum. It is the following operation: // sum here is the 16 bit value sum =3D ((sum && 0xff00) >> 8) + (sum && 0x00ff); // first foldover, but it might have a carry, so do it one more time sum =3D ((sum && 0xff00) >> 8) + (sum && 0x00ff); // second foldover is done It should compile to roughly an additional 6 opcodes that in 2-way parallelism could be computed in 4 instruction cycles. (I can add that to the doc) It would also be simpler to implement in that the checksum would be in a known fixed location, hence verification would be simpler. In theory, if one did not wish to use a checksum, one could store the 0x0000 value there, and always use 0xffff to represent a 1's complement value of zero. The cost of the above is that one always consumes 2 bytes from the surplus area to represent this, even if one does not wish to checksum the options area. Whereas if one does wish to checksum the options, it consumes the same space as the current scheme. I'd argue that for robustness reasons, one would almost always wish to checksum the options area. I'd suggest that the above scheme is actually simpler than the current one. I am against allowing 0 checksums for the option space. At best, the default should be that the checksum is used. So I am again proposing: 1) Remove the OCS option. 2) Add a fixed length 16 bit checksum field at a known location (The start of the surplus area). I am happy with this suggestion. The use of a fixed location is just the typical trade-off between space and complexity. Using an optional checksum allows its removal to save space. I don=E2=80=99t have a strong position as to how to pick between the two. The primary reason for the foldover, FWIW, was to save space (by adding a few opcodes and weakening the sum). I would prefer using the already implemented 16 bit checksums, less code is better. Others raised concerns about using the existing IP checksum, but it would have the benefit of potential support using existing accelerator hardware. 3) Potentially allow one to store 0x0000 in that field to indicate the options themselves are not protected by a checksum. I do not think a 0 checksum a good idea. IMO, the sum needs to be optional, regardless of mechanism. Even with IPv6 we see many places where UDP checksums are disabled (largely tunnel uses). Not having that potential here would be problematic for some intended users. Joe, Zero UDPv6 checksum can only be used in tunneling if conditions of RFC6935 and RFC6936 are met. The requirements to use this or actually fairly strict, and it is not the intent that this is the default for tunneling. Tom Joe --001a1140d79c4ffd680566885bf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mar 3, 2018 8:54 AM, "Joe Touch" <touch@strayalpha.com> wro= te:
<= div style=3D"word-wrap:break-word;line-break:after-white-space">Hi, all,

On Mar 3, 2018, at 8:25 AM, Tom Jo= nes <tom@erg.abd= n.ac.uk> wrote:
...


The draft suggests "folding over" the result of a 16= bit calculation
which is probabl= y a similar amount of code to writing an 8 bit sum.

It is the following operation:

// sum here is the 16 bit valu= e
sum =3D ((sum && 0= xff00) >> 8) + (sum && 0x00ff);
// first foldover, but it might have a carry, so do it on= e more time
sum =3D ((sum &a= mp;& 0xff00) >> 8) + (sum && 0x00ff);
// second foldover is done

=
It should compile to roughly an additional 6 opcodes that in 2-way par= allelism could be computed in 4 instruction cycles.

(I can add that to the doc)

= It would also be simpler to implement in that the checksum would be in
a= known fixed location, hence verification would be simpler.

In theor= y, if one did not wish to use a checksum, one could store the
0x0000 val= ue there, and always use 0xffff to represent a 1's complement
value = of zero.

The cost of the above is that one always consumes 2 bytes f= rom the surplus
area to represent this, even if one does not wish to che= cksum the options
area.=C2=A0 Whereas if one does wish to checksum the o= ptions, it consumes the
same space as the current scheme.=C2=A0 I'd = argue that for robustness reasons,
one would almost always wish to check= sum the options area.=C2=A0 I'd suggest
that the above scheme is act= ually simpler than the current one.


I am against allowing 0 checksums for the option space. = =C2=A0

At best, the defau= lt should be that the checksum is used.


So I am again proposing:

1) Remove the OCS option.
2) Add a = fixed length 16 bit checksum field at a known location
=C2=A0=C2=A0(The = start of the surplus area).

I am happy with this suggestion.=C2=A0

The use of a fixed location is just the typi= cal trade-off between space and complexity. Using an optional checksum allo= ws its removal to save space.
I don=E2=80=99t have a strong posit= ion as to how to pick between the two.

The primary= reason for the foldover, FWIW, was to save space (by adding a few opcodes = and weakening the sum).

I would prefer using the already implemented 16 bit checksums, le= ss code
is better.

Others raised concerns about using the = existing IP checksum, but it would have the benefit of potential support us= ing existing accelerator hardware.


3) Pote= ntially allow one to store 0x0000 in that field to indicate the
=C2=A0= =C2=A0options themselves are not protected by a checksum.
<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I do not think a 0 checksum a good idea.=

IMO, the sum needs to be= optional, regardless of mechanism.

Even with IPv6= we see many places where UDP checksums are disabled (largely tunnel uses).= Not having that potential here would be problematic for some intended user= s.
=

Joe,
<= div dir=3D"auto">
Zero UDPv6 checksum can only b= e used in tunneling if conditions of RFC6935 and RFC6936 are met. The requi= rements to use this or actually fairly strict, and it is not the intent tha= t this is the default for tunneling.

Tom


Joe
--001a1140d79c4ffd680566885bf6-- From nobody Sat Mar 3 13:05:18 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E01B1271FD for ; Sat, 3 Mar 2018 13:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khQcoYu0viET for ; Sat, 3 Mar 2018 13:05:15 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6C5CF1270A7 for ; Sat, 3 Mar 2018 13:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=czma7SkGkmp7ZKO6rU0VvBPqflilyt1Pnqpz/acE6OI=; b=rW0Dh9oASZcPT/WpafcvAd7r6b zjNXLHUUGrvIhjFi1EidMNOkyWbHfiB+BqMagaKsNZP6Pm2E/5y6Vp/2pWvYjhieJqvsvwroYBCRv ggsukoinPhJWPulAP1auRkqr/xJ2FmEBPw/AA3c5IwL5K9HfjEJtNbx7fDcPxVbEjXtFazH8LgaVg HHrsu52rz79C2LxPvwrOVXo6WuKUJRQt6S1owg9omhJW76P38qvwg6zz9L8bqQFTwq4s+YTIChYVP W10SmowUIG+IfjfIlYAjEu/I+LOTtg/GZj9iOm9k5h5oUARGSaccI7Mk9hOv9GpFmmaavtTXPuXLk bb2TTPYA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62251 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1esEL6-0000tg-Rk; Sat, 03 Mar 2018 16:05:09 -0500 To: Tom Herbert Cc: tsvwg References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> From: Joe Touch Message-ID: Date: Sat, 3 Mar 2018 13:04:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 21:05:16 -0000 On 3/3/2018 12:58 PM, Tom Herbert wrote: > Zero UDPv6 checksum can only be used in tunneling if conditions of > RFC6935 and RFC6936 are met. The requirements to use this or actually > fairly strict, and it is not the intent that this is the default for > tunneling. For tunneling anything based on IP or UDP - even if encapsulated via an intermediary (e.g., GRE), it would be fine according to those conditions, and those are the bulk of such tunnels. Joe From nobody Sat Mar 3 13:07:54 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DB11270A7 for ; Sat, 3 Mar 2018 13:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syffTriJvvlr for ; Sat, 3 Mar 2018 13:07:51 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D1E8A124217 for ; Sat, 3 Mar 2018 13:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mrUIrh4jsWl4lLgBRYUZa243mhOYkWyQ0F7Oy1wTFjA=; b=jFRDaSxb6imSTh7wX3eDa4kLVZ GdF2GRDrg8CdQ8XPdsrBcmN8U5kZyeTsisxo2CuNqePKjJLIV/Kq8pw1vZv7h8Du9p013f/OMBKkp 6quQkYeMNchiDgVvJuON60vrmCNF2OXXLpAJtl1dCG3s5/VbOHnJovdTATcwnPqIkxwzgsGTymnn/ VfeEVJxEVoMath5BjjLeAijD13B8vOMmMHfuqIbRFFrWVyq/zMGtv2BOEy3iN14b6r42IA/PPU8KV cDoaCFpczL0Ux/M90ESsNKcQXPpIHLRiPtUHvugFYIATJX1XbX6b90WTPJCJ7PMzRK6TnKyvfKizx xUHgqSsw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62309 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1esENQ-0003Wb-Rq; Sat, 03 Mar 2018 16:07:50 -0500 To: Tom Herbert Cc: tsvwg References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> From: Joe Touch Message-ID: <5b4b8aab-b4bf-891a-276e-7bef6018b1a8@strayalpha.com> Date: Sat, 3 Mar 2018 13:07:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 21:07:53 -0000 On 3/3/2018 12:52 PM, Tom Herbert wrote: > ... > > The benefit is more likely from using optimized routines to do > checksum that HW offload. There is optimized for many different checksums already, including the ones proposed for the alternate checksum. However, there's no benefit regarding the one proposed for OCS - it's already ones complement with minor post-processing. > Checksum offload probably doesn't help to compute the options > checksum, but it will need to be considered. For instance, if NIC > returns checksum over IP packet in rx, the host will need to compute > csum over options to verify udp csum regardless of whether csum is > enabled in options. The NIC shouldn't do a checksum over the IP packet anyway - the UDP checksum doesn't include the whole IP header. Joe From nobody Sat Mar 3 13:13:53 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311E31270A7 for ; Sat, 3 Mar 2018 13:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxLCz1q9eINi for ; Sat, 3 Mar 2018 13:13:51 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 EDD2A124217 for ; Sat, 3 Mar 2018 13:13:50 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id j4so16134491qth.8 for ; Sat, 03 Mar 2018 13:13:50 -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:from:date:message-id:subject:to :cc; bh=H1sQRzVOlcOdRL+iqebnRzvrBZ86jP+dSMap5qIPgXQ=; b=cT6r7o2eEkN3XRm1o+SDjcT+HgWttwkC7NBw13c9ctJ1CnGXpdtPL6r2qwx0LkPSbB xKZkyluZR+g6LPUWPPYjKUbU/JEv0vwBeT7DGMuM44VYpHj8V9SLThGkqq+R5bYXX5aA UHn4r8vLP+aeyzlKHYYgn0/iBh7bEKZNexI97qxqWliM6rr7H5IaIiqeoYujXJZiDU4z YrikT5DXNBCFM+5GVEPllJtVFy2nxtB3KlRA2Px4YMTuAoUTWYt4uG9v2tuEFB4AH9sr IC64/gMZcGxHn4ZU4mrOwVtPsUqilrep0Rm6x0qnp8vUlEcw0u7GfeKNQ41dJ306k6mo CbNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H1sQRzVOlcOdRL+iqebnRzvrBZ86jP+dSMap5qIPgXQ=; b=SZkCWAu8jDBQu4fVZVoN8pXf3Z7MM0vHbs9pt35TOV7NCTeSm1UHc7HqE7UMj0bn8a r8DlLMs/8BM5Dq8kO54oXobMGW5XPgTERjAMUa1E4mvCogprw+DPUNhrZZgGwUfQ0fen tEWeEdzY2c9cMR92vCI1UxoLdlB9tJTCimvVh4uAnQ1+o+97eIbcK21SdWRBzQd9nAx6 3X5fKRZhjfMUZze9SBUmmPQddTFpb4LiAW19Q7n+kqOA/iqZJ5v1iII5SCSnlZQ4jYAW 5zo7aGGrFj8i8zl9FdQ6xBvUO8qVELSwhmBlMJUlUxbImrm/Vm6oOJPaGKVX5nJcn7uq JYcg== X-Gm-Message-State: AElRT7FZgTP786+kFrfpTHz0hjbUFDLE7AMdlm2J7RM3DyHZs7rEpSOB hyZxSVnbK3Sl7U7TO9MvqMKzBDspyzXvDlD+d0jDsQ== X-Google-Smtp-Source: AG47ELt23TG3WS0ZhLM7xNuyJnLInpFci4EbQ4u50ICta6kL1JChLfYKA8CXBiqFZ9eNj+ZYIivRcgxYG+0BRPb7Qq4= X-Received: by 10.200.52.73 with SMTP id v9mr15265639qtb.66.1520111629853; Sat, 03 Mar 2018 13:13:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 13:13:49 -0800 (PST) Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 13:13:49 -0800 (PST) In-Reply-To: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> From: Tom Herbert Date: Sat, 3 Mar 2018 13:13:49 -0800 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="001a11414b9ab77e960566889181" Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 21:13:52 -0000 --001a11414b9ab77e960566889181 Content-Type: text/plain; charset="UTF-8" On Mar 3, 2018 1:05 PM, "Joe Touch" wrote: On 3/3/2018 12:58 PM, Tom Herbert wrote: > Zero UDPv6 checksum can only be used in tunneling if conditions of > RFC6935 and RFC6936 are met. The requirements to use this or actually > fairly strict, and it is not the intent that this is the default for > tunneling. For tunneling anything based on IP or UDP - even if encapsulated via an intermediary (e.g., GRE), it would be fine according to those conditions, and those are the bulk of such tunnels. Look at RFC8086 (GRE over UDP) section 6.2. Tom Joe --001a11414b9ab77e960566889181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mar 3, 2018 1:05 PM, "Joe Touch" <touch@strayalpha.com> wro= te:
<= div class=3D"m_4850189201703735306quoted-text">

On 3/3/2018 12:58 PM, Tom Herbert wrote:
> Zero UDPv6 checksum can only be used in tunneling if conditions of
> RFC6935 and RFC6936 are met. The requirements to use this or actually<= br> > fairly strict, and it is not the intent that this is the default for > tunneling.

For tunneling anything based on IP or UDP - even if encapsulated via = an
intermediary (e.g., GRE), it would be fine according to those
conditions, and those are the bulk of such tunnels.
Look at RFC8086 (GRE over UDP) section 6.2.
Tom


Joe


--001a11414b9ab77e960566889181-- From nobody Sat Mar 3 13:21:50 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FEF126C25 for ; Sat, 3 Mar 2018 13:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szamFuRR6Iyp for ; Sat, 3 Mar 2018 13:21:48 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 27409124217 for ; Sat, 3 Mar 2018 13:21:48 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id w142so16293040qkb.8 for ; Sat, 03 Mar 2018 13:21:48 -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:from:date:message-id:subject:to :cc; bh=TF+gpEzDVXCgfb7Q2qCESncmQg65W4Wmvn8WKd2b1Os=; b=zcqBFaZ/Jem8LN/rQI8F84QNnmWzPR/EDAbLOp2zUTbasY8OHiQflPeuCItMI0aRB2 xsAcWyYHtBjlSWJqKZD6rkk1Ty4yE+JbPNgxz/OyYihNxnw/R6EsmrI2Dr/KIhPwVgLX 3Aj8YPV4SuIaz/zOTZCtNaTTgrpmDUxHrsZVpJOlex8ezwrhr1DYNfD4QQtscCmZEScq BTcEm8ij59n0amoyDBGd9+GZlEuTXdidG+ustJa4Hi3OJKuCospimz3eTRiAUfCZ7Sxu cqUrp3huYDQl9lhJLKkB4QPsajZciNrS4Sb6RVE3WKYXp+YEOQv29lKWiqK48C5954xj /5MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TF+gpEzDVXCgfb7Q2qCESncmQg65W4Wmvn8WKd2b1Os=; b=G51ARBbrh4RNS6apuP4dX9yJG1AknrGPuLYFWRsIfEwUzTXK4+F520V1GU5Bl6Jxnr fJnSbfEmRhqipigrhxiEGbK/LPAJ35CoOkZLs28bHAL6bY0XGPsWuVn6VNNOafhYUxgv iPMDXtyl0l/0MOaYaMekcBUaYNIpheAZjjxfFAGf+XH0B56kppvV3XX1iAqWle4AcDFz czZ3p3YAxalrQlL36dnqmw3bNAHD3Py7wV6ZPwHryVkkdVSARxRATp8oSKjQBEFbGWTl V8/8fPNxDKzxCnArDa9YNdtTCulW9+p5fDiP6YyNMZ6Zvo2772kUR4ybI9Lmscw+7PxP Kw/w== X-Gm-Message-State: AElRT7ES2FxC4WEqaBmeZGEclF+mzPU9x+5QGNv6lpsM6AMWBV552X7l dBy1yj02Be5b1o0Na8pKn5A6cCQlvW/uS/J4N+BAJA== X-Google-Smtp-Source: AG47ELuLV0ukrfZY7G6vwcJObny0lwodHQMzMjjwnIkfIhTGjOBEVWMffgwzl0qA3xUNekcUE0mNOVfUsW/FvltaR0g= X-Received: by 10.55.60.12 with SMTP id j12mr14512266qka.203.1520112107135; Sat, 03 Mar 2018 13:21:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 13:21:46 -0800 (PST) Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 13:21:46 -0800 (PST) In-Reply-To: <5b4b8aab-b4bf-891a-276e-7bef6018b1a8@strayalpha.com> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <5b4b8aab-b4bf-891a-276e-7bef6018b1a8@strayalpha.com> From: Tom Herbert Date: Sat, 3 Mar 2018 13:21:46 -0800 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="001a114a12562a38cb056688ae79" Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 21:21:49 -0000 --001a114a12562a38cb056688ae79 Content-Type: text/plain; charset="UTF-8" On Mar 3, 2018 1:07 PM, "Joe Touch" wrote: On 3/3/2018 12:52 PM, Tom Herbert wrote: > ... > > The benefit is more likely from using optimized routines to do > checksum that HW offload. There is optimized for many different checksums already, including the ones proposed for the alternate checksum. However, there's no benefit regarding the one proposed for OCS - it's already ones complement with minor post-processing. Not to the extent that IP checksum has been optimized. > Checksum offload probably doesn't help to compute the options > checksum, but it will need to be considered. For instance, if NIC > returns checksum over IP packet in rx, the host will need to compute > csum over options to verify udp csum regardless of whether csum is > enabled in options. The NIC shouldn't do a checksum over the IP packet anyway - the UDP checksum doesn't include the whole IP header. Joe, That's exactly what we want NICs to do. The alternative is the NICs does DPI to find UDP or TCP or GRE checksums (legacy method). If they do that, they'll still miss them if there are extension headers or encapsulation. When we get full checksum, host can easily pull it up as headers are parsed. Any number of checksums in a packet can be verified. This technique is pretty well established now. Tom Joe --001a114a12562a38cb056688ae79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mar 3, 2018 1:07 PM, "Joe Touch" <touch@strayalpha.com> wrote:


On 3/3/2018 12:52 PM, Tom Herbert wrote:
> ...
>
> The benefit is more likely from using optimized routines to do
> checksum that HW offload.

There is optimized for many different checksums already, including th= e
ones proposed for the alternate checksum. However, there's no benefit regarding the one proposed for OCS - it's already ones complement with<= br> minor post-processing.
=
Not to the extent that IP checksum has been opt= imized.


> Checksum offload probably doesn't help to compute the options
> checksum, but it will need to be considered. For instance, if NIC
> returns checksum over IP packet in rx, the host will need to compute > csum over options to verify udp csum regardless of whether csum is
> enabled in options.

The NIC shouldn't do a checksum over the IP packet anyway - the U= DP
checksum doesn't include the whole IP header.

Joe,

That's exactly what we want NICs to do. The alternative i= s the NICs does DPI to find UDP or TCP or GRE checksums (legacy method). If= they do that, they'll still miss them if there are extension headers o= r encapsulation. When we get full checksum, host can easily pull it up as h= eaders are parsed. Any number of checksums in a packet can be verified. Thi= s technique is pretty well established now.=C2=A0
Tom


Joe


--001a114a12562a38cb056688ae79-- From nobody Sat Mar 3 13:58:03 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D82127286 for ; Sat, 3 Mar 2018 13:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxwIb0OMWx8S for ; Sat, 3 Mar 2018 13:58:01 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 50E63127010 for ; Sat, 3 Mar 2018 13:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YfVlVHszb/xQInO7/RUhC6Okmf74NmiE7uocUwQSpdg=; b=bUhMBGgnpcu/OoVObW9Uz+Ag1 TkP+oIxFbu61kGEDIZAQJ3mBaIpW+6hyN/KyC6xeA1L3h+z1uYIRhbe3PsnoV+xV/SWUXVF0MMtxS 3STX15joA0iHZZ3hbO8M++sejadeBuueDu0wOdURukNgAFCh3loR7dB0NwmDfXCbDpdYKWHPw9OXI XadD7089A4TBzevkRAJ2RTabsJi5KyrwL1olvwMjNQ9W8dz5KWZ5hMTHE4JcrzVdrZBfYBCPzvGnG X5b8SUMTOOaEgWPBCVMdhbw++ACRpjcf3K0PKIFrbL5xsuHhZUpXqs1UJ1JIqJMm6cs+cx4xRLJer 41uxtyWXw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62421 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1esF9j-0013PM-Db; Sat, 03 Mar 2018 16:57:44 -0500 To: Tom Herbert Cc: tsvwg References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <5b4b8aab-b4bf-891a-276e-7bef6018b1a8@strayalpha.com> From: Joe Touch Message-ID: <1bc9aa54-5322-e333-16c8-df476ebc7532@strayalpha.com> Date: Sat, 3 Mar 2018 13:57:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E5132EB8FCA7DA0FDD7EFC9F" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 21:58:03 -0000 This is a multi-part message in MIME format. --------------E5132EB8FCA7DA0FDD7EFC9F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 3/3/2018 1:21 PM, Tom Herbert wrote: > > The NIC shouldn't do a checksum over the IP packet anyway - the UDP > checksum doesn't include the whole IP header. > > > Joe, > > That's exactly what we want NICs to do. Some NICs already do enough DPI to jump in at the IP payload. When the payload isn't something easily "undone" later, the work is just wasted and re-done in the "slow path" in software. However, this is all somewhat moot anyway. First, for OCS, we're already talking about using the IP checksum with minor post processing (a one's complement 8-bit sum is the same as a ones-complement 16-bit sum folded over, just as the 16-bit is the 32-bit folded over). Second, the minor differences would need to be accommodated in either hardware or software to support these options anyway. Joe --------------E5132EB8FCA7DA0FDD7EFC9F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 3/3/2018 1:21 PM, Tom Herbert wrote:
The NIC shouldn't do a checksum over the IP packet anyway - the UDP
checksum doesn't include the whole IP header.

Joe,

That's exactly what we want NICs to do.

Some NICs already do enough DPI to jump in at the IP payload. When the payload isn't something easily "undone" later, the work is just wasted and re-done in the "slow path" in software.

However, this is all somewhat moot anyway.

First, for OCS, we're already talking about using the IP checksum with minor post processing (a one's complement 8-bit sum is the same as a ones-complement 16-bit sum folded over, just as the 16-bit is the 32-bit folded over).

Second, the minor differences would need to be accommodated in either hardware or software to support these options anyway.

Joe
--------------E5132EB8FCA7DA0FDD7EFC9F-- From nobody Sat Mar 3 14:05:52 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF510127333 for ; Sat, 3 Mar 2018 14:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c4h2jtckjMD for ; Sat, 3 Mar 2018 14:05:49 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6D55D1272E1 for ; Sat, 3 Mar 2018 14:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d8uL52OhvfObP0bETEPmr962ra36U/U8UvrbegFooAM=; b=4/SmLwBdfxrR5X4KiP9NLg4VO x1BuRWAG6LWm7Vc6p8dj+zgw5X7JWEfE2W5J4DAyJJ2y8e0ti7gsuXqir8Z2rbgxsKq16j385UJsd vrLT6l2SrFu5KWhRdvuq83+ZWGpDoMGbVrD5ML/MX4bQKQrn7LPtpbvwd4halypdcoU3EqT7ZGvc0 bsGfjhgAoPm0cKfBVluOBF65F0idxhhIQALmec4hHY+9zsycumkpE4WFLXXBoQSM0n6YevsKV0cN2 FZTCzv6ixi3KWxesY8mtexsLVgsO8VPmINQgX5BPrKbBSz7Ad3eMphjhxrNYtdUWoghq71CKv/0zu hnTJez6Hw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62464 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1esFHd-001CTd-7w; Sat, 03 Mar 2018 17:05:43 -0500 To: Tom Herbert Cc: tsvwg References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> From: Joe Touch Message-ID: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> Date: Sat, 3 Mar 2018 14:05:37 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------29B8F4E3CEF550CD3BC52706" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 22:05:51 -0000 This is a multi-part message in MIME format. --------------29B8F4E3CEF550CD3BC52706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 3/3/2018 1:13 PM, Tom Herbert wrote: > > > On Mar 3, 2018 1:05 PM, "Joe Touch" > wrote: > > > > On 3/3/2018 12:58 PM, Tom Herbert wrote: > > Zero UDPv6 checksum can only be used in tunneling if conditions of > > RFC6935 and RFC6936 are met. The requirements to use this or > actually > > fairly strict, and it is not the intent that this is the default for > > tunneling. > > For tunneling anything based on IP or UDP - even if encapsulated > via an > intermediary (e.g., GRE), it would be fine according to those > conditions, and those are the bulk of such tunnels. > > Look at RFC8086 (GRE over UDP) section 6.2. That section already points out the permission to turn those checksums off (which is why we want to support it as well). And, AFAIR, that section is written to carefully advise against turning off that checksum except in what turns out to be the most common case - using GRE in UDP as an IP or Ethernet tunnel. In that case, the tunneled traffic does not need any particular new protection, especially when the GRE checksum is used instead. So again, there's no point in UDP options being more strict than the rest of UDP here. In both cases, the use of the checksum is recommended by default (now anyway) and in both cases both should be capable of being disabled if desired. Joe --------------29B8F4E3CEF550CD3BC52706 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 3/3/2018 1:13 PM, Tom Herbert wrote:


On Mar 3, 2018 1:05 PM, "Joe Touch" <touch@strayalpha.com> wrote:


On 3/3/2018 12:58 PM, Tom Herbert wrote:
> Zero UDPv6 checksum can only be used in tunneling if conditions of
> RFC6935 and RFC6936 are met. The requirements to use this or actually
> fairly strict, and it is not the intent that this is the default for
> tunneling.

For tunneling anything based on IP or UDP - even if encapsulated via an
intermediary (e.g., GRE), it would be fine according to those
conditions, and those are the bulk of such tunnels.
Look at RFC8086 (GRE over UDP) section 6.2.

That section already points out the permission to turn those checksums off (which is why we want to support it as well).

And, AFAIR, that section is written to carefully advise against turning off that checksum except in what turns out to be the most common case - using GRE in UDP as an IP or Ethernet tunnel. In that case, the tunneled traffic does not need any particular new protection, especially when the GRE checksum is used instead.

So again, there's no point in UDP options being more strict than the rest of UDP here. In both cases, the use of the checksum is recommended by default (now anyway) and in both cases both should be capable of being disabled if desired.

Joe
--------------29B8F4E3CEF550CD3BC52706-- From nobody Sat Mar 3 14:15:14 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F15127333 for ; Sat, 3 Mar 2018 14:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N59E3xj304Q1 for ; Sat, 3 Mar 2018 14:15:11 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 492191272E1 for ; Sat, 3 Mar 2018 14:15:11 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id d26so16221743qtk.10 for ; Sat, 03 Mar 2018 14:15:11 -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:from:date:message-id:subject:to :cc; bh=fgo3RbcmTcpjR6TgmFHHl8rpD4lK6moFCaJ2Yt99NNg=; b=oT6wP+1wfukkTzKFCv41Ia0B/jqNjs/3ZDwY4zoEZQMoSbgYgqmu8I/Fp70BwLvInw 8uvv1qlEN3CrSBtq14pWJXXEhPsrsoxyem8FF0Y+B/vgUSQ/GpAPb2xJO9ErBqa2RrOs En/xvJsizLunZ0UBU2ZWh9q1RbKLTV/LSF2ZM7+v9ZnaSGdr+Pwc89GLx6geE2UekIY2 auAjxNnbzcNfej1AhxBxdCawvTcP8Rl1PUwaLAMB77Qvl+udQHjr1Ld2zBTuk6rvpzz6 +eQlHJ0/FID3iHaPbBCcaux0ELshhb90bySQv2ws5bRTJ2MGZ4JvMPNaZpX1hpoo7onP r77g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fgo3RbcmTcpjR6TgmFHHl8rpD4lK6moFCaJ2Yt99NNg=; b=WS7FgV8FURgRAqXFZR6L0SCMgaaut/nsK1TOz65F8RvzNMqIjsyvy0F66j6tpoWPMd 0XsQTscuCHaf7kflPMhbeXVeovihoBXc77iU02ToHSK3QnlEElsPymhZH++YTYtW2mbz Y83Crh7j7hqpsgM8dbOqyeXDG8b05mSV7lNgO9Zc89RJR2yO9BVIkMfYXXIatMMJrSn9 AuueABAe9wFT0gkb4HWskM7iZtbmUph+dgZDJJFt1YxuUFk77DY4vmMu+yFizJ2hsQ5l aaW5dx/yxcjGj4e19farO3h+fktsuyXcd5/1roD7oKFT8ActH2IgtUIf+4CBG0jaFS3N Wl9Q== X-Gm-Message-State: AElRT7GvdAJIGHEktOIHOJfkADGJjlBh/YMRQMMdAsQtj3IQ3qsMKgGS U993tT+VBUifKXJnKDwLf4cpncyj4Q9zjlFd3Cjqdw== X-Google-Smtp-Source: AG47ELv7xObUEwBuQtCu5lUsUqYHkuNmrlQbEm7eqbzHKzi3bR26xaCHsPbEH1mLHbRbCsd4KiVglyEHa4N3IlibeTA= X-Received: by 10.200.42.15 with SMTP id k15mr15814509qtk.101.1520115310313; Sat, 03 Mar 2018 14:15:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 14:15:09 -0800 (PST) Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 14:15:09 -0800 (PST) In-Reply-To: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> From: Tom Herbert Date: Sat, 3 Mar 2018 14:15:09 -0800 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="001a1140d79c16d7180566896d71" Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 22:15:13 -0000 --001a1140d79c16d7180566896d71 Content-Type: text/plain; charset="UTF-8" On Mar 3, 2018 2:05 PM, "Joe Touch" wrote: On 3/3/2018 1:13 PM, Tom Herbert wrote: On Mar 3, 2018 1:05 PM, "Joe Touch" wrote: On 3/3/2018 12:58 PM, Tom Herbert wrote: > Zero UDPv6 checksum can only be used in tunneling if conditions of > RFC6935 and RFC6936 are met. The requirements to use this or actually > fairly strict, and it is not the intent that this is the default for > tunneling. For tunneling anything based on IP or UDP - even if encapsulated via an intermediary (e.g., GRE), it would be fine according to those conditions, and those are the bulk of such tunnels. Look at RFC8086 (GRE over UDP) section 6.2. That section already points out the permission to turn those checksums off (which is why we want to support it as well). And, AFAIR, that section is written to carefully advise against turning off that checksum except in what turns out to be the most common case - using GRE in UDP as an IP or Ethernet tunnel. In that case, the tunneled traffic does not need any particular new protection, especially when the GRE checksum is used instead. The concern isn't so much protecting the tunneled packet, it's the fact that IPv6 does not have a header checksum. If UDP checksum is zero there is nothing in IP that can detect misdelivery due to corrupted destination address. In any case, UDP checksum would be independent of the options checksum as you point out. Tom So again, there's no point in UDP options being more strict than the rest of UDP here. In both cases, the use of the checksum is recommended by default (now anyway) and in both cases both should be capable of being disabled if desired. Joe --001a1140d79c16d7180566896d71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mar 3, 2018 2:05 PM, "Joe Touch" <touch@strayalpha.com> wrote:
=20 =20 =20



On 3/3/2018 1:13 PM= , Tom Herbert wrote:


On Mar 3, 2018 1:05 PM, "Joe To= uch" <touch@strayalpha.com> wrote:


On 3/3/2018 12:58 PM, Tom Herbert wrote:
> Zero UDPv6 checksum can only be used in tunneling if conditions of
> RFC6935 and RFC6936 are met. The requirements to use this or actually
> fairly strict, and it is not the intent that this is the default for
> tunneling.

For tunneling anything based on IP or UDP - even if encapsulated via an
intermediary (e.g., GRE), it would be fine according to those
conditions, and those are the bulk of such tunnels.
Look at RFC8086 (GRE over UDP) section 6.2.

That section already points out the permission to turn those checksums off (which is why we want to support it as well).

And, AFAIR, that section is written to carefully advise against turning off that checksum except in what turns out to be the most common case - using GRE in UDP as an IP or Ethernet tunnel. In that case, the tunneled traffic does not need any particular new protection, especially when the GRE checksum is used instead.

The concern isn't so much protecting the tunneled packet, i= t's the fact that IPv6 does not have a header checksum. If UDP checksum= is zero there is nothing in IP that can detect misdelivery due to corrupte= d destination address. In any case, UDP checksum would be independent of th= e options checksum as you point out.

Tom


So again, there's no point in UDP options being more strict than th= e rest of UDP here. In both cases, the use of the checksum is recommended by default (now anyway) and in both cases both should be capable of being disabled if desired.

Joe

--001a1140d79c16d7180566896d71-- From nobody Sat Mar 3 14:21:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777F5124239 for ; Sat, 3 Mar 2018 14:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaQHrYmTeDFc for ; Sat, 3 Mar 2018 14:21:24 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 2375B12025C for ; Sat, 3 Mar 2018 14:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZmNbQ4x42LhczthnuevqWBbdWVIt2ynyg3dXDuQ1McA=; b=YzheE3dpcEXFsRHtDbz17nGPjE ktbN0o+bXGu5YiLCAJEo+OfQkdE1kA1A0tLfI0hXOgcqjRA6c7h/LGNsc+s8ZP4lDkeAoLl1BL7/N +hOcx8llUL5tH+5B7l8aKuqUo99KuOu6Xr/yJxsLRAEHSlHarRfYGDL2yk7NN/KtVloK2hjwJX2nl ExZA5uW5HqcDVo83VBcETvV+fVIkmWqrZuuqlJD1NS4To42XEBKxFEID0tyGutQhYthUcc3mulIO+ DscBwmsuKstoYFNS0sYBDQQVtrEiyWRwd/XN70vT6/fh4y2mTz0oZuW+YyZFKjWzP5hcPhMLtgKVP ueADw+iQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62506 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1esFWn-001WHe-0e; Sat, 03 Mar 2018 17:21:18 -0500 To: Tom Herbert Cc: tsvwg References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> From: Joe Touch Message-ID: Date: Sat, 3 Mar 2018 14:21:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 22:21:25 -0000 On 3/3/2018 2:15 PM, Tom Herbert wrote: > The concern isn't so much protecting the tunneled packet, it's the > fact that IPv6 does not have a header checksum. If UDP checksum is > zero there is nothing in IP that can detect misdelivery due to > corrupted destination address. In any case, UDP checksum would be > independent of the options checksum as you point out. > > Tom But that's the case for existing IP over UDP tunnels, which was actually the use case for disabling UDP checksums in the first place. E.g., consider IPv6 or IPv4 traffic:         app + UDP w/checksum + IPv4 w/checksum         app + UDP w/checksum (recommended) + IPv6 (no CS) The presumption is that the IPv6 either travels over a link that has some sort of protection (or rare errors) or that the transport will help prevent a problem even if it is misdelivered. Put either of those inside UDP' + IPv6' and you're in the case where UDP' is allowed to disable the checksum because the inner UDP already has it. Replace UDP' with UDP'+UDPhdr' and that's why (and when) it's similarly OK to leave off the checksum. I.e., *for the same places where UDP can turn of its checksum, so can UDP-opts* (and for the same reasons - performance, largely when other layers are already trusted to be configured to provide the needed protection). Joe From nobody Sat Mar 3 14:41:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB431200E5 for ; Sat, 3 Mar 2018 14:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLpWNYCjRTHV for ; Sat, 3 Mar 2018 14:41:08 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 21F8E1200C5 for ; Sat, 3 Mar 2018 14:41:08 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id g60so16250938qtd.11 for ; Sat, 03 Mar 2018 14:41:08 -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:from:date:message-id:subject:to :cc; bh=rn/t0f9nv0V7PMGnOEJQJKSXg9DjLoMtL6L6qRvL9JE=; b=vUZVkzd15dXB5dI/VDNZ3TgsDRPmBz+u1co0q4YB1mU0FtEP8jiWShU7qGBaN/uQXm xLCm59/j4gPjHN+kUQ/sw6V7btQrE9EUY+YmwPyEPO91zBPXY0ROEcxEA8K5iLGIdRAI S77etb7t4muPY+xLfBVC9tZlgJs+9K7lSozZhHupgIX3uxAFjYX+CpyyHHCyj7ZUIkWt IjXliI0G4faiFRdhcLs3rwqkGgXGoxhtNBH7nisDuZtDSWDGfoW2rstxttIVeJJq159w 2/zdwIt0dpaCDD0FM8Q173agrlrmvekvl3l5bzzHdaSU7DQ2P99Qq9srsNfxOor3IcQ2 5dcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rn/t0f9nv0V7PMGnOEJQJKSXg9DjLoMtL6L6qRvL9JE=; b=cUf6pPILs5hA0a4rpgaV3lU8T8auSeLiAqhAzkMuwxWNc/ibleE8d2ez1U2RpsoH3C GjAMcVSJOrYHnGrEjb1gQ+9Svuc9umTvJACEwivS8NuUHI0OmYqk4vgK2vc0LXfu5+x2 0qv1tqOuJN50zADPAiH3Y24SyDghevJ6pjMyR5I6rn2RhM1EaV4I/vt8qY+E3MK6D7ws q322Wf7n6/bpaOlzu1XdDJdojfUMcSpq9XVxyRsI0To/9wpkyFRyu9R62I/hcb0yQ3aM 27AEFvl86hCzd5WZi0c04Q20h8O+mzKuMm/jtjtWlgVr44Y4wP1ke6eNZKqtDqKFyMkR poMA== X-Gm-Message-State: AElRT7FdVYeEpR5xBNII6p2jAnEPt9QccuKZko2xHhBYPrbFGFT+7D4u IsWbgDXWxbIByvR0WcZDqVfgHtvOA+tM9nTc6v9t5Q== X-Google-Smtp-Source: AG47ELvu9bzP3hUGB52uE/DS8sNyoeY5dWRZPduKX0I2W0UbLtX9NFEiaJw4K5jT8TLIe+bjb+DCIZIw2y+GiuiAU60= X-Received: by 10.200.8.165 with SMTP id v34mr14872595qth.162.1520116867108; Sat, 03 Mar 2018 14:41:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 14:41:06 -0800 (PST) Received: by 10.200.26.181 with HTTP; Sat, 3 Mar 2018 14:41:06 -0800 (PST) In-Reply-To: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> From: Tom Herbert Date: Sat, 3 Mar 2018 14:41:06 -0800 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="001a1144de20e1a59e056689c950" Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 22:41:10 -0000 --001a1144de20e1a59e056689c950 Content-Type: text/plain; charset="UTF-8" On Mar 3, 2018 2:21 PM, "Joe Touch" wrote: On 3/3/2018 2:15 PM, Tom Herbert wrote: > The concern isn't so much protecting the tunneled packet, it's the > fact that IPv6 does not have a header checksum. If UDP checksum is > zero there is nothing in IP that can detect misdelivery due to > corrupted destination address. In any case, UDP checksum would be > independent of the options checksum as you point out. > > Tom But that's the case for existing IP over UDP tunnels, which was actually the use case for disabling UDP checksums in the first place. E.g., consider IPv6 or IPv4 traffic: app + UDP w/checksum + IPv4 w/checksum app + UDP w/checksum (recommended) + IPv6 (no CS) The presumption is that the IPv6 either travels over a link that has some sort of protection (or rare errors) or that the transport will help prevent a problem even if it is misdelivered. Put either of those inside UDP' + IPv6' and you're in the case where UDP' is allowed to disable the checksum because the inner UDP already has it. Replace UDP' with UDP'+UDPhdr' and that's why (and when) it's similarly OK to leave off the checksum. Joe, as I said, the requirements for using a UDPv6 checksum are listed in great detail in RFC6936. I don't see a reason to redefine those here. I.e., *for the same places where UDP can turn of its checksum, so can UDP-opts* (and for the same reasons - performance, largely when other layers are already trusted to be configured to provide the needed protection). My bigger concern is still using a TLV to hold an optional checksum. If the TLV type is corrupted then receiver would not see checksum to verify it and hence the mechanism failed in it's primary purpose. We have a similar problem in GUE. The answer there was that GUE is likely used with tight coordination so it can be agreed if presence of the checksum is required. If the protocol is used between to random nodes in Internet this is a bigger concern. Tom --001a1144de20e1a59e056689c950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mar 3, 2018 2:21 PM, "Joe Touch" <touch@strayalpha.com> wro= te:
<= div class=3D"m_6862933288538541642quoted-text">

On 3/3/2018 2:15 PM, Tom Herbert wrote:
> The concern isn't so much protecting the tunneled packet, it's= the
> fact that IPv6 does not have a header checksum. If UDP checksum is
> zero there is nothing in IP that can detect misdelivery due to
> corrupted destination address. In any case, UDP checksum would be
> independent of the options checksum as you point out.
>
> Tom

But that's the case for existing IP over UDP tunnels, which was a= ctually
the use case for disabling UDP checksums in the first place.

E.g., consider IPv6 or IPv4 traffic:
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 app + UDP w/checksum + IPv4 w/checksu= m
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 app + UDP w/checksum (recommended) + IPv6 = (no CS)

The presumption is that the IPv6 either travels over a link that has
some sort of protection (or rare errors) or that the transport will help prevent a problem even if it is misdelivered.

Put either of those inside UDP' + IPv6' and you're in the case = where
UDP' is allowed to disable the checksum because the inner UDP already has it.

Replace UDP' with UDP'+UDPhdr' and that's why (and when) it= 's similarly
OK to leave off the checksum.


J= oe, as I said, the requirements for using a UDPv6 checksum are listed in gr= eat detail in RFC6936. I don't see a reason to redefine those here.

=
I.e., *for the same places where UDP can turn of its checksum, so can
UDP-opts* (and for the same reasons - performance, largely when other
layers are already trusted to be configured to provide the needed
protection).

=
My bigger concern is still using a TLV to hold an optiona= l checksum. If the TLV type is corrupted then receiver would not see checks= um to verify it and hence the mechanism failed in it's primary purpose.= We have a similar problem in GUE. The answer there was that GUE is likely = used with tight coordination so it can be agreed if presence of the checksu= m is required. If the protocol is used between to random nodes in Internet = this is a bigger concern.

Tom
--001a1144de20e1a59e056689c950-- From nobody Sat Mar 3 16:30:36 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBDF127876 for ; Sat, 3 Mar 2018 16:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCdNUHy1h-Hv for ; Sat, 3 Mar 2018 16:30:34 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 363701200C1 for ; Sat, 3 Mar 2018 16:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ttgWNk5g5AMRNSZ+xhc7UhI9ImVmSwwhIK8PLZ962R0=; b=67qUDDVM2RCjO+j8yEscOVyGF 9ykhHkkfwujklU+4Ml/U8Vb1SYARAQpvS+NRT8J+0+6Iyp329YyHbgw1DznJJeRq21O1DFXhLJAx2 HPQ7TyqH08dVGloWfqpx6afTjAuvLvsxJ8Fv5wSy+XgNqgphUco+ABjhAbq5sF0PU6rMQRM+zZ7d5 fVkpGhnxBL09MP+gOrb8+ChKNH0eurpX/3fY1NAkFWcKNRBJ8VzBdzEOdLkyicQ7Tswz5w7uw96mn TCJZMiDtbY41vQ8+VK7zYU9Zx5oV8l6Is7ualpdnWk7FLnCXnk2Bse8Aj7kjt2/ZPoIr/vVA0cIqy XftdOWUPw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64670 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esHXc-0041Um-LL; Sat, 03 Mar 2018 19:30:18 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F13CDCBF-0D02-43D9-ADCC-8D30A9EA66B9" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Sat, 3 Mar 2018 16:30:10 -0800 Cc: tsvwg Message-Id: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 00:30:36 -0000 --Apple-Mail=_F13CDCBF-0D02-43D9-ADCC-8D30A9EA66B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 3, 2018, at 2:41 PM, Tom Herbert wrote: > ... >=20 > Joe, as I said, the requirements for using a UDPv6 checksum are listed = in great detail in RFC6936. I don't see a reason to redefine those here. Agreed - the point is that checksums are optional there, even with = caveats. We don=E2=80=99t need to revisit the caveats, but i do think = that those other discussions are reasons why we need OCS to remain = optional. >=20 > I.e., *for the same places where UDP can turn of its checksum, so can > UDP-opts* (and for the same reasons - performance, largely when other > layers are already trusted to be configured to provide the needed > protection). >=20 > My bigger concern is still using a TLV to hold an optional checksum. = If the TLV type is corrupted then receiver would not see checksum to = verify it and hence the mechanism failed in it's primary purpose. We = have a similar problem in GUE. The answer there was that GUE is likely = used with tight coordination so it can be agreed if presence of the = checksum is required. If the protocol is used between to random nodes in = Internet this is a bigger concern. I=E2=80=99m not sure I agree with your concerns; finding UDP options = already relies on an uncorrupted IP header and UDP header that would not = be protected if the primary UDP checksum were off. Further, if we = can=E2=80=99t disable OCS then we=E2=80=99d be required to do twice the = work when using ACS. As with all TLV vs fixed header alternatives, there=E2=80=99s the issue = of required vs. optional space. Having TLV allows the space to be saved = when OCS isn=E2=80=99t present, and that was a concern when we discussed = this issue before (as a group via email). Finally, there=E2=80=99s the impact on LITE+FRAG and the way in which = reassembly can preserve options. That will require deeper consideration = to determine if it is possible and with what impact. The big question, IMO, is what is the gain. Given these options are = already =E2=80=9Cfloating=E2=80=9D, it=E2=80=99s hard to see why a = =E2=80=9Cfixed header=E2=80=9D is important to consider, IMO, but it=E2=80= =99d be useful to hear what others have to say too, certainly. Joe --Apple-Mail=_F13CDCBF-0D02-43D9-ADCC-8D30A9EA66B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 3, 2018, at 2:41 PM, Tom Herbert <tom@herbertland.com>= wrote:
...

Joe, as I said, the requirements for using a UDPv6 checksum = are listed in great detail in RFC6936. I don't see a reason to redefine = those here.

Agreed - the point is that checksums are optional = there, even with caveats. We don=E2=80=99t need to revisit the caveats, = but i do think that those other discussions are reasons why we need OCS = to remain optional.


I.e., *for the same places where UDP can turn of its checksum, so can
UDP-opts* (and for the same reasons - performance, largely when other
layers are already trusted to be configured to provide the needed
protection).

My bigger concern is still using a TLV to hold an optional = checksum. If the TLV type is corrupted then receiver would not see = checksum to verify it and hence the mechanism failed in it's primary = purpose. We have a similar problem in GUE. The answer there was that GUE = is likely used with tight coordination so it can be agreed if presence = of the checksum is required. If the protocol is used between to random = nodes in Internet this is a bigger = concern.

I=E2=80=99m not sure I agree with your = concerns; finding UDP options already relies on an uncorrupted IP header = and UDP header that would not be protected if the primary UDP checksum = were off. Further, if we can=E2=80=99t disable OCS then we=E2=80=99d be = required to do twice the work when using ACS.

As with all TLV vs fixed header alternatives, there=E2=80=99s the = issue of required vs. optional space. Having TLV allows the space to be = saved when OCS isn=E2=80=99t present, and that was a concern when we = discussed this issue before (as a group via email).

Finally, there=E2=80=99s the impact on LITE+FRAG and the way in = which reassembly can preserve options. That will require deeper = consideration to determine if it is possible and with what = impact.

The big question, IMO, is what is the gain. = Given these options are already =E2=80=9Cfloating=E2=80=9D, it=E2=80=99s = hard to see why a =E2=80=9Cfixed header=E2=80=9D is important to = consider, IMO, but it=E2=80=99d be useful to hear what others have to = say too, certainly.

Joe


= --Apple-Mail=_F13CDCBF-0D02-43D9-ADCC-8D30A9EA66B9-- From nobody Sat Mar 3 21:54:55 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4923124239; Sat, 3 Mar 2018 21:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ecKW7zxksSH; Sat, 3 Mar 2018 21:54:52 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 4E3221200C1; Sat, 3 Mar 2018 21:54:52 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 75657351E80E; Sun, 4 Mar 2018 05:54:48 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 4 Mar 2018 05:54:49 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Sat, 3 Mar 2018 21:54:38 -0800 From: Yingzhen Qu To: "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" CC: Lin Han , Thomas Nadeau Thread-Topic: Agenda requests for TSVWG@IETF101 Thread-Index: AQHTs31He8dVfiO+dEamE9tKlKhCog== Date: Sun, 4 Mar 2018 05:54:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.137] Content-Type: multipart/alternative; boundary="_000_A1F61D2019114A6E9F80A1DF1EF91816huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 05:54:54 -0000 --_000_A1F61D2019114A6E9F80A1DF1EF91816huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMsDQoNCkEgbmV3IGRyYWZ0IChUaGUgZHJhZnQgd2FzIHN1Z2dlc3RlZCBieSBU U1ZXRyBASUVURjEwMCkgd2FzIGp1c3Qgc3VibWl0dGVkLCBhbmQgd2XigJlkIGxpa2UgdG8gcmVx dWVzdCBhIHRpbWUgc2xvdCB0byBwcmVzZW50IGl0IEBJRVRGMTAxLg0KDQpUaXRsZTogQSBOZXcg Q29uZ2VzdGlvbiBDb250cm9sIGluIEJhbmR3aWR0aCBHdWFyYW50ZWVkIE5ldHdvcmsNClByZXNl bnRlcjogWWluZ3poZW4gUXUgKEh1YXdlaSkNClRpbWUgcmVxdWlyZWQgKGluY2x1ZGluZyBRL0Ep OiAxMCBtaW5zDQpEcmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aGFuLXRzdndnLWNjLw0KDQpJZiB0aGVyZSBpcyBhbnkgcXVlc3Rpb24sIHBsZWFzZSBraW5kbHkg bGV0IHVzIGtub3cuDQoNClRoYW5rcywNCllpbmd6aGVuDQo= --_000_A1F61D2019114A6E9F80A1DF1EF91816huaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A4A0B7643827C4881204AA12DDADCE7@huawei.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlBUIE1vbm8iOw0KCXBhbm9zZS0xOjIg NiA1IDkgMiAyIDUgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciIsc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIixzZXJpZjt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+RGVhciBDaGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5BIG5ldyBkcmFmdCAoVGhlIGRyYWZ0IHdhcyBzdWdnZXN0ZWQgYnkgVFNWV0cgQElF VEYxMDApIHdhcyBqdXN0IHN1Ym1pdHRlZCwgYW5kIHdl4oCZZCBsaWtlIHRvIHJlcXVlc3QgYSB0 aW1lIHNsb3QgdG8gcHJlc2VudCBpdCBASUVURjEwMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlRpdGxlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QSBOZXcgQ29uZ2VzdGlvbiBD b250cm9sIGluIEJhbmR3aWR0aCBHdWFyYW50ZWVkIE5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ UHJlc2VudGVyOiBZaW5nemhlbiBRdSAoSHVhd2VpKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaW1lIHJl cXVpcmVkIChpbmNsdWRpbmcgUS9BKTogMTAgbWluczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EcmFmdDog PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFuLXRzdndn LWNjLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW4tdHN2d2ct Y2MvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgdGhl cmUgaXMgYW55IHF1ZXN0aW9uLCBwbGVhc2Uga2luZGx5IGxldCB1cyBrbm93LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5ZaW5nemhlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_A1F61D2019114A6E9F80A1DF1EF91816huaweicom_-- From nobody Sun Mar 4 02:34:43 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABE2120713; Sun, 4 Mar 2018 02:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fviXCC0HvRT4; Sun, 4 Mar 2018 02:34:33 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20107.outbound.protection.outlook.com [40.107.2.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42423120454; Sun, 4 Mar 2018 02:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wQu5UEJjpl7G+JeVXtAP3kUhOa2ikcpJHlCLY3dWqYY=; b=WZSSvlmRbnUqId4fZcdpPZduB2aCKJm2QF7BW8I1uiOi+Poz9uSRGwpY4jvg3DIMHAUZy4kw85vbajBq7JZDp9hDBAqYauXiyX6uEKHVE8Rcq6KCpcSoB9P7/ge+UwO/zmgUo88pAghD3fCr+FWMeZGz5ubj3d1E43YKSbHFyNY= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2388.eurprd07.prod.outlook.com (10.169.152.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.5; Sun, 4 Mar 2018 10:34:29 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::4935:9288:dcd6:7db0]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::4935:9288:dcd6:7db0%5]) with mapi id 15.20.0567.009; Sun, 4 Mar 2018 10:34:29 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Yingzhen Qu , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" CC: Thomas Nadeau , "tcpm@ietf.org" Thread-Topic: Agenda requests for TSVWG@IETF101 Thread-Index: AQHTs31He8dVfiO+dEamE9tKlKhCoqO/3Ckg Date: Sun, 4 Mar 2018 10:34:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [2003:c6:33c2:ef00:758f:3f2e:54ea:360b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2388; 7:GbzBW6ytWbMeDgnaAMHXLEM4rKnyKClBcOe+TeehoIDahOdRqAhPmkvfFQMocoUNq/0bnJiGuTx7B1b431qcVGqqiHtxmBEErWRoz3fwum1Ah96tDtA1r/k1CXbyzivvu8d4wt42uzkPX0V2uO+afYriRenMntI35gz/MvDkK8GMGz+XG32ClioTfJMOBGHoNPBt13V/cL0RgBKaIOBHdo51QjeviDa6O0gfth5ObFh+ULALx2KqRGGzLfhE7S3/ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6ce83faf-9c61-484e-e482-08d581bb82bd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM5PR0701MB2388; x-ms-traffictypediagnostic: AM5PR0701MB2388: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231220)(11241501184)(806099)(944501244)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM5PR0701MB2388; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2388; x-forefront-prvs: 060166847D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(39380400002)(376002)(366004)(199004)(189003)(53754006)(105586002)(3280700002)(54906003)(81166006)(81156014)(99286004)(106356001)(53936002)(110136005)(8936002)(6246003)(8676002)(76176011)(7696005)(46003)(6116002)(54896002)(790700001)(6306002)(236005)(9686003)(316002)(5660300001)(606006)(6436002)(74316002)(5250100002)(2501003)(68736007)(229853002)(2950100002)(86362001)(966005)(33656002)(2201001)(25786009)(478600001)(2900100001)(55016002)(14454004)(2906002)(59450400001)(3660700001)(97736004)(102836004)(186003)(53546011)(4326008)(6506007)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2388; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XYNPhHitiHXfXsWc0Cypp0DeLhiGrnY7VZgSk/pwrnXYM1PNUNn2uHNFYFjlD/xTj1kAXdm8pTF1IvkYyrRkfG0+VBQhjf8Lx8/+2+8u6LHyiSiLYKsLHEJmAiD14ZyqqO/0RKB4JhJf/tqIyPLd0/jPgbmidNcET1JOtGewyxHje2G/qFVLQsfShxJ22lZKTbiUaGkLUtJDlWc9WFnlwrEhtMp1OZHQCtEE/3ie3mUrW2qNr+1iZkT81nd3yIrkVwKHJmclIkNVDh/jEq0mYOukaGCzbz7+/RzGt4x+/l32YbWj1EJufZ5rLdMwY3ePMt1x8XL7YgBW7+GfYGm32Y7fWXvHxnfX/65EC1000Ln2/BuiuDW9tAtJ3Nha/5hi spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB254755BA63E33173CC7C7BCE93DB0AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ce83faf-9c61-484e-e482-08d581bb82bd X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2018 10:34:29.3872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2388 Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 10:34:36 -0000 --_000_AM5PR0701MB254755BA63E33173CC7C7BCE93DB0AM5PR0701MB2547_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpGcm9tIHRoZSBhYnN0cmFjdDog4oCc4oCmIFRoaXMgZHJhZnQgcHJvcG9zZXMg YSBuZXcgVENQIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0gdXNlZCBpbiBiYW5kd2lkdGgg Z3VhcmFudGVlZCBuZXR3b3Jrcy4gIEl0IGlzIGFuIGV4dGVuc2lvbiB0byB0aGUgY3VycmVudCBU Q1Agc3RhbmRhcmRzLuKAnQ0KDQpJbiB0aGUgSUVURiwgSSBiZWxpZXZlIHRoZSBleHBlcnRpc2Ug Zm9yIHRoaXMgc3BlY2lmaWMgZG9jdW1lbnQgd291bGQgYmUgaW4gVENQTSwgd2hpY2ggaW4gQ0Mu IElmIHRoZSBhdXRob3JzIGFyZSBpbnRlcmVzdGVkIGluIGZlZWRiYWNrIG9uIHRoZSBwcm9wb3Nl ZCBtZWNoYW5pc20sIEkgd291bGQgcmVjb21tZW5kIHRvIGFzayBUQ1BNLg0KDQpBbHRlcm5hdGl2 ZWx5LCBjb3JyZXNwb25kaW5nIHJlc2VhcmNoIGNvdWxkIHBlcmhhcHMgYmUgcGVyZm9ybWVkIGlu IHRoZSBJQ0NSRy4gSUNDUkcgaGFzIHB1Ymxpc2hlZCBSRkMgNjA3NyB0byBkb2N1bWVudCBzb21l IG9mIHRoZSBvcGVuIHJlc2VhcmNoIGlzc3VlcyBpbiB0aGlzIHNwYWNlLg0KDQpNaWNoYWVsDQoN Cg0KRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgWWluZ3poZW4gUXUNClNlbnQ6IFN1bmRheSwgTWFyY2ggMDQsIDIwMTggNjo1NSBBTQ0KVG86 IHRzdndnQGlldGYub3JnOyB0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmcNCkNjOiBUaG9tYXMgTmFkZWF1 IDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4NClN1YmplY3Q6IFt0c3Z3Z10gQWdlbmRhIHJlcXVl c3RzIGZvciBUU1ZXR0BJRVRGMTAxDQoNCkRlYXIgQ2hhaXJzLA0KDQpBIG5ldyBkcmFmdCAoVGhl IGRyYWZ0IHdhcyBzdWdnZXN0ZWQgYnkgVFNWV0cgQElFVEYxMDApIHdhcyBqdXN0IHN1Ym1pdHRl ZCwgYW5kIHdl4oCZZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1lIHNsb3QgdG8gcHJlc2VudCBpdCBA SUVURjEwMS4NCg0KVGl0bGU6IEEgTmV3IENvbmdlc3Rpb24gQ29udHJvbCBpbiBCYW5kd2lkdGgg R3VhcmFudGVlZCBOZXR3b3JrDQpQcmVzZW50ZXI6IFlpbmd6aGVuIFF1IChIdWF3ZWkpDQpUaW1l IHJlcXVpcmVkIChpbmNsdWRpbmcgUS9BKTogMTAgbWlucw0KRHJhZnQ6IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhbi10c3Z3Zy1jYy8NCg0KSWYgdGhlcmUgaXMgYW55 IHF1ZXN0aW9uLCBwbGVhc2Uga2luZGx5IGxldCB1cyBrbm93Lg0KDQpUaGFua3MsDQpZaW5nemhl bg0K --_000_AM5PR0701MB254755BA63E33173CC7C7BCE93DB0AM5PR0701MB2547_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiUFQgTW9ubyI7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2 M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpDb3VyaWVyO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvdXJp ZXI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9t IHRoZSBhYnN0cmFjdDogPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+4oCc4oCmPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gVGhpcyBkcmFmdCBwcm9wb3NlcyBhIG5ldyBU Q1AgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobSB1c2VkIGluIGJhbmR3aWR0aA0KIGd1YXJh bnRlZWQgbmV0d29ya3MuJm5ic3A7IEl0IGlzIGFuIGV4dGVuc2lvbiB0byB0aGUgY3VycmVudCBU Q1Agc3RhbmRhcmRzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPuKAnTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkluIHRoZSBJRVRGLCBJIGJlbGlldmUgdGhlIGV4cGVydGlzZSBmb3IgdGhp cyBzcGVjaWZpYyBkb2N1bWVudCB3b3VsZCBiZSBpbiBUQ1BNLCB3aGljaCBpbiBDQy4gSWYgdGhl IGF1dGhvcnMgYXJlIGludGVyZXN0ZWQgaW4gZmVlZGJhY2sgb24gdGhlIHByb3Bvc2VkIG1lY2hh bmlzbSwgSSB3b3VsZCByZWNvbW1lbmQgdG8gYXNrIFRDUE0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbHRlcm5hdGl2ZWx5LCBjb3JyZXNwb25kaW5nIHJlc2Vh cmNoIGNvdWxkIHBlcmhhcHMgYmUgcGVyZm9ybWVkIGluIHRoZSBJQ0NSRy4gSUNDUkcgaGFzIHB1 Ymxpc2hlZCBSRkMgNjA3NyB0byBkb2N1bWVudCBzb21lIG9mIHRoZSBvcGVuIHJlc2VhcmNoIGlz c3VlcyBpbiB0aGlzIHNwYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IHRzdndnIFttYWlsdG86dHN2 d2ctYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WWluZ3poZW4gUXU8YnI+ DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAwNCwgMjAxOCA2OjU1IEFNPGJyPg0KPGI+VG86 PC9iPiB0c3Z3Z0BpZXRmLm9yZzsgdHN2d2ctY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9i PiBUaG9tYXMgTmFkZWF1ICZsdDt0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW3RzdndnXSBBZ2VuZGEgcmVxdWVzdHMgZm9yIFRTVldHQElFVEYxMDE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+RGVhciBDaGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5BIG5ldyBkcmFmdCAoVGhlIGRyYWZ0IHdhcyBzdWdnZXN0ZWQgYnkg VFNWV0cgQElFVEYxMDApIHdhcyBqdXN0IHN1Ym1pdHRlZCwgYW5kIHdl4oCZZCBsaWtlIHRvIHJl cXVlc3QgYSB0aW1lIHNsb3QgdG8gcHJlc2VudCBpdCBASUVURjEwMS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRpdGxlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNr Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QSBOZXcgQ29uZ2VzdGlv biBDb250cm9sIGluIEJhbmR3aWR0aCBHdWFyYW50ZWVkIE5ldHdvcms8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+UHJlc2VudGVyOiBZaW5nemhlbiBRdSAoSHVhd2VpKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaW1l IHJlcXVpcmVkIChpbmNsdWRpbmcgUS9BKTogMTAgbWluczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EcmFm dDogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFuLXRz dndnLWNjLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW4tdHN2 d2ctY2MvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYg dGhlcmUgaXMgYW55IHF1ZXN0aW9uLCBwbGVhc2Uga2luZGx5IGxldCB1cyBrbm93LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5ZaW5nemhlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_AM5PR0701MB254755BA63E33173CC7C7BCE93DB0AM5PR0701MB2547_-- From nobody Sun Mar 4 03:45:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0841243F3 for ; Sun, 4 Mar 2018 03:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6qvHlpeiTF3 for ; Sun, 4 Mar 2018 03:45:07 -0800 (PST) Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id E561112422F for ; Sun, 4 Mar 2018 03:45:06 -0800 (PST) Received: from supmail (supmail.isae.fr [10.132.1.9]) by smtpextng.isae.fr (Postfix) with ESMTP id 0248270CBF for ; Sun, 4 Mar 2018 12:47:32 +0100 (CET) Received: from smtp-secung (smtp-secung.isae.fr [192.93.254.79]) by supmail (Postfix) with ESMTP id 3D0D1C8859F for ; Sun, 4 Mar 2018 12:32:29 +0100 (CET) Received: from [192.168.1.53] (c2s31-2-83-152-88-205.fbx.proxad.net [83.152.88.205]) by smtp-secung (Postfix) with ESMTPSA id ECA8373F5A for ; Sun, 4 Mar 2018 12:47:37 +0100 (CET) To: tsvwg@ietf.org References: From: Emmanuel Lochin Message-ID: <419905ca-305b-594d-2958-fb468e6e5bb0@isae-supaero.fr> Date: Sun, 4 Mar 2018 12:45:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BA91522752EEB5BF2D54B29B" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 11:45:10 -0000 This is a multi-part message in MIME format. --------------BA91522752EEB5BF2D54B29B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Yingzhen Just for your information, you might be interested in gTFRC : https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02 which is a similar solution i.e. a CC for bandwidth guaranteed networks with TFRC. Furthermore just a quick question : in your draft does AR/VR stands for Augmented/Real Virtuality ? Regards Emmanuel On 04/03/2018 06:54, Yingzhen Qu wrote: > > Dear Chairs, > > A new draft (The draft was suggested by TSVWG @IETF100) was just > submitted, and we’d like to request a time slot to present it @IETF101. > > Title:A New Congestion Control in Bandwidth Guaranteed Network > > Presenter: Yingzhen Qu (Huawei) > > Time required (including Q/A): 10 mins > > Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > > > If there is any question, please kindly let us know. > > Thanks, > > Yingzhen > -- Emmanuel LOCHIN Professeur ISAE ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30 --------------BA91522752EEB5BF2D54B29B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Yingzhen

Just for your information, you might be interested in gTFRC : https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02
which is a similar solution i.e. a CC for bandwidth guaranteed networks with TFRC.
Furthermore just a quick question : in your draft does AR/VR stands for Augmented/Real Virtuality ?

Regards

Emmanuel

On 04/03/2018 06:54, Yingzhen Qu wrote:

Dear Chairs,

 

A new draft (The draft was suggested by TSVWG @IETF100) was just submitted, and we’d like to request a time slot to present it @IETF101.

 

Title: A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/

 

If there is any question, please kindly let us know.

 

Thanks,

Yingzhen


-- 
Emmanuel LOCHIN
Professeur ISAE

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30
--------------BA91522752EEB5BF2D54B29B-- From nobody Sun Mar 4 04:50:29 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0491270AC; Sun, 4 Mar 2018 04:50:22 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLLss3in8w1v; Sun, 4 Mar 2018 04:50:20 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9CE1243F3; Sun, 4 Mar 2018 04:50:20 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 17E7E1B0010D; Sun, 4 Mar 2018 12:49:42 +0000 (GMT) Message-ID: <5A9BEB65.6010102@erg.abdn.ac.uk> Date: Sun, 04 Mar 2018 12:49:41 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Scharf, Michael (Nokia - DE/Stuttgart)" CC: Yingzhen Qu , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , Thomas Nadeau , "tcpm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 12:50:23 -0000 I am unsure yet what the correct group of people world be to explore a "Bandwidth Guaranteed Network". The presentation last IETF looked like the work could imply a need for changes proposed to the network layer (using OAM exchnages) to set the sending rate and make those bandwidth reservations. In the end, it could result in a protocol quite different to TCP, I think this sort of change may possibly have a home in TSVWG - but first I'd agree with Michaeland would encourage a presentation of the problem statement in ICCRG to explore the issues. Gorry On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > Hi all, > > From the abstract: “…This draft proposes a new TCP congestion control > algorithm used in bandwidth guaranteed networks. It is an extension > to the current TCP standards.” > > In the IETF, I believe the expertise for this specific document would > be in TCPM, which in CC. If the authors are interested in feedback on > the proposed mechanism, I would recommend to ask TCPM. > > Alternatively, corresponding research could perhaps be performed in > the ICCRG. ICCRG has published RFC 6077 to document some of the open > research issues in this space. > > Michael > > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu > *Sent:* Sunday, March 04, 2018 6:55 AM > *To:* tsvwg@ietf.org; tsvwg-chairs@ietf.org > *Cc:* Thomas Nadeau > *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 > > Dear Chairs, > > A new draft (The draft was suggested by TSVWG @IETF100) was just > submitted, and we’d like to request a time slot to present it @IETF101. > > Title:A New Congestion Control in Bandwidth Guaranteed Network > > Presenter: Yingzhen Qu (Huawei) > > Time required (including Q/A): 10 mins > > Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > > If there is any question, please kindly let us know. > > Thanks, > > Yingzhen > From nobody Sun Mar 4 07:33:43 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1E6120726 for ; Sun, 4 Mar 2018 07:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.32 X-Spam-Level: X-Spam-Status: No, score=0.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8tKeq5VZuMM for ; Sun, 4 Mar 2018 07:33:39 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 03361120721 for ; Sun, 4 Mar 2018 07:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Content-Transfer-Encoding: Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PomGsWMrPWFN6PAhdM8eQdIqjR7Za3Q6rPW19ZD6YZM=; b=E6Vl7yCtZtIFGNCj/5150/s2HX 2aEAdxPzu+KmQLYkk0/k3DzAx3Sr/jiLNkHdNARz23Y5doYmycwRI2DvGswZqqVE27QPN2XWATiQ0 Q/IOdV0fpTDXVuzbu3CcHujpSglW9x0ELnkpsLjjNzxZIVcmgZ0Cv1SEd0YbsjDjvY+LPAQSt7FZn IaW8hY+sDO5GP8H4ZwsNkJSkP8hpc+x5RA0saozV1noRT7SwmdmxYjahsrujP5CJnQnsKFJw6O/50 xqTw3Yq+xU6idwzAkA5K+E9pBATLNkDY93tB6Weh4OETxS8QY2ftlNFtabOmyj+IDjaDB8iypwnGt OY4kM1Xw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56240 helo=[192.168.1.158]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esVdo-0032cf-Vx; Sun, 04 Mar 2018 10:33:38 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-44957F35-FBEC-4406-8ED3-BB4CA3DFF80B Mime-Version: 1.0 Content-Language: en-US From: Joe Touch X-Enigmail-Draft-Status: N1110 In-Reply-To: <20180303140456.GA39320@accordion.employees.org> X-Identity-Key: id4 Date: Sun, 4 Mar 2018 07:33:31 -0800 X-Account-Key: account5 X-Mailer: iPad Mail (15D100) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0; deliveryformat=4 Message-Id: <00DEFF55-E660-436E-AF3D-6D5620E90E35@strayalpha.com> Content-Transfer-Encoding: 7bit References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> To: Derek Fawcus , tsvwg@ietf.org X-OutGoing-Spam-Status: No, score=0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 15:33:42 -0000 --Apple-Mail-44957F35-FBEC-4406-8ED3-BB4CA3DFF80B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Derek, Back to the origin of the recent thread... > On 3/3/2018 6:04 AM, Derek Fawcus wrote: > Two of the points raised before adoption were: > a) if the OCS field should be optional > b) if the checksum over the otions (which OCS provides) should be 16 bit= s > see this thread: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14= 926.html >=20 > This effectively got deferred until after adoption. That link points to the touch-options-05 announcement. There were many updat= es since then (06..09); it was 09 that was adopted and then started the tsv-= options-00 sequence. Can you provide a more specific pointer? Joe --Apple-Mail-44957F35-FBEC-4406-8ED3-BB4CA3DFF80B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Derek,

Back to the origin of the recent thread...

On 3/3/2018 6:04 AM, Derek Fawcus wrote:

Two of the points raised before adoption were:
  a) if the OCS field should be optional
  b) if the checksum over the otions (which OCS provides) should be 16 bits
see this thread: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14926.html

This effectively got deferred until after adoption.
That link points to the touch-options-05 announcement. There were many updates since then (06..09); it was 09 that was adopted and then started the tsv-options-00 sequence.

Can you provide a more specific pointer?

Joe

--Apple-Mail-44957F35-FBEC-4406-8ED3-BB4CA3DFF80B-- From nobody Sun Mar 4 08:15:04 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBB312420B for ; Sun, 4 Mar 2018 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7gWHoc4E3qY for ; Sun, 4 Mar 2018 08:15:01 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 6EADF120726 for ; Sun, 4 Mar 2018 08:15:01 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id j4so17674591qth.8 for ; Sun, 04 Mar 2018 08:15:01 -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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e+SdkkXhrqrKV2eS1Dmte2mSb+OIBleDcxe8W8hOQwY=; b=jrMsBL3GnYoEa0LVw8LvH4yLXhvCM+niPQ/rSYT8rv+ZFIRtmv0ndMTc4rY8GskrDW P75vSMSP5CAWUNkrUm3Y5R/pQroCAjxBOJEdgdL8bQF2AzopDw2aJURZCHPYWV9EP9PC ysYAHH0BGmVDxElcHkNkTxOd/uCWYkEwhKwi6UmfoKVc5oZvr6d7F0acZfYYlP3L9zR7 fFdehwskWL9LzR2S2Pu41KLUeNdxj+jyceOwy72lphgO4NxYDXDMo96Yws4gFVGkzr5D Ta+GH2Q+L66/hcgifTiontKe+APHHHLLJqqyQluIUILmtq/52dVyX9fs0Yt4mL06IuK2 ZSLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=e+SdkkXhrqrKV2eS1Dmte2mSb+OIBleDcxe8W8hOQwY=; b=sI/ghvNljxT74+hAwudNUxwcTsGyk5TDa2OUlQfxV4CyRpW1FifGN59wkLMR1XMIyt 1/qXPqrXBXV+9AX0daSXc4ZoNMvXGFTSPp3iBG/N39vBSo3Wzzrv+gdkGyvgHmwPSCCn p8fXBpc6n5KkKG+GcmDHq3v7/E0Vfonzgc4mXLd9x2spLaxmv9h8xdmBo4RhL1KKN52D W1X4mELK55mIJhWgD1NPdSNusgvVKUqIXQjy60aaC3sL3a5+00ni2Mp0T8qR/JnTCoT3 4n7RAuVMbeqlfn6azkvS/4oRVqkUYP7D5bymY/Y0TQX+UeuL6a4NlgUrYSh/kXUx67zk QWUQ== X-Gm-Message-State: AElRT7F2sOvYhX7/SZjI/Nyf3ULfVu5zW1qCz362RrmMZxtJgWa3eS4N ta8eJpgy2QS3sceBMTN6dOpNrziw0m9XZrTyAIiOHw== X-Google-Smtp-Source: AG47ELv7d53gXsCPx/j9UA3XiawoExUvlW5BJy0JQiQreOLc8FbZjptoRAlA+omcKivk8OUgP5kNL0XrWHms9TFSCYo= X-Received: by 10.200.49.28 with SMTP id g28mr18007476qtb.279.1520180100345; Sun, 04 Mar 2018 08:15:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 08:14:59 -0800 (PST) In-Reply-To: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 08:14:59 -0800 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:15:03 -0000 On Sat, Mar 3, 2018 at 4:30 PM, Joe Touch wrote: > > > On Mar 3, 2018, at 2:41 PM, Tom Herbert wrote: > > ... > > > Joe, as I said, the requirements for using a UDPv6 checksum are listed in > great detail in RFC6936. I don't see a reason to redefine those here. > > > Agreed - the point is that checksums are optional there, even with caveat= s. > We don=E2=80=99t need to revisit the caveats, but i do think that those o= ther > discussions are reasons why we need OCS to remain optional. > > > I.e., *for the same places where UDP can turn of its checksum, so can > UDP-opts* (and for the same reasons - performance, largely when other > layers are already trusted to be configured to provide the needed > protection). > > > My bigger concern is still using a TLV to hold an optional checksum. If t= he > TLV type is corrupted then receiver would not see checksum to verify it a= nd > hence the mechanism failed in it's primary purpose. We have a similar > problem in GUE. The answer there was that GUE is likely used with tight > coordination so it can be agreed if presence of the checksum is required.= If > the protocol is used between to random nodes in Internet this is a bigger > concern. > > > I=E2=80=99m not sure I agree with your concerns; finding UDP options alre= ady relies > on an uncorrupted IP header and UDP header that would not be protected if > the primary UDP checksum were off. Further, if we can=E2=80=99t disable O= CS then > we=E2=80=99d be required to do twice the work when using ACS. > Joe, I think the point of having a checksum in the options is that the options can be validated as being correct independent of anything else. For instance, there is no need to assume that the packets is verified by a checksum or CRC at a lower layer. UDP checksums are optional in IPv4, and in IPv6 there's no checksum in the IPv6 header so the header could be quite corrupted and UDP options still are found. Corruption in the header could also include the IP length field which means the presence option space is incorrectly inferred. If checksum were required this could be used to validate that the options are actually UDP options (like a magic number essentially) > As with all TLV vs fixed header alternatives, there=E2=80=99s the issue o= f required > vs. optional space. Having TLV allows the space to be saved when OCS isn= =E2=80=99t > present, and that was a concern when we discussed this issue before (as a > group via email). > You may want to work out the probabilities of an undetected data corruption in the options. For instance, if someone is using a 32 bit CRC then they would expect a very low probability of not detecting a corruption (something like 1/2^32). If the CRC is in an optional TLV such that corruption of the type field will causes the CRC to be missed, then probability of missing corruption of options is higher. There's no reason that the type field is any less susceptible to corruption that any other field, so establishing the probability is missing a corruption in this case should be quantifiable (it is probably be related to number of bytes in options). Tom > Finally, there=E2=80=99s the impact on LITE+FRAG and the way in which rea= ssembly can > preserve options. That will require deeper consideration to determine if = it > is possible and with what impact. > > The big question, IMO, is what is the gain. Given these options are alrea= dy > =E2=80=9Cfloating=E2=80=9D, it=E2=80=99s hard to see why a =E2=80=9Cfixed= header=E2=80=9D is important to consider, > IMO, but it=E2=80=99d be useful to hear what others have to say too, cert= ainly. > > Joe > > From nobody Sun Mar 4 08:30:18 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1E5124B18 for ; Sun, 4 Mar 2018 08:30:16 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLKb-Y38xI-U for ; Sun, 4 Mar 2018 08:30:14 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8040B124BFA for ; Sun, 4 Mar 2018 08:30:14 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id C12F02D5048; Sun, 4 Mar 2018 16:30:13 +0000 (UTC) Date: Sun, 4 Mar 2018 16:30:13 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304163013.GA92206@accordion.employees.org> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:30:16 -0000 On Sat, Mar 03, 2018 at 04:30:10PM -0800, Joe Touch wrote: > > On Mar 3, 2018, at 2:41 PM, Tom Herbert wrote: > > My bigger concern is still using a TLV to hold an optional checksum. That is actually my largest concern, and why I'd prefer a fixed header, since it allows the whole verification to use preexisting logic, rather than custom logic. I'd like to be able to do a simple scan over the options area and validate it, without having to parse the TLVs. Hence I could use a two pass approach to this if it made sense, validating without parsing. As an example, compare the two routines at the end of this message. For simplicity, I assume a machine which can perform unaligned access; I've also made the TLV form deal a byte at a time, doing 16 bits at a time would be more complex. I've also ignored the LITE header issues, as the impact of it would be the similar for both routines. Of the two, the first (validate_options_fix) could simply be replaced with a call to pre-existing logic, but it looks as if validate_options_tlv has to be custom coded. Or maybe there is a simpler way to code the _tlv form which I've missed? A futher question came up when coding this: should the OSC scheme terminate when it sees the EOL option? i.e. Does its checksum exclude any bytes after EOL? If so, then the TLV version becomes more complex. Certainly I'm assuming with my fixed proposal that the checksum would include such bytes after the EOL, but within the surplus. > As with all TLV vs fixed header alternatives, there’s the issue of required vs. optional space. Having TLV allows the space to be saved when OCS isn’t present, and that was a concern when we discussed this issue before (as a group via email). I don't recall that being a concern, but then memory is fragile. Either way I don't see those 2 extra bytes as being significant, and as Tom points out, it may even be 2 fixed vs 3/4 variable. > Finally, there’s the impact on LITE+FRAG and the way in which reassembly can preserve options. > That will require deeper consideration to determine if it is possible and with what impact. I view that portion as a trivial extension. One does some initial set up at the start of the routine, then the rest of the loop is the same. > The big question, IMO, is what is the gain. Hopefully the two code examples below highlight that. DF bool validate_options_fix (uint8_t *bp, unsigned len) { uint32_t chk = 0; uint16_t *wp = (uint16_t *)bp; if (len & 1) bp[len] = 0; /* Cheat - assume safe to write */ len /= 2; while (len--) chk += *wp++; /* fold over result */ return (chk == 0) || (chk == 0xffff); } #define OPT_OSC 2 bool validate_options_tlv (uint8_t *bp, unsigned len) { uint16_t chk = 0; uint8_t osc; while (len--) { if (*bp == OPT_OCS) { if (len < 1) return false; chk += OPT_OCS; --len, ++bp; osc = *bp++; continue; } chk += *bp++; } /* fold over result */ return osc == chk; } From nobody Sun Mar 4 08:31:50 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07639124BFA for ; Sun, 4 Mar 2018 08:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93HlZY5XzKxO for ; Sun, 4 Mar 2018 08:31:47 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 59BD3124B18 for ; Sun, 4 Mar 2018 08:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cmNZ/gohk5D3SprICUHucOkOed1NT6fFmtT0ngM3YR4=; b=MOMcUOjt8aCDxbszZm4kc7PxO OJia3AxgT8UtovurrZY6BwqcSowoqjIF/bKqyKjnbmE50dnhtXpTdk/6ul+CvIu8AE4M3KtDvS1Uc DIDInaK9vHHJrJXvCSxm0B0oc2Rz5s1PjDPv/usKn62fTY0IsJMwtvve86RwVC3igDxAfG/CSdiiV Pu+AfQeKfVAF3EafzVkWB9yYPWWZcUrFpmIycZWjDSnfppASdCwX8nNXP6DFjJV0O7725CF2cSClC +BB2CP51lzzav1yTc1m7OmkMO/2+PfdI0pGX7D6f7otvnAs+bmmcENb2gxvXTNqZZ0LR/BBdrpHjl 6GWhm6I+w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64768 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esWXh-004EHF-MK; Sun, 04 Mar 2018 11:31:31 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Sun, 4 Mar 2018 08:31:16 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <6CAFAF48-107C-42CD-BE2E-87D26D1A41C6@strayalpha.com> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:31:49 -0000 > On Mar 4, 2018, at 8:14 AM, Tom Herbert wrote: =E2=80=A6. > Joe, >=20 > I think the point of having a checksum in the options is that the > options can be validated as being correct independent of anything > else. That property is not possible for UDP options, nor for UDP in general. = If the IPv6 header is corrupted, its length may be wrong and thus the = UDP header. If the UDP header is wrong (directly or by IP header error), = then the location (and thus content) of the UDP options will be wrong. = It thus isn=E2=80=99t important to ensure that the UDP options = themselves have some sort of =E2=80=9Ccontext independent=E2=80=9D = property that they already inherently lack. > For instance, there is no need to assume that the packets is > verified by a checksum or CRC at a lower layer. UDP checksums are > optional in IPv4, and in IPv6 there's no checksum in the IPv6 header > so the header could be quite corrupted and UDP options still are > found. IPv6 is basically a TLV chain itself. > Corruption in the header could also include the IP length field > which means the presence option space is incorrectly inferred. Or options are cut off prematurely as well. > If > checksum were required this could be used to validate that the options > are actually UDP options (like a magic number essentially) Agreed - that=E2=80=99s they=E2=80=99re SHOULD use (and default on), but = (for exactly the same reasons) some users don=E2=80=99t want the cost of = doing these checks just for UDP checksums when they=E2=80=99re disabled = at the IP (v6) and UDP levels. But we already allow IP(v6) and UDP to turn this off and the same exact = reasons apply here. >=20 >> As with all TLV vs fixed header alternatives, there=E2=80=99s the = issue of required >> vs. optional space. Having TLV allows the space to be saved when OCS = isn=E2=80=99t >> present, and that was a concern when we discussed this issue before = (as a >> group via email). >>=20 > You may want to work out the probabilities of an undetected data > corruption in the options. For instance, if someone is using a 32 bit > CRC then they would expect a very low probability of not detecting a > corruption (something like 1/2^32). If the CRC is in an optional TLV > such that corruption of the type field will causes the CRC to be > missed, then probability of missing corruption of options is higher. > There's no reason that the type field is any less susceptible to > corruption that any other field, so establishing the probability is > missing a corruption in this case should be quantifiable (it is > probably be related to number of bytes in options). The probabilities depend on the TLV chains that get you there in the = first place too. However, the primary assumption for OCS is that there is no reason that = these options require something beyond what IPv4, UDP, and TCP already = use. If you want stronger protections, then you want to use ACS. And my assumption is that the risk of folding over the OCS to one byte = is commensurate with the anticipation that the options are typically = smaller than the typical payload. If we don=E2=80=99t think byte = alignment or space is an issue, simply don=E2=80=99t fold it over. Joe From nobody Sun Mar 4 08:36:58 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7781242F7 for ; Sun, 4 Mar 2018 08:36:57 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypsZWHfo0Xpf for ; Sun, 4 Mar 2018 08:36:56 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303CD1200F1 for ; Sun, 4 Mar 2018 08:36:56 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 114F32D50DF; Sun, 4 Mar 2018 16:36:56 +0000 (UTC) Date: Sun, 4 Mar 2018 16:36:56 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304163656.GB92206@accordion.employees.org> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:36:57 -0000 On Sat, Mar 03, 2018 at 04:30:10PM -0800, Joe Touch wrote: > > Further, if we can’t disable OCS then we’d be required to do twice the work when using ACS. I don't believe that is correct. ACS protects the actual UDP data payload, whereas OCS protects the options within the surplus. The draft says: The Alternate Checksum (ACS) is a 16-bit CRC of the UDP payload only (excluding the IP pseudoheader, UDP header, and UDP options). So I could well see wanting to have ACS and OCS in use, as they serve different purposes. DF From nobody Sun Mar 4 08:41:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC121242F7 for ; Sun, 4 Mar 2018 08:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2_063NolhSc for ; Sun, 4 Mar 2018 08:41:46 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 32AFD1200F1 for ; Sun, 4 Mar 2018 08:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=n4juVHyfHmuh6avB/jBi9ad49v/H/lcmlenWsDyjCEY=; b=x+IgZp+3C3hR3+0hoaayn5gAM CEqo9UEnK3Z5FbOgePyYj+BmKo81N8SnEDLBr9JIVS9YxbgetyKeITl/52v4q52mtOicjjnb/H8hF fpfae+4i6u1o2nlFc6ued9lKmvK9bdKVxSUIXhNDQPUtUiuc57UsGw41OiaUmNqq/WCXWA/j3HmXg iPS8mzoAxTi0UhwhWANKgNV+LYAE+Fk43En7oB673WBMCcSBdmc04zkLB86aUT2zF7XkqPFssCWPC tGnpd7E0XQnis2ajri139t8Tyr37zPTFYCdW88rZrl7Rixm/OhS+iwN7mSIbuVk0JjR7XFPIvJ8Su Jh3sthWAQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64782 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esWha-0002dU-Gt; Sun, 04 Mar 2018 11:41:35 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304163013.GA92206@accordion.employees.org> Date: Sun, 4 Mar 2018 08:41:33 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <20180304163013.GA92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:41:48 -0000 > On Mar 4, 2018, at 8:30 AM, Derek Fawcus = wrote: >=20 > On Sat, Mar 03, 2018 at 04:30:10PM -0800, Joe Touch wrote: >>> On Mar 3, 2018, at 2:41 PM, Tom Herbert wrote: >>> My bigger concern is still using a TLV to hold an optional checksum. >=20 > That is actually my largest concern, and why I'd prefer a fixed = header, > since it allows the whole verification to use preexisting logic, > rather than custom logic. The options are in a variable location depending on a field in the UDP = header. That issue is overlooked for =E2=80=98fast-path=E2=80=99 IP headers = because a very high percent of UDP headers are in a fixed location, but = that=E2=80=99s not true for option headers, so the hardware already has = a TLV-like complexity. > I'd like to be able to do a simple scan over the options area and = validate > it, without having to parse the TLVs. That doesn=E2=80=99t seem feasible as follows: - it will burn space when OCS isn=E2=80=99t used (and yes, this = is a concern) - it needs space to indicate the start and/or end of OCS = coverage or we would have to remove LITE - we would need to find a new way to incorporate LITE notably that involves not needing to recopy the entire = LITE region after option processing If you have a proposed solution that preserves all of these and supports = the existing properties, please post it. Until then, AFAICT, we have what we have. ... >=20 >> Finally, there=E2=80=99s the impact on LITE+FRAG and the way in which = reassembly can preserve options. >> That will require deeper consideration to determine if it is possible = and with what impact. >=20 > I view that portion as a trivial extension. =20 Fragmentation and reassembly is one of the primary use cases - it is key = to allowing fragmentation to traverse NATs because UDP-level frag would = preserve the info NATs use for rewriting. LITE+FRAG is a very important development because it is backward = compatible without injecting partial payloads to the legacy endpoint. So yes, any solution that replaces TLV with a fixed header would need to = support that. Joe= From nobody Sun Mar 4 08:43:13 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EB71242F7 for ; Sun, 4 Mar 2018 08:43:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f06ZfjHf530m for ; Sun, 4 Mar 2018 08:43:10 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B576A1200F1 for ; Sun, 4 Mar 2018 08:43:10 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 8F7892D50D0; Sun, 4 Mar 2018 16:43:10 +0000 (UTC) Date: Sun, 4 Mar 2018 16:43:10 +0000 From: Derek Fawcus To: tsvwg@ietf.org Message-ID: <20180304164310.GC92206@accordion.employees.org> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <00DEFF55-E660-436E-AF3D-6D5620E90E35@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00DEFF55-E660-436E-AF3D-6D5620E90E35@strayalpha.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:43:12 -0000 On Sun, Mar 04, 2018 at 07:33:31AM -0800, Joe Touch wrote: > > On 3/3/2018 6:04 AM, Derek Fawcus wrote: > > > > This effectively got deferred until after adoption. > > That link points to the touch-options-05 announcement. There were many updates since then (06..09); it was 09 that was adopted and then started the tsv-options-00 sequence. > > Can you provide a more specific pointer? Joe, Not easily. I suffered a catastrophic system failure on the machine used for mailing list participation, and lost my local archive. So I've have to search the above email archive to find it. I vaguely recall you stating in a message that you'd prefer to discuss these topics after adoption. DF From nobody Sun Mar 4 08:43:45 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1557124B18 for ; Sun, 4 Mar 2018 08:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boLva0bDBNwf for ; Sun, 4 Mar 2018 08:43:42 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DC7841242F7 for ; Sun, 4 Mar 2018 08:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zmdGT5qqvlti5JZPAZUTKNQk7SnSLNE1HidWBzJg0ig=; b=uwkICEffV1TAjlhsUl/iRUpY8 P17VGuaBzrhzHIm1DTOpFTerHUyfEyFo959S/AjKeVl9NZCV12b3n4PAPffvUDhcMisBKAL24dE6r HPeFMlPFreJSa5pC1S+gac3UPl8DEnbBb3Cggi6gKWiTKY5QRmY4yNAbJtY551SVPWDxBvju3PVg1 wecbqdpyeVjo+zvW5GPbRRy9/zAXGh21LxKSqtE1QqI1fLCA6BkKWOqXPXbJOofyHU3frl1Sz16SL px0z0nAw7My7SQEotyXIDC9XmnAuIOiOsbPn7K/I3/Kmo0HNlJ+y1kEnzpr1pvygqFgjbPn5ZNmC8 Qpdrd4iFA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64784 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esWjd-0004a4-4O; Sun, 04 Mar 2018 11:43:42 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304163656.GB92206@accordion.employees.org> Date: Sun, 4 Mar 2018 08:43:29 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <35EF80F5-D536-46B7-A863-6CCCC236C8D5@strayalpha.com> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <20180304163656.GB92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:43:44 -0000 > On Mar 4, 2018, at 8:36 AM, Derek Fawcus = wrote: >=20 > On Sat, Mar 03, 2018 at 04:30:10PM -0800, Joe Touch wrote: >>=20 >> Further, if we can=E2=80=99t disable OCS then we=E2=80=99d be = required to do twice the work when using ACS. >=20 > I don't believe that is correct. > ACS protects the actual UDP data payload, whereas OCS protects the = options within the surplus. >=20 > The draft says: > The Alternate Checksum (ACS) is a 16-bit CRC of the UDP payload only > (excluding the IP pseudoheader, UDP header, and UDP options). >=20 > So I could well see wanting to have ACS and OCS in use, as they serve = different purposes. Sorry - mistyped. ACS won=E2=80=99t relieve the work of doing the UDP = checksum if that=E2=80=99s done for the entire packet. If we want something stronger than OCS, then that would have the same = property as ACS/UDP-cs interaction this way. Joe= From nobody Sun Mar 4 08:54:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483AE1242F7 for ; Sun, 4 Mar 2018 08:54:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhWmGsH6D2vL for ; Sun, 4 Mar 2018 08:54:37 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47CF1200F1 for ; Sun, 4 Mar 2018 08:54:37 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 8467C2D5148; Sun, 4 Mar 2018 16:54:37 +0000 (UTC) Date: Sun, 4 Mar 2018 16:54:37 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304165437.GD92206@accordion.employees.org> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:54:39 -0000 On Sun, Mar 04, 2018 at 08:41:33AM -0800, Joe Touch wrote: > > > > On Mar 4, 2018, at 8:30 AM, Derek Fawcus wrote: > > > > On Sat, Mar 03, 2018 at 04:30:10PM -0800, Joe Touch wrote: > >>> On Mar 3, 2018, at 2:41 PM, Tom Herbert wrote: > >>> My bigger concern is still using a TLV to hold an optional checksum. > > > > That is actually my largest concern, and why I'd prefer a fixed header, > > since it allows the whole verification to use preexisting logic, > > rather than custom logic. > > The options are in a variable location depending on a field in the UDP header. > > That issue is overlooked for ‘fast-path’ IP headers because a very high percent > of UDP headers are in a fixed location, but that’s not true for option headers, > so the hardware already has a TLV-like complexity. Who said I was worried about hardware implementation? I'm interested in high speed s/w implementations. So the cost of finding the start of the surplus is trivial, as all it invoves is reading from a fixed location in the UDP header. c.f. TCP options. > > I'd like to be able to do a simple scan over the options area and validate > > it, without having to parse the TLVs. > > That doesn’t seem feasible as follows: > - it will burn space when OCS isn’t used (and yes, this is a concern) That is for people to weigh up. > - it needs space to indicate the start and/or end of OCS coverage > or we would have to remove LITE Nope. Use the existing swap scheme, and have the checksum cover from the start of the LITE header in figure 10 through to the end of the surplus area. > - we would need to find a new way to incorporate LITE > notably that involves not needing to recopy the entire LITE > region after option processing > > If you have a proposed solution that preserves all of these and supports the existing properties, please post it. That was mentioned in the discussion on draft 5, one uses a fixed header at the start of the surplus, the first two bytes being the checksum field. Then for the LITE case, one uses the same 'swap some bytes' scheme you already describe, but rather than swap 4 bytes, one swaps 6 bytes. > Until then, AFAICT, we have what we have. > > ... > > > > >> Finally, there’s the impact on LITE+FRAG and the way in which reassembly can preserve options. > >> That will require deeper consideration to determine if it is possible and with what impact. > > > > I view that portion as a trivial extension. I mean a trivial extension to the code I posted. It would simply work with you existing swap scheme. > Fragmentation and reassembly is one of the primary use cases - it is key to allowing fragmentation > to traverse NATs because UDP-level frag would preserve the info NATs use for rewriting. > > LITE+FRAG is a very important development because it is backward compatible without injecting partial payloads to the legacy endpoint. > > So yes, any solution that replaces TLV with a fixed header would need to support that. I believe it would, as the only thing being replaced is the OCS option, the rest of the TLV scheme for the options would be preserved. DF From nobody Sun Mar 4 08:59:19 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B7F1242F7 for ; Sun, 4 Mar 2018 08:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEagS0O61Hd9 for ; Sun, 4 Mar 2018 08:59:17 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 170001200F1 for ; Sun, 4 Mar 2018 08:59:17 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s188so17953461qkb.2 for ; Sun, 04 Mar 2018 08:59: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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LGGyoWdBLCEBvwk2u2Daoo25DHpCXz4R2MmhFSlugD8=; b=Plv1g4OtPLxczNT8rq6x3f2rQyq0BNtzfuhbqzQua2hpwkrqe6u6Y0gzplDP930kV1 tL1Y77h5Gs4kcZA2zYMivtslQgV4g2E8hK9wl4cCRe+0+o2Y8JFYAGYZ8PUONrTK0AIb i58AKzAa+Gzijj5ri86FH8APNqoNoP06kqztJx6fRHFmPxMnyP7o91V5VUnWn26/w2Fb SQQhgym+nmsneEOB7u7AWz9lKmaPtiPSMDOj2CGAyv7fh4qjCwD0+73IDnUfEcyjENF0 rBXgJP++3f5rhAHq1d3cSeqSDZbHUirfwDZOMKWSGe/BGF92kLZ1WOsnHNSWQcNGWP4S Ii9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LGGyoWdBLCEBvwk2u2Daoo25DHpCXz4R2MmhFSlugD8=; b=Uzs8kdUY82Wvqnsp7VlcaPGaFm9VyoFzScpQWNLnz0FQabMy8bKhYPso8cn1tTVsg5 eG3iJg7MkyWRZbVPepWV2qD+dTlJgX9OqP23KPIeGeOAb5+2pNnJp2+KfeWm7KbLk1KQ s1mFo2lcLywWO+YHonsNII1AP6QjWJD7PQg6gFKfsIyj0BXrMiVzMylez4gqpkWQ21FV EXZFewQ+vPh+3LGhRbdBReiR/0cibFOktLAayMset3icxONfuzeKpCOTdwqRbxxq43IW ddurEK8hZbg8Kc57WjQejo2A71J9PCfsMFRhPHVQjdfH0vknArygl7lvVPs0HGzLdNlj nZVg== X-Gm-Message-State: AElRT7F1eoOanOmUtECKxg+9j5l3O8elIU65v9L34kq+vY6U/cOvLbqr gpPHIN7x919QBgU5XJT80iWxUSdVF422vLzplIccfg== X-Google-Smtp-Source: AG47ELuhcSOVauiJ4ypA8Tv2YRxbdDZ9p8DA6hcU6vnDXxmW3TAiQSJ4mJM7RUE2U8oeUFfUQcswa6wlGUb6lN1Tx8I= X-Received: by 10.55.110.7 with SMTP id j7mr18724409qkc.168.1520182755877; Sun, 04 Mar 2018 08:59:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 08:59:15 -0800 (PST) In-Reply-To: <6CAFAF48-107C-42CD-BE2E-87D26D1A41C6@strayalpha.com> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <20180303162527.GA4472@tom-desk.erg.abdn.ac.uk> <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <6CAFAF48-107C-42CD-BE2E-87D26D1A41C6@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 08:59:15 -0800 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 16:59:19 -0000 On Sun, Mar 4, 2018 at 8:31 AM, Joe Touch wrote: > > >> On Mar 4, 2018, at 8:14 AM, Tom Herbert wrote: > =E2=80=A6. >> Joe, >> >> I think the point of having a checksum in the options is that the >> options can be validated as being correct independent of anything >> else. > > That property is not possible for UDP options, nor for UDP in general. If= the IPv6 header is corrupted, its length may be wrong and thus the UDP hea= der. If the UDP header is wrong (directly or by IP header error), then the = location (and thus content) of the UDP options will be wrong. It thus isn= =E2=80=99t important to ensure that the UDP options themselves have some so= rt of =E2=80=9Ccontext independent=E2=80=9D property that they already inhe= rently lack. > Right, so if the length field becomes corrupted, or a sender puts other random stuff in the surplus area, or a checksum TLV is corrupted-- then what is the mechanism that a receiver uses to identify the corruption so that it does not incorrectly process the bits as UDP options? It seems something like a fixed checksum and/or magic numbers are needed to be robust. Tom >> For instance, there is no need to assume that the packets is >> verified by a checksum or CRC at a lower layer. UDP checksums are >> optional in IPv4, and in IPv6 there's no checksum in the IPv6 header >> so the header could be quite corrupted and UDP options still are >> found. > > IPv6 is basically a TLV chain itself. > >> Corruption in the header could also include the IP length field >> which means the presence option space is incorrectly inferred. > > Or options are cut off prematurely as well. > >> If >> checksum were required this could be used to validate that the options >> are actually UDP options (like a magic number essentially) > > Agreed - that=E2=80=99s they=E2=80=99re SHOULD use (and default on), but = (for exactly the same reasons) some users don=E2=80=99t want the cost of do= ing these checks just for UDP checksums when they=E2=80=99re disabled at th= e IP (v6) and UDP levels. > > But we already allow IP(v6) and UDP to turn this off and the same exact r= easons apply here. > >> >>> As with all TLV vs fixed header alternatives, there=E2=80=99s the issue= of required >>> vs. optional space. Having TLV allows the space to be saved when OCS is= n=E2=80=99t >>> present, and that was a concern when we discussed this issue before (as= a >>> group via email). >>> >> You may want to work out the probabilities of an undetected data >> corruption in the options. For instance, if someone is using a 32 bit >> CRC then they would expect a very low probability of not detecting a >> corruption (something like 1/2^32). If the CRC is in an optional TLV >> such that corruption of the type field will causes the CRC to be >> missed, then probability of missing corruption of options is higher. >> There's no reason that the type field is any less susceptible to >> corruption that any other field, so establishing the probability is >> missing a corruption in this case should be quantifiable (it is >> probably be related to number of bytes in options). > > The probabilities depend on the TLV chains that get you there in the firs= t place too. > > However, the primary assumption for OCS is that there is no reason that t= hese options require something beyond what IPv4, UDP, and TCP already use. = If you want stronger protections, then you want to use ACS. > > And my assumption is that the risk of folding over the OCS to one byte is= commensurate with the anticipation that the options are typically smaller = than the typical payload. If we don=E2=80=99t think byte alignment or space= is an issue, simply don=E2=80=99t fold it over. > > Joe > > From nobody Sun Mar 4 09:17:57 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5276124234 for ; Sun, 4 Mar 2018 09:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-PTHcPgbTQX for ; Sun, 4 Mar 2018 09:17:54 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 3F41B1200B9 for ; Sun, 4 Mar 2018 09:17:54 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id n12so17767443qtl.5 for ; Sun, 04 Mar 2018 09:17:54 -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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zH0xb1m4zSlHnGSYhhh/HPzNj/dra9I2rH7KkYzVLTI=; b=qP3ptGc/wrjGMHojGBoLdLIfs7795IVWFEfgpe8wzUj4Je4WEn202lhtzTodnMaecV jDwP4CHqltWMgHs2iK32Bl6j+nTOFs2EaNQtnWTmO6OOXjgb5ofhBPXtCEUQcn0O8U64 LvZ4/54JpCaUkRfuLhMYkwqXffpGzYPMAREt1d8QMa/7xyHxHKXzswAshpLoxxBpPRMy dQ2ZOuOzUogKwF0ITRRXea24LqqmNCYo/kAOz6BCEK42mOq195eSwzaj7+wcH121askZ xrxw/KCD2gVihryGTDkppA1+ue4O2+coBjnkJfOnO5pa/OjX2+735YLx2yu7ss+1Iftd sNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zH0xb1m4zSlHnGSYhhh/HPzNj/dra9I2rH7KkYzVLTI=; b=t2tcm687VFtu3PsOUE4fMTg9oQqSlozVtQLnwkm4cgh7dc47m9zjyzYa9RR8LEhI3B MOUJNFxUEUxxzVvzgxPtuPksOm6fOKN1qpVY8PY/rx6f+FjklqfXJ4aBlDwd4nK7aymM qgv9PpXIMZLciY1LiwlnPUR/sLfJ1yT5r0JjqaHqU21/q9oA+qPaSJhgJhpid/Yf7OSC VGSG5SN+pf9wyM1Ppt2NGis2J1TG4JkIvH9mu0DhpXqGDbOWx8UymyFqOkFJt6Bq98Q5 oL6LZuZjkAsOcVPsMRwlubJfOC9h99AiOrtx1aIUmnAHcIHBSpFxtG9K2SyYKOABjdSu DTvQ== X-Gm-Message-State: AElRT7GZLpxqA9DiJOgvHR/W8ocD/dVG7M8fFSaWs+OOVTuz4hBOOfIs 5lgsQF1R0peuLV51xmH0tznrEvqVkAJXl5+vwGWqxA== X-Google-Smtp-Source: AG47ELtJnpmFqHJG/k4FuKwahJJz4HlGVRByA5n5rBs5mtV4WUHVX3J/umz+YNzpoRoU2RPi/1hWeZMWGRNVDn6t0cQ= X-Received: by 10.200.8.165 with SMTP id v34mr18064469qth.162.1520183873095; Sun, 04 Mar 2018 09:17:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 09:17:51 -0800 (PST) In-Reply-To: <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 09:17:51 -0800 Message-ID: To: Joe Touch Cc: Derek Fawcus , tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 17:17:56 -0000 On Sun, Mar 4, 2018 at 8:41 AM, Joe Touch wrote: > > >> On Mar 4, 2018, at 8:30 AM, Derek Fawcus wrote: >> >> On Sat, Mar 03, 2018 at 04:30:10PM -0800, Joe Touch wrote: >>>> On Mar 3, 2018, at 2:41 PM, Tom Herbert wrote: >>>> My bigger concern is still using a TLV to hold an optional checksum. >> >> That is actually my largest concern, and why I'd prefer a fixed header, >> since it allows the whole verification to use preexisting logic, >> rather than custom logic. > > The options are in a variable location depending on a field in the UDP he= ader. > > That issue is overlooked for =E2=80=98fast-path=E2=80=99 IP headers becau= se a very high percent of UDP headers are in a fixed location, but that=E2= =80=99s not true for option headers, so the hardware already has a TLV-like= complexity. > Joe, I don't understand your point about hardware already having "TLV-like complexity". We know that TLVs are extremely difficult and expensive to process in a performant hardware data path.The failure of IPv4 options and HBH options in IPv6 demonstrate that. Can you clarify exactly what hardware and capabilities you're referring to? Thanks, Tom >> I'd like to be able to do a simple scan over the options area and valida= te >> it, without having to parse the TLVs. > > That doesn=E2=80=99t seem feasible as follows: > - it will burn space when OCS isn=E2=80=99t used (and yes, this i= s a concern) > - it needs space to indicate the start and/or end of OCS coverage > or we would have to remove LITE > - we would need to find a new way to incorporate LITE > notably that involves not needing to recopy the entire LI= TE > region after option processing > > If you have a proposed solution that preserves all of these and supports = the existing properties, please post it. > > Until then, AFAICT, we have what we have. > > ... > >> >>> Finally, there=E2=80=99s the impact on LITE+FRAG and the way in which r= eassembly can preserve options. >>> That will require deeper consideration to determine if it is possible a= nd with what impact. >> >> I view that portion as a trivial extension. > > Fragmentation and reassembly is one of the primary use cases - it is key = to allowing fragmentation to traverse NATs because UDP-level frag would pre= serve the info NATs use for rewriting. > > LITE+FRAG is a very important development because it is backward compatib= le without injecting partial payloads to the legacy endpoint. > > So yes, any solution that replaces TLV with a fixed header would need to = support that. > > Joe From nobody Sun Mar 4 10:01:52 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27AF126B6D for ; Sun, 4 Mar 2018 10:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tq-tJUGj9Zu for ; Sun, 4 Mar 2018 10:01:48 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 9065C1242F7 for ; Sun, 4 Mar 2018 10:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tNWY8J9x/lYLojBB6FgjR747rqQLBzx6PS/BNo8nSGg=; b=BUK5561piIblEQeY5/xyKMzdz lY36NGuQ2yFKzToAxTUoUIDpID9KoguwK5YRlo7opxj67MHaJIB+mz/wSrSZIRedjhuriBTbajhe3 KwiaJyNrHl+AWSfLuPHZpJkb1LVoOVYs5tI5ArUa1//jsH4akQYttH8BQzvUJ1zBhLl/PpA/MCve3 NJQdBwowuZY37onL5Y2JaPbADGFfY3fsDylE1ojSLN9slyvNMHgzMXd8e/2f5sORbXApOAqdSqlra s1mB1//AKgLzTj4U0vyTw1mZ+Vx0umOmIIlyjRBykGrwDVmOLn2xlJdzUKWqsDURS1hL+gCBJcHDx 02j/jCC6g==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64951 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esXxD-001dn2-96; Sun, 04 Mar 2018 13:01:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304164310.GC92206@accordion.employees.org> Date: Sun, 4 Mar 2018 10:01:23 -0800 Cc: tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> <00DEFF55-E660-436E-AF3D-6D5620E90E35@strayalpha.com> <20180304164310.GC92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 18:01:51 -0000 >=20 > On Mar 4, 2018, at 8:43 AM, Derek Fawcus = wrote: >=20 > On Sun, Mar 04, 2018 at 07:33:31AM -0800, Joe Touch wrote: >>> On 3/3/2018 6:04 AM, Derek Fawcus wrote: >>>=20 >>> This effectively got deferred until after adoption. >>=20 >> That link points to the touch-options-05 announcement. There were = many updates since then (06..09); it was 09 that was adopted and then = started the tsv-options-00 sequence. >>=20 >> Can you provide a more specific pointer? >=20 > Joe, >=20 > Not easily. >=20 > I suffered a catastrophic system failure on the machine used for = mailing list > participation, and lost my local archive. >=20 > So I've have to search the above email archive to find it. >=20 > I vaguely recall you stating in a message that you'd prefer to discuss > these topics after adoption. >=20 > DF I recall that too, but I thought y tracking of pending issues indicated = we had. Joe From nobody Sun Mar 4 10:02:05 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150521277BB for ; Sun, 4 Mar 2018 10:01:58 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWsvHmbnCb7D for ; Sun, 4 Mar 2018 10:01:55 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10C512D7EF for ; Sun, 4 Mar 2018 10:01:55 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 26C6D2D5151; Sun, 4 Mar 2018 18:01:55 +0000 (UTC) Date: Sun, 4 Mar 2018 18:01:55 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304180155.GE92206@accordion.employees.org> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180304165437.GD92206@accordion.employees.org> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 18:02:04 -0000 BTW - The option Kind numbers in some of the diagrams are out of sync with those in the table at the start of section 5. On Sun, Mar 04, 2018 at 04:54:37PM +0000, Derek Fawcus wrote: > On Sun, Mar 04, 2018 at 08:41:33AM -0800, Joe Touch wrote: > > > > >> Finally, there’s the impact on LITE+FRAG and the way in which reassembly can preserve options. > > >> That will require deeper consideration to determine if it is possible and with what impact. > > > > > > I view that portion as a trivial extension. > > I mean a trivial extension to the code I posted. It would simply work with you existing swap scheme. Below is a more complete verification routine for the scheme I propose, untested of course, but it should show how what I have in mind would work. All it does is validate the options in the packet, and covers the LITE case, hence should also cover the LITE+FRAG case. I simply delete the OCS option, add a fixed header for a 16 bit checksum, and keep everything else the same TLVs and all (except 4 vs 6 bytes for LITE processing). Note that this assumes the checksum covers the whole surplus area, and so also includes bytes after a EOL option. You shoudl also note that all of the extra logic is initial set up and verification, it then falls in to the common existing checksum algorithm. One thing I noticed in coding this is that there is a minimal LITE length which can be carried, currently 4 bytes, and then 6 bytes in my scheme. To carry less, the 'swap bytes for LITE' would have to be replaced with a more complex case handling overlapping ranges, which I don't view as worthwhile. It would however be worth calling this out in the document. DF #define OPT_LITE 2 #define OPT_LITE_LEN 4 /* bytes */ /* * dp points to start of UDP payload, dlen is UDP payload length. * plen is IP payload length. * Assumed that dlen vs plen validity already verified. */ bool validate_options_chk (uint8_t *dp, uint16_t dlen, uint16_t plen) { uint16_t slen = plen - dlen - 8; uint8_t *sp = dp + dlen; uint16_t *wp = (uint16_t *)sp; if (slen == 0) return true; /* No options */ if (slen < 2) return false; /* Too short */ if (slen & 1) sp[slen++] = 0; /* Cheat - assume safe to write */ slen /= 2; uint32_t chk = *wp++; --slen; if (chk == 0) return true; /* Unprotected */ /* Account for LITE header, skip to remaining options */ if ((slen > OPT_LITE_LEN / 2) && sp[2] == OPT_LITE && sp[3] == OPT_LITE_LEN) { chk += wp[1]; chk += wp[2]; uint16_t oo = (s[4] * 256) | s[5]; if (oo < 8 + dlen + 2 + OPT_LITE_LEN) return false; if (oo > plen - 2 - OPT_LITE_LEN) return false; wp = (uint16_t *)(dp + oo - 8 + (2 + OPT_LITE_LEN)); slen -= OPT_LITE_LEN / 2; } /* Everything from here is normal checksum algorithm */ while (slen--) chk += *wp++; /* fold over result */ return (chk == 0) || (chk == 0xffff); } From nobody Sun Mar 4 10:13:19 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C328124BAC for ; Sun, 4 Mar 2018 10:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEMTexBWXJW7 for ; Sun, 4 Mar 2018 10:13:16 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 1581C1242F7 for ; Sun, 4 Mar 2018 10:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fa5kvLNDLXGEzF6+0ypaX8N+kEhKaGc1Aq/iD/mUSZc=; b=cDl+ziVmUC30ESo/OO6NIavbq wpKBOvYMPC9bYoU3XE94aJEk5hKPzqHWo+MMObvjPC+DhwxgR/2mnuMWzmH052XrO46iB70VddSAg HWE5kHVjed3PGZ5zVUZVCXrR3OoUVvNJKeVf++v6/qXA2BnPXtsRb7zkRjD+gtyS4Ib87OCXDplJy EUt8WfHoSHVgQvCZYWj9Lz4KWifF/vblzSv6lynjon80aBMA29IdSqnJ2/ubfaKnwMfneZxmtQ3aA 9mMloAgBkOk/kdT6eSg+W8QjheDtAkUIWe6dTUmjA6JBgX5K47kiiV5oE4TKcIVUm3eGt3XI9JI8Q hdvAwEDDw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64959 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esY8A-001rhE-Hx; Sun, 04 Mar 2018 13:13:10 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_AAA4581E-9C92-4F4D-9433-5121E6703817" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Sun, 4 Mar 2018 10:12:59 -0800 Cc: tsvwg Message-Id: References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 18:13:18 -0000 --Apple-Mail=_AAA4581E-9C92-4F4D-9433-5121E6703817 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 4, 2018, at 9:17 AM, Tom Herbert wrote: >=20 > Joe, >=20 > I don't understand your point about hardware already having "TLV-like > complexity=E2=80=9D. > We know that TLVs are extremely difficult and expensive > to process in a performant hardware data path.The failure of IPv4 > options and HBH options in IPv6 demonstrate that. Hardware support is only one part of the reason they=E2=80=99re not = supported. NAT traversal and cost savings by vendors (i.e., the lack of = a compliance process) is also part. It isn=E2=80=99t easy to determine = which is the driving factor. > Can you clarify > exactly what hardware and capabilities you're referring to?TCP options = already are TLV. TCP options already are TLV. As are IPv6 options, which means finding the transport header involves = TLV traversal. I.e., getting *to* the option field involves processing a chain of one = or more unprotected TLV fields anyway. Again, if you expect the checksum and don=E2=80=99t get it (via out of = band info), then you would drop the packet as corrupt anyway. Additionally, as per the other part of this thread, there=E2=80=99s no = way to jump right into hardware use of the OCS. We still have the LITE = swap to contend with, at a minimum, and that might not be word-aligned = as well. Joe= --Apple-Mail=_AAA4581E-9C92-4F4D-9433-5121E6703817 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 4, 2018, at 9:17 AM, Tom Herbert <tom@herbertland.com>= wrote:

Joe,
I don't understand your point about hardware = already having "TLV-like
complexity=E2=80=9D. =

We know that TLVs are extremely difficult = and expensive
to process in a performant hardware data = path.The failure of IPv4
options and HBH options in IPv6 = demonstrate that.

Hardware support is only one part of the reason = they=E2=80=99re not supported. NAT traversal and cost savings by vendors = (i.e., the lack of a compliance process) is also part. It isn=E2=80=99t = easy to determine which is the driving factor.

 Can you clarify
exactly what hardware and capabilities you're = referring to?TCP options already are = TLV.

TCP options = already are TLV.

As are IPv6 = options, which means finding the transport header involves TLV = traversal.

I.e., getting *to* the option field = involves processing a chain of one or more unprotected TLV fields = anyway.

Again, if you expect the = checksum and don=E2=80=99t get it (via out of band info), then you would = drop the packet as corrupt anyway.

Additionally, as per the other part of this = thread, there=E2=80=99s no way to jump right into hardware use of the = OCS. We still have the LITE swap to contend with, at a minimum, and that = might not be word-aligned as well.

Joe
= --Apple-Mail=_AAA4581E-9C92-4F4D-9433-5121E6703817-- From nobody Sun Mar 4 10:19:39 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3B4124BAC for ; Sun, 4 Mar 2018 10:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcMFUHQ1UDZD for ; Sun, 4 Mar 2018 10:19:36 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 B2ED41242F7 for ; Sun, 4 Mar 2018 10:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5fgoFVEnEpvPINt5Nx2jBUPMU5KZE3OOuHS+AyWZpj8=; b=EPp5UltdMLt6DfLpF7Yedritr 34Z1v4/visgGqggEvSNueBzaZtdUF0iQlRD0rBTYorjOEoWhb/LosIiqyqszq3+fm5QIUSsCjcr1K /ZcnkM3xWeiUQutSCRfl4GAtDDJId5urtX14DZJSvfPUe97mIwcmuDa5qKm6OgZ7gTVd/cJtQFveK 8NVdV5JHf0k4/GHiokLI4YJ6PDzM/ZxCKr5sFMjmQLH2oJ6ttrHy0kkei+FS7f6hTYT0Tf9/2r/Y7 PVw1cEE/8PZ2ZYSts162wBWMnFveEiH7p1ROpIeBpo1JeNCE0WodaEUY1SytKsud6T08aZATzGDXQ 28SvgFi+Q==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64966 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esYEC-001yQc-58; Sun, 04 Mar 2018 13:19:20 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_92895D29-C026-4A8A-BE0B-28DC69750DC7" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304165437.GD92206@accordion.employees.org> Date: Sun, 4 Mar 2018 10:19:15 -0800 Cc: tsvwg Message-Id: <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> References: <0a5f436b-193f-7481-cd98-855bf602458b@strayalpha.com> <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 18:19:38 -0000 --Apple-Mail=_92895D29-C026-4A8A-BE0B-28DC69750DC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Derek, > On Mar 4, 2018, at 8:54 AM, Derek Fawcus = wrote: >=20 > Nope. Use the existing swap scheme, and have the checksum cover from = the > start of the LITE header in figure 10 through to the end of the = surplus > area. I=E2=80=99m not sure how that works. If the OCS always comes first, when you hit it you stop and compute the = checksum. However, OCS doesn=E2=80=99t =E2=80=9Ccome first=E2=80=9D with LITE - = LITE comes first. So we need a fixed field (for the same reason) to always indicate = whether LITE is present and the swap needs to happen before the checksum = proceeds. You note this in your other post with the code: > One thing I noticed in coding this is that there is a minimal LITE = length > which can be carried, currently 4 bytes, and then 6 bytes in my = scheme. > To carry less, the 'swap bytes for LITE' would have to be replaced = with > a more complex case handling overlapping ranges, which I don't view = as > worthwhile. It would however be worth calling this out in the = document. So you=E2=80=99re saying at least that the minimum overhead for all = options goes from zero bytes (in the current scheme) to 6 (2 for the = checksum, 4 for LITE even when it isn=E2=80=99t used). And you have to = handle LITE processing or at least checking even when you=E2=80=99re not = using it at all. I don=E2=80=99t see that as forward progress. Joe= --Apple-Mail=_92895D29-C026-4A8A-BE0B-28DC69750DC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Derek,

On Mar 4, 2018, at 8:54 AM, Derek Fawcus = <dfawcus+lists-tsvwg@employees.org> wrote:

Nope.  Use the existing = swap scheme, and have the checksum cover from the
start of the LITE header in figure 10 through to = the end of the surplus
area.

I=E2=80=99m not sure how that works.

If the OCS always comes first, when you = hit it you stop and compute the checksum.

However, OCS doesn=E2=80=99t =E2=80=9Ccom= e first=E2=80=9D with LITE - LITE comes first.

So we need a fixed field (for the same = reason) to always indicate whether LITE is present and the swap needs to = happen before the checksum proceeds.

You note this in your other post with = the code:

One thing I noticed in = coding this is that there is a minimal LITE length
which = can be carried, currently 4 bytes, and then 6 bytes in my scheme.
To carry less, the 'swap bytes for LITE' would have to be = replaced with
a more complex case handling overlapping = ranges,  which I don't view as
worthwhile.  It = would however be worth calling this out in the document.

So you=E2=80=99re saying at least that = the minimum overhead for all options goes from zero bytes (in the = current scheme) to 6 (2 for the checksum, 4 for LITE even when it = isn=E2=80=99t used). And you have to handle LITE processing or at least = checking even when you=E2=80=99re not using it at all.

I don=E2=80=99t see that = as forward progress.

Joe
= --Apple-Mail=_92895D29-C026-4A8A-BE0B-28DC69750DC7-- From nobody Sun Mar 4 10:39:02 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F14C124C27 for ; Sun, 4 Mar 2018 10:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsIpKW80Eres for ; Sun, 4 Mar 2018 10:38:58 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32172124BAC for ; Sun, 4 Mar 2018 10:38:58 -0800 (PST) Received: from [IPv6:2003:cd:6bc4:bb00:29d9:ee41:605:c631] (p200300CD6BC4BB0029D9EE410605C631.dip0.t-ipconnect.de [IPv6:2003:cd:6bc4:bb00:29d9:ee41:605:c631]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 554EF721E281A; Sun, 4 Mar 2018 19:38:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: Date: Sun, 4 Mar 2018 19:38:53 +0100 Cc: tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A0E7F3B.9020905@erg.abdn.ac.uk> To: Kacheong Poon X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] WGLC comments request for draft-ietf-tsvwg-rfc4960-errata-04.txt - to end Fri 8th Dec 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 18:39:01 -0000 > On Dec 5, 2017, at 11:40 AM, Ka-Cheong Poon = wrote: >=20 > On 11/17/2017 02:18 PM, Gorry Fairhurst wrote: >=20 >> As we discussed during the TSVWG session today, the draft "RFC 4960 = Errata and Issues", is thought ready for publication and now ready for = feedback. The latest version of the draft is available here: >> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04 >=20 Hi Kacheong, thanks for your review. Please see my comments in-line. Best regards Michael >=20 > Some comments: >=20 > 3.6.2. >=20 > It may not be clear what "path currently is used for data > transfer" is. Does it mean that an SCTP impl can only use > one path to send data? What does it mean if an SCTP impl > sends data to more than one path simultaneously? RFC 4960 does not cover load sharing or CMT. We are not using the term "primary path" since an implementation might use a different different path if the primary becomes unavailable. Please note that we are not using MUST, since you can implement smarter ways of handling the counter... >=20 >=20 > 3.17.2. >=20 > I remembered that there was a discussion on which addresses > are considered to be confirmed when using sctp_connectx(). > The new text means that all the addresses passed to > sctp_connectx() are considered confirmed. But I remembered Correct. That was the result of the discussion in the past and is also the intention of the text. > that the discussion argued for only the address used by the > peer to send the INIT-ACK is confirmed. Is this correct? I think you are thinking about the passive side: Here RFC 4960 states: 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the one to which the INIT-ACK was sent. Please note that this is not the active side. >=20 >=20 > 3.26.2. >=20 > o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. >=20 > If MUST is used, this excludes other congestion control > algorithms. Is it better to use "SHOULD"? This probably > also applies to 3.27.2 (section 7.2.1). But the original > already uses MUST... We are describing congestion avoidance here and are using the same normative language as RFC 5681. I don't think this will limit the evolution of other congestion = controls. >=20 >=20 > 3.31.2. >=20 > This sentence "When calculating the number of packets to transmit > and particularly using the formula above, cwnd SHOULD NOT be > changed" can be confusing regarding the following >=20 > if((flightsize + Max.Burst*MTU) < cwnd) > cwnd =3D flightsize + Max.Burst*MTU >=20 > cwnd is set to a NEW value yet the sentence required that cwnd > cannot be changed. Maybe use another variable, eff_cwnd (effective > cwnd) in the formula? The statement is "SHOULD NOT be changed permanently". To stress this = point I added "temporarily" to "The limit MAY be applied by adjusting cwnd temporarily as follows:" >=20 >=20 > 3.40. >=20 > Just a question. When the I-D.ietf-tsvwg-ecn-experimentation > becomes an RFC later, will this be updated in this doc too? > Or will the reference stay as an I-D? The ID became already an RFC and I have updated the references to RFC 8311: = https://github.com/sctplab/rfc4960bis/commit/1c46ddcd3b91cbcfd2096b46e087a= 55c6abc00c3 >=20 >=20 > 3.41. >=20 > Another question. Should the Host Name Address parameter be > completed removed from the doc instead of stating that it MUST > not be used everywhere? I found it very strange that a type is > specified in the doc and then everywhere else states that it > MUST not be used... We discussed this and decided that it might be confusing to not mention it... Therefore we kept the definition be state clearly that its usage is deprecated. >=20 > If it has to stay, I guess RFC 4960 3.3.2.1 (where Host Name Address > is first mentioned) should be updated to clearly state that it > is deprecated. It does already: --------- Old text: (Section 3.3.2.1) --------- The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a NAT box. --------- New text: (Section 3.3.2.1) --------- The sender of an INIT chunk MUST NOT include this parameter. The usage of the Host Name Address parameter is deprecated. >=20 >=20 > Thanks. >=20 >=20 > --=20 > K. Poon > ka-cheong.poon@oracle.com >=20 >=20 From nobody Sun Mar 4 11:10:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869E6126BF6 for ; Sun, 4 Mar 2018 11:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb9c90pPfYCA for ; Sun, 4 Mar 2018 11:10:10 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 05B5E1242F7 for ; Sun, 4 Mar 2018 11:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vzEe3rP6wauZ+cT0pLc3Na0PdxR0ccjcDyC+Jegg9JI=; b=f4T0gNwSZdJCRgJaRjX+e5mrA QjkGflIX5DD8RXS9NJ5xQWf6XcJyrvo9NWBGAoT7XQr2xATU+Y/TF3talFzwT9IciR3gtQnE/pnm2 8u9aePwL1DGYlayypzMGs6MGRsTb9HQ91r+lepkKX22gvI1U65vDqJh+aIi24C2tYZYcv6JQcXHGf 2UTHcC8E8VWtbf4qkA7PV2DHaJt2Jo4QWlexrkc5ALtZ+jBIy6OBJ34mz/CTCokbXL3qDDkrZtXQl SGeGnRspfl1SKq2txunHV2h1m7TJn7lN3HkZc7GBHRCXCjOh55bmqZ2mIRl56HTgt8y7FlXgcOVMv pl5QyUSrw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:65308 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esZ1H-0032FH-1d; Sun, 04 Mar 2018 14:10:03 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304185041.GF92206@accordion.employees.org> Date: Sun, 4 Mar 2018 11:10:02 -0800 Cc: Derek Fawcus , tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 19:10:12 -0000 > On Mar 4, 2018, at 10:50 AM, Derek Fawcus = wrote: >=20 > On Sun, Mar 04, 2018 at 10:19:15AM -0800, Joe Touch wrote: >>> On Mar 4, 2018, at 8:54 AM, Derek Fawcus = wrote: >>>=20 >>> Nope. Use the existing swap scheme, and have the checksum cover = from the >>> start of the LITE header in figure 10 through to the end of the = surplus >>> area. >>=20 >> I=E2=80=99m not sure how that works. >>=20 >> If the OCS always comes first, when you hit it you stop and compute = the checksum. >=20 > Note I am suggesting to remove the OCS option. You=E2=80=99re just requiring it as being first, i.e., removing the = =E2=80=9CO=E2=80=9D. The rest is largely the same which is why I=E2=80=99m= saying it that way, but agreed that your plan is to make it mandatory. = We could call the difference OCS vs MCS (mandatory). >=20 > Have you looked at the code I included? > Or should I try and express that algorithm in some other fashion? It would be useful to show headers first, code later. Code changes; = header can=E2=80=99t. Joe From nobody Sun Mar 4 11:29:51 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B39A124B17 for ; Sun, 4 Mar 2018 11:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejbwlcDH1t7W for ; Sun, 4 Mar 2018 11:29:49 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 1C07C1242F7 for ; Sun, 4 Mar 2018 11:29:49 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id n12so17988698qtl.5 for ; Sun, 04 Mar 2018 11:29:49 -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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T8fmh5gJ7fLPwHD4b5252uKjuKa4EGqWYDQQhmfipe0=; b=NbNrMEBJLJ8C480Uj17y82whYyk1RNR73SFS+7r3hQnKynjKtk6vw9lJd/DHjZ7cjb ZNR5oh+ryodN6BksSBufxMhQC9Y8TdIjASR4oT2NMVGQBRtTYBQmC+GV7Sg5n4sJY2B2 PMOfAWIpEOXc3as2+a6NVa3gd/Kh7FQcrQ6GlFrOyxdLwwncrILjhkA07fTqZl5yGx1I qY/D38J9St5oPwyy/ZCbrV5zwA8G/zCSG0dIE92mguOOrnO0Ff3mdA06wVO8BDJgGTzo FywMuXruYP051gYJKPJgkt9ZyfNY+oxh0xBovyFaIXLEc5r86eg8yokjFQV7f6JNbUBu 9ibA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T8fmh5gJ7fLPwHD4b5252uKjuKa4EGqWYDQQhmfipe0=; b=MPto4pvtA8tAm/N0ChN8Tjuanl05waaGj0dK6JimiIhinzdtzVSWxaCwTdwuuqoW3h Ejmja9T5ibBWSZNyIz3rBuLqezGJkfFcnMlp/0L/caetQ4FEEA3lzkOE0w2G9EL2CHPV FITl9+0DuK3MtPrwOCoJSAuFXY8JeHu7hy1zZ8BKr3cX6i0hL1tjNmFUlRbG2dT865tY g+wnh944R5MgtzeNTEFKQ8GFuCCCYGBlQdKoBhqMUo4i6NJ8Ou1iVudyCa7FvHf8T5sb zFVMkfwdEBLYo17dJa3y2j2W6rrWLZBs0bESHLbDmuGEQwHMnj0nEurZX+ohQrWV+nuk +eyw== X-Gm-Message-State: AElRT7FpKvKdS+hhPIi5cQQR9tG0BERqZeAKlTccZsiVS1ysyWsPTeGH thOY+EUGIEw9Yk3QCIvGHHUGE6JHA95OehDvC494DA== X-Google-Smtp-Source: AG47ELuCDUS5VoZK0myLHHZODxe9CtoPOkqXwMtLUPZKM8s9CbHNSwAMkhMRnZ8w+QkzXBLpDjZ/9PYhCfnEHEfVDDU= X-Received: by 10.200.8.165 with SMTP id v34mr18527891qth.162.1520191788094; Sun, 04 Mar 2018 11:29:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 11:29:47 -0800 (PST) In-Reply-To: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> From: Tom Herbert Date: Sun, 4 Mar 2018 11:29:47 -0800 Message-ID: To: Joe Touch Cc: Derek Fawcus , tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 19:29:50 -0000 On Sun, Mar 4, 2018 at 11:10 AM, Joe Touch wrote: > > >> On Mar 4, 2018, at 10:50 AM, Derek Fawcus wrote: >> >> On Sun, Mar 04, 2018 at 10:19:15AM -0800, Joe Touch wrote: >>>> On Mar 4, 2018, at 8:54 AM, Derek Fawcus wrote: >>>> >>>> Nope. Use the existing swap scheme, and have the checksum cover from = the >>>> start of the LITE header in figure 10 through to the end of the surplu= s >>>> area. >>> >>> I=E2=80=99m not sure how that works. >>> >>> If the OCS always comes first, when you hit it you stop and compute the= checksum. >> >> Note I am suggesting to remove the OCS option. > > You=E2=80=99re just requiring it as being first, i.e., removing the =E2= =80=9CO=E2=80=9D. The rest is largely the same which is why I=E2=80=99m say= ing it that way, but agreed that your plan is to make it mandatory. We coul= d call the difference OCS vs MCS (mandatory). > I think it's more like that becomes part of a fixed header in the beginning of the options space. And if you have the checksum there, then the length of the space should also be there so that the checksum can be validated without having to parse all the options to find EOL. Tom >> >> Have you looked at the code I included? >> Or should I try and express that algorithm in some other fashion? > > It would be useful to show headers first, code later. Code changes; heade= r can=E2=80=99t. > > Joe > From nobody Sun Mar 4 11:33:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E885124B17 for ; Sun, 4 Mar 2018 11:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxKULBsd_-3h for ; Sun, 4 Mar 2018 11:33:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 5FEA61242F7 for ; Sun, 4 Mar 2018 11:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f3reLIJYKpyUnl7aPuMLNmtQY0pp0fXkX1+LxQYaf+U=; b=d0k2FRfsF2TTFxTwa9VyOd2S0 EJpQEgsp1Ft+xjqfp8tyDh5V4CwsCgev1SVF972DbMezrUoIFbsUfWVjvrBCUWxsaGltJg492/LxO QP6JS3tZXLxwtX/Wv0+pZAjQaRICj2IYLCmZZt2zyJ9b+JPYsscv/4XslfTrLhYqgQ8h7qButyFIJ 81AczZoLFz5SFBqMvM55jbiHFNLnTVWZ29XEma/O2GYVs/f6qtqgbQOznwGWjzp8dfttVkB3qEEq0 +FVhs/rC6C0RRtTd0VpWTH1XogTqD5b1Vf3QKRambCoLBY9VTJrL35oRV8VgGyaRWqB4D499LgY0l sh5N2BV4Q==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:65532 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esZNe-003XXi-Sv; Sun, 04 Mar 2018 14:33:11 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_DB64CDF8-DFC9-4685-AF32-0AF81CEB87B8" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Sun, 4 Mar 2018 11:33:04 -0800 Cc: Derek Fawcus , tsvwg Message-Id: <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 19:33:25 -0000 --Apple-Mail=_DB64CDF8-DFC9-4685-AF32-0AF81CEB87B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 4, 2018, at 11:29 AM, Tom Herbert wrote: >=20 > On Sun, Mar 4, 2018 at 11:10 AM, Joe Touch > wrote: >>=20 >>=20 >>> On Mar 4, 2018, at 10:50 AM, Derek Fawcus = wrote: >>>=20 >>> On Sun, Mar 04, 2018 at 10:19:15AM -0800, Joe Touch wrote: >>>>> On Mar 4, 2018, at 8:54 AM, Derek Fawcus = wrote: >>>>>=20 >>>>> Nope. Use the existing swap scheme, and have the checksum cover = from the >>>>> start of the LITE header in figure 10 through to the end of the = surplus >>>>> area. >>>>=20 >>>> I=E2=80=99m not sure how that works. >>>>=20 >>>> If the OCS always comes first, when you hit it you stop and compute = the checksum. >>>=20 >>> Note I am suggesting to remove the OCS option. >>=20 >> You=E2=80=99re just requiring it as being first, i.e., removing the = =E2=80=9CO=E2=80=9D. The rest is largely the same which is why I=E2=80=99m= saying it that way, but agreed that your plan is to make it mandatory. = We could call the difference OCS vs MCS (mandatory). >>=20 > I think it's more like that becomes part of a fixed header in the > beginning of the options space. And if you have the checksum there, > then the length of the space should also be there so that the checksum > can be validated without having to parse all the options to find EOL. Then you also need to know where the start is too to have enough info = for the swap. That=E2=80=99s 6 bytes and that=E2=80=99s quite a hefty overhead if you = don=E2=80=99t want the CS at all. And all the processing you do seems = the same either way=E2=80=A6 you still have to check to see if a swap is = needed and whether CS =3D=3D unused. That=E2=80=99s the set of problems AFAICT - space is very high and = processing doesn=E2=80=99t seem to win much. Joe= --Apple-Mail=_DB64CDF8-DFC9-4685-AF32-0AF81CEB87B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 4, 2018, at 11:29 AM, Tom Herbert <tom@herbertland.com>= wrote:

On Sun, Mar 4, 2018 at 11:10 AM, = Joe Touch <touch@strayalpha.com> wrote:


On Mar 4, 2018, at 10:50 = AM, Derek Fawcus <dfawcus@employees.org> wrote:

On Sun, Mar 04, 2018 at 10:19:15AM -0800, Joe Touch wrote:
On Mar 4, 2018, at 8:54 AM, Derek Fawcus <dfawcus+lists-tsvwg@employees.org> wrote:

Nope.  Use the existing swap scheme, and = have the checksum cover from the
start of the LITE header = in figure 10 through to the end of the surplus
area.

I=E2=80=99m not sure how that = works.

If the OCS always comes first, when = you hit it you stop and compute the checksum.

Note I am suggesting to remove = the OCS option.

You=E2=80=99re = just requiring it as being first, i.e., removing the =E2=80=9CO=E2=80=9D. = The rest is largely the same which is why I=E2=80=99m saying it that = way, but agreed that your plan is to make it mandatory. We could call = the difference OCS vs MCS (mandatory).

I think it's more like that becomes part = of a fixed header in the
beginning of the options space. = And if you have the checksum there,
then the length of the space = should also be there so that the checksum
can be validated without having = to parse all the options to find EOL.

Then you also need to know where the start is too = to have enough info for the swap.

That=E2=80=99s 6 bytes and that=E2=80=99s quite a = hefty overhead if you don=E2=80=99t want the CS at all. And all the = processing you do seems the same either way=E2=80=A6 you still have to = check to see if a swap is needed and whether CS =3D=3D = unused.

That=E2=80=99s the set of = problems AFAICT - space is very high and processing doesn=E2=80=99t seem = to win much.

Joe
= --Apple-Mail=_DB64CDF8-DFC9-4685-AF32-0AF81CEB87B8-- From nobody Sun Mar 4 11:46:59 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F5B126BF6 for ; Sun, 4 Mar 2018 11:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYPv5C98OPWV for ; Sun, 4 Mar 2018 11:46:56 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 E51531242F7 for ; Sun, 4 Mar 2018 11:46:55 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id d26so18027729qtk.10 for ; Sun, 04 Mar 2018 11:46:55 -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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6B8lgaGlfSCjjjSZ+ShdmvUXI/JOR63ZZiHy3hsxnXM=; b=ok99UzALM6jTJtuzOBSefPxBf8Xvr7tYICYuXKx29+t4TN6dpFkJongAbH9n3ObLLy gAOwwz/xIhKxvOV95MMWHLguNkuj8dBSVKuqv25OQUVrLnl19UfguIIKQAtf9dk+xMtf /Yyxp+x7aTAO73IgfzhR4DlX3LmUMoMZrRU9rbAD0fQ52h169NJNWy4pHxCLhTT3tHXD cdWwx3XhkmsrDGRDmgZV0MoFBFxl+7cz7fQRbkc/Oenyb80bGirnFk6OikgSLRXfDpZm PclJaurpSB4f9zDRRnDC8LCz7RwAgOzPBdVWfpxX4MElfv+cBma24xM0LZm3uDyqDzGQ 8/5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6B8lgaGlfSCjjjSZ+ShdmvUXI/JOR63ZZiHy3hsxnXM=; b=n4mjY6XvT2Z+12VzKSk8G/ya39Giag97cXGzrPi/+WkGQvRG90QtFgR3AmAEbOV/Am AmOK9ayOxfyOqN59phq+5U11+khDr17UqQDlZpBy9UxxoMI4dL+7qoVGdDsKI1Kb47dr e11TEGha/RDcsHPe0+WfXrsV3FShJNrkxqF+Y4KLKMBKKw+JIxT5lXL2ny6tcT04ZcsZ plNU0QnO7l799G2ecgEr3UcwoSL2AqXOgI5IxFgogLkUODDeA3y+C+CjqKDwTozJGd5i ujctEI6ubGmHsf1aPcIT/wgwW9k0irVThpj1jQw4HSD1aemYuO8L05O5qFHfts4JjvdU nJEA== X-Gm-Message-State: AElRT7G6/XucWb8Lb5d++lxEGy39Edh0XUCaLxILa6bz6utR+nAFIwbT vUxc+UdEVe622tL90ohkpJDoe1zF+7dA9SSII37mtA== X-Google-Smtp-Source: AG47ELuD7VOqhvG4SuWaiuNuTSeiiPw0RtqGMsQiN5jgq2DhQIudDuTOdm3hHndrLM3iXmQNj63r5F3m2AAaV73OEHA= X-Received: by 10.200.49.28 with SMTP id g28mr18765605qtb.279.1520192814828; Sun, 04 Mar 2018 11:46:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 11:46:54 -0800 (PST) In-Reply-To: <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 11:46:54 -0800 Message-ID: To: Joe Touch Cc: Derek Fawcus , tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 19:46:57 -0000 On Sun, Mar 4, 2018 at 11:33 AM, Joe Touch wrote: > > > On Mar 4, 2018, at 11:29 AM, Tom Herbert wrote: > > On Sun, Mar 4, 2018 at 11:10 AM, Joe Touch wrote: > > > > On Mar 4, 2018, at 10:50 AM, Derek Fawcus wrote: > > On Sun, Mar 04, 2018 at 10:19:15AM -0800, Joe Touch wrote: > > On Mar 4, 2018, at 8:54 AM, Derek Fawcus > wrote: > > Nope. Use the existing swap scheme, and have the checksum cover from the > start of the LITE header in figure 10 through to the end of the surplus > area. > > > I=E2=80=99m not sure how that works. > > If the OCS always comes first, when you hit it you stop and compute the > checksum. > > > Note I am suggesting to remove the OCS option. > > > You=E2=80=99re just requiring it as being first, i.e., removing the =E2= =80=9CO=E2=80=9D. The rest is > largely the same which is why I=E2=80=99m saying it that way, but agreed = that your > plan is to make it mandatory. We could call the difference OCS vs MCS > (mandatory). > > I think it's more like that becomes part of a fixed header in the > beginning of the options space. And if you have the checksum there, > then the length of the space should also be there so that the checksum > can be validated without having to parse all the options to find EOL. > > > Then you also need to know where the start is too to have enough info for > the swap. > > That=E2=80=99s 6 bytes and that=E2=80=99s quite a hefty overhead if you d= on=E2=80=99t want the CS at > all. And all the processing you do seems the same either way=E2=80=A6 you= still have > to check to see if a swap is needed and whether CS =3D=3D unused. > > That=E2=80=99s the set of problems AFAICT - space is very high and proces= sing > doesn=E2=80=99t seem to win much. > The win is to increase the probability that the UDP options are correctly interpreted. One potential issue with this proposal is that it retroactively defines the slack space to have certain semantics. There may be implementations out there that are now creating non-zero slack space, and I don't think it's possible to retroactively declare that those are out of protocol conformance. Personally, I am much more concerned about a protocol being correct and robust than saving a couple of bytes of header. IMO there should be a means to validate that the bits in a slack space are indeed well formed UDP options with high probability. Tom . > Joe From nobody Sun Mar 4 11:59:32 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37AF1242F7 for ; Sun, 4 Mar 2018 11:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bctlwlOkh4B for ; Sun, 4 Mar 2018 11:59:29 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 511221242F5 for ; Sun, 4 Mar 2018 11:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tu+DGuAdU+iPVg47rMLnyzCA5hC/4320ENZVE+WMd/w=; b=ob03qn+uaSHrCTQuBNm9Vt5Sr SGzA2g/ybOpN6j6TDLRDHboynMbNV4TbKWwVQmvJuFlHcqh+q9Ug1sq7VL58i9obQCbRC6+GBWOdr 8BigdAdCgV10DGz6zXZWQlPaOvQ0CTqAzanWBO36+W8Wg71eV99+IyiaclNj1gvjEX26ta9t/tb0x DNmDBuV9Sdd24D0f6XuurvMTJvIJs5ihumDyUSfc6m1Hs2hVDyW04tO+rfRDZHXZYc6oVzoAXIdEA rUsgdFOIoZslYNGqpFp/LM9cJbelR3HBc0qzegWh1qUccN/FKw/awnOWoUj8+hvQ06MthJMXtnwtx yA3AQZOQw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56735 helo=[192.168.1.158]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esZmn-00417k-Vt; Sun, 04 Mar 2018 14:59:13 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (15D100) In-Reply-To: Date: Sun, 4 Mar 2018 11:59:09 -0800 Cc: Derek Fawcus , tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> To: Tom Herbert X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 19:59:31 -0000 > On Mar 4, 2018, at 11:46 AM, Tom Herbert wrote: >=20 > There may be implementations out there that are now creating non-zero > slack space, and I don't think it's possible to retroactively declare > that those are out of protocol conformance. They are until they=E2=80=99re defined as in.=20 Ie UDP is a standard. This doc extends that with a new one. There are no oth= er similar extensions underway and none have already been approved. Joe= From nobody Sun Mar 4 12:22:56 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED9E126C89 for ; Sun, 4 Mar 2018 12:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOmSJcNBtEfG for ; Sun, 4 Mar 2018 12:22:53 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 144D6126BFD for ; Sun, 4 Mar 2018 12:22:53 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id l25so18120635qtj.1 for ; Sun, 04 Mar 2018 12:22:53 -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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QXptr1YDoKFxXZCoae12Lgg0FU04Ew/+JoNUrMF85TQ=; b=ILK8Tp7Gmp+LmxZbNfA6OXqYTrDbHfALr5zvhxMLW5tMfm3Ew7WaCpu2eYKL5pzG4q dlc6t/IFvi+LEt3s9hAeMa/wVYg2/2PHPM9MfO7FSVSkBnag9ofg1VROZTVSiNOxtdSv 1+yLDJOCI5wuIG7oCvvOjACu3lEutqhFaUEo7QKv8Hb91SH5te3biKoXI3yqs5sCLM+B dJga4gE3gC/ht8/+2/YrmmoSRYrdnRJtfKqKZ5mkM41KvdVqyOcUF9PIlAa//oAwx8cd bd2Ccbn5WFaAN4vT+4dT+ZsPm6GpYlTov7J0FGSMwlI9YYIlT9bQjp3iQno2TKCZQvwF d9pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QXptr1YDoKFxXZCoae12Lgg0FU04Ew/+JoNUrMF85TQ=; b=JGJodplXekYi8L/67afTja7kw45dxAwQuwIxQy3AO24Wxk0G5PVIaf62qrpIqobkrx AprE1EqHDpGCIXHfjbCZF5DSfcFnRr3EedYB6DQU1n9LTh3FZDCMLoZFD776aU8cWW1W MUPULPbFHdAvpPZTUmsLjTCczFN6DQLVo59f3It+5Cure2aESwPruSvfktukTccAXmdo K57pYUYO9nRpmTFE4nDpSEYhHxufJWJsOz5K8NXJN6cq2tphruJOroqyBPvPaqUcC9yq VMgtv7+PKUBLiS6UcNbz5kDdGBib9xjvrAnUFlQCTe22QHUZfpcKy11LgtxtHEgfva1E VQTw== X-Gm-Message-State: AElRT7Hyekccwhqm3KvuOwoptsAF3U2EZ0vgesr5ooMm0G+FeDDBS6CL txKSD0NNb5c8DJGs05cxOAI7T8NPs1Dp+AII6fvMZw== X-Google-Smtp-Source: AG47ELvrFae10Kp/apQKW28lP2X+Tsw+GmkaQpeMiv1eDWtBGDiazWNXd/bXZPNgHlpL9c/6Yt9PRhdkVPMnzIinNaI= X-Received: by 10.200.52.73 with SMTP id v9mr19505047qtb.66.1520194972058; Sun, 04 Mar 2018 12:22:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 12:22:51 -0800 (PST) In-Reply-To: <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 12:22:51 -0800 Message-ID: To: Joe Touch Cc: Derek Fawcus , tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 20:22:54 -0000 On Sun, Mar 4, 2018 at 11:59 AM, Joe Touch wrote: > > >> On Mar 4, 2018, at 11:46 AM, Tom Herbert wrote: >> >> There may be implementations out there that are now creating non-zero >> slack space, and I don't think it's possible to retroactively declare >> that those are out of protocol conformance. > > They are until they=E2=80=99re defined as in. > ? From section 9 of the draft" :It has always been permissible for the UDP Length to be inconsistent with the IP transport payload length [RFC768]" > Ie UDP is a standard. This doc extends that with a new one. There are no = other similar extensions underway and none have already been approved. > What does "approved" mean? If someone is using the slack space for their own purposes in their network then that is their business. AFAIK there is no RFC that say they are breaking anything and they don't need approval to do that. But, if UDP options are deployed things could then break things in these environments, That risk needs to be considered and proper mechanisms are used to mitigate the risk. If nothing else, these issues will be raised again when someone suggests to implement support in Linux and other OSes. Even if something is completely correct protocol-wise, we can't arbitrarily break things for real users. Tom > Joe From nobody Sun Mar 4 12:26:24 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018AA126C0F for ; Sun, 4 Mar 2018 12:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPP_utVeAFN7 for ; Sun, 4 Mar 2018 12:26:17 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E171D126BFD for ; Sun, 4 Mar 2018 12:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OomXmrCMubPMuUFMA+JvCOhPqMfBi6VmSsS4rh4cZVo=; b=vERR30zZse73HL3OVNW+cVDGG Zf+BaANU1UvmIZX8R287n1GCsGZAkHXcFLLSRwTyOOsL4DWcAiAAS/VhvE23ozDQ0KBnPPGlB8SVG omzxgWqEiXMo0F8+SGv6/odPHrdSH8R/t41uxG0ArJqkC5hYIyCyky0b1WZuktD3NGRA6F3dRdoQE nLketwReKENMm2M2DHNJ68yweX3p8rfL6mGM1vlGT+2oiDMAx0uk5a14Nx+NC3eOAkWXZdM95Cb8r i+D4GDlFlVEI7nTVae/BVDiO0Wz4O00ZnEwi1bXHuL+KDQREwh0jNqVjpY5ELEL7ZjJGMr74uj8dr LwjpQkYWQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57309 helo=[192.168.1.158]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esaCj-000EOH-Ns; Sun, 04 Mar 2018 15:26:07 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (15D100) In-Reply-To: Date: Sun, 4 Mar 2018 12:25:51 -0800 Cc: Derek Fawcus , tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <425A8FEC-9356-46DA-B81C-46213F692498@strayalpha.com> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> To: Tom Herbert X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 20:26:19 -0000 > On Mar 4, 2018, at 12:22 PM, Tom Herbert wrote: >=20 >> On Sun, Mar 4, 2018 at 11:59 AM, Joe Touch wrote: >>=20 >>=20 >>> On Mar 4, 2018, at 11:46 AM, Tom Herbert wrote: >>>=20 >>> There may be implementations out there that are now creating non-zero >>> slack space, and I don't think it's possible to retroactively declare >>> that those are out of protocol conformance. >>=20 >> They are until they=E2=80=99re defined as in. >>=20 > ? =46rom section 9 of the draft" :It has always been permissible for > the UDP Length to be inconsistent with the IP transport payload length > [RFC768]" Yes, but this doc is the first and only specified use thereof. >=20 >> Ie UDP is a standard. This doc extends that with a new one. There are no o= ther similar extensions underway and none have already been approved. >>=20 > What does "approved" mean? Standard in the Ietf. We can=E2=80=99t and don=E2=80=99t define standards to specify the use of th= ose who don=E2=80=99t follow standards. =20 > If someone is using the slack space for > their own purposes in their network then that is their business. AFAIK > there is no RFC that say they are breaking anything and they don't > need approval to do that. But, if UDP options are deployed things > could then break things in these environments, That risk needs to be > considered and proper mechanisms are used to mitigate the risk. If > nothing else, these issues will be raised again when someone suggests > to implement support in Linux and other OSes. Even if something is > completely correct protocol-wise, we can't arbitrarily break things > for real users. We don=E2=80=99t. Others do, and there is no way to ever prevent that. Joe >=20 > Tom >>=20 From nobody Sun Mar 4 12:30:36 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72147126C0F for ; Sun, 4 Mar 2018 12:30:34 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us5OvjvZoHYX for ; Sun, 4 Mar 2018 12:30:33 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0547A126BFD for ; Sun, 4 Mar 2018 12:30:33 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 8F3922D516B; Sun, 4 Mar 2018 20:30:32 +0000 (UTC) Date: Sun, 4 Mar 2018 20:30:32 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304203032.GG92206@accordion.employees.org> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 20:30:34 -0000 On Sun, Mar 04, 2018 at 11:46:54AM -0800, Tom Herbert wrote: > > > > I think it's more like that becomes part of a fixed header in the > > beginning of the options space. And if you have the checksum there, > > then the length of the space should also be there so that the checksum > > can be validated without having to parse all the options to find EOL. Well, I am obviously proposing that the whole of the surplus/slack area then becomes UDP options. So there would be no need for an additional length field. In terms of an implementation (slackU) which currently makes use of the surplus/slack area, well they already can't guarentee that an unknown peer will even recognise it, they might just dump anything beyond the UDP payload. So from that perspective, I'd say it makes things no worse for that implementation, as they never had any basis to expect its use to be interpreted. So if be call a implemention using UDP options optU; there would only seem to be a few potential issues: 1) slackU sending to optU, optU needs to ignore/discard the surplus area. 2) optU sending to slackU, slackU will possibly misinterpret the options. (but it already had this issue, as a current implementation could send junk in the surplus area) 3) wanting to upgrade a slackU box to understand optU, while still being compatible with another (identical) slackU stack. For that a well known checksum would/could help to distinguish cases. But is this case really one we should worry about. So case 1 would seem to be the only one in scope for worrying about in this draft. If a checksum is used, it would give some protection; if omitted then the application is taking its chances (unless communicating with a known compatible stack). > Personally, I am much more concerned about a protocol being correct > and robust than saving a couple of bytes of header. IMO there should > be a means to validate that the bits in a slack space are indeed well > formed UDP options with high probability. That would be possible with what I propose, as long as the application stored a non 0x0000 value in the checksum. If they chose to use the 0x0000 value, then they're taking their chances. Well with what I'm proposing, one could verify that the bytes in the surplus are potentially valid options (due to the checksum), before then going on to parse the options, when stricter validation could occur. DF From nobody Sun Mar 4 12:48:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD91126BFD for ; Sun, 4 Mar 2018 12:48:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obUl6XMSpmZF for ; Sun, 4 Mar 2018 12:48:13 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 3E5641201F2 for ; Sun, 4 Mar 2018 12:48:13 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id c7so18139374qtn.3 for ; Sun, 04 Mar 2018 12:48:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D54PAw5ERTCnXZZe/JZpBUSUG4aaP7ytOWjHSSZfxkk=; b=rO9X4qgSwv+rVgw65zvY8aoDH2Pa4SDmTrnNry+u8tj3RuYAbXiEs/6xiXJxuCLY8G O2Puj32OJS6MCVk/t0dlreRrEYaaeHS+G0oq7N3g1QlTuBqBsfXoiX2o/0Tc8h1uBMMa tPCeQkfO/kU3zogHplMtmioBhOpXCJhsOsQU6SlxpzCPiM488VYblNtd+vMjJUijXH7U 0k9ejncgMsbcOJTBYFsGUZckKzDlPXf9a2MSNdeXrUt8lGhB+GdpHplXcMnYiHOvctF2 yeWrR4CNnu3mwdGLV5Pe7KUsceRA10z5lDUBdGMApl4/9QRJF1nQD4V8BTTwNgHHJjUl v82w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D54PAw5ERTCnXZZe/JZpBUSUG4aaP7ytOWjHSSZfxkk=; b=EtlUoqKCtEjH9hPiMb3L7Cc+/9Sdw6SIbgkxmvfnhCow5yjPAIa5dbtd+9jGpcwW+V rcLxH873ix+sxAdK/gYZbTB0JQT7oXOcX7kCRlBqqShUiS3K8XQ7e2T9VHVg224+qvRs bqGCjkoJa/rPvVm4ChapgbigHxXcqGzfMYwpxzuxfwcf2oExwuwKrbl0hys2Ucr7WLIF Iqhh2MeXLKkvUemaA/8JLkZwNYqZVYDRCuKiBcvECTJANJj43fNnwDxoNnypCJjyBj/H /sZbrhwF1TaHlwsLz6beHnnWFqwy+hFm2+XsbPwMO1wQNFNPkcuilaSe7HZl4ysFCLA4 8NFg== X-Gm-Message-State: AElRT7EhVC6XzdJ36tqa2gzvPRdmIausLQ+G8wlrS06Sq+pbng/GIWe+ pQ+LlzXAntG6GMcLKlYI+2z95ofxnRI7QD2vOA== X-Google-Smtp-Source: AG47ELsYyBYv+jOm2LzQQ53moFl1jLZJqyTZFW9VYqh0I9VBEcPHkOCHBpmWlvYdRQQpyQ8taBt4I/OCX7k/px2uZag= X-Received: by 10.237.41.194 with SMTP id o60mr19867751qtd.128.1520196492430; Sun, 04 Mar 2018 12:48:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.46.10 with HTTP; Sun, 4 Mar 2018 12:48:12 -0800 (PST) In-Reply-To: <419905ca-305b-594d-2958-fb468e6e5bb0@isae-supaero.fr> References: <419905ca-305b-594d-2958-fb468e6e5bb0@isae-supaero.fr> From: Yingzhen Qu Date: Sun, 4 Mar 2018 12:48:12 -0800 Message-ID: To: Emmanuel Lochin Cc: tsvwg@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1257aaeb910f05669c53ad" Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 20:48:15 -0000 --94eb2c1257aaeb910f05669c53ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Emmanuel, Thanks for the pointer. I was not aware of the existence of this draft. I agree they have some similarities with detail variations. Just curious, why this draft didn't progress? BTW, yes, AR/VR means Augmented Reality/Virtual Reality. I'll add the acronyms to the next version. Thanks, Yingzhen On Sun, Mar 4, 2018 at 3:45 AM, Emmanuel Lochin < emmanuel.lochin@isae-supaero.fr> wrote: > Hi Yingzhen > Just for your information, you might be interested in gTFRC : > https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02 > which is a similar solution i.e. a CC for bandwidth guaranteed networks > with TFRC. > Furthermore just a quick question : in your draft does AR/VR stands for > Augmented/Real Virtuality ? > > Regards > > Emmanuel > > > On 04/03/2018 06:54, Yingzhen Qu wrote: > > Dear Chairs, > > > > A new draft (The draft was suggested by TSVWG @IETF100) was just > submitted, and we=E2=80=99d like to request a time slot to present it @IE= TF101. > > > > Title: A New Congestion Control in Bandwidth Guaranteed Network > > Presenter: Yingzhen Qu (Huawei) > > Time required (including Q/A): 10 mins > > Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > > > > If there is any question, please kindly let us know. > > > > Thanks, > > Yingzhen > > > -- > Emmanuel LOCHIN > Professeur ISAE > > ISAE SUPAERO - Institut Sup=C3=A9rieur de l'A=C3=A9ronautique et de l'Esp= ace10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE = - http://www.isae-supaero.fr > Tel +33 5 61 33 84 85 <+33%205%2061%2033%2084%2085> - Fax (+33) 5 61 33 8= 3 30 <+33%205%2061%2033%2083%2030> > > --94eb2c1257aaeb910f05669c53ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Emmanuel,

Thanks for the pointer. I = was not aware of the existence of this draft. I agree they have some simila= rities with detail variations. Just curious, why this draft didn't prog= ress?

BTW, yes, AR/VR means Augmented Reality/Virt= ual Reality. I'll add the acronyms to the next version.

<= /div>
Thanks,
Yingzhen

=C2=A0
<= /div>

On Sun, Mar = 4, 2018 at 3:45 AM, Emmanuel Lochin <emmanuel.lochin@isae-su= paero.fr> wrote:
=20 =20 =20

Hi Yingzhen

Just for your information, you might be interested in gTFRC : h= ttps://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02 <= br> which is a similar solution i.e. a CC for bandwidth guaranteed networks with TFRC.
Furthermore just a quick question : in your draft does AR/VR stands for Augmented/Real Virtuality ?

Regards

Emmanuel


On 04/03/2018 06:5= 4, Yingzhen Qu wrote:
=20 =20 =20 =20 =20

Dear Chairs= ,

=C2= =A0

A new draft (The draft was suggested by TSVWG @IETF100) was just submitted, and we=E2=80=99d like to request a time slot to pres= ent it @IETF101.

=C2= =A0

Title: A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/=

=C2= =A0

If there is any question, please kindly let us know.

=C2= =A0

Thanks,<= /u>

Yingzhen=


--=20
Emmanuel LOCHIN
Professeur ISAE

ISAE SUPAERO - Institut Sup=C3=A9rieur de l'A=C3=A9ronautique et de l&#=
39;Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOU=
LOUSE CEDEX 4 FRANCE - http://www.isae-=
supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30=

--94eb2c1257aaeb910f05669c53ad-- From nobody Sun Mar 4 12:59:03 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279B5120727; Sun, 4 Mar 2018 12:59:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APvykZHj_yXG; Sun, 4 Mar 2018 12:59:00 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 CC0301201F2; Sun, 4 Mar 2018 12:58:59 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id y137so18360527qka.4; Sun, 04 Mar 2018 12:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pGE5ScbbxRhG16nt+zRu9k5qwqSwzU12FNpvTHQ9pXw=; b=Z76WE4KNyOr19jtAvTXvE2Euh56oWUyFXRzVpLzSbLzdT74X3D2Zn23pnHoBpwc6XX xugArpl7nloADUDtGIO5Sf4NRAcjS7VRHpgUBO/QklcNenPU5Hpy030wloWPPlJ0DwdL qlkANkJDsbMq74JWU85wdMBh22HaYqYIa1ufbKuKNUQcXLPPMbwPfJEYDIYEJnXSRNyO 35P67mHLFbrv6106im7GIjhgdSrg9IXGpZpTMiA7vNMklvWlt//WRI0WYKQU2hpAYiJ0 aFrFo2CCSZRyUoONgj2aLWz6vjBAskO6ZPCD3rOpeZCf1cUGnFIwLyWjl3OfKlNBdMRD yhNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pGE5ScbbxRhG16nt+zRu9k5qwqSwzU12FNpvTHQ9pXw=; b=eAotmaZxb5aYALU1MFTZG/kl+fIRrdezGwQgGx/94ARtgNepvbKRuywJ8zMigAHrNv 2Rz4rBKM9UP+uUY8YmipHn3InyXMd85KuaKCB0kK5EE0+BfVSr/2vQZbofFaCbsUPsus vOQNP/FS+5Yb06AY9Suc9mK1meZ3dj+/INkiuSkFK8s45R9vckzgQL6ekLDAP4Jxlk/O xXnzw5tmW0sESqqhCxrBT1TAbs9FAusyZ9lOoVHPQPn4U6phqOlbBsLsypItEz7Tkq64 hr7XICcgT88ZRhyh/3pQ3ui/13Hc7ndRu3l1kDxELaiN4WiGRgZgItDH7E9t2nEmBoZo 3N8w== X-Gm-Message-State: AElRT7H8xxjgRm0nHF6Qud/IMXTjY1wuQSdMz0SUAIwjvZX9ndSn1wdW T6KKP8fywdDwd6qNHMSwNYWViyuaRlA/00uidQ== X-Google-Smtp-Source: AG47ELu3jpS+vfX/XCZ38dntbVrHHgDtJF7rompnA6rO0KtQOcqvhjfhatUlzPbXQq6ZXEUmb36zPZw0pi9VI3X0GRg= X-Received: by 10.233.232.75 with SMTP id a72mr19382219qkg.76.1520197138791; Sun, 04 Mar 2018 12:58:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.46.10 with HTTP; Sun, 4 Mar 2018 12:58:58 -0800 (PST) In-Reply-To: <5A9BEB65.6010102@erg.abdn.ac.uk> References: <5A9BEB65.6010102@erg.abdn.ac.uk> From: Yingzhen Qu Date: Sun, 4 Mar 2018 12:58:58 -0800 Message-ID: To: gorry@erg.abdn.ac.uk Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , Thomas Nadeau , "tcpm@ietf.org" , Yingzhen Qu , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11019a72409705669c7a12" Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 20:59:02 -0000 --94eb2c11019a72409705669c7a12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gorry and Michael, Thanks for the suggestion, I'll request a presentation in ICCRG. Meanwhile, I think since the in-band signaling draft was presented in TSVWG, if time allows it still makes sense to present this draft in TSVWG. The in-band signaling draft covers lots of aspects, and the required changes include network layer and transport layer. We're working on updating the draft, and may break it into pieces to fit different WGs. Your comments and help are very much appreciated. Thanks, Yingzhen On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst wrote: > I am unsure yet what the correct group of people world be to explore a > "Bandwidth Guaranteed Network". The presentation last IETF looked like th= e > work could imply a need for changes proposed to the network layer (using > OAM exchnages) to set the sending rate and make those bandwidth > reservations. In the end, it could result in a protocol quite different = to > TCP, I think this sort of change may possibly have a home in TSVWG - but > first I'd agree with Michaeland would encourage a presentation of the > problem statement in ICCRG to explore the issues. > > Gorry > > On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > >> >> Hi all, >> >> From the abstract: =E2=80=9C=E2=80=A6This draft proposes a new TCP conge= stion control >> algorithm used in bandwidth guaranteed networks. It is an extension to = the >> current TCP standards.=E2=80=9D >> >> In the IETF, I believe the expertise for this specific document would be >> in TCPM, which in CC. If the authors are interested in feedback on the >> proposed mechanism, I would recommend to ask TCPM. >> >> Alternatively, corresponding research could perhaps be performed in the >> ICCRG. ICCRG has published RFC 6077 to document some of the open researc= h >> issues in this space. >> >> Michael >> >> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu >> *Sent:* Sunday, March 04, 2018 6:55 AM >> *To:* tsvwg@ietf.org; tsvwg-chairs@ietf.org >> *Cc:* Thomas Nadeau >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 >> >> Dear Chairs, >> >> A new draft (The draft was suggested by TSVWG @IETF100) was just >> submitted, and we=E2=80=99d like to request a time slot to present it @I= ETF101. >> >> Title:A New Congestion Control in Bandwidth Guaranteed Network >> >> Presenter: Yingzhen Qu (Huawei) >> >> Time required (including Q/A): 10 mins >> >> Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ >> >> If there is any question, please kindly let us know. >> >> Thanks, >> >> Yingzhen >> >> > --94eb2c11019a72409705669c7a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gorry and Michael,

Thanks for the su= ggestion, I'll request a presentation in ICCRG. Meanwhile, I think sinc= e the in-band signaling draft was presented in TSVWG, if time allows it sti= ll makes sense to present this draft in TSVWG.=C2=A0

The in-band signaling draft covers lots of aspects, and the required cha= nges include network layer and transport layer. We're working on updati= ng the draft, and may break it into pieces to fit different WGs.
=
Your comments and help are very much appreciated.
=
Thanks,
Yingzhen

On Sun, Mar 4, 2018 at 4:49 AM, Gorry F= airhurst <gorry@erg.abdn.ac.uk> wrote:
I am unsure yet what the correct group of people world be t= o explore a "Bandwidth Guaranteed Network". The presentation last= IETF looked like the work could imply a need for changes proposed to the n= etwork layer (using OAM exchnages) to set the sending rate and make those b= andwidth reservations.=C2=A0 In the end, it could result in a protocol quit= e different to TCP, I think this sort of change may possibly have a home in= TSVWG=C2=A0 - but first I'd agree with Michaeland would encourage a pr= esentation of the problem statement in ICCRG to explore the issues.

Gorry

On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

Hi all,

>From the abstract: =E2=80=9C=E2=80=A6This draft proposes a new TCP congesti= on control algorithm used in bandwidth guaranteed networks.=C2=A0 It is an = extension to the current TCP standards.=E2=80=9D

In the IETF, I believe the expertise for this specific document would be in= TCPM, which in CC. If the authors are interested in feedback on the propos= ed mechanism, I would recommend to ask TCPM.

Alternatively, corresponding research could perhaps be performed in the ICC= RG. ICCRG has published RFC 6077 to document some of the open research issu= es in this space.

Michael

*From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu
*Sent:* Sunday, March 04, 2018 6:55 AM
*To:* tsvwg@ietf.org; tsvwg-chairs@= ietf.org
*Cc:* Thomas Nadeau <tnadeau@lucidvision.com>
*Subject:* [tsvwg] Agenda requests for TSVWG@IETF101

Dear Chairs,

A new draft (The draft was suggested by TSVWG @IETF100) was just submitted,= and we=E2=80=99d like to request a time slot to present it @IETF101.

Title:A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/dra= ft-han-tsvwg-cc/

If there is any question, please kindly let us know.

Thanks,

Yingzhen



--94eb2c11019a72409705669c7a12-- From nobody Sun Mar 4 13:41:59 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BE9126B72 for ; Sun, 4 Mar 2018 13:41:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A23LAX90IfTy for ; Sun, 4 Mar 2018 13:41:56 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E201200FC for ; Sun, 4 Mar 2018 13:41:56 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 64D292D510F; Sun, 4 Mar 2018 21:41:56 +0000 (UTC) Date: Sun, 4 Mar 2018 21:41:56 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304214156.GH92206@accordion.employees.org> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 21:41:58 -0000 On Sun, Mar 04, 2018 at 11:10:02AM -0800, Joe Touch wrote: > > It would be useful to show headers first, code later. Code changes; header can’t. The problem with that is such code then becomes inherently non portable, such that it isn't really safe to write the code in such a form. Anyway - here is a version which should work on a system offering packed structures, unaligned accesses, and the common zero length array extension. Hopefully I've not added any errors in applying structures. DF #define UDPHDR_LEN 8 #define CHK_LEN 2 #define OPT_LITE 2 struct surplus { uint16_t checksum; union { uint16_t words[0]; uint8_t tlv[0]; } u; }; struct opt_lite { uint8_t type; uint8_t len; uint16_t offset; }; /* * dp points to start of UDP payload, dlen is UDP payload length. * plen is IP payload length. * Assumed that dlen vs plen validity already verified. */ bool validate_options_chk (uint8_t *dp, uint16_t dlen, uint16_t plen) { uint16_t slen = plen - dlen - UDPHDR_LEN; struct surplus *sur = (void *)(dp + dlen); struct opt_lite *lite = (void *)sur->tlv; if (slen == 0) return true; /* No options */ if (slen < sizeof *sur) return false; /* Too short */ /* Cheat - assume it is safe to write one extra byte */ if (slen & 1) sur->u.tlv[slen - CHK_LEN] = 0; slen /= 2; uint32_t chk = sur->checksum; --slen; if (chk == 0) return true; /* Unprotected */ wp = sur->u.words; /* Account for LITE header, skip to remaining options */ if ((slen * 2 >= sizeof *lite) && lite->type == OPT_LITE && lite->len == sizeof *lite) { chk += wp[0]; chk += wp[1]; uint16_t oo = ntohs(lite->offset); if (oo < UDPHDR_LEN + dlen + CHK_LEN + sizeof *lite) return false; if (oo > plen - CHK_LEN - sizeof *lite) return false; wp = (uint16_t *)(dp + oo - UDPHDR_LEN + (CHK_LEN + sizeof *lite)); slen -= sizeof *lite / 2; } /* Everything from here is normal checksum algorithm */ while (slen--) chk += *wp++; /* add the fold over of chk here */ return (chk == 0) || (chk == 0xffff); } From nobody Sun Mar 4 13:51:26 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB88F126B72 for ; Sun, 4 Mar 2018 13:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T9HTnDGJW6X for ; Sun, 4 Mar 2018 13:51:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 8C4691200FC for ; Sun, 4 Mar 2018 13:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2OZOs89y6TINPESqpOld8jIWnVn9Z10jNLd6mInPKj8=; b=irMUSQme1ejhN3Wrn6+r+ltgg Uin4tTag2HXop5XJ02i7hqpLxP0u1+3ajAAkibG4R0tA+/KGCtwXmC9I4T3uefJKOz/OqsrfgLRKo SqiZBLNCct0eVm2IF2nCy/2i66DXGeWr9ybpF9AZHBsM64mWYy6UHDSeLWJdpHSQF7EhY9CgO1pqd PWsNFpF89pidjlhHpH7Hm2Cv8O4UoS4qb8TkxXI3bQ7gxgfRmMdErrYrBc+HaSSPFJUtbt9tTh9YC OO3PTTV18CIGyfeGOVGTVxFMnul99i/7r0SFK6Su2sJsVfNbuqIjO+cP+/0RrvEC3toRVIf12SyO5 iL+R/f52A==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49366 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esbXO-001qEc-6F; Sun, 04 Mar 2018 16:51:22 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304214156.GH92206@accordion.employees.org> Date: Sun, 4 Mar 2018 13:51:15 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <20180304214156.GH92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 21:51:25 -0000 > On Mar 4, 2018, at 1:41 PM, Derek Fawcus = wrote: >=20 > On Sun, Mar 04, 2018 at 11:10:02AM -0800, Joe Touch wrote: >>=20 >> It would be useful to show headers first, code later. Code changes; = header can=E2=80=99t. >=20 > The problem with that is such code then becomes inherently non = portable, > such that it isn't really safe to write the code in such a form. The doc won=E2=80=99t be specifying normative code. I=E2=80=99m not = aware of RFCs that do - they provide (at best) examples. We need specify headers and procedures and leave implementation details = to implementers. Joe From nobody Sun Mar 4 14:25:58 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A7F120227 for ; Sun, 4 Mar 2018 14:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfDFPwTii6JP for ; Sun, 4 Mar 2018 14:25:55 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 3EEC0126BFD for ; Sun, 4 Mar 2018 14:25:55 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id 130so18445140qkd.13 for ; Sun, 04 Mar 2018 14:25:55 -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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kUyVej1QPvd2SIa/sGoQ2CJR0v9WwsOOOWoY710WYzc=; b=KYaX4pSMnkBLh3HP5N9Xmi9TBh+DWaY8F0ZhRyGQeDyec1hnzCaTbKSuyHBOifZ5bZ 6c5Y1v59YH5+WApSbrGXwj5RUKhiPbnKhHdoqnNc1W/WLlxRHYwwgyryOVRuZ9Cwu6Th pss2QV0obqcelNuSQ2w4qdSK6+xMibZJVykIAGevVNrzd9zM5SWPsSqk23WBJxfQHbwm CJVu93hjJJUMUQsbXDPNR+TN2Ahaqyxmjj76YvRfRXEVXnSsBa6mMCeHAxlMtmreLnd1 WniwcrEU2ZYXrhTCnvY67uWPYS25xmbujIAUylbFKDiWQ33G1vZjPwC+ar8y3ZbvnWHC nFSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kUyVej1QPvd2SIa/sGoQ2CJR0v9WwsOOOWoY710WYzc=; b=Vohpkx4EAJ4+np5QfgLVfoi7sA2cEcgVjn+YGH5gCFURtWvBzNNh+DufhPVgFAfNu6 Y0xBEpENDcsb9eH0cZ3vN9P0R9PUGmMpicA5DMljfPj995xMdBTiupCs4nxauyS0Wr8v ZmNXFdDbvswZhljwymxVmDnmGQ2iGJb9r0rGVVQx7KLGDJYqSguEOSXMxDun9vsVU06H cwqVdqkLVOl37FJnzJrRB8kNYSlGrR3c4SsPEyeculPAzUP2kTAwaJMsppxmFzGRRXSZ ZXYnlNT4xNrWItX5WtJ5PuTPDV2v4ubdCqbtKi48S0FU44/aZd2OKo44cucIuKwPEh6f gDHA== X-Gm-Message-State: AElRT7Egu0Ac2rmTJWkAwpDgQVQRc3xgIRJ/twXKWSzqJWXKvANY1qFS /0FTgNQEbIcU2ri5IuxEori5heQf0q+Fph/MT/qDbw== X-Google-Smtp-Source: AG47ELtnRXzcxygfMVYe2GsrrVrI6d8pd3Lx2ggXU1R5YRcLsuY5lQcJv6P/Wff1+MHQwci5kJU1yLhfIA+TrCtH90s= X-Received: by 10.55.60.12 with SMTP id j12mr18914627qka.203.1520202354190; Sun, 04 Mar 2018 14:25:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 14:25:53 -0800 (PST) In-Reply-To: <425A8FEC-9356-46DA-B81C-46213F692498@strayalpha.com> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> <425A8FEC-9356-46DA-B81C-46213F692498@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 14:25:53 -0800 Message-ID: To: Joe Touch Cc: Derek Fawcus , tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 22:25:57 -0000 On Sun, Mar 4, 2018 at 12:25 PM, Joe Touch wrote: > > >> On Mar 4, 2018, at 12:22 PM, Tom Herbert wrote: >> >>> On Sun, Mar 4, 2018 at 11:59 AM, Joe Touch wrote= : >>> >>> >>>> On Mar 4, 2018, at 11:46 AM, Tom Herbert wrote: >>>> >>>> There may be implementations out there that are now creating non-zero >>>> slack space, and I don't think it's possible to retroactively declare >>>> that those are out of protocol conformance. >>> >>> They are until they=E2=80=99re defined as in. >>> >> ? From section 9 of the draft" :It has always been permissible for >> the UDP Length to be inconsistent with the IP transport payload length >> [RFC768]" > > Yes, but this doc is the first and only specified use thereof. > >> >>> Ie UDP is a standard. This doc extends that with a new one. There are n= o other similar extensions underway and none have already been approved. >>> >> What does "approved" mean? > > Standard in the Ietf. > > We can=E2=80=99t and don=E2=80=99t define standards to specify the use of= those who don=E2=80=99t follow standards. > Who is not following the standards? As you said in the draft it has always been permissible for the lengths not to match, so someone may already be beneficially using this like the draft is proposing. Slack space was never reserved for future use. We don't know if anyone is using it, but if they are it would conform with the standards AFAICT. So it's incumbent not to break them by retroactively declaring they are doing something, possibly for many years, as wrong and not approved. Tom >> If someone is using the slack space for >> their own purposes in their network then that is their business. AFAIK >> there is no RFC that say they are breaking anything and they don't >> need approval to do that. But, if UDP options are deployed things >> could then break things in these environments, That risk needs to be >> considered and proper mechanisms are used to mitigate the risk. If >> nothing else, these issues will be raised again when someone suggests >> to implement support in Linux and other OSes. Even if something is >> completely correct protocol-wise, we can't arbitrarily break things >> for real users. > > We don=E2=80=99t. Others do, and there is no way to ever prevent that. > > Joe >> >> Tom >>> > From nobody Sun Mar 4 14:37:14 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C04129BBF for ; Sun, 4 Mar 2018 14:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IYbhMqNoXRM for ; Sun, 4 Mar 2018 14:36:59 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 8446D127286 for ; Sun, 4 Mar 2018 14:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=y/21LHLkSmhignjhWVsnnr2oigUeeEdw286cKkv+vVU=; b=FIVJvQ9WY/X0gWGXyirFoEihH oNngcc3PLnaNzsavXW3dq5dLN0FNx7yHLw/5NqQbtH3NKxTygGCPJovVr8FcODj6PHwiTevq65T5X h4V7QSdeOkJjxuiamFccYDLFP//j1RwSHF4t6Wi+13ajC/P2HmA8YXrvl8OybS5+aNnvahdVLFNog ur3l07G2GCtfrTg5XBC7PklHdoVM98h45qLMa/EkOrAbrb+ZPB9lQiEMXanDbVLbL8DNsj7LT+c8Q abZOcm/vBzZfgVjvXrxWYzaVmxz/tCzFr92Fs5C5ptr/uOx5oLfIAtR+CO8quSzP6xWG36n8f/0PF t/A6gRU+Q==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49451 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1escFV-002lkJ-Qz; Sun, 04 Mar 2018 17:36:58 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Sun, 4 Mar 2018 14:36:50 -0800 Cc: tsvwg , Derek Fawcus Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> <425A8FEC-9356-46DA-B81C-46213F692498@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 22:37:13 -0000 > On Mar 4, 2018, at 2:25 PM, Tom Herbert wrote: >=20 > On Sun, Mar 4, 2018 at 12:25 PM, Joe Touch = wrote: >> ... >>=20 >> We can=E2=80=99t and don=E2=80=99t define standards to specify the = use of those who don=E2=80=99t follow standards. >>=20 > Who is not following the standards? Whoever else is actually using that spare area. > As you said in the draft it has > always been permissible for the lengths not to match, That explains why we=E2=80=99re not breaking UDP by trying to use it = optionally - not that all uses of that space are hereby validated. > Slack > space was never reserved for future use. Our doc only reminds us that it was not prohibited from future = *specified* use, and that=E2=80=99s what we=E2=80=99re doing. It was never authorized for un-specified uses. Joe From nobody Sun Mar 4 14:40:19 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB50124217 for ; Sun, 4 Mar 2018 14:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26JEmDoPLhcm for ; Sun, 4 Mar 2018 14:40:16 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6987C120227 for ; Sun, 4 Mar 2018 14:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:Message-Id:Subject:Date:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wzWgAqbpcB0ka5IullPHiZeomGHanv4STi0pk/mx7mI=; b=vm1X83F0YnmyI3EZKnmN/c2M17 64Xzzghvu8n4X5nN7kojUHqfbKfp23s3ZRalFFoFGietUDqwczszuPDR8+dkckYeOhB7gZO5PC+9o AnZcxLRwOlBulvCX1IhsgOaGQpRMoX8gLh6wXrTFCyoUR0r5mYfRUPd+wB0+z4dh1C3A4qghPeX6p lc6LckN1AIGdWbFG/CasTixdTAYXrDkSt+n/qmMyGCQ2sHj26WeYDQpXii2Em0LzRLdqol+6o+E0b 3GLzEF1CeuNJQ2jF9AHJT5eKC3+qyasamqKD78bXRcpv4dBgLDyyhfeOgxHR2XiLRR+473INzNCZ1 Q1fYom1A==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49456 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1escI6-002q6x-Rz; Sun, 04 Mar 2018 17:40:10 -0500 From: Joe Touch Content-Type: multipart/alternative; boundary="Apple-Mail=_39BD30F9-FB77-4F78-A32D-B25F4E27531E" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 4 Mar 2018 14:39:37 -0800 Message-Id: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> To: tsvwg X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 22:40:18 -0000 --Apple-Mail=_39BD30F9-FB77-4F78-A32D-B25F4E27531E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, IMO, we would benefit popping up a level to the list of issues and = summarizing our views. Here=E2=80=99s my attempt to do that. Joe =E2=80=94=E2=80=94=E2=80=94 Some assumptions: a) overhead is useful to minimize (efficiency and may reduce or = avoid fragmentation) b) LITE capability must be preserved c) LITE+FRAG capability must be preserved d) this solution is not expected to outperform TCP (i.e., this = is not an opportunity to redesign transport from scratch) - TLV vs fixed header motivated (AFAICT) by the desire to enable hardware optimization = and/or to detect error/misuses of spare area no clear hardware benefit (given the option area =E2=80=9Cfloats=E2= =80=9D relative to the UDP header,=20 which floats relative to the IPv6 header TLV chain, and given it = may not be word aligned) no clear benefit regarding packet errors or other spare area = uses=20 (both require either CS works or TLV chain parses, neither of = which is likely for random errors or other misuses) fixed wastes at least 2 bytes if CS isn=E2=80=99t used, (maybe = 4-6 if supporting LITE/LITE+FRAG) - Optional CS vs. mandatory motivated (AFAICT) by the desire to avoid processing packets = with errors (accidental or by others misusing the extra space) optional is needed to correlate to lack of UDP checksum (for = some types of tunnels, e.g.) mandatory also implies fixed (above), which incurs 2-6 bytes of = overhead=09 - option-area checksum details size 8 if TLV, 16 if fixed; no clear problem with either = choice algorithm no clear issue with using minor mods (foldover for 8 = bit, invert or not) there are known dangers to using the complement of the = sum=20 (such that the sum and data zero-out), as noted by the = Partridge paper in the 90s. - EOL vs option length field length would have to be 2 bytes; EOL is an optional one byte = (not needed if no spare area remains) EOL thus saves up to 2 bytes when not needed (and it should = generally not be needed at all) allowing EOL (i.e., allowing remaining unused spare area) = implies that processing needs to stop at some point,=20 either based on a counter or the data seen (and given that a CS = loads data into a register anyway, there=E2=80=99s no clear performance = win to either approach) EOL itself is patterned after the TCP option of the same name and yes, leaving the spare area available for future use by = other protocol extensions is intended here - does CS end when EOL is seen? yes, as currently specified as noted above, leaving the spare are for future standards is a = goal My conclusion is that all the choices above either fail to improve the = situation vs. our current proposal or increase overhead (or both). I = don=E2=80=99t yet see a reason why any of them warrant a change vs. the = existing approach. --Apple-Mail=_39BD30F9-FB77-4F78-A32D-B25F4E27531E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, all,

IMO, we would benefit popping up a = level to the list of issues and summarizing our views.

Here=E2=80=99s my attempt to do = that.

Joe

=E2=80=94=E2=80=94=E2=80=94

Some assumptions:
a) overhead is useful to minimize = (efficiency and may reduce or avoid fragmentation)
b) LITE capability must be = preserved
c) = LITE+FRAG capability must be preserved
d) this solution is not expected = to outperform TCP (i.e., this is not an opportunity to redesign = transport from scratch)

- TLV vs fixed header
= motivated (AFAICT) by the desire to enable hardware optimization = and/or to detect error/misuses of spare area
no clear hardware benefit (given the option area = =E2=80=9Cfloats=E2=80=9D relative to the UDP header, 
which floats relative to the IPv6 = header TLV chain, and given it may not be word aligned)
no clear benefit regarding packet = errors or other spare area uses 
(both require either CS works or = TLV chain parses, neither of which is likely for random errors or other = misuses)
fixed = wastes at least 2 bytes if CS isn=E2=80=99t used, (maybe 4-6 if = supporting LITE/LITE+FRAG)

- Optional CS vs. mandatory
motivated (AFAICT) by the desire = to avoid processing packets with errors (accidental or by others = misusing the extra space)
= optional is needed to correlate to lack of UDP checksum (for some = types of tunnels, e.g.)
= mandatory also implies fixed (above), which incurs 2-6 bytes of = overhead =

- = option-area checksum details
= size
8 = if TLV, 16 if fixed; no clear problem with either choice
algorithm
no clear issue with using = minor mods (foldover for 8 bit, invert or not)
there are known dangers = to using the complement of the sum 
(such that the sum and = data zero-out), as noted by the Partridge paper in the 90s.

- EOL vs option length = field
length = would have to be 2 bytes; EOL is an optional one byte (not needed if no = spare area remains)
EOL thus = saves up to 2 bytes when not needed (and it should generally not be = needed at all)
allowing = EOL (i.e., allowing remaining unused spare area) implies that processing = needs to stop at some point, 
= either based on a counter or the data seen (and given that a CS = loads data into a register anyway, there=E2=80=99s no clear performance = win to either approach)
= EOL itself is patterned after the TCP option of the same = name
and yes, = leaving the spare area available for future use by other protocol = extensions is intended here

- does CS end when EOL is seen?
yes, as currently = specified
as noted = above, leaving the spare are for future standards is a goal

My conclusion is that all the = choices above either fail to improve the situation vs. our current = proposal or increase overhead (or both). I don=E2=80=99t yet see a = reason why any of them warrant a change vs. the existing = approach.

= --Apple-Mail=_39BD30F9-FB77-4F78-A32D-B25F4E27531E-- From nobody Sun Mar 4 14:56:54 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93705126B72 for ; Sun, 4 Mar 2018 14:56:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHiE0fj6Phdo for ; Sun, 4 Mar 2018 14:56:51 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C07124217 for ; Sun, 4 Mar 2018 14:56:51 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id CE8742D50C9; Sun, 4 Mar 2018 22:56:50 +0000 (UTC) Date: Sun, 4 Mar 2018 22:56:50 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304225650.GI92206@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: [tsvwg] UDP options - FRAG+LITE X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 22:56:53 -0000 This was buried in the other thread, so pulling this out in to its own one: Looking at it again, I may have been misinterpreting how LITE+FRAG is to be used. I was reading it as still performing the same 'swap some bytes' logic as used for LITE alone. However looking again at Figure 8, maybe Joe means 'slide the LITE ahead of the 'LiteFrag'. Please clarify. DF From nobody Sun Mar 4 15:01:19 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA510126B72 for ; Sun, 4 Mar 2018 15:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyF3Dfu-XXoR for ; Sun, 4 Mar 2018 15:01:10 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 425E1126C25 for ; Sun, 4 Mar 2018 15:01:10 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id f25so18573526qkm.0 for ; Sun, 04 Mar 2018 15:01:10 -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:from:date:message-id:subject:to :cc; bh=9qMQ1rOLWMTpTJZLFH3H0mH33mC0xsXYeDra2wsYznQ=; b=2ALdzQDBOPRPlhclUqI2/0AoZhI/3fqG/IV1lALOoYmgmYZzhQko6863ByfSgoC0bo eV1qkJWXP5acRnbb34BCzh0vSj77uaP46+u21eBrwUmOMQ+AKVNw6XPOsnbHF9St2FSg 1SuH65bULIJi+nRFZOrydyuZxc4iszbH/vHSM3lFCXEBX5E7iEDO8mDYST8FHtg0PVh6 91VYFZIaTvRBToQd0b/PQPAnm7CGRyZF7ku0hEgkCZRDrWT4PssmvpzxZ15sQQ6F7/9/ p/DlID2L5W+W5NKYmmvONDnCemv9o83c/AMdzCH6j5rYnlhz2QvAdtO+K+f3/TW6sTKp 6ctg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9qMQ1rOLWMTpTJZLFH3H0mH33mC0xsXYeDra2wsYznQ=; b=GnIGoC4ltCAwu2LFhMpWMKOtaIN9PS59r7TgJIq/3BAu/XsjWeip9tuZmLumC85G7b uulEttRBAs1OGCdtbHoTFFGYHEq6+hwxqM70AjpijamYNV/DFE0ce5CHpMj/aSjfjDwP PBdl3BJBLsDFPB/F3WZmJfPLJjJtJQcoMQ6Hq0waktXlyywFOK4POdtc+iyxFZjOFAuM 3j/Kt8/L6WWxCVstMDk+BpEQeg4/+pO/BpN4Tfn6HFFV1EdA/xSfI3s90B5zETs7/S8v cYZoQikux4wrIa6FWhFh2pVeB85KGq1nHu3gSGUU5kB5bGYwdrrQMwfpWdQ6INyNcjTu PqwA== X-Gm-Message-State: AElRT7E6yPLdZSYR8qVKJguwTBHcRaUR0hf6G4yqWoRh4X2AsieVbj8V ukp0OCZJm9DiEwPBrDIZOKS+5KvrtqFgdg4jNHhwHA== X-Google-Smtp-Source: AG47ELvgQg1YAl9+knTv1WYwrad0Yni6MsjbuthP1ZZtfy2m+8AjDXPRJqpTP5wDEcqWqmAHV2cPTITdzIgtgAzgGiQ= X-Received: by 10.233.214.1 with SMTP id r1mr20183909qkk.121.1520204467943; Sun, 04 Mar 2018 15:01:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 15:01:07 -0800 (PST) Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 15:01:07 -0800 (PST) In-Reply-To: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> <425A8FEC-9356-46DA-B81C-46213F692498@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 15:01:07 -0800 Message-ID: To: Joe Touch Cc: tsvwg , Derek Fawcus Content-Type: multipart/alternative; boundary="089e08e5966b4c550c05669e2fa8" Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 23:01:12 -0000 --089e08e5966b4c550c05669e2fa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mar 4, 2018 2:36 PM, "Joe Touch" wrote: > On Mar 4, 2018, at 2:25 PM, Tom Herbert wrote: > > On Sun, Mar 4, 2018 at 12:25 PM, Joe Touch wrote: >> ... >> >> We can=E2=80=99t and don=E2=80=99t define standards to specify the use o= f those who don=E2=80=99t follow standards. >> > Who is not following the standards? Whoever else is actually using that spare area. Joe, I'm having a hard time finding what the standards say in this area. RFC768 defines UDP length, but says nothing more about this. Please provide specific references to the operative RFCs with standards that would be violated. Thanks, Tom > As you said in the draft it has > always been permissible for the lengths not to match, That explains why we=E2=80=99re not breaking UDP by trying to use it option= ally - not that all uses of that space are hereby validated. > Slack > space was never reserved for future use. Our doc only reminds us that it was not prohibited from future *specified* use, and that=E2=80=99s what we=E2=80=99re doing. It was never authorized for un-specified uses. Joe --089e08e5966b4c550c05669e2fa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mar 4, 2018 2:36 PM, "Joe Touch" <touch@strayalpha.com> wrote:


> On Mar 4, 2018, at 2:25 PM, Tom Herbert <tom@herbertland.com> wrote:
>
> On Sun, Mar 4, 2018 at 12:25 PM, Joe Touch <touch@strayalpha.com> wrote:
>> ...
>>
>> We can=E2=80=99t and don=E2=80=99t define standards to specify the= use of those who don=E2=80=99t follow standards.
>>
> Who is not following the standards?

Whoever else is actually using that spare area.

Joe,

I'm having a hard time finding what the standards say i= n this area. RFC768 defines UDP length, but says nothing more about this. P= lease provide specific references to the operative RFCs with standards that= would=C2=A0 be violated.

Thanks,
Tom


> As you said in the draft it has
> always been permissible for the lengths not to match,

That explains why we=E2=80=99re not breaking UDP by trying to use it = optionally - not that all uses of that space are hereby validated.

> Slack
> space was never reserved for future use.

Our doc only reminds us that it was not prohibited from future *speci= fied* use, and that=E2=80=99s what we=E2=80=99re doing.

It was never authorized for un-specified uses.

Joe


--089e08e5966b4c550c05669e2fa8-- From nobody Sun Mar 4 15:07:28 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC6F126B72 for ; Sun, 4 Mar 2018 15:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1hT1lX93UBV for ; Sun, 4 Mar 2018 15:07:24 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C3BDE126C22 for ; Sun, 4 Mar 2018 15:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lRucIGIO2C8zXAOn65nNTWrmnujgBB461+sh1ZNTXv4=; b=hNdmoA2OxuFeiCHSPgfnxD5wo ONnheaeJkngXOK1M9l+NcdIE786XbsPmgA7wDJdbXlxVri+oNxY5R3i2DsJrCz4xaLs05ZEhOBfVm bSrNDQcLlnpAftdNT8fhCe/Ec6JmJ77m7Tgk+Z5I6bFIbCCphCMrGQwkEJv+nyNbMn+gt2Xzkv5gP zuw9kMejUDfoAmrEL22gpjVk2CvbU0Be9Sn8Kc6w/oFKf3nF2+wYPSZtapOw06RkraNC2aGN1ww4n xL3yIShPygA/aOqkJqPLOk6H/NcZKrNYrMX0Jmftzs/SM5syq94IEgTCw4xPvl6vwi8kuOy69gcYl ucAyG0LSw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49483 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1escim-003HaA-PV; Sun, 04 Mar 2018 18:07:13 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304225650.GI92206@accordion.employees.org> Date: Sun, 4 Mar 2018 15:07:11 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180304225650.GI92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options - FRAG+LITE X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 23:07:26 -0000 On Mar 4, 2018, at 2:56 PM, Derek Fawcus = wrote: >=20 > This was buried in the other thread, so pulling this out in to its own = one: >=20 > Looking at it again, I may have been misinterpreting how LITE+FRAG > is to be used. I was reading it as still performing the same 'swap = some bytes' > logic as used for LITE alone. However looking again at Figure 8, = maybe > Joe means 'slide the LITE ahead of the 'LiteFrag'. Please clarify. >=20 > DF Fig 8 is ACS. I=E2=80=99ve lost context. Can you ask the question again and clarify which fig you=E2=80=99re = referring to? Joe From nobody Sun Mar 4 15:10:02 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C53126B6E for ; Sun, 4 Mar 2018 15:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVAN1vZk0G9N for ; Sun, 4 Mar 2018 15:09:59 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 3BE70124217 for ; Sun, 4 Mar 2018 15:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RygffHy4C8QrdCk2NldYr8MgcqVMv4FAuHvfLRvleCM=; b=Kq2QdBtyMGWHIz2c7Sc0jVG8S P5mX2Vw3Lh49bL+kTYUc1iCxFl/O5cYTYeMJ6IJitJze6S5ihWiFbH/f1h28C1tsN/ptXXCmELWSe uo96NOYbyojZb+4JGWcWjHoQn6hx86gpahGadrApcy1acXTj4iVIuoDpqsLtr40UCp1G6vLOZIzCG gRQM+LfLqtLTckDuD2dvOCHryvXmm71dawg8HoQfhct117Q4LufIUHIGE34n3KkTAHecW3CRL/JnS RBgo8oV0WclWrKehjf8CnytwViZl32azCjpSvKx9jUcxR/QziIcY0oFz0wS0eq7A4vhQGxMPl8Z2S yprpouj2Q==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49485 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esclH-003LfN-IB; Sun, 04 Mar 2018 18:09:48 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_553FB962-484E-4E79-B290-B09091988B6F" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Sun, 4 Mar 2018 15:09:46 -0800 Cc: tsvwg , Derek Fawcus Message-Id: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> <425A8FEC-9356-46DA-B81C-46213F692498@strayalpha.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 23:10:00 -0000 --Apple-Mail=_553FB962-484E-4E79-B290-B09091988B6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 4, 2018, at 3:01 PM, Tom Herbert wrote: >=20 >=20 >=20 > On Mar 4, 2018 2:36 PM, "Joe Touch" > wrote: >=20 >=20 > > On Mar 4, 2018, at 2:25 PM, Tom Herbert > wrote: > > > > On Sun, Mar 4, 2018 at 12:25 PM, Joe Touch > wrote: > >> ... > >> > >> We can=E2=80=99t and don=E2=80=99t define standards to specify the = use of those who don=E2=80=99t follow standards. > >> > > Who is not following the standards? >=20 > Whoever else is actually using that spare area. >=20 > Joe, >=20 > I'm having a hard time finding what the standards say in this area. = RFC768 defines UDP length, but says nothing more about this. Please = provide specific references to the operative RFCs with standards that = would be violated. You=E2=80=99re looking for something that is defined by its absence. 1) RFC 768 does not prohibit use of the area, BUT DOES NOT DEFINE A = SPECIFIC USE either 2) there are no other RFCs (except this one, when published as such) = that define a specific use Thus any specific use (other than ones documented by us here) would be = not be a standard. We don=E2=80=99t need to thus *support* that = particular (not yet authorized) use. Joe --Apple-Mail=_553FB962-484E-4E79-B290-B09091988B6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 4, 2018, at 3:01 PM, Tom Herbert <tom@herbertland.com>= wrote:



On Mar = 4, 2018 2:36 PM, "Joe Touch" <touch@strayalpha.com> wrote:


> On Mar 4, 2018, at 2:25 PM, Tom Herbert <tom@herbertland.com>= wrote:
>
> On Sun, Mar 4, 2018 at 12:25 PM, Joe Touch <touch@strayalpha.com> wrote:
>> ...
>>
>> We can=E2=80=99t and don=E2=80=99t define standards to specify = the use of those who don=E2=80=99t follow standards.
>>
> Who is not following the standards?

Whoever else is actually using that spare area.

Joe,

I'm having a hard time = finding what the standards say in this area. RFC768 defines UDP length, = but says nothing more about this. Please provide specific references to = the operative RFCs with standards that would  be = violated.

You=E2=80=99re looking for something that is = defined by its absence.

1) RFC 768 = does not prohibit use of the area, BUT DOES NOT DEFINE A SPECIFIC USE = either
2) there are no other RFCs (except this one, when = published as such) that define a specific use

Thus any specific use (other than ones documented = by us here) would be not be a standard. We don=E2=80=99t need to thus = *support* that particular (not yet authorized) use.

Joe

= --Apple-Mail=_553FB962-484E-4E79-B290-B09091988B6F-- From nobody Sun Mar 4 15:22:03 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BBF126B6E for ; Sun, 4 Mar 2018 15:22:02 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kweWx8K2xQXI for ; Sun, 4 Mar 2018 15:22:00 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C94124217 for ; Sun, 4 Mar 2018 15:22:00 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 8DEFD2D5048; Sun, 4 Mar 2018 23:22:00 +0000 (UTC) Date: Sun, 4 Mar 2018 23:22:00 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304232200.GJ92206@accordion.employees.org> References: <20180304225650.GI92206@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] UDP options - FRAG+LITE X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 23:22:02 -0000 On Sun, Mar 04, 2018 at 03:07:11PM -0800, Joe Touch wrote: > On Mar 4, 2018, at 2:56 PM, Derek Fawcus wrote: > > > > This was buried in the other thread, so pulling this out in to its own one: > > > > Looking at it again, I may have been misinterpreting how LITE+FRAG > > is to be used. I was reading it as still performing the same 'swap some bytes' > > logic as used for LITE alone. However looking again at Figure 8, maybe > > Joe means 'slide the LITE ahead of the 'LiteFrag'. Please clarify. > > > > DF > > Fig 8 is ACS. I’ve lost context. > > Can you ask the question again and clarify which fig you’re referring to? Sorry Fig 18 - sect 5.8.1. DF From nobody Sun Mar 4 15:29:35 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361A2126B72 for ; Sun, 4 Mar 2018 15:29:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKy5fzjrvCBH for ; Sun, 4 Mar 2018 15:29:31 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E9E124217 for ; Sun, 4 Mar 2018 15:29:31 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 849FC2D4FEA; Sun, 4 Mar 2018 23:29:31 +0000 (UTC) Date: Sun, 4 Mar 2018 23:29:31 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180304232931.GK92206@accordion.employees.org> References: <20180304225650.GI92206@accordion.employees.org> <20180304232200.GJ92206@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180304232200.GJ92206@accordion.employees.org> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] UDP options - FRAG+LITE X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 23:29:33 -0000 On Sun, Mar 04, 2018 at 11:22:00PM +0000, Derek Fawcus wrote: > On Sun, Mar 04, 2018 at 03:07:11PM -0800, Joe Touch wrote: > > On Mar 4, 2018, at 2:56 PM, Derek Fawcus wrote: > > > > > > This was buried in the other thread, so pulling this out in to its own one: > > > > > > Looking at it again, I may have been misinterpreting how LITE+FRAG > > > is to be used. I was reading it as still performing the same 'swap some bytes' > > > logic as used for LITE alone. However looking again at Figure 8, maybe > > > Joe means 'slide the LITE ahead of the 'LiteFrag'. Please clarify. > > > > > > DF > > > > Fig 8 is ACS. I’ve lost context. > > > > Can you ask the question again and clarify which fig you’re referring to? > > Sorry Fig 18 - sect 5.8.1. Compare it to Fig 12 for LITE alone. In fig 12 the arrow points to 'Ldat', data swapped from the front of the 'Lite data' section, whereas in 18 it points to the FRAG header. Suggesting sliding blocks, vs if it point to say 'LFdat' i.e. data swapped from the front of the 'Lite Frag' section. So I'm asking if the swap mechanism used for LITE alone is supposed to be used for LITE+FRAG, or if you intend some other mechanism? I'm reading Fig 18 as suggesting a different mechanism, i.e. reorder the chunks from the order 'Lite Frag', 'LITE', 'FRAG' to be in the order 'LITE', 'Lite Frag', 'FRAG', which would entail rewriting all of the bytes between the UDP header and the FRAG header. DF From nobody Sun Mar 4 16:27:08 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C172124217 for ; Sun, 4 Mar 2018 16:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGuNCwmcMsBQ for ; Sun, 4 Mar 2018 16:27:04 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 968EA1201FA for ; Sun, 4 Mar 2018 16:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AQC35kCU+KMcOnlF38o5Ie2Umm7LoP3Wa9Q0W4g509E=; b=1kziYzW2c0yMlhto32WL2XtXT XKz+62ZeN0AT1qYRD7R3UrupsyYpNfPTdzGeSRAogOtajUt2yB5VBAvfoFXbimGo63iBIHfs41RN4 u/6FIPMl8gPjJ0iDARdPwAzhgH1eC92ThPycQUOFEkaENz/jsP7onU38a7X1uV/jevVPAm9WhvhoQ cfmky6czGvnm6pxNbLz8XDeI+rV765PQd6LzT8VYsDarJVymTZu+AQNqmpLNT8z/HalmYptj1kdtY ZDumzRfvTKSieORkZmFzL/7U1T2ehPrmY+ObPkk9kKU7mLJc6a8lWGBmGxlND2xxdJJ0UqV3Ta07v pgkqkkPGw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50301 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esdxx-000Ku7-3m; Sun, 04 Mar 2018 19:27:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_1D1457B6-477C-4B1E-9D6F-E7F8010C6DE2" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180304232931.GK92206@accordion.employees.org> Date: Sun, 4 Mar 2018 16:26:55 -0800 Cc: tsvwg Message-Id: <18D3CE97-6973-41D6-A2DC-276FFA1E7C18@strayalpha.com> References: <20180304225650.GI92206@accordion.employees.org> <20180304232200.GJ92206@accordion.employees.org> <20180304232931.GK92206@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options - FRAG+LITE X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 00:27:06 -0000 --Apple-Mail=_1D1457B6-477C-4B1E-9D6F-E7F8010C6DE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In LITE, on transmission: info ordering starts as shown in Fig 10 (or 11 - same thing): UDPpayload / LITEdata[0..n] / LITEopthdr / otherheaders the first 4 bytes of LITEdata are swapped with the LITEopthdr as = shown in Fig 12: UDPpayload / LITEopthdr / LITEdata[4=E2=80=A6n] / = LITEdata[0..3] / otherheaders On reception, the sequence is reversed once the LITEopthdr is seen. =E2=80=94=E2=80=94 Figs 17 and 18 are intended to just be an instance of Figs 10/11 and 12 = (respectively) with the following specifics: a) UDPpayload is null (i.e., 0 bytes) b) otherheaders starts with the FRAGopthdr (Fig 18 doesn=E2=80=99t quite show the LITEdata[0=E2=80=A63] where it = should be - I=E2=80=99ll fix that) I.e., there=E2=80=99s nothing different here. Nothing =E2=80=9Cslides=E2=80= =9D; it's (intended to be) the same swap operation. Joe > On Mar 4, 2018, at 3:29 PM, Derek Fawcus = wrote: >=20 > On Sun, Mar 04, 2018 at 11:22:00PM +0000, Derek Fawcus wrote: >> On Sun, Mar 04, 2018 at 03:07:11PM -0800, Joe Touch wrote: >>> On Mar 4, 2018, at 2:56 PM, Derek Fawcus = wrote: >>>>=20 >>>> This was buried in the other thread, so pulling this out in to its = own one: >>>>=20 >>>> Looking at it again, I may have been misinterpreting how LITE+FRAG >>>> is to be used. I was reading it as still performing the same 'swap = some bytes' >>>> logic as used for LITE alone. However looking again at Figure 8, = maybe >>>> Joe means 'slide the LITE ahead of the 'LiteFrag'. Please clarify. >>>>=20 >>>> DF >>>=20 >>> Fig 8 is ACS. I=E2=80=99ve lost context. >>>=20 >>> Can you ask the question again and clarify which fig you=E2=80=99re = referring to? >>=20 >> Sorry Fig 18 - sect 5.8.1. >=20 > Compare it to Fig 12 for LITE alone. In fig 12 the arrow points to = 'Ldat', > data swapped from the front of the 'Lite data' section, whereas in 18 = it points > to the FRAG header. Suggesting sliding blocks, vs if it point to say = 'LFdat' > i.e. data swapped from the front of the 'Lite Frag' section. >=20 > So I'm asking if the swap mechanism used for LITE alone is supposed to = be used > for LITE+FRAG, or if you intend some other mechanism? >=20 > I'm reading Fig 18 as suggesting a different mechanism, i.e. reorder = the chunks > from the order 'Lite Frag', 'LITE', 'FRAG' to be in the order 'LITE', = 'Lite Frag', > 'FRAG', which would entail rewriting all of the bytes between the UDP = header and > the FRAG header. >=20 > DF --Apple-Mail=_1D1457B6-477C-4B1E-9D6F-E7F8010C6DE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
In LITE, on transmission:

info ordering starts as shown in = Fig 10 (or 11 - same thing):
= UDPpayload / LITEdata[0..n] / LITEopthdr / otherheaders

the first = 4 bytes of LITEdata are swapped with the LITEopthdr as shown in Fig = 12:
UDPpayload / LITEopthdr / = LITEdata[4=E2=80=A6n] / LITEdata[0..3] / otherheaders

On reception, the = sequence is reversed once the LITEopthdr is seen.
=E2=80=94=E2=80=94

Figs 17 and 18 are = intended to just be an instance of Figs 10/11 and 12 (respectively) with = the following specifics:

= a) UDPpayload is null (i.e., 0 bytes)
b) = otherheaders starts with the FRAGopthdr


(Fig= 18 doesn=E2=80=99t quite show the LITEdata[0=E2=80=A63] where it should = be - I=E2=80=99ll fix that)

I.e., there=E2=80=99s nothing different here. Nothing = =E2=80=9Cslides=E2=80=9D; it's (intended to be) the same swap = operation.

Joe


On Mar 4, 2018, at 3:29 PM, Derek Fawcus = <dfawcus+lists-tsvwg@employees.org> wrote:

On Sun, Mar 04, 2018 at = 11:22:00PM +0000, Derek Fawcus wrote:
On Sun, Mar 04, 2018 at = 03:07:11PM -0800, Joe Touch wrote:
On Mar 4, 2018, at 2:56 PM, Derek Fawcus <dfawcus+lists-tsvwg@employees.org> wrote:

This was = buried in the other thread, so pulling this out in to its own one:

Looking at it again, I may have been = misinterpreting how LITE+FRAG
is to be used.  I was = reading it as still performing the same 'swap some bytes'
logic as used for LITE alone.  However looking again at = Figure 8, maybe
Joe means 'slide the LITE ahead of the = 'LiteFrag'.  Please clarify.

DF

Fig 8 is ACS. I=E2=80=99ve lost = context.

Can you ask the question again and = clarify which fig you=E2=80=99re referring to?

Sorry Fig 18 - sect 5.8.1.

Compare it to Fig 12 for LITE alone. =  In fig 12 the arrow points to 'Ldat',
data swapped from the front of the 'Lite data' = section, whereas in 18 it points
to the FRAG header. Suggesting = sliding blocks, vs if it point to say 'LFdat'
i.e. data swapped from the front of the 'Lite = Frag' section.

So I'm asking if the swap = mechanism used for LITE alone is supposed to be used
for LITE+FRAG, or if you intend some other = mechanism?

I'm reading Fig 18 as suggesting = a different mechanism, i.e. reorder the chunks
from the order 'Lite Frag', 'LITE', 'FRAG' to be = in the order 'LITE', 'Lite Frag',
'FRAG', which would entail = rewriting all of the bytes between the UDP header and
the FRAG header.

DF

= --Apple-Mail=_1D1457B6-477C-4B1E-9D6F-E7F8010C6DE2-- From nobody Sun Mar 4 19:47:00 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288B6124C27 for ; Sun, 4 Mar 2018 19:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vM16aoyhz2j for ; Sun, 4 Mar 2018 19:46:56 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 AEDE41241F3 for ; Sun, 4 Mar 2018 19:46:56 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id t6so18838322qtn.9 for ; Sun, 04 Mar 2018 19:46:56 -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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HzeeFbMIWTojRd8bvAQ9U287UWxrrZsYG3xpjx6nHg8=; b=XwrREL0x5oKNUIFWq1OIrz1dSfQKypc0YOIUiV6e/U1unDD9/lKbu7kF9LVKC+MypI 5gVQ2NBSmp8tMjix7EVCFljB4FopfGbZzu73sxUAbGbDUNKRNfLiSyoPuFRag6BckK12 Uy7SZP+d2s4P3rnf2NrpC5i7lGhPTwzmwuSH4G2pbQiLRLqn/Kqa2AFCfK279eHEVf9o 1eZF06N6WhV6JTvLpCOTtyZcfu5iBmY5DOXSpYTpVT9NPbbpSe4gCIHtT3io6tBN6Q4B 2k60qzOd3nLKp6I25sn2AxYTuGq36rFXW4+xnQgslTHC2dg5OoVM0QXgHc3hwHF8glDi dLlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HzeeFbMIWTojRd8bvAQ9U287UWxrrZsYG3xpjx6nHg8=; b=A9EvSDKW9bCfty4H6iWLiEcoxyIwIiK8gMRMq1Xecx/LxFeXfyF7oI9xLITCEqQeAD YMGFdLH8Y1qwWoJdKbkRn2Ejo51oiP/d3uFBlfttS4s4VrQb/kI9O82Gvti65KWCjVmC iAe7n57Y2wDgm5W3xFkFczj2celnF5+joLCqoU3mAOcbE4WaqkiJ3tLDXB7JoXlSwC/L M9OItfw0K48HYWKMsD2mxL4TypiJyl2uaXWOwb4ZwjP6VvNqOnt0o05QBBJjhjAyr787 envUF7OKoQT1vwrAGh/mqAcgcLyDx/Y0+Cqg3W/yVPNPHFUAkHOtbKLohoLx3Gj1FU/C y92w== X-Gm-Message-State: AElRT7E9/Cp0hUZYr3EHSXp+ON+mZ9HQVQKLgpAas8qu92cX0lQfDGL5 Tj/B6nszeSNG6HXdzZjIeYWZPPTUUfwgW6H7ZIF9Kg== X-Google-Smtp-Source: AG47ELvTOThpXe/sYuzCHiyAc8HhFtux2iHRGA/WOOPh+FU3NXcMhl0FKs8f/RpERpmwoqTb2kCW6P1McXv9rzxptBY= X-Received: by 10.200.52.73 with SMTP id v9mr20779765qtb.66.1520221615662; Sun, 04 Mar 2018 19:46:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 19:46:54 -0800 (PST) In-Reply-To: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <2EA15FC1-3E5B-4AC0-BDDD-F125AEF08A2F@strayalpha.com> <5E98B496-D533-4A08-A388-7A24C9313D59@strayalpha.com> <425A8FEC-9356-46DA-B81C-46213F692498@strayalpha.com> From: Tom Herbert Date: Sun, 4 Mar 2018 19:46:54 -0800 Message-ID: To: Joe Touch Cc: tsvwg , Derek Fawcus Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 03:46:58 -0000 On Sun, Mar 4, 2018 at 3:09 PM, Joe Touch wrote: > > > On Mar 4, 2018, at 3:01 PM, Tom Herbert wrote: > > > > On Mar 4, 2018 2:36 PM, "Joe Touch" wrote: > > > >> On Mar 4, 2018, at 2:25 PM, Tom Herbert wrote: >> >> On Sun, Mar 4, 2018 at 12:25 PM, Joe Touch wrote: >>> ... >>> >>> We can=E2=80=99t and don=E2=80=99t define standards to specify the use = of those who don=E2=80=99t >>> follow standards. >>> >> Who is not following the standards? > > Whoever else is actually using that spare area. > > > Joe, > > I'm having a hard time finding what the standards say in this area. RFC76= 8 > defines UDP length, but says nothing more about this. Please provide > specific references to the operative RFCs with standards that would be > violated. > > > You=E2=80=99re looking for something that is defined by its absence. > Joe, I don't understand the concept of something being defined by it's absence. In any case, I will suggest a four byte header in the options space: header type: 1 byte length: 1 bytes csum: 2 bytes The header type allows alternate formats, so if someone is already using the slack space they can define a type for it. The length is just the length in bytes not including first four bytes (I don't see any legitimate reason to make it more than 255 bytes max). csum is the normal 1-s complement checksum calculated from the header type byte through the length + 4. IMO checksum should always be set since it's only over a small amount of data and as I mentioned it's likely that a host will need to compute the checksum anyway in checksum complete processing. If it is desirable for it to be optional then zero could be used. The value of this header is that it provides a consistent means to verify with pretty good probability that UDP options are correctly formed. Also, it allows other formats in the slack space to be defined. The cost is four bytes of overhead, but as I said before I believe that is inconsequential compared to the assuring correctness of the protocol. Tom From nobody Sun Mar 4 20:30:37 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B2B124E15 for ; Sat, 3 Mar 2018 06:18:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff7xIDeJQl8I for ; Sat, 3 Mar 2018 06:18:06 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094EE120721 for ; Sat, 3 Mar 2018 06:18:05 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id AE7432D5048; Sat, 3 Mar 2018 14:18:05 +0000 (UTC) Date: Sat, 3 Mar 2018 14:18:05 +0000 From: Derek Fawcus To: Derek Fawcus Cc: tsvwg@ietf.org Message-ID: <20180303141805.GB39320@accordion.employees.org> References: <151641832182.3163.5991614599671930276@ietfa.amsl.com> <20180303140456.GA39320@accordion.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180303140456.GA39320@accordion.employees.org> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: X-Mailman-Approved-At: Sun, 04 Mar 2018 20:30:36 -0800 Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 14:18:07 -0000 On Sat, Mar 03, 2018 at 02:04:56PM +0000, Derek Fawcus wrote: > I also suggested how this would work when the FRAG mechanism was in use. That is a typo, it should have said LITE header, not FRAG mechanism. DF From nobody Sun Mar 4 20:30:42 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F170D1242F7 for ; Sun, 4 Mar 2018 10:50:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNUk_qcAZDoe for ; Sun, 4 Mar 2018 10:50:42 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652B31205D3 for ; Sun, 4 Mar 2018 10:50:42 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 40B9A2D50DF; Sun, 4 Mar 2018 18:50:41 +0000 (UTC) Date: Sun, 4 Mar 2018 18:50:41 +0000 From: Derek Fawcus To: Joe Touch Cc: Derek Fawcus , tsvwg Message-ID: <20180304185041.GF92206@accordion.employees.org> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: X-Mailman-Approved-At: Sun, 04 Mar 2018 20:30:36 -0800 Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 18:50:44 -0000 On Sun, Mar 04, 2018 at 10:19:15AM -0800, Joe Touch wrote: > > On Mar 4, 2018, at 8:54 AM, Derek Fawcus wrote: > > > > Nope. Use the existing swap scheme, and have the checksum cover from the > > start of the LITE header in figure 10 through to the end of the surplus > > area. > > I’m not sure how that works. > > If the OCS always comes first, when you hit it you stop and compute the checksum. Note I am suggesting to remove the OCS option. So we'd have a fixed 2 byte field, followed by a bunch of TLV options. When LITE is being used, LITE would be the first TLV in the TLV section. > So we need a fixed field (for the same reason) to always indicate whether LITE > is present and the swap needs to happen before the checksum proceeds. If the checksum is in a fixed field up front, and there is no OCS option, the the code I posted shows how the checksum can be verified without first performing the swap. > You note this in your other post with the code: > > > One thing I noticed in coding this is that there is a minimal LITE length > > which can be carried, currently 4 bytes, and then 6 bytes in my scheme. > > To carry less, the 'swap bytes for LITE' would have to be replaced with > > a more complex case handling overlapping ranges, which I don't view as > > worthwhile. It would however be worth calling this out in the document. > > So you’re saying at least that the minimum overhead for all options goes from zero bytes (in the current scheme) to 6 (2 for the checksum, 4 for LITE even when it isn’t used). No - I am saying two things: 1) with the current scheme, due to the 'swap logic', there have to be at least 4 bytes of LITE data when it is being used without FRAG. 2) with my scheme, the same LITE without FRAG would imply there would have to be at least 6 bytes of LITE data. Now looking at it again, I may have been misinterpreting how LITE+FRAG is to be used. I was reading it as still performing the same 'swap some bytes' logic as used for LITE alone. However looking again at Figure 8, maybe you mean 'slide the LITE ahead of the 'LiteFrag'. Please clarify. I believe the LITE+FRAG case should still work if the 'swap some bytes' approach for LITE alone was used in the encoding/decoding first step. If the 'swap some bytes' scheme is to be used, then it would likewise imply that would have to be at least 4 bytes within the 'LiteFrag' using the current scheme, and 6 bytes there with my scheme. I do not see that as a problem in the use case with either approach, as it simply affects how one would generate fragments. As to the minimal overhead in general. In the current scheme it is zero, in my scheme it would be two. > And you have to handle LITE processing or at least checking even when you’re not using it at all. That is no diferent from the current scheme, where one always has to check the start of the surplus area to see if it states with a LITE header. Have you looked at the code I included? Or should I try and express that algorithm in some other fashion? (I did rather assume that most people would be able to comprehend C :-) DF From nobody Sun Mar 4 21:10:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8B124B0A for ; Sun, 4 Mar 2018 21:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tMEm44IpXPn for ; Sun, 4 Mar 2018 21:10:37 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 64EF1124235 for ; Sun, 4 Mar 2018 21:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JjZFlbs2LZBMC6Rqg8aQPqbGGIS5t6m7YRX89ejzwHU=; b=c3YqcmCicItVYx9Dk0Lm8/KLZ JwxIQJKHrxgI5W70iaFugAFQLzNtdLCIX0zbp9wbWmrOFZ7D2J8YrubaFoEgoFmeIPiBkpUlMRaCZ KZWMumswnbJK84CUGeVMZODJiOPiS/r0dw8515Ylg4u0DOmWPyJu/gSv1op3e78cQj94LddYmaT7Z LYwt3ry13uED+qtIzojI+73ZBZNOFe3kN+0Bj+tPN/BUrLkf/B+cTXEpuzTBi7oo2EI7pBmf2s0WR Hq48EKttItHfpVYVd7lOd65FMK8VUegYBzW/Q1mBtn+B6Zge2+KmxkDBbOhZtB2NZQFIjWubWMEIR ZqusGqfgw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57529 helo=[192.168.1.158]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esiO0-000fqg-JX; Mon, 05 Mar 2018 00:10:26 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (15D100) In-Reply-To: <20180304185041.GF92206@accordion.employees.org> Date: Sun, 4 Mar 2018 21:10:07 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <8C831161-12A5-4AC2-AAAD-C34664ABFEF6@strayalpha.com> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> To: Derek Fawcus X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 05:10:39 -0000 > On Mar 4, 2018, at 10:50 AM, Derek Fawcus wrote: >=20 > Have you looked at the code I included? No, and I do not plan to. Again, we=E2=80=99re not standardizing code. > Or should I try and express that algorithm in some other fashion? As I noted, it is useful to show a header and explain the approach as in a s= pec, not an algorithm. Joe= From nobody Mon Mar 5 00:09:53 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B301127023; Mon, 5 Mar 2018 00:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1_cpc6KJStH; Mon, 5 Mar 2018 00:09:43 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::71f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1B2126579; Mon, 5 Mar 2018 00:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O+Hk7qt2z7C/1CoIE2FGg58IsLx/lIpdqgOQ7jDcLLQ=; b=qtoGQE0pEvC/RCqLFcu5Z1PTN++S8yvzihogDK5hQAzEeMi60VWxKXC2hU7FKTMXtTAwEVDq5effag2Ykfp6cWartWiHDP6xY5CUnCr2w1Cnl5Ui9D5dX2h4V8Lq66h1gxSCu85AbuOy6G0HOt5j0D4TO9jOOFUpNLCVGYVSy7k= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2642.eurprd07.prod.outlook.com (10.173.92.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Mon, 5 Mar 2018 08:09:39 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::4935:9288:dcd6:7db0]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::4935:9288:dcd6:7db0%5]) with mapi id 15.20.0567.011; Mon, 5 Mar 2018 08:09:39 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Yingzhen Qu , "gorry@erg.abdn.ac.uk" CC: Thomas Nadeau , "tcpm@ietf.org" , Yingzhen Qu , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Thread-Topic: [tsvwg] Agenda requests for TSVWG@IETF101 Thread-Index: AQHTs31He8dVfiO+dEamE9tKlKhCoqO/3CkggAArYoCAAIi0AIAAt21Q Date: Mon, 5 Mar 2018 08:09:39 +0000 Message-ID: References: <5A9BEB65.6010102@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [92.203.242.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2642; 7:LjrrmYiz5j6jYS+F7ZQCiJpCBoaeWT/U722/w/9mXTubHjD0r7BFEcqiBqPJV18IdX/xk7cpXHHiIvipNZkGv23tJCVgnijcMLPFeiesy4wPZWSMYu9Zo9uxsEuUBAeDYZ+HjF7mR8QvsC0W5DFMJgbrtrySsCcBg6ZQmhYVolNaGiWlN4uNToQF7dQEE3oNahm+d12N8iDAokzBI5pbBQU6L587f9CtagpyIAwMZKu7xLZvEdxR2CUo/hZaMayL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 11c9d21a-8e45-418c-a36d-08d582707173 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:AM5PR0701MB2642; x-ms-traffictypediagnostic: AM5PR0701MB2642: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(50582790962513)(82608151540597)(85827821059158)(130329453890623)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231220)(11241501184)(806099)(944501244)(52105095)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:AM5PR0701MB2642; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2642; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39380400002)(346002)(396003)(39860400002)(199004)(51914003)(189003)(53754006)(97736004)(54896002)(6436002)(6306002)(55016002)(76176011)(606006)(25786009)(186003)(14454004)(81166006)(86362001)(66066001)(39060400002)(81156014)(105586002)(2906002)(3280700002)(229853002)(236005)(9686003)(26005)(8676002)(99286004)(106356001)(316002)(74316002)(59450400001)(561944003)(3846002)(6116002)(7696005)(3660700001)(4326008)(19609705001)(102836004)(790700001)(966005)(6246003)(53936002)(6506007)(2501003)(5660300001)(5250100002)(54906003)(53546011)(8936002)(110136005)(2950100002)(68736007)(33656002)(93886005)(478600001)(2900100001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2642; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3tRv/rRpPd8PW6eFDkJmYTHigOFlbZp95YM4Y77WnSx7/ttYX49zHAJravTFvAxNvp0ktJhU5kT2XDgh1ww5Lo0mRgFq75utxVZ9d6szbGw62RP+8lT5yYVaII+trseoG76UuGEFd7tVhrOmbY6zEWs4WMn5hjYRKeLrBnacdV0N2AEXP135P3RWgCXQ5pZPz9l0ZV8ySVo1YxN7MGeqXUOyG+ffXBQ2rKeIvwkw6/oAsq+GNnOPrU5NXc/5uhwGLkq/vk2QQVtNOVtNnsENo9eCCGL4vH08uuEiamuNcXXYI+FRf/djmugQ77LRGZNHYtQmyigNjPP/VNE9iN7E/cVQwCJRLLM9+Z+RW/6qTj8Sw8C5HOw3QqTGSLcoQaFO spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25474AC4A52E38B43E543FA193DA0AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11c9d21a-8e45-418c-a36d-08d582707173 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2018 08:09:39.2944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2642 Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 08:09:46 -0000 --_000_AM5PR0701MB25474AC4A52E38B43E543FA193DA0AM5PR0701MB2547_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgdGhpcyBwcm9wb3NhbCBpcyBzaW1pbGFyIHRvIFF1aWNrU3RhcnQgVENQ IChSRkMgNDc4MiksIHdoaWNoIGlzIG5vdCBjaXRlZCBpbiBkcmFmdC1oYW4tdHN2d2ctY2MsIGFu ZCB0aGUgcmVmZXJlbmNlIGlzIGFsc28gbWlzc2luZyBpbiBkcmFmdC1oYW4tNm1hbi1pbi1iYW5k LXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFvcy4NCg0KUkZDIDYwNzcgZXhwbGFpbnMgc29tZSBv ZiB0aGUgaXNzdWVzIHRoYXQgYW4gaW4tYmFuZCBzaWduYWxpbmcgbWVjaGFuaXNtIGxpa2UgUXVp Y2stU3RhcnQgaGFzIHRvIHNvbHZlLiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIGZ1bmRhbWVu dGFsIGNoYWxsZW5nZSBpcyBuZWl0aGVyIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIG5vciBh IHByb3RvdHlwZSBpbXBsZW1lbnRhdGlvbi4gRm9yIGluc3RhbmNlLCBpdCBoYXMgYmVlbiBwcm92 ZW4gdGhhdCBRdWlja1N0YXJ0IFRDUCBjYW4gYmUgaW1wbGVtZW50ZWQgZS5nLiBpbiBuZXR3b3Jr IHByb2Nlc3NvcnMgKHNlZSBodHRwOi8vd3d3Lmlrci51bmktc3R1dHRnYXJ0LmRlL0NvbnRlbnQv UHVibGljYXRpb25zL0FyY2hpdmUvU2ZfRGlzc180MDExMi5wZGYpLg0KDQpTbywgd2hlbiB1cGRh dGluZyB0aGUgZG9jdW1lbnRzLCBJIHN1Z2dlc3QgdG8gYWRkIGEgZGlzY3Vzc2lvbiBvZiBob3cg dGhlIG9wZW4gcmVzZWFyY2ggaXNzdWVzIGV4cGxhaW5lZCBpbiBSRkMgNjA3NyBhcmUgYWRkcmVz c2VkLg0KDQpNaWNoYWVsDQoNCg0KRnJvbTogWWluZ3poZW4gUXUgW21haWx0bzp5aW5nemhlbi5p ZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgTWFyY2ggMDQsIDIwMTggOTo1OSBQTQ0KVG86 IGdvcnJ5QGVyZy5hYmRuLmFjLnVrDQpDYzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0 dXR0Z2FydCkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT47IFRob21hcyBOYWRlYXUgPHRuYWRl YXVAbHVjaWR2aXNpb24uY29tPjsgdGNwbUBpZXRmLm9yZzsgWWluZ3poZW4gUXUgPHlpbmd6aGVu LnF1QGh1YXdlaS5jb20+OyB0c3Z3Z0BpZXRmLm9yZzsgdHN2d2ctY2hhaXJzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3RzdndnXSBBZ2VuZGEgcmVxdWVzdHMgZm9yIFRTVldHQElFVEYxMDENCg0K SGkgR29ycnkgYW5kIE1pY2hhZWwsDQoNClRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24sIEknbGwg cmVxdWVzdCBhIHByZXNlbnRhdGlvbiBpbiBJQ0NSRy4gTWVhbndoaWxlLCBJIHRoaW5rIHNpbmNl IHRoZSBpbi1iYW5kIHNpZ25hbGluZyBkcmFmdCB3YXMgcHJlc2VudGVkIGluIFRTVldHLCBpZiB0 aW1lIGFsbG93cyBpdCBzdGlsbCBtYWtlcyBzZW5zZSB0byBwcmVzZW50IHRoaXMgZHJhZnQgaW4g VFNWV0cuDQoNClRoZSBpbi1iYW5kIHNpZ25hbGluZyBkcmFmdCBjb3ZlcnMgbG90cyBvZiBhc3Bl Y3RzLCBhbmQgdGhlIHJlcXVpcmVkIGNoYW5nZXMgaW5jbHVkZSBuZXR3b3JrIGxheWVyIGFuZCB0 cmFuc3BvcnQgbGF5ZXIuIFdlJ3JlIHdvcmtpbmcgb24gdXBkYXRpbmcgdGhlIGRyYWZ0LCBhbmQg bWF5IGJyZWFrIGl0IGludG8gcGllY2VzIHRvIGZpdCBkaWZmZXJlbnQgV0dzLg0KDQpZb3VyIGNv bW1lbnRzIGFuZCBoZWxwIGFyZSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQuDQoNClRoYW5rcywNCllp bmd6aGVuDQoNCk9uIFN1biwgTWFyIDQsIDIwMTggYXQgNDo0OSBBTSwgR29ycnkgRmFpcmh1cnN0 IDxnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PiB3cm90 ZToNCkkgYW0gdW5zdXJlIHlldCB3aGF0IHRoZSBjb3JyZWN0IGdyb3VwIG9mIHBlb3BsZSB3b3Js ZCBiZSB0byBleHBsb3JlIGEgIkJhbmR3aWR0aCBHdWFyYW50ZWVkIE5ldHdvcmsiLiBUaGUgcHJl c2VudGF0aW9uIGxhc3QgSUVURiBsb29rZWQgbGlrZSB0aGUgd29yayBjb3VsZCBpbXBseSBhIG5l ZWQgZm9yIGNoYW5nZXMgcHJvcG9zZWQgdG8gdGhlIG5ldHdvcmsgbGF5ZXIgKHVzaW5nIE9BTSBl eGNobmFnZXMpIHRvIHNldCB0aGUgc2VuZGluZyByYXRlIGFuZCBtYWtlIHRob3NlIGJhbmR3aWR0 aCByZXNlcnZhdGlvbnMuICBJbiB0aGUgZW5kLCBpdCBjb3VsZCByZXN1bHQgaW4gYSBwcm90b2Nv bCBxdWl0ZSBkaWZmZXJlbnQgdG8gVENQLCBJIHRoaW5rIHRoaXMgc29ydCBvZiBjaGFuZ2UgbWF5 IHBvc3NpYmx5IGhhdmUgYSBob21lIGluIFRTVldHICAtIGJ1dCBmaXJzdCBJJ2QgYWdyZWUgd2l0 aCBNaWNoYWVsYW5kIHdvdWxkIGVuY291cmFnZSBhIHByZXNlbnRhdGlvbiBvZiB0aGUgcHJvYmxl bSBzdGF0ZW1lbnQgaW4gSUNDUkcgdG8gZXhwbG9yZSB0aGUgaXNzdWVzLg0KDQpHb3JyeQ0KDQpP biAwNC8wMy8yMDE4LCAxMDozNCwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2Fy dCkgd3JvdGU6DQoNCkhpIGFsbCwNCg0KRnJvbSB0aGUgYWJzdHJhY3Q6IOKAnOKAplRoaXMgZHJh ZnQgcHJvcG9zZXMgYSBuZXcgVENQIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0gdXNlZCBp biBiYW5kd2lkdGggZ3VhcmFudGVlZCBuZXR3b3Jrcy4gIEl0IGlzIGFuIGV4dGVuc2lvbiB0byB0 aGUgY3VycmVudCBUQ1Agc3RhbmRhcmRzLuKAnQ0KDQpJbiB0aGUgSUVURiwgSSBiZWxpZXZlIHRo ZSBleHBlcnRpc2UgZm9yIHRoaXMgc3BlY2lmaWMgZG9jdW1lbnQgd291bGQgYmUgaW4gVENQTSwg d2hpY2ggaW4gQ0MuIElmIHRoZSBhdXRob3JzIGFyZSBpbnRlcmVzdGVkIGluIGZlZWRiYWNrIG9u IHRoZSBwcm9wb3NlZCBtZWNoYW5pc20sIEkgd291bGQgcmVjb21tZW5kIHRvIGFzayBUQ1BNLg0K DQpBbHRlcm5hdGl2ZWx5LCBjb3JyZXNwb25kaW5nIHJlc2VhcmNoIGNvdWxkIHBlcmhhcHMgYmUg cGVyZm9ybWVkIGluIHRoZSBJQ0NSRy4gSUNDUkcgaGFzIHB1Ymxpc2hlZCBSRkMgNjA3NyB0byBk b2N1bWVudCBzb21lIG9mIHRoZSBvcGVuIHJlc2VhcmNoIGlzc3VlcyBpbiB0aGlzIHNwYWNlLg0K DQpNaWNoYWVsDQoNCipGcm9tOip0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmc+XSAqT24gQmVoYWxmIE9mICpZaW5nemhlbiBR dQ0KKlNlbnQ6KiBTdW5kYXksIE1hcmNoIDA0LCAyMDE4IDY6NTUgQU0NCipUbzoqIHRzdndnQGll dGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz47IHRzdndnLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86dHN2d2ctY2hhaXJzQGlldGYub3JnPg0KKkNjOiogVGhvbWFzIE5hZGVhdSA8dG5hZGVhdUBs dWNpZHZpc2lvbi5jb208bWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tPj4NCipTdWJqZWN0 OiogW3RzdndnXSBBZ2VuZGEgcmVxdWVzdHMgZm9yIFRTVldHQElFVEYxMDENCg0KRGVhciBDaGFp cnMsDQoNCkEgbmV3IGRyYWZ0IChUaGUgZHJhZnQgd2FzIHN1Z2dlc3RlZCBieSBUU1ZXRyBASUVU RjEwMCkgd2FzIGp1c3Qgc3VibWl0dGVkLCBhbmQgd2XigJlkIGxpa2UgdG8gcmVxdWVzdCBhIHRp bWUgc2xvdCB0byBwcmVzZW50IGl0IEBJRVRGMTAxLg0KDQpUaXRsZTpBIE5ldyBDb25nZXN0aW9u IENvbnRyb2wgaW4gQmFuZHdpZHRoIEd1YXJhbnRlZWQgTmV0d29yaw0KDQpQcmVzZW50ZXI6IFlp bmd6aGVuIFF1IChIdWF3ZWkpDQoNClRpbWUgcmVxdWlyZWQgKGluY2x1ZGluZyBRL0EpOiAxMCBt aW5zDQoNCkRyYWZ0OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW4t dHN2d2ctY2MvDQoNCklmIHRoZXJlIGlzIGFueSBxdWVzdGlvbiwgcGxlYXNlIGtpbmRseSBsZXQg dXMga25vdy4NCg0KVGhhbmtzLA0KDQpZaW5nemhlbg0KDQoNCg== --_000_AM5PR0701MB25474AC4A52E38B43E543FA193DA0AM5PR0701MB2547_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRoYXQgdGhpcyBwcm9wb3NhbCBp cyBzaW1pbGFyIHRvIFF1aWNrU3RhcnQgVENQIChSRkMgNDc4MiksIHdoaWNoIGlzIG5vdCBjaXRl ZCBpbiBkcmFmdC1oYW4tdHN2d2ctY2MsIGFuZCB0aGUgcmVmZXJlbmNlIGlzIGFsc28gbWlzc2lu ZyBpbiBkcmFmdC1oYW4tNm1hbi1pbi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFvcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDIDYwNzcgZXhwbGFpbnMgc29tZSBvZiB0aGUgaXNz dWVzIHRoYXQgYW4gaW4tYmFuZCBzaWduYWxpbmcgbWVjaGFuaXNtIGxpa2UgUXVpY2stU3RhcnQg aGFzIHRvIHNvbHZlLiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIGZ1bmRhbWVudGFsIGNoYWxs ZW5nZSBpcyBuZWl0aGVyIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIG5vciBhIHByb3RvdHlw ZSBpbXBsZW1lbnRhdGlvbi4gRm9yIGluc3RhbmNlLA0KIGl0IGhhcyBiZWVuIHByb3ZlbiB0aGF0 IFF1aWNrU3RhcnQgVENQIGNhbiBiZSBpbXBsZW1lbnRlZCBlLmcuIGluIG5ldHdvcmsgcHJvY2Vz c29ycyAoc2VlDQo8YSBocmVmPSJodHRwOi8vd3d3Lmlrci51bmktc3R1dHRnYXJ0LmRlL0NvbnRl bnQvUHVibGljYXRpb25zL0FyY2hpdmUvU2ZfRGlzc180MDExMi5wZGYiPg0KaHR0cDovL3d3dy5p a3IudW5pLXN0dXR0Z2FydC5kZS9Db250ZW50L1B1YmxpY2F0aW9ucy9BcmNoaXZlL1NmX0Rpc3Nf NDAxMTIucGRmPC9hPikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB3aGVuIHVwZGF0aW5n IHRoZSBkb2N1bWVudHMsIEkgc3VnZ2VzdCB0byBhZGQgYSBkaXNjdXNzaW9uIG9mIGhvdyB0aGUg b3BlbiByZXNlYXJjaCBpc3N1ZXMgZXhwbGFpbmVkIGluIFJGQyA2MDc3IGFyZSBhZGRyZXNzZWQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBZaW5nemhlbiBRdSBbbWFpbHRvOnlpbmd6aGVuLmlldGZAZ21haWwuY29tXSA8YnI+DQo8Yj5T ZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAwNCwgMjAxOCA5OjU5IFBNPGJyPg0KPGI+VG86PC9iPiBn b3JyeUBlcmcuYWJkbi5hYy51azxicj4NCjxiPkNjOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChOb2tp YSAtIERFL1N0dXR0Z2FydCkgJmx0O21pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSZndDs7IFRob21h cyBOYWRlYXUgJmx0O3RuYWRlYXVAbHVjaWR2aXNpb24uY29tJmd0OzsgdGNwbUBpZXRmLm9yZzsg WWluZ3poZW4gUXUgJmx0O3lpbmd6aGVuLnF1QGh1YXdlaS5jb20mZ3Q7OyB0c3Z3Z0BpZXRmLm9y ZzsgdHN2d2ctY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2dd IEFnZW5kYSByZXF1ZXN0cyBmb3IgVFNWV0dASUVURjEwMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEdvcnJ5IGFuZCBNaWNoYWVsLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgc3VnZ2Vz dGlvbiwgSSdsbCByZXF1ZXN0IGEgcHJlc2VudGF0aW9uIGluIElDQ1JHLiBNZWFud2hpbGUsIEkg dGhpbmsgc2luY2UgdGhlIGluLWJhbmQgc2lnbmFsaW5nIGRyYWZ0IHdhcyBwcmVzZW50ZWQgaW4g VFNWV0csIGlmIHRpbWUgYWxsb3dzIGl0IHN0aWxsIG1ha2VzIHNlbnNlIHRvIHByZXNlbnQgdGhp cyBkcmFmdCBpbiBUU1ZXRy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGluLWJhbmQgc2lnbmFsaW5nIGRyYWZ0IGNvdmVycyBs b3RzIG9mIGFzcGVjdHMsIGFuZCB0aGUgcmVxdWlyZWQgY2hhbmdlcyBpbmNsdWRlIG5ldHdvcmsg bGF5ZXIgYW5kIHRyYW5zcG9ydCBsYXllci4gV2UncmUgd29ya2luZyBvbiB1cGRhdGluZyB0aGUg ZHJhZnQsIGFuZCBtYXkgYnJlYWsgaXQgaW50byBwaWVjZXMgdG8gZml0IGRpZmZlcmVudCBXR3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv dXIgY29tbWVudHMgYW5kIGhlbHAgYXJlIHZlcnkgbXVjaCBhcHByZWNpYXRlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWluZ3poZW48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g U3VuLCBNYXIgNCwgMjAxOCBhdCA0OjQ5IEFNLCBHb3JyeSBGYWlyaHVyc3QgJmx0OzxhIGhyZWY9 Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmdvcnJ5QGVyZy5h YmRuLmFjLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBhbSB1bnN1cmUgeWV0IHdoYXQgdGhlIGNvcnJlY3QgZ3JvdXAg b2YgcGVvcGxlIHdvcmxkIGJlIHRvIGV4cGxvcmUgYSAmcXVvdDtCYW5kd2lkdGggR3VhcmFudGVl ZCBOZXR3b3JrJnF1b3Q7LiBUaGUgcHJlc2VudGF0aW9uIGxhc3QgSUVURiBsb29rZWQgbGlrZSB0 aGUgd29yayBjb3VsZCBpbXBseSBhIG5lZWQgZm9yIGNoYW5nZXMgcHJvcG9zZWQgdG8gdGhlIG5l dHdvcmsgbGF5ZXIgKHVzaW5nIE9BTSBleGNobmFnZXMpIHRvDQogc2V0IHRoZSBzZW5kaW5nIHJh dGUgYW5kIG1ha2UgdGhvc2UgYmFuZHdpZHRoIHJlc2VydmF0aW9ucy4mbmJzcDsgSW4gdGhlIGVu ZCwgaXQgY291bGQgcmVzdWx0IGluIGEgcHJvdG9jb2wgcXVpdGUgZGlmZmVyZW50IHRvIFRDUCwg SSB0aGluayB0aGlzIHNvcnQgb2YgY2hhbmdlIG1heSBwb3NzaWJseSBoYXZlIGEgaG9tZSBpbiBU U1ZXRyZuYnNwOyAtIGJ1dCBmaXJzdCBJJ2QgYWdyZWUgd2l0aCBNaWNoYWVsYW5kIHdvdWxkIGVu Y291cmFnZSBhIHByZXNlbnRhdGlvbg0KIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpbiBJQ0NS RyB0byBleHBsb3JlIHRoZSBpc3N1ZXMuPGJyPg0KPGJyPg0KR29ycnk8YnI+DQo8YnI+DQpPbiAw NC8wMy8yMDE4LCAxMDozNCwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpIaSBhbGwsPGJyPg0KPGJyPg0KRnJv bSB0aGUgYWJzdHJhY3Q6IOKAnOKAplRoaXMgZHJhZnQgcHJvcG9zZXMgYSBuZXcgVENQIGNvbmdl c3Rpb24gY29udHJvbCBhbGdvcml0aG0gdXNlZCBpbiBiYW5kd2lkdGggZ3VhcmFudGVlZCBuZXR3 b3Jrcy4mbmJzcDsgSXQgaXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBjdXJyZW50IFRDUCBzdGFuZGFy ZHMu4oCdPGJyPg0KPGJyPg0KSW4gdGhlIElFVEYsIEkgYmVsaWV2ZSB0aGUgZXhwZXJ0aXNlIGZv ciB0aGlzIHNwZWNpZmljIGRvY3VtZW50IHdvdWxkIGJlIGluIFRDUE0sIHdoaWNoIGluIENDLiBJ ZiB0aGUgYXV0aG9ycyBhcmUgaW50ZXJlc3RlZCBpbiBmZWVkYmFjayBvbiB0aGUgcHJvcG9zZWQg bWVjaGFuaXNtLCBJIHdvdWxkIHJlY29tbWVuZCB0byBhc2sgVENQTS48YnI+DQo8YnI+DQpBbHRl cm5hdGl2ZWx5LCBjb3JyZXNwb25kaW5nIHJlc2VhcmNoIGNvdWxkIHBlcmhhcHMgYmUgcGVyZm9y bWVkIGluIHRoZSBJQ0NSRy4gSUNDUkcgaGFzIHB1Ymxpc2hlZCBSRkMgNjA3NyB0byBkb2N1bWVu dCBzb21lIG9mIHRoZSBvcGVuIHJlc2VhcmNoIGlzc3VlcyBpbiB0aGlzIHNwYWNlLjxicj4NCjxi cj4NCk1pY2hhZWw8YnI+DQo8YnI+DQoqRnJvbToqdHN2d2cgW21haWx0bzo8YSBocmVmPSJtYWls dG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRzdndnLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSAqT24gQmVoYWxmIE9mICpZaW5nemhlbiBRdTxicj4NCipTZW50OiogU3Vu ZGF5LCBNYXJjaCAwNCwgMjAxOCA2OjU1IEFNPGJyPg0KKlRvOiogPGEgaHJlZj0ibWFpbHRvOnRz dndnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHN2d2dAaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJtYWlsdG86dHN2d2ctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0c3Z3Zy1j aGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KKkNjOiogVGhvbWFzIE5hZGVhdSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+dG5hZGVhdUBs dWNpZHZpc2lvbi5jb208L2E+Jmd0Ozxicj4NCipTdWJqZWN0OiogW3RzdndnXSBBZ2VuZGEgcmVx dWVzdHMgZm9yIFRTVldHQElFVEYxMDE8YnI+DQo8YnI+DQpEZWFyIENoYWlycyw8YnI+DQo8YnI+ DQpBIG5ldyBkcmFmdCAoVGhlIGRyYWZ0IHdhcyBzdWdnZXN0ZWQgYnkgVFNWV0cgQElFVEYxMDAp IHdhcyBqdXN0IHN1Ym1pdHRlZCwgYW5kIHdl4oCZZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1lIHNs b3QgdG8gcHJlc2VudCBpdCBASUVURjEwMS48YnI+DQo8YnI+DQpUaXRsZTpBIE5ldyBDb25nZXN0 aW9uIENvbnRyb2wgaW4gQmFuZHdpZHRoIEd1YXJhbnRlZWQgTmV0d29yazxicj4NCjxicj4NClBy ZXNlbnRlcjogWWluZ3poZW4gUXUgKEh1YXdlaSk8YnI+DQo8YnI+DQpUaW1lIHJlcXVpcmVkIChp bmNsdWRpbmcgUS9BKTogMTAgbWluczxicj4NCjxicj4NCkRyYWZ0OiA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW4tdHN2d2ctY2MvIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW4tdHN2d2ct Y2MvPC9hPjxicj4NCjxicj4NCklmIHRoZXJlIGlzIGFueSBxdWVzdGlvbiwgcGxlYXNlIGtpbmRs eSBsZXQgdXMga25vdy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KWWluZ3poZW48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_AM5PR0701MB25474AC4A52E38B43E543FA193DA0AM5PR0701MB2547_-- From nobody Mon Mar 5 00:56:55 2018 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 7D805126579; Mon, 5 Mar 2018 00:56:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152024020944.27921.8245457142742447045@ietfa.amsl.com> Date: Mon, 05 Mar 2018 00:56:49 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 08:56:49 -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 WG of the IETF. Title : Forward Error Correction (FEC) Framework Extension to Sliding Window Codes Authors : Vincent Roca Ali Begen Filename : draft-ietf-tsvwg-fecframe-ext-01.txt Pages : 20 Date : 2018-03-05 Abstract: RFC 6363 describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However FECFRAME as per RFC 6363 is restricted to block FEC codes. The present document extends FECFRAME to support FEC Codes based on a sliding encoding window, in addition to Block FEC Codes, in a backward compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-01 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe-ext-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-fecframe-ext-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 01:13:35 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89B01272E1 for ; Mon, 5 Mar 2018 01:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABPJyxz0flKi for ; Mon, 5 Mar 2018 01:13:30 -0800 (PST) Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id 46DD6126579 for ; Mon, 5 Mar 2018 01:13:30 -0800 (PST) Received: from smtp-secu-int (smtp-secu-int.isae.fr [10.132.1.48]) by smtpextng.isae.fr (Postfix) with ESMTP id 8A79F7126A for ; Mon, 5 Mar 2018 10:15:55 +0100 (CET) Received: from [10.161.3.211] (pc-lochin.isae.fr [10.161.3.211]) by smtp-secu-int (Postfix) with ESMTPSA id AB9653F24C for ; Mon, 5 Mar 2018 10:15:57 +0100 (CET) To: tsvwg@ietf.org References: <419905ca-305b-594d-2958-fb468e6e5bb0@isae-supaero.fr> From: Emmanuel Lochin Message-ID: <9ef0cc0b-7bbc-d266-2410-b03265b8c2a1@isae-supaero.fr> Date: Mon, 5 Mar 2018 10:16:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E28FA816B0310D8CF5BB2C29" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 09:13:34 -0000 This is a multi-part message in MIME format. --------------E28FA816B0310D8CF5BB2C29 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 04/03/2018 à 21:48, Yingzhen Qu a écrit : > Hi Emmanuel, > > Thanks for the pointer. I was not aware of the existence of this > draft. I agree they have some similarities with detail variations. > Just curious, why this draft didn't progress? Hi Yingzhen, What I remember (looking back IETF archives) is that Sally Floyd answered she had no objection concerning the proposal if it was clearly written that the gTFRC mechanism must be used only in the context of a QoS network. Sally Floyd also asked questions related to the algorithm and proposed enhancements about the slow-start behavior of the mechanism. We answered that we fully agreed with this hypothesis and justified the choice of our design concerning the slow-start method. Therefore, a second discussion started with Mark Allman on potential security issues raised by this mechanism. Basically, Mark asked us to add a part concerning the reaction to the congestion in the guaranteed part (the “g” part) even if we are in a context of a QoS network. We have discussed this point and following this emails exchange, published a new version of the draft. We also talked about the best way to publish this proposal, it seemed to be well-accepted to publish a new draft rather than inserting this contribution inside the new TFRC draft (now RFC 5348). As a result, we extended the gTFRC draft in order to detail a complete protocol for QoS networks. Finally I left the laboratory I worked during the elaboration of this draft in 2007 and I assume that this work has not been pursued. Considering your proposal, I reckon you'll be face to the same questions in particular the one on the security issue. But I'm quite interesting in discussing this proposal on the mailing-list while even doing something more generic about transport protocol extensions for QoS networks. EL > > BTW, yes, AR/VR means Augmented Reality/Virtual Reality. I'll add the > acronyms to the next version. > > Thanks, > Yingzhen > > > On Sun, Mar 4, 2018 at 3:45 AM, Emmanuel Lochin > > wrote: > > Hi Yingzhen > > Just for your information, you might be interested in gTFRC : > https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02 > > which is a similar solution i.e. a CC for bandwidth guaranteed > networks with TFRC. > Furthermore just a quick question : in your draft does AR/VR > stands for Augmented/Real Virtuality ? > > Regards > > Emmanuel > > > On 04/03/2018 06:54, Yingzhen Qu wrote: >> >> Dear Chairs, >> >> A new draft (The draft was suggested by TSVWG @IETF100) was just >> submitted, and we’d like to request a time slot to present it >> @IETF101. >> >> Title:A New Congestion Control in Bandwidth Guaranteed Network >> >> Presenter: Yingzhen Qu (Huawei) >> >> Time required (including Q/A): 10 mins >> >> Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ >> >> >> If there is any question, please kindly let us know. >> >> Thanks, >> >> Yingzhen >> > > -- > Emmanuel LOCHIN > Professeur ISAE > > ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace > 10 avenue Edouard Belin > - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http://www.isae-supaero.fr > Tel+33 5 61 33 84 85 - Fax(+33) 5 61 33 83 30 > > -- Emmanuel LOCHIN Professeur ISAE ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 Web : http://personnel.isae.fr/emmanuel-lochin/ --------------E28FA816B0310D8CF5BB2C29 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Le 04/03/2018 à 21:48, Yingzhen Qu a écrit :
Hi Emmanuel,

Thanks for the pointer. I was not aware of the existence of this draft. I agree they have some similarities with detail variations. Just curious, why this draft didn't progress?

Hi Yingzhen,

What I remember (looking back IETF archives) is that Sally Floyd answered she had no objection concerning the proposal if it was clearly written that the gTFRC mechanism must be used only in the context of a QoS network. Sally Floyd also asked questions related to the algorithm and proposed enhancements about the slow-start behavior of the mechanism. We answered that we fully agreed with this hypothesis and justified the choice of our design concerning the slow-start method.

Therefore, a second discussion started with Mark Allman on potential security issues raised by this mechanism. Basically, Mark asked us to add a part concerning the reaction to the congestion in the guaranteed part (the “g” part) even if we are in a context of a QoS network. We have discussed this point and following this emails exchange, published a new version of the draft.

We also talked about the best way to publish this proposal, it seemed to be well-accepted to publish a new draft rather than inserting this contribution inside the new TFRC draft (now RFC 5348). As a result, we extended the gTFRC draft in order to detail a complete protocol for QoS networks.

Finally I left the laboratory I worked during the elaboration of this draft in 2007 and I assume that this work has not been pursued.

Considering your proposal, I reckon you'll be face to the same questions in particular the one on the security issue. But I'm quite interesting in discussing this proposal on the mailing-list while even doing something more generic about transport protocol extensions for QoS networks.

EL




BTW, yes, AR/VR means Augmented Reality/Virtual Reality. I'll add the acronyms to the next version.

Thanks,
Yingzhen

 

On Sun, Mar 4, 2018 at 3:45 AM, Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr> wrote:

Hi Yingzhen

Just for your information, you might be interested in gTFRC : https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02
which is a similar solution i.e. a CC for bandwidth guaranteed networks with TFRC.
Furthermore just a quick question : in your draft does AR/VR stands for Augmented/Real Virtuality ?

Regards

Emmanuel


On 04/03/2018 06:54, Yingzhen Qu wrote:

Dear Chairs,

 

A new draft (The draft was suggested by TSVWG @IETF100) was just submitted, and we’d like to request a time slot to present it @IETF101.

 

Title: A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/

 

If there is any question, please kindly let us know.

 

Thanks,

Yingzhen


-- 
Emmanuel LOCHIN
Professeur ISAE

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30


-- 
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://personnel.isae.fr/emmanuel-lochin/
--------------E28FA816B0310D8CF5BB2C29-- From nobody Mon Mar 5 01:34:21 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956B4127275 for ; Mon, 5 Mar 2018 01:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dit0JvGaMsKo for ; Mon, 5 Mar 2018 01:34:17 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702D3126579 for ; Mon, 5 Mar 2018 01:34:17 -0800 (PST) Received: from [IPv6:2003:cd:6bc4:bb00:29d9:ee41:605:c631] (p200300CD6BC4BB0029D9EE410605C631.dip0.t-ipconnect.de [IPv6:2003:cd:6bc4:bb00:29d9:ee41:605:c631]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 2EE47721E280C; Mon, 5 Mar 2018 10:34:14 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: <5A319522.5020708@erg.abdn.ac.uk> Date: Mon, 5 Mar 2018 10:34:13 +0100 Cc: tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <38DBD7E5-A2F9-462C-A588-ACAD8659ACF3@lurchi.franken.de> References: <5A319522.5020708@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-rfc4960-errata-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 09:34:20 -0000 > On Dec 13, 2017, at 10:01 PM, Gorry Fairhurst = wrote: >=20 >=20 > This email contains a shepherd review for the above draft. There are = several issues, that seem straight forward to correct and where = alternate wording may be needed. >=20 > I have a comment about the use of lower case RFC2119 wording: While I = know that documents continue to be published with a mix of upper case = normative keywords and lower case words, I'd like the authors to = explicitly check each of the lower case uses. In some places, the = correct thing appears to be to use a normative version. >=20 > I suggest we should be extremely careful in this usage when = considering progressing a document to full standard. I'd advise = replacing all other non-normative uses of /should/ and /may/ with /ought = to/ and /could/ to remove this ambiguity. This would make it really = clear what the normative requirements are. Hi Gorry, I've checked the usage and changed it to make it clear. I looked for must, should, shall, may (not all caps) in the "New Texts". Thanks for the comments, see my comments in-line. Best regards Michael > Gorry > (TSVWG Co-Chair). >=20 > ---- >=20 > Abstract > - English? > /time based/ > - seems wrong, this could be hypenated, although maybe it would be = better as /time ordered/? Using time ordered. > --- > Introduction > /the publishing of this/ > - may be better as /the publication of this/. > --- Taken. > 3.1.2 > /the endpoint should mark the corresponding/ > - This seems like a protocol action, why is this not > /the endpoint SHOULD mark the corresponding/ > --- > /and may also/ > - similarly /and MAY also/ > - although I would understand why the latter was /and could also/ ... = but I'd prefer to avoid the lower case MAY. > --- >=20 > /After this, the endpoint should continue > HEARTBEAT on this destination address but should stop increasing the > counter./ > - are these /SHOULD/ if not, why not? and if a reason, I suggest you = replace by /ought/. > --- Changed to SHOULD/MAY. > 3.2.2 > /and should discard subsequent ULP shutdown requests./ >=20 > - are these /SHOULD/ if not, why not? and if a reason, I suggest you = replace by /ought/. The text now says: it MUST ignore subsequent ULP shutdown requests > --- > 3.2.3 > /If it did the endpoints/ > - please insert comma aftre /did/. Done. > --- > 3.3.2 > - RFC2434 needs to be replaced by RFC5226. Changed. But it was already taken care of in 3.43.2. > --- > 3.6.2 > /An endpoint shall keep a counter on the total number of consecutive > retransmissions to its peer/ > - is this /SHOULD/ if not, I suggest you replace by /ought/. Changed to SHOULD. > --- > /the path currently used for data transfer shall > not increment the association error counter, / > - Could this lead to failure, is this /SHOULD NOT/ or actually /MUST = NOT/? I'm preferring SHOULD NOT, since you might implement other counter = strategies. > --- > 3.9.2 > /to the current Path MTU/ > - Elsewhere this is called PMTU. OK. Changed to PMTU. > --- > /for path MTU discovery./ > - seems wrong, should this be: > /for Path MTU Discovery./ or /for PMTU Discovery./ ? Took: PMTU Discovery > --- > /constraint of the path MTU/ > - Capital P, or PMTU? PMTU chosen. > --- > 3.11.2 > /SCTP should perform slow/ > - If SCTP is to follow TCP CC, then I think this needs to be: > /SCTP SHOULD perform slow/ Taken. > --- > 3.13.2 > /When a > HEARTBEAT ACK is received from the peer endpoint, the counter should > also be reset./ > - I think that is SHOULD be reset. Taken. > --- > /The receiver of the HEARTBEAT ACK may choose not to > clear the counter if there is outstanding data on the association. > - I think that is MAY or /could/ MAY > --- > / > Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT > should clear the error counter/ > - I think that is SHOULD be clear, since it sets what comes on the = wire. Taken. > --- > /The endpoint may optionally report/ > - /could optionally report/ or /is permitted to optionally report/? We can use MAY. > --- > /The receiver of the HEARTBEAT ACK should also clear/ > - I'd have thought that was SHOULD. Done. > --- > 3.15.2 > - PMTU or Path MTU. PMTU. > --- > 3.16.2 > - The following text seems odd, but perhaps you could refer to > where this exact phrase is used?: > /The initial value of ssthresh SHOULD be arbitrarily high (e.g., > to the size of the largest possible advertised window)./ Not sure what is odd... We already provide a reference where the same text is used in RFC 5681... > --- > 3.20.1 > /But receiving new packets from the peer does not guarantee peer's = accessibility/ > - Maybe better as: > /However, reception of new packets from the peer does not guarantee = the peer's accessibility/ > - Is reachability better than accessibility? Text taken and using reachability. >=20 > --- > 3.20.2 > /should not increment the error counter/ > - /ought not/ or /should not/. SHOULD NOT > --- > /This is because the receiver MAY > keep its window closed for an indefinite time./ > - is this really /MAY/ - are we permitting something or saying it can = be so? > If the latter, please use /could/ in place of MAY. could > --- > - This text seems odd: > /Refer to Section 6.2 on the receiver behavior when it advertises a = zero window./ > - would this be better as: >=20 > /Section 6.2 deescribes the receiver behavior when it advertises a = zero window./ Taken. >=20 > --- > 3.21.2 (multiple) > /When > this flag is set, the stream id and Stream Sequence Number must > accompany this receive./ > - This seems like protocol action is it /MUST/? Section 10 is informative, so no normative language can be used. Therefore no change. Now we are in 3.23.2 > --- > /the endpoint shall > clear the error counter of the destination transport address to = which > the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD/ > - why is the first /shall/ lower case, and not an /ought to/ or a = SHALL? SHOULD. > --- > /should clear the error counter/ > - why is the /should/ lower case, and not an /ought to/ or a SHALL? Using a SHOULD. > --- (multiple) > / An endpoint should limit the number of retransmissions of the > SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'./ > - why is the /should/ lower case, and not an /ought to/ or a SHALL? Changed to SHOULD. > --- Now you are in 3.25.2: > - A MUST states a requirement: > /Furthermore, we require > that the receiver of an INIT chunk MUST enforce these rules by > silently discarding the INIT chunk and all further chunks if the = INIT > chunk is bundled with other chunks or the packet has a non-zero > verification tag. / > - needs to be rewritten as: > /The receiver of an INIT chunk MUST silently discard the INIT chunk > and all further chunks if the INIT > chunk is bundled with other chunks or the packet has a non-zero > verification tag./ Changed as suggested. > --- > 3.26.2 > / > When cwnd is greater than ssthresh, cwnd should be incremented by > 1*MTU per RTT if the sender has cwnd or more bytes of data > outstanding for the corresponding transport address./ > - /SHOULD/. Done. > --- > 3.27.2 > / > When the endpoint does not transmit data on a given transport > address, the cwnd of the transport address should be adjusted to > max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the > ssthresh of the transport address should be adjusted to the = cwnd./ > - /SHOULD be adjusted/ (twice)? Done. > --- > 3.32.1 > - This update is based on RFC6298. > I think the updated text should in some way refer > to this update as the basis of the method. Why? The intention of this document is provide the background for all changes. So we don't need to change the style of the SCTP = specification. We don't provide in reference for the values given in the table. > --- > 3.33.2. > / > The endpoint may bundle the ERROR chunk/ > - /MAY/. Done. > --- > 3.35.2 > - This text doesn't seem very clear to me: > / > SCTP implementations MAY allow an application to configure the > Differentiated Services Code Point (DSCP) used for sending packets. > If a DSCP change might result in outgoing packets being queued in > different queues, the congestion control parameters for all affected > destination addresses MUST be reset to their initial values. >=20 > / > - (1) Does this mean for each packet? or for the entire asscociation = or what? > (I think it reads like an association?) I think it is pretty clear... The socket API allow the DSCP to be set = per remote address, but this is just an example. The crucial point is that you reset the congestion controller to its initial state for all = affected destination addresses. This is what the text describes. > - What does /being queued in different queues/ mean? ... any change to = the > DSCP could result in different results, but this is more likely if the = change The text says, when you are in doubt, reset the congestion controller. > modifies an AF class. It is probably safer to point to RFC7657 for = specifics. > - Please update this. Again: I think this is pretty clear. But I'm open to concrete text = suggestions. > --- > 3.40.2 > - The update you note in the following two specific cases is not in = the ID you cite, but in AccECN I think... where the change I think RFC 3168 describes a way to set the ECE and the CWR bit. This is what we are referring to. Not to something improved. There was more specific ID, but that never progressed. > from RTT-based reduction is mentioned. Please check and update. > / > [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] > details a specific bit for a receiver to send back in its > TCP acknowledgements to notify the sender of the Congestion > Experienced (CE) bit having arrived from the network./ > - > / > RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] > details a specific bit for a sender to send in the header > of its next outbound TCP segment to indicate to its peer that it has > reduced its congestion window./ > - Although maybe you could choose not to cite this? So you want to remove(!) the reference to [RFC3168]? I don't think the = text then makes much sense. The best way would be to specify ECN completely = and not give some hints in an Appendix, but this would require the ECN for = SCTP ID to be progressed. I leave it for now. However, you can make a concrete text propsoal for changing Appendix A. This current goal was just to replace the reference to RFC 3168 by a reference to RFC 3168 and RFC 8311. Just the = references, not the actual content... > --- > 3.44 > - Section 3.44 clearly DOES have IANA implications. This represents = changes > that were made to port assignment, and although these are captured in > a published RFC they are re-stated here and I think this NEEDS to be > called out in the IANA considerations. IANA would be expected to = review > these changes (again), and this needs to be explained in section 4. OK. I changed it to: of this document updates the = port number registry for SCTP to be consistent with .= IANA is requested to view . > --- The following seems to be from 3.41.2: > / > If the name resolution is not successful, the endpoint MUST > immediately send an ABORT with "Unresolvable Address" error cause > to its peer. The ABORT shall be sent to the source IP address > from which the last peer packet was received./ > - please replace/update the /shall/. This is "old text", only cited and can't be changed. > --- > /Should be set to all '0's and ignored by the receiver./ > - SHOULD. Fixed. > --- > 3.4.62 > - Can one of the authors give me assurance that the code quoted is = still correct at this time? I checked it when getting the source code in the ID. > --- >=20 From nobody Mon Mar 5 02:55:26 2018 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 E64BB12783A; Mon, 5 Mar 2018 02:55:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152024732591.27980.12930524113592715316@ietfa.amsl.com> Date: Mon, 05 Mar 2018 02:55:25 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 10:55:26 -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 WG of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME Authors : Vincent Roca Belkacem Teibi Filename : draft-ietf-tsvwg-rlc-fec-scheme-02.txt Pages : 27 Date : 2018-03-05 Abstract: This document describes two fully-specified FEC Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over GF(2) (binary case), a second one for RLC over GF(2^^8), both of them with the possibility of controlling the code density. They are meant to protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real- time flows in terms of reduced FEC-related latency while often providing improved erasure recovery capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 05:10:56 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0172124D68 for ; Mon, 5 Mar 2018 05:10:55 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uuNa7uVDter for ; Mon, 5 Mar 2018 05:10:52 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E7312D7E2 for ; Mon, 5 Mar 2018 05:10:49 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 0E4702D4FEA; Mon, 5 Mar 2018 13:10:48 +0000 (UTC) Date: Mon, 5 Mar 2018 13:10:48 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180305131047.GA78549@accordion.employees.org> References: <20180304225650.GI92206@accordion.employees.org> <20180304232200.GJ92206@accordion.employees.org> <20180304232931.GK92206@accordion.employees.org> <18D3CE97-6973-41D6-A2DC-276FFA1E7C18@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <18D3CE97-6973-41D6-A2DC-276FFA1E7C18@strayalpha.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] UDP options - FRAG+LITE X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 13:10:56 -0000 On Sun, Mar 04, 2018 at 04:26:55PM -0800, Joe Touch wrote: > > (Fig 18 doesn’t quite show the LITEdata[0…3] where it should be - I’ll fix that) > > I.e., there’s nothing different here. Nothing “slides”; it's (intended to be) the same swap operation. Thanks, I just wanted to make sure before I tried coding something up. DF From nobody Mon Mar 5 05:19:08 2018 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 A67671270AE; Mon, 5 Mar 2018 05:19:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152025594164.27968.15620218597611880732@ietfa.amsl.com> Date: Mon, 05 Mar 2018 05:19:01 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 13:19:02 -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 WG of the IETF. Title : Packetization Layer Path MTU Discovery for Datagram Transports Authors : Godred Fairhurst Tom Jones Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-datagram-plpmtud-01.txt Pages : 31 Date : 2018-03-05 Abstract: This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization layers. The method allows a Packetization Layer (PL), or a datagram application that uses a PL, to probe an network path with progressively larger packets to determine a maximum packet size. The document describes an extension to RFC 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for IPv4 and IPv6. This provides functionally for datagram transports that is equivalent to the Packetization layer PMTUD specification for TCP, specified in RFC4821. When published, this specification updates RFC4821. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-01 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-datagram-plpmtud-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-datagram-plpmtud-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 05:27:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DCB12D82F for ; Mon, 5 Mar 2018 05:27:11 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubyw8iI_Wtpv for ; Mon, 5 Mar 2018 05:27:09 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C98412D80F for ; Mon, 5 Mar 2018 05:27:09 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 6C9632D5048; Mon, 5 Mar 2018 13:27:09 +0000 (UTC) Date: Mon, 5 Mar 2018 13:27:09 +0000 From: Derek Fawcus To: tsvwg Message-ID: <20180305132709.GB78549@accordion.employees.org> References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <8C831161-12A5-4AC2-AAAD-C34664ABFEF6@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8C831161-12A5-4AC2-AAAD-C34664ABFEF6@strayalpha.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 13:27:11 -0000 On Sun, Mar 04, 2018 at 09:10:07PM -0800, Joe Touch wrote: > > On Mar 4, 2018, at 10:50 AM, Derek Fawcus wrote: > > Have you looked at the code I included? > > No, and I do not plan to. Again, we’re not standardizing code. The point in posting the code was not to have it standardised, it was an attempt to achieve clarity regarding my proposal. We had the following in prior exchanges: Joe Touch wrote: > > Finally, there’s the impact on LITE+FRAG and the way in which reassembly can preserve options. > > That will require deeper consideration to determine if it is possible and with what impact. > > > Derek Fawcus > > I view that portion as a trivial extension. One does some initial > set up at the start of the routine, then the rest of the loop is > the same. Joe Touch wrote: > > - we would need to find a new way to incorporate LITE > > notably that involves not needing to recopy the entire LITE > > region after option processing > > > > If you have a proposed solution that preserves all of these and supports the existing properties, please post it. The point of the posted code was to supply proof that what I suggested in terms of checksum could be trivially made to cope with the uses of the LITE header, and would not involve any re-copying of data. What one then does in processing the options would entail whatever copying it requires, but the checksum per-se would not add to that. DF From nobody Mon Mar 5 05:39:55 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA0E12D7E5; Mon, 5 Mar 2018 05:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUEwZq3TUrYf; Mon, 5 Mar 2018 05:39:51 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 13689120454; Mon, 5 Mar 2018 05:39:51 -0800 (PST) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0C3411B001FE; Mon, 5 Mar 2018 13:39:49 +0000 (GMT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id D67A3211E1; Mon, 5 Mar 2018 08:39:46 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Mon, 05 Mar 2018 08:39:46 -0500 X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 224A72463E; Mon, 5 Mar 2018 08:39:46 -0500 (EST) Date: Mon, 5 Mar 2018 13:39:42 +0000 From: Tom Jones To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, tsvwg@ietf.org Message-ID: <20180305133941.GA10306@tom-desk.erg.abdn.ac.uk> References: <152025594164.27968.15620218597611880732@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152025594164.27968.15620218597611880732@ietfa.amsl.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 13:39:53 -0000 Hello All, We have updated our Datagram PLPMTUD draft. This revision improves the introductory text, addresses nits and adds new text covering probe search approaches and alignment with work proposed in QUIC WQ. Thanks - [tj] From nobody Mon Mar 5 06:44:55 2018 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 32D2B12711D; Mon, 5 Mar 2018 06:44:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152026109418.14644.3173388906895599659@ietfa.amsl.com> Date: Mon, 05 Mar 2018 06:44:54 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4960-errata-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 14:44:54 -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 WG of the IETF. Title : RFC 4960 Errata and Issues Authors : Randall R. Stewart Michael Tuexen Maksim Proshin Filename : draft-ietf-tsvwg-rfc4960-errata-05.txt Pages : 88 Date : 2018-03-05 Abstract: This document is a compilation of issues found since the publication of RFC4960 in September 2007 based on experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time ordered way. The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc4960-errata-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc4960-errata-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 06:59:35 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DE4127337 for ; Mon, 5 Mar 2018 06:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyvDtBiu7Wan for ; Mon, 5 Mar 2018 06:59:33 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 4CAC912711D for ; Mon, 5 Mar 2018 06:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aBtGLv3neXqUAicgcixb47axR/ztUfst+vkdQbYLbdE=; b=Dl2EFSCTp3CmkBv/irHj4Vw4E KBUdtSmFwJLtCtunnwUmttXmjqUVfSkeqZxWau3VgP3LOcInkRZ1a4GigXNoMUobiUU66h08qiAvA BFJxf4RWFL6jiuBMW5VLV9zyblO4PmHaC+QUIF9RU4XKQKllJorhbq79QkUmHfs8djvUob3Uh+9HH X6ugQBL3Rl4g2g5seO2XaOFipAnbt4V5hAdkDWXBOrx8jjCvlhWhq9hXHNW0fRZMzAZe+0vY5X9HI olYS5FXAW9YWJqQS9mL480EFW1csk6oAJIE5pEJRDzbZRU1MpDXm33LC7EdhorYLktlMIOp2Qm1/N JNdBXotgg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51025 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1esra9-003ob9-Ah; Mon, 05 Mar 2018 09:59:32 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_448B808F-4665-4448-AC05-9901E8498FA7" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180305132709.GB78549@accordion.employees.org> Date: Mon, 5 Mar 2018 06:59:10 -0800 Cc: tsvwg Message-Id: References: <20180304163013.GA92206@accordion.employees.org> <4DD8D9D8-A202-4D62-A742-D77F41975871@strayalpha.com> <20180304165437.GD92206@accordion.employees.org> <60AD9522-E22B-4980-B98B-08860538BF2E@strayalpha.com> <20180304185041.GF92206@accordion.employees.org> <8C831161-12A5-4AC2-AAAD-C34664ABFEF6@strayalpha.com> <20180305132709.GB78549@accordion.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Size of OCS checksum, and should OCS be optional? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 14:59:35 -0000 --Apple-Mail=_448B808F-4665-4448-AC05-9901E8498FA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 5, 2018, at 5:27 AM, Derek Fawcus = wrote: >=20 > The point of the posted code was to supply proof that what I suggested = in terms > of checksum could be trivially made to cope with the uses of the LITE = header, > and would not involve any re-copying of data. OK, so (again) without looking at the code (because it isn=E2=80=99t = helpful here), I=E2=80=99m assuming the following: - the CS comes first - when LITE is seen, it is =E2=80=9Cjumped over=E2=80=9D rather than = being processed by the CS - nothing else would need to change In that case, we still have two problems: 1) the CS can=E2=80=99t be word-aligned (we can=E2=80=99t start with 1-3 = NOPs) 2) we always burn 2 bytes even when CS is unused The only benefit proposed so far is that this would be =E2=80=9Cstronger=E2= =80=9D than using CS as TLV after LITE or wherever it appears and a = performance argument. When CS is turned off, it doesn=E2=80=99t need to be stronger. When CS = is turned on, it would be required only when both ends had already = negotiated it as required, in which case there is no strength benefit = either. As to performance, we are trading an opcode (checking to see its type) = vs. the ability to align it (much more important for performance) and = space (a key issue as well). Again, my view is that space is the driving issue and that = strength/protection is not sufficiently impacted. Joe --Apple-Mail=_448B808F-4665-4448-AC05-9901E8498FA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 5, 2018, at 5:27 AM, Derek Fawcus <dfawcus+lists-tsvwg@employees.org> wrote:

The point of the posted code was = to supply proof that what I suggested in terms
of checksum could be trivially made to cope with = the uses of the LITE header,
and would not involve any = re-copying of data.

OK,= so (again) without looking at the code (because it isn=E2=80=99t = helpful here), I=E2=80=99m assuming the following:

- the CS comes first
- when LITE is = seen, it is =E2=80=9Cjumped over=E2=80=9D rather than being processed by = the CS
- nothing else would need to change

In that case, we still have two = problems:

1) the CS can=E2=80=99t be = word-aligned (we can=E2=80=99t start with 1-3 NOPs)
2) we = always burn 2 bytes even when CS is unused

The only benefit proposed so far is that this = would be =E2=80=9Cstronger=E2=80=9D than using CS as TLV after LITE or = wherever it appears and a performance argument.

When CS is turned off, it doesn=E2=80=99t need to = be stronger. When CS is turned on, it would be required only when both = ends had already negotiated it as required, in which case there is no = strength benefit either.

As to = performance, we are trading an opcode (checking to see its type) vs. the = ability to align it (much more important for performance) and space (a = key issue as well).

Again, my view = is that space is the driving issue and that strength/protection is not = sufficiently impacted.

Joe

= --Apple-Mail=_448B808F-4665-4448-AC05-9901E8498FA7-- From nobody Mon Mar 5 12:26:14 2018 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 6A3001204DA; Mon, 5 Mar 2018 12:26:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152028157237.31662.4431555726598906197@ietfa.amsl.com> Date: Mon, 05 Mar 2018 12:26:12 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-le-phb-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 20:26: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 WG of the IETF. Title : A Lower Effort Per-Hop Behavior (LE PHB) Author : Roland Bless Filename : draft-ietf-tsvwg-le-phb-04.txt Pages : 15 Date : 2018-03-05 Abstract: This document specifies properties and characteristics of a Lower Effort (LE) per-hop behavior (PHB). The primary objective of this LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard DSCP value for the LE PHB. This specification updates the DSCP recommended in RFC 4594 and RFC 8325 to use the DSCP assigned in this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-le-phb-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-le-phb-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 15:31:28 2018 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 D176712D87C; Mon, 5 Mar 2018 15:31:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152029268181.12750.8149564296073625747@ietfa.amsl.com> Date: Mon, 05 Mar 2018 15:31:21 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 23:31:22 -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 WG of the IETF. Title : DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) Authors : Koen De Schepper Bob Briscoe Olga Bondarenko Ing-jyh Tsang Filename : draft-ietf-tsvwg-aqm-dualq-coupled-04.txt Pages : 36 Date : 2018-03-05 Abstract: Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---DCTCP is so aggressive that existing TCP algorithms approach starvation. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-04 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 Mar 6 04:35:29 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13745127735 for ; Tue, 6 Mar 2018 04:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrhV_LaApgQK for ; Tue, 6 Mar 2018 04:35:25 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7131D1276AF for ; Tue, 6 Mar 2018 04:35:25 -0800 (PST) Received: from dhcp-207-156.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:35e8:ac16:bdb2:e441]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B92BF1B001B9 for ; Tue, 6 Mar 2018 12:35:24 +0000 (GMT) Reply-To: gorry@erg.abdn.ac.uk References: <93ed178b-5ca3-e4ee-dfa6-2d79e712596f@kit.edu> To: tsvwg WG From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. X-Forwarded-Message-Id: <93ed178b-5ca3-e4ee-dfa6-2d79e712596f@kit.edu> Message-ID: Date: Tue, 6 Mar 2018 12:35:24 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <93ed178b-5ca3-e4ee-dfa6-2d79e712596f@kit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] New revision: Re: NiTs and comments on the DS LE draft. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 12:35:27 -0000 Hi Roland, I've just read the updated version of your I-D (-04). This new version addresses all my comments, and in particular I think it now makes the intended changes to existing RFCs really clear. Thanks for submitting this revision! Best regards, Gorry From nobody Tue Mar 6 05:40:36 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28C1127775 for ; Tue, 6 Mar 2018 05:40:34 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmp_6YAZBqKk for ; Tue, 6 Mar 2018 05:40:31 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF91200B9 for ; Tue, 6 Mar 2018 05:40:31 -0800 (PST) Received: from dhcp-207-156.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:35e8:ac16:bdb2:e441]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2CA551B001FE; Tue, 6 Mar 2018 13:40:29 +0000 (GMT) Reply-To: gorry@erg.abdn.ac.uk To: Michael Tuexen Cc: tsvwg@ietf.org References: <5A319522.5020708@erg.abdn.ac.uk> <38DBD7E5-A2F9-462C-A588-ACAD8659ACF3@lurchi.franken.de> From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Tue, 6 Mar 2018 13:40:28 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <38DBD7E5-A2F9-462C-A588-ACAD8659ACF3@lurchi.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-rfc4960-errata-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 13:40:35 -0000 The changes in the new revision look good to me. Thank you Michael for making these changes. We will now proceed with WG writeup for publication. Gorry On 05/03/2018 09:34, Michael Tuexen wrote: >> On Dec 13, 2017, at 10:01 PM, Gorry Fairhurst wrote: >> >> >> This email contains a shepherd review for the above draft. There are several issues, that seem straight forward to correct and where alternate wording may be needed. >> >> I have a comment about the use of lower case RFC2119 wording: While I know that documents continue to be published with a mix of upper case normative keywords and lower case words, I'd like the authors to explicitly check each of the lower case uses. In some places, the correct thing appears to be to use a normative version. >> >> I suggest we should be extremely careful in this usage when considering progressing a document to full standard. I'd advise replacing all other non-normative uses of /should/ and /may/ with /ought to/ and /could/ to remove this ambiguity. This would make it really clear what the normative requirements are. > > Hi Gorry, > > I've checked the usage and changed it to make it clear. > I looked for must, should, shall, may (not all caps) in the "New Texts". > Thanks for the comments, see my comments in-line. > > Best regards > Michael >> Gorry >> (TSVWG Co-Chair). >> >> ---- >> >> Abstract >> - English? >> /time based/ >> - seems wrong, this could be hypenated, although maybe it would be better as /time ordered/? > Using time ordered. >> --- >> Introduction >> /the publishing of this/ >> - may be better as /the publication of this/. >> --- > Taken. >> 3.1.2 >> /the endpoint should mark the corresponding/ >> - This seems like a protocol action, why is this not >> /the endpoint SHOULD mark the corresponding/ >> --- >> /and may also/ >> - similarly /and MAY also/ >> - although I would understand why the latter was /and could also/ ... but I'd prefer to avoid the lower case MAY. >> --- >> >> /After this, the endpoint should continue >> HEARTBEAT on this destination address but should stop increasing the >> counter./ >> - are these /SHOULD/ if not, why not? and if a reason, I suggest you replace by /ought/. >> --- > Changed to SHOULD/MAY. >> 3.2.2 >> /and should discard subsequent ULP shutdown requests./ >> >> - are these /SHOULD/ if not, why not? and if a reason, I suggest you replace by /ought/. > The text now says: it MUST ignore subsequent ULP shutdown requests >> --- >> 3.2.3 >> /If it did the endpoints/ >> - please insert comma aftre /did/. > Done. >> --- >> 3.3.2 >> - RFC2434 needs to be replaced by RFC5226. > Changed. But it was already taken care of in 3.43.2. >> --- >> 3.6.2 >> /An endpoint shall keep a counter on the total number of consecutive >> retransmissions to its peer/ >> - is this /SHOULD/ if not, I suggest you replace by /ought/. > Changed to SHOULD. >> --- >> /the path currently used for data transfer shall >> not increment the association error counter, / >> - Could this lead to failure, is this /SHOULD NOT/ or actually /MUST NOT/? > I'm preferring SHOULD NOT, since you might implement other counter strategies. >> --- >> 3.9.2 >> /to the current Path MTU/ >> - Elsewhere this is called PMTU. > OK. Changed to PMTU. >> --- >> /for path MTU discovery./ >> - seems wrong, should this be: >> /for Path MTU Discovery./ or /for PMTU Discovery./ ? > Took: PMTU Discovery >> --- >> /constraint of the path MTU/ >> - Capital P, or PMTU? > PMTU chosen. >> --- >> 3.11.2 >> /SCTP should perform slow/ >> - If SCTP is to follow TCP CC, then I think this needs to be: >> /SCTP SHOULD perform slow/ > Taken. >> --- >> 3.13.2 >> /When a >> HEARTBEAT ACK is received from the peer endpoint, the counter should >> also be reset./ >> - I think that is SHOULD be reset. > Taken. >> --- >> /The receiver of the HEARTBEAT ACK may choose not to >> clear the counter if there is outstanding data on the association. >> - I think that is MAY or /could/ > MAY >> --- >> / >> Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT >> should clear the error counter/ >> - I think that is SHOULD be clear, since it sets what comes on the wire. > Taken. >> --- >> /The endpoint may optionally report/ >> - /could optionally report/ or /is permitted to optionally report/? > We can use MAY. >> --- >> /The receiver of the HEARTBEAT ACK should also clear/ >> - I'd have thought that was SHOULD. > Done. >> --- >> 3.15.2 >> - PMTU or Path MTU. > PMTU. >> --- >> 3.16.2 >> - The following text seems odd, but perhaps you could refer to >> where this exact phrase is used?: >> /The initial value of ssthresh SHOULD be arbitrarily high (e.g., >> to the size of the largest possible advertised window)./ > Not sure what is odd... We already provide a reference where the > same text is used in RFC 5681... >> --- >> 3.20.1 >> /But receiving new packets from the peer does not guarantee peer's accessibility/ >> - Maybe better as: >> /However, reception of new packets from the peer does not guarantee the peer's accessibility/ >> - Is reachability better than accessibility? > > Text taken and using reachability. >> >> --- >> 3.20.2 >> /should not increment the error counter/ >> - /ought not/ or /should not/. > SHOULD NOT >> --- >> /This is because the receiver MAY >> keep its window closed for an indefinite time./ >> - is this really /MAY/ - are we permitting something or saying it can be so? >> If the latter, please use /could/ in place of MAY. > could >> --- >> - This text seems odd: >> /Refer to Section 6.2 on the receiver behavior when it advertises a zero window./ >> - would this be better as: >> >> /Section 6.2 deescribes the receiver behavior when it advertises a zero window./ > Taken. >> >> --- >> 3.21.2 (multiple) >> /When >> this flag is set, the stream id and Stream Sequence Number must >> accompany this receive./ >> - This seems like protocol action is it /MUST/? > Section 10 is informative, so no normative language can be used. > Therefore no change. > > Now we are in 3.23.2 >> --- >> /the endpoint shall >> clear the error counter of the destination transport address to which >> the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD/ >> - why is the first /shall/ lower case, and not an /ought to/ or a SHALL? > SHOULD. >> --- >> /should clear the error counter/ >> - why is the /should/ lower case, and not an /ought to/ or a SHALL? > Using a SHOULD. >> --- (multiple) >> / An endpoint should limit the number of retransmissions of the >> SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'./ >> - why is the /should/ lower case, and not an /ought to/ or a SHALL? > Changed to SHOULD. >> --- > Now you are in 3.25.2: >> - A MUST states a requirement: >> /Furthermore, we require >> that the receiver of an INIT chunk MUST enforce these rules by >> silently discarding the INIT chunk and all further chunks if the INIT >> chunk is bundled with other chunks or the packet has a non-zero >> verification tag. / >> - needs to be rewritten as: >> /The receiver of an INIT chunk MUST silently discard the INIT chunk >> and all further chunks if the INIT >> chunk is bundled with other chunks or the packet has a non-zero >> verification tag./ > Changed as suggested. >> --- >> 3.26.2 >> / >> When cwnd is greater than ssthresh, cwnd should be incremented by >> 1*MTU per RTT if the sender has cwnd or more bytes of data >> outstanding for the corresponding transport address./ >> - /SHOULD/. > Done. >> --- >> 3.27.2 >> / >> When the endpoint does not transmit data on a given transport >> address, the cwnd of the transport address should be adjusted to >> max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the >> ssthresh of the transport address should be adjusted to the cwnd./ >> - /SHOULD be adjusted/ (twice)? > Done. >> --- >> 3.32.1 >> - This update is based on RFC6298. >> I think the updated text should in some way refer >> to this update as the basis of the method. > Why? The intention of this document is provide the background for > all changes. So we don't need to change the style of the SCTP specification. > We don't provide in reference for the values given in the table. >> --- >> 3.33.2. >> / >> The endpoint may bundle the ERROR chunk/ >> - /MAY/. > Done. >> --- >> 3.35.2 >> - This text doesn't seem very clear to me: >> / >> SCTP implementations MAY allow an application to configure the >> Differentiated Services Code Point (DSCP) used for sending packets. >> If a DSCP change might result in outgoing packets being queued in >> different queues, the congestion control parameters for all affected >> destination addresses MUST be reset to their initial values. >> >> / >> - (1) Does this mean for each packet? or for the entire asscociation or what? >> (I think it reads like an association?) > I think it is pretty clear... The socket API allow the DSCP to be set per > remote address, but this is just an example. The crucial point is that > you reset the congestion controller to its initial state for all affected > destination addresses. This is what the text describes. >> - What does /being queued in different queues/ mean? ... any change to the >> DSCP could result in different results, but this is more likely if the change > The text says, when you are in doubt, reset the congestion controller. >> modifies an AF class. It is probably safer to point to RFC7657 for specifics. >> - Please update this. > Again: I think this is pretty clear. But I'm open to concrete text suggestions. >> --- >> 3.40.2 >> - The update you note in the following two specific cases is not in the ID you cite, but in AccECN I think... where the change > I think RFC 3168 describes a way to set the ECE and the CWR bit. > This is what we are referring to. Not to something improved. > There was more specific ID, but that never progressed. >> from RTT-based reduction is mentioned. Please check and update. >> / >> [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] >> details a specific bit for a receiver to send back in its >> TCP acknowledgements to notify the sender of the Congestion >> Experienced (CE) bit having arrived from the network./ >> - >> / >> RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] >> details a specific bit for a sender to send in the header >> of its next outbound TCP segment to indicate to its peer that it has >> reduced its congestion window./ >> - Although maybe you could choose not to cite this? > So you want to remove(!) the reference to [RFC3168]? I don't think the text > then makes much sense. The best way would be to specify ECN completely and > not give some hints in an Appendix, but this would require the ECN for SCTP > ID to be progressed. > > I leave it for now. However, you can make a concrete text propsoal for > changing Appendix A. This current goal was just to replace the reference > to RFC 3168 by a reference to RFC 3168 and RFC 8311. Just the references, > not the actual content... >> --- >> 3.44 >> - Section 3.44 clearly DOES have IANA implications. This represents changes >> that were made to port assignment, and although these are captured in >> a published RFC they are re-stated here and I think this NEEDS to be >> called out in the IANA considerations. IANA would be expected to review >> these changes (again), and this needs to be explained in section 4. > OK. I changed it to: > > of this document updates the port > number registry for SCTP to be consistent with . > IANA is requested to view . > >> --- > The following seems to be from 3.41.2: >> / >> If the name resolution is not successful, the endpoint MUST >> immediately send an ABORT with "Unresolvable Address" error cause >> to its peer. The ABORT shall be sent to the source IP address >> from which the last peer packet was received./ >> - please replace/update the /shall/. > This is "old text", only cited and can't be changed. >> --- >> /Should be set to all '0's and ignored by the receiver./ >> - SHOULD. > Fixed. >> --- >> 3.4.62 >> - Can one of the authors give me assurance that the code quoted is still correct at this time? > I checked it when getting the source code in the ID. >> --- >> > From nobody Tue Mar 6 10:45:46 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9099712D778 for ; Tue, 6 Mar 2018 10:45:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 zaC5Au9hFyds for ; Tue, 6 Mar 2018 10:45:42 -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 D0620124234 for ; Tue, 6 Mar 2018 10:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: Subject:From:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CymIdszkOJa4HvBZMsImuYOuMKOMhC6drh9TyWna1sM=; b=hRapGkkA2JMRDd8xb2hStu1Gjw L7X2yTPeckiVebqAXXLvRYClPH7EhTrxo642NB161If0EJo7WGK/i1DLN7yu6ItjoNfljlZeB+46U HXydvTDeu5P6m3/ZXt/hpYKn05kyX6q5VR2Pod6ntfeK8l8328fYewMD243b06mc37NLLbgSOQhRt Ul/vTigFhu6WOyFMGwtFodi/6xie9IKApJij6OY5J499RtR7wLuypQ7ywpCLlo5nWHK12h4in9cCn gR50iT5UY3dixwN0bACSv1Ah157Nimv4VZ804Cat47k82szFLbelscw7XcnNPKQT616ZxRvqjYerh r5viqWaQ==; Received: from [84.92.178.164] (port=40638 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1etHal-00052w-Tn; Tue, 06 Mar 2018 18:45:40 +0000 To: "Bless, Roland (TM)" From: Bob Briscoe Cc: tsvwg IETF list Message-ID: <0ee62473-fc44-b733-de9a-d3ef61d9c239@bobbriscoe.net> Date: Tue, 6 Mar 2018 18:45:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BB21842F72BC802679CE1623" Content-Language: en-GB 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: Subject: [tsvwg] Suggestion for draft-ietf-tsvwg-le-phb-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 18:45:45 -0000 This is a multi-part message in MIME format. --------------BB21842F72BC802679CE1623 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Roland, I like how this draft has turned out. I particularly agree with LE updating CS1, not just being recommended alongside it. One suggestion in Section 5 though: CURRENT: For some applications and services, it is favorable if the transmission is finished earlier than expected. However, in some cases it may be against the original intention of the LE PHB user to strictly send the traffic only if otherwise unused resources are available, i.e., LE traffic may compete with BE traffic for the same resources and thus adversely affect the original BE aggregate. In some cases users want to be sure that their LE marked traffic actually fulfills the "no harm" property. Applications that want to ensure the lower precedence compared to BE traffic SHOULD use additionally a corresponding Lower- than-Best-Effort transport protocol [RFC6297 ], e.g., LEDBAT [RFC6817 ]. SUGGESTED: Therefore applications MUST use additionally a corresponding Lower- than-Best-Effort transport protocol [RFC6297 ], e.g., LEDBAT [RFC6817 ], unless for example ... . I much prefer recommending an LBE transport instead of the original le-min/le-strict distinction. However, I've suggested the above because user-preference is only one exception, and it's not well articulated here anyway (IMO). Normally a "SHOULD" needs to also explain in what cases an implementation will not follow the recommendation. The logic of the preceding sentence would imply that the exception to the SHOULD is when the application does not want to comply with the "no harm" principle. Or put another way, when the application does not care about harming BE traffic. I don't think that's how you intended this to be interpreted, given a sociopath wouldn't be using LE in the first place. However, I can think of cases where an application would not need to use an LBE transport, e.g. where the app knows by configuration or measurement: * that all bottlenecks on the network path support the LE PHB, * or that the network path has really high capacity that is rarely used, * or that the volume of traffic to be sent is not that great. * or that the application could use DF, but LE would be preferable if it was available (which is what I think you meant) So here I would argue for a sentence construction like "MUST use LBE... unless for example...", followed by some example exceptions, like my bullets above. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------BB21842F72BC802679CE1623 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Roland,

I like how this draft has turned out. I particularly agree with LE updating CS1, not just being recommended alongside it. One suggestion in Section 5 though:

CURRENT:
   For some applications and
   services, it is favorable if the transmission is finished earlier
   than expected.  However, in some cases it may be against the original
   intention of the LE PHB user to strictly send the traffic only if
   otherwise unused resources are available, i.e., LE traffic may
   compete with BE traffic for the same resources and thus adversely
   affect the original BE aggregate.  In some cases users want to be
   sure that their LE marked traffic actually fulfills the "no harm"
   property.  Applications that want to ensure the lower precedence
   compared to BE traffic SHOULD use additionally a corresponding Lower-
   than-Best-Effort transport protocol [RFC6297], e.g., LEDBAT
   [RFC6817].
SUGGESTED:
   Therefore applications MUST use additionally a corresponding Lower-
   than-Best-Effort transport protocol [RFC6297], e.g., LEDBAT
   [RFC6817], unless for example ... <bullet list of exceptions>.

I much prefer recommending an LBE transport instead of the original le-min/le-strict distinction. However, I've suggested the above because user-preference is only one exception, and it's not well articulated here anyway (IMO).

Normally a "SHOULD" needs to also explain in what cases an implementation will not follow the recommendation. The logic of the preceding sentence would imply that the exception to the SHOULD is when the application does not want to comply with the "no harm" principle. Or put another way, when the application does not care about harming BE traffic. I don't think that's how you intended this to be interpreted, given a sociopath wouldn't be using LE in the first place.

However, I can think of cases where an application would not need to use an LBE transport, e.g. where the app knows by configuration or measurement:
* that all bottlenecks on the network path support the LE PHB,
* or that the network path has really high capacity that is rarely used,
* or that the volume of traffic to be sent is not that great.
* or that the application could use DF, but LE would be preferable if it was available (which is what I think you meant)

So here I would argue for a sentence construction like "MUST use LBE... unless for example...", followed by some example exceptions, like my bullets above.




Bob



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------BB21842F72BC802679CE1623-- From nobody Tue Mar 6 21:59:29 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AFD126C26 for ; Tue, 6 Mar 2018 21:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=cI1uTttC; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=DARZh0bd 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 0e-5FKPIpXjI for ; Tue, 6 Mar 2018 21:59:25 -0800 (PST) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 6FEE7124BE8 for ; Tue, 6 Mar 2018 21:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1520402365; x=1551938365; h=from:to:subject:date:message-id:mime-version; bh=8erb/Ay2WibVyZo98Mr3hYlrdl/+7N1AepJvxHxG5bA=; b=cI1uTttCRlxEVNrG0lGDFQK2pggCsbAxq78m2Ci6Dz3BvGnbzX9fKzaZ orzNs1S0iLSbBP1qC65y3vB9BoMAGxe4HcZsEN0RY1r25rAeKQg+L9oeN /GFW/aFt1Za27xUcf05ud5Ld2xSsfUNOqpo1z20E7GpiCR6sjYN3UQZew s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FZAQBGf59ah2Oa6ERdHgEGDIJaIoEqE?= =?us-ascii?q?HAoCptngxiUNBSBP0IKI4UNAoMEITQYAQIBAQEBAQECAQIQAQEBCgsJCCgjC4I?= =?us-ascii?q?4IhFLIQYyAQEBAQEBAQEBAQEBAQEBAQEBFwI9ARJOEx8bEQEqHTkUEgEEEwiEL?= =?us-ascii?q?2QBD6p9gwiFaYIZAwWFMYIugViBZYR0gWcCAwGBOgEPAwEhK4MOgjKTTIcfAwY?= =?us-ascii?q?ChlKDEokAhDWIXIl9hywCBAIEBQIagS4egRpxcE+CQ4JBggd3iWuBIoEYAQEB?= X-IPAS-Result: =?us-ascii?q?A2FZAQBGf59ah2Oa6ERdHgEGDIJaIoEqEHAoCptngxiUNBS?= =?us-ascii?q?BP0IKI4UNAoMEITQYAQIBAQEBAQECAQIQAQEBCgsJCCgjC4I4IhFLIQYyAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBFwI9ARJOEx8bEQEqHTkUEgEEEwiEL2QBD6p9gwiFaYI?= =?us-ascii?q?ZAwWFMYIugViBZYR0gWcCAwGBOgEPAwEhK4MOgjKTTIcfAwYChlKDEokAhDWIX?= =?us-ascii?q?Il9hywCBAIEBQIagS4egRpxcE+CQ4JBggd3iWuBIoEYAQEB?= Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2018 23:59:24 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2018 11:59:24 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w275xMWh023032 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 7 Mar 2018 00:59:23 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w275xMWh023032 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1520402363; bh=TC/B3ZGgi1pBIVJ1EMiFA+3tT1A=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=DARZh0bdt0emjjfMjjJCP2Cdn8jxefT2nIfQ1T024jTAcG1HYJ1mF5LOVv3LBsbhd C8AlSCw9wfPEzCzaMxol+4FCFSYjYW5XvVPL4uvBx0S/basNBgn651sQNY/MbNi4PG ybTGCO7CVDxvkbmDhCx7ym3izDZcRqzMNI/CXlHc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w275xMWh023032 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Wed, 7 Mar 2018 00:59:04 -0500 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w275x4DP001402 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 7 Mar 2018 00:59:05 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0352.000; Wed, 7 Mar 2018 00:59:04 -0500 To: "tsvwg@ietf.org" Thread-Topic: WGLC for draft-ietf-tsvwg-iana-dscp-registry-00 as PS, closes 30 March 2018 Thread-Index: AdO12JS20YErh6thQ9OAtNm/9s8Y7Q== Date: Wed, 7 Mar 2018 05:59:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363003DB7EMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] WGLC for draft-ietf-tsvwg-iana-dscp-registry-00 as PS, closes 30 March 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 05:59:27 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363003DB7EMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email announces a TSVWG Working Group Last Call (WGLC) on: IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC draft-ietf-tsvwg-iana-dscp-registry-00 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ This WGLC will last for longer than usual - it ends the week after the upco= ming London meetings in order to allow for comments arising from discussion during those meetings. Comments should be sent to the tsvwg@ietf.org list, = although purely editorial comments may be sent directly to the author. Please cc: the WG chairs at tsvwg-chairs@ietf.org if you wo= uld like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on draft-ietf-tsvwg-iana-dscp-registry-00 Thanks, David and Wes (TSVWG Co-Chairs) (Gorry is the draft author) --_000_CE03DB3D7B45C245BCA0D243277949363003DB7EMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This email announces a TSVWG Working Group Last C= all (WGLC) on:

 

IANA Assignment of DSCP Pool 3 (xxxx01) Values to= require Publication of

        &= nbsp;    a Standards Track or Best Current Practice RFC=

        &= nbsp;        draft-ietf-tsvwg-iana-dscp-= registry-00

 

https://datatracker.ietf.org/doc/draft-iet= f-tsvwg-iana-dscp-registry/

 

This WGLC will last for longer than usual –= it ends the week after the upcoming

London meetings in order to allow for comments ar= ising from discussion

during those meetings.

 

Comments should be sent to the tsvwg@ietf.org list, although purely

editorial comments may be sent directly to the au= thor. Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to

track such editorial comments as part of the WGLC= process.

 

No IPR disclosures have been submitted directly o= n

draft-ietf-tsvwg-iana-dscp-registry-00=

 

Thanks,

David and Wes

(TSVWG Co-Chairs)

(Gorry is the draft author)

 

 

--_000_CE03DB3D7B45C245BCA0D243277949363003DB7EMX307CL04corpem_-- From nobody Tue Mar 6 22:03:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45894127058 for ; Tue, 6 Mar 2018 22:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=f8BftNlx; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Gsrz84Ud 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 yY5aIKHYhmp7 for ; Tue, 6 Mar 2018 22:03:09 -0800 (PST) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 0ED72124BE8 for ; Tue, 6 Mar 2018 22:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1520402589; x=1551938589; h=from:to:subject:date:message-id:mime-version; bh=EgTDLGpwEi5uTaQkRhTFjWkAwzPCPEvp7V9qK0yThwc=; b=f8BftNlxz5/6+5ClaLwfHDaNd/Bn4ByL9K6HiFoSIMug5TCq0HfCUUJW qw2RmLKxNTO+Y9fVOjeSTHl0BKm+sQQWeRHJOS1GJ4LqDXeHuUyXxDmRA Pon3/l57OhqE7k3eCpwoOYXBAFzMMYKmDVORlxou+07sgyXg1HT72ZQJB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FKAQBGf59amD+a6ERaAx4BBgyCWiKBK?= =?us-ascii?q?hBwFhIKm2eDGJQ0gVNCCoUwAoMEITQYAQIBAQEBAQECAQIQAQEBAQEICwsGKC6?= =?us-ascii?q?COCIRSyEGMgEBAQEBAQEBAQEBAQEBAQEBARcCPRNIBhMfGxEBKh05FBIBBAESC?= =?us-ascii?q?IQvZAGqUjqDCIVpghkIhTGCLoFYgWWIUB8mgnSCMognZpFeAwYCn3WRKQIEAgQ?= =?us-ascii?q?FAhqBLh6CC3CDEgmCOIIHdzOKWoEYAQEB?= X-IPAS-Result: =?us-ascii?q?A2FKAQBGf59amD+a6ERaAx4BBgyCWiKBKhBwFhIKm2eDGJQ?= =?us-ascii?q?0gVNCCoUwAoMEITQYAQIBAQEBAQECAQIQAQEBAQEICwsGKC6COCIRSyEGMgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARcCPRNIBhMfGxEBKh05FBIBBAESCIQvZAGqUjqDCIV?= =?us-ascii?q?pghkIhTGCLoFYgWWIUB8mgnSCMognZpFeAwYCn3WRKQIEAgQFAhqBLh6CC3CDE?= =?us-ascii?q?gmCOIIHdzOKWoEYAQEB?= Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2018 00:03:08 -0600 From: "Black, David" To: "Black, David" , "tsvwg@ietf.org" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2018 11:56:33 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w27637K1001111 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 7 Mar 2018 01:03:07 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com w27637K1001111 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1520402587; bh=qleYDZxNZnrP40h/kPp5fnERGFA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Gsrz84UdQsqalHq7TjVnvI4S4jR3K8lD6OEljyt0HDuTP5xDss7zrm+rvFnJiV13o 2/4KOZMdR5ed+97Tf7TyaNEbrcEKGgzd8Mr2OIukgoxZsbI7eaFrNmm7V7daynyJGw Kkg5t6Qtmday3t8x5eEKCG5Y1vcyzt8ZP84FyCVQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com w27637K1001111 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd05.lss.emc.com (RSA Interceptor) for ; Wed, 7 Mar 2018 01:02:35 -0500 Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w2762oCm003637 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Wed, 7 Mar 2018 01:02:51 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0352.000; Wed, 7 Mar 2018 01:02:50 -0500 Thread-Topic: draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems Thread-Index: AdO12eq1F1y9sQDzRIWtX3v9rSNVsQ== Date: Wed, 7 Mar 2018 06:02:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363003DBA5MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 06:03:11 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363003DBA5MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A first WGLC comment - it looks like a bunch of acronyms were corrupted in = the initial WG -00 version of this draft. Changes needed include: IONA -> IANA DEC -> DSCP PB -> PHB RCS -> RFCs TAUS -> TAUS Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949363003DBA5MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A first WGLC comment – it looks like a bunch of acronyms were c= orrupted in the initial WG -00 version of this draft.=

 

Changes needed include= :

 

IONA -> IANA

DEC -> DSCP

PB -> PHB

RCS -> RFCs

TAUS -> TAUS

 

Thanks, --David

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

David L. Black, Distin= guished Engineer

Dell EMC, 176 South St= ., Hopkinton, MA  01748

+1 (508) 293-7953&= nbsp;   Mobile: +1 (978) 394-7754

David.Black@dell.com

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

 

--_000_CE03DB3D7B45C245BCA0D243277949363003DBA5MX307CL04corpem_-- From nobody Wed Mar 7 00:57:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D824127978 for ; Wed, 7 Mar 2018 00:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Dmq4f-lIj6 for ; Wed, 7 Mar 2018 00:57:35 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0DB126D3F for ; Wed, 7 Mar 2018 00:57:35 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 9DE201B0013B; Wed, 7 Mar 2018 08:57:00 +0000 (GMT) Message-ID: <5A9FA95C.20200@erg.abdn.ac.uk> Date: Wed, 07 Mar 2018 08:57:00 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Black, David" CC: "tsvwg@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 08:57:36 -0000 I am really sorry. That's quite a nuisance! I now have a new revision -01 ready that resloves this issue. Gorry On 07/03/2018, 06:02, Black, David wrote: > > A first WGLC comment it looks like a bunch of acronyms were > corrupted in the initial WG -00 version of this draft. > > Changes needed include: > > IONA -> IANA > > DEC -> DSCP > > PB -> PHB > > RCS -> RFCs > > TAUS -> TAUS > > Thanks, --David > > ---------------------------------------------------------------- > > David L. Black, Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 Mobile: +1 (978) 394-7754 > > David.Black@dell.com > > ---------------------------------------------------------------- > From nobody Wed Mar 7 08:17:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1660512D7E6 for ; Wed, 7 Mar 2018 08:17:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 Fpm1Bxjv1ZA8 for ; Wed, 7 Mar 2018 08:17:37 -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 20A661270AB for ; Wed, 7 Mar 2018 08:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:To:References:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/unUdaJkE+FCt0ypk8/yqLb3pEdnjO0hFvWG4tM6/5o=; b=77hczrX6YWaQe/CcZEHM2ygNU ZS8cZ/F9Sx1vvTJ7XeBdUN9fp0SbkGVTQK4t2102SFPLAGFJzWF23gSKaomvLxdy22Wa1EgjiGIzs LpK1W5l0asjeyhdFxXZjTmQ35t31h4krkxGdXnE5oZSwFV43sKkyiRUIMmgS43YZcj8tXhuz2RHzB o5fqDf+axl1gxLLErTSdi0Kf8aniEzbFkjEv/Zn7fhmWPMDNmEAgeWhAqJWd5kMgL32kOU8adkfY3 Xh+lwABc5M3ryLA9uCnxzun9l114lRUbqqVVpihgBBzNVx3BoriTZHF7adGv1lYvUDN1oFs4jTjTM Fz6rLp79A==; Received: from [84.92.178.164] (port=44068 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1etbl0-0007Y6-QJ; Wed, 07 Mar 2018 16:17:35 +0000 References: <152029464941.12916.18073052497148806928.idtracker@ietfa.amsl.com> To: "Black, David" , Gorry Fairhurst , Wesley Eddy , tsvwg IETF list From: Bob Briscoe X-Forwarded-Message-Id: <152029464941.12916.18073052497148806928.idtracker@ietfa.amsl.com> Message-ID: <134b9a2e-9ba8-cddd-3ddd-dffe8db29cf5@bobbriscoe.net> Date: Wed, 7 Mar 2018 16:17:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152029464941.12916.18073052497148806928.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------872A7AFE7466CBB82DF845C7" Content-Language: en-GB 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: Subject: [tsvwg] New draft: "Interactions between L4S & Diffserv" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 16:17:40 -0000 This is a multi-part message in MIME format. --------------872A7AFE7466CBB82DF845C7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit TSVWG chairs & list, As requested and promised, on Monday I submitted a -00 individual draft on the interaction between L4S and Diffserv. Intended status: INFORMATIONAL. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-00 *Status** *It's reasonably complete already (in 17pp). It developed from initial discussions with DavidB & Gorry in Singapore (& over email afterwards including Wes), as well as internal discussions in CableLabs and presentations to a number of vendors and operators. However, all views expressed and mistakes are my own. So it's ready to review for adoption, which can hopefully be achieved in reasonably short order (given it's informational about an experiment there is scope for it to change during the experiment). *Known Gaps* * The Abstract promises "in which cases one can stand alone without needing the other". That's implicitly embedded in the text, but not brought out explicitly. * Mapping to 802.11 user priorities (or LTE QCIs)? Not strictly within the scope, but perhaps desirable to add, or at least to mention how L4S (experimental) would affect RFC8325 which gives (standards track) mappings between Diffserv and 802.11. * Comparison between L4S policing and Diffserv traffic conditioning is TBA * Security Considerations are TBA (largely depends on the previous bullet) *Fit with other L4S drafts** * The idea is to use this informational draft to explain in longhand how L4S and Diffserv fit together, then put any normative requirements on L4S concerning Diffserv in the relevant experimental drafts, specifically: * draft-ietf-tsvwg-aqm-l4s-dualq-coupled [DONE & SUBMITTED as -04] * draft-ietf-tsvwg-ecn-l4s-id [DONE but I screwed up the metadata just before the deadline - will post on Monday of IETF when draft server opens again.] We will also summarize this L4S-Diffserv draft (once stable) in the L4S architecture (draft-ietf-tsvwg-l4s-arch). I didn't want to make the L4S architecture 17 pages longer solely to describe interactions with an architecture that actually only exists as one PHB in many parts of the Internet. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-briscoe-tsvwg-l4s-diffserv-00.txt Date: Mon, 05 Mar 2018 16:04:09 -0800 From: internet-drafts@ietf.org To: Bob Briscoe A new version of I-D, draft-briscoe-tsvwg-l4s-diffserv-00.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-briscoe-tsvwg-l4s-diffserv Revision: 00 Title: Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services Document date: 2018-03-05 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-l4s-diffserv-00.txt Status: https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-l4s-diffserv/ Htmlized: https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-00 Abstract: L4S and Diffserv offer somewhat overlapping services (low latency and low loss), but bandwidth allocation is out of scope for L4S. Therefore there is scope for the two approaches to complement each other, but also to conflict. This informational document explains how the two approaches interact, how they can be arranged to complement each other and in which cases one can stand alone without needing the other. 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 --------------872A7AFE7466CBB82DF845C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit TSVWG chairs & list,

As requested and promised, on Monday I submitted a -00 individual draft on the interaction between L4S and Diffserv.
Intended status: INFORMATIONAL.

https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-00

Status
It's reasonably complete already (in 17pp).
It developed from initial discussions with DavidB & Gorry in Singapore (& over email afterwards including Wes), as well as internal discussions in CableLabs and presentations to a number of vendors and operators. However, all views expressed and mistakes are my own.

So it's ready to review for adoption, which can hopefully be achieved in reasonably short order (given it's informational about an experiment there is scope for it to change during the experiment).

Known Gaps
  • The Abstract promises "in which cases one can stand alone without needing the other". That's implicitly embedded in the text, but not brought out explicitly.
  • Mapping to 802.11 user priorities (or LTE QCIs)? Not strictly within the scope, but perhaps desirable to add, or at least to mention how L4S (experimental) would affect RFC8325 which gives (standards track) mappings between Diffserv and 802.11.
  • Comparison between L4S policing and Diffserv traffic conditioning is TBA
  • Security Considerations are TBA (largely depends on the previous bullet)

Fit with other L4S drafts

The idea is to use this informational draft to explain in longhand how L4S and Diffserv fit together, then put any normative requirements on L4S concerning Diffserv in the relevant experimental drafts, specifically:
  • draft-ietf-tsvwg-aqm-l4s-dualq-coupled [DONE & SUBMITTED as -04]
  • draft-ietf-tsvwg-ecn-l4s-id [DONE but I screwed up the metadata just before the deadline - will post on Monday of IETF when draft server opens again.]

We will also summarize this L4S-Diffserv draft (once stable) in the L4S architecture (draft-ietf-tsvwg-l4s-arch). I didn't want to make the L4S architecture 17 pages longer solely to describe interactions with an architecture that actually only exists as one PHB in many parts of the Internet.


Bob
 



-------- Forwarded Message --------
Subject: New Version Notification for draft-briscoe-tsvwg-l4s-diffserv-00.txt
Date: Mon, 05 Mar 2018 16:04:09 -0800
From: internet-drafts@ietf.org
To: Bob Briscoe <ietf@bobbriscoe.net>


A new version of I-D, draft-briscoe-tsvwg-l4s-diffserv-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-briscoe-tsvwg-l4s-diffserv
Revision:	00
Title:		Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services
Document date:	2018-03-05
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-l4s-diffserv-00.txt
Status:         https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-l4s-diffserv/
Htmlized:       https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-00


Abstract:
   L4S and Diffserv offer somewhat overlapping services (low latency and
   low loss), but bandwidth allocation is out of scope for L4S.
   Therefore there is scope for the two approaches to complement each
   other, but also to conflict.  This informational document explains
   how the two approaches interact, how they can be arranged to
   complement each other and in which cases one can stand alone without
   needing the other.

                                                                                  


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

--------------872A7AFE7466CBB82DF845C7-- From nobody Wed Mar 7 11:20:50 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFC01270FC for ; Wed, 7 Mar 2018 11:20:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdsH2lJwzdiR for ; Wed, 7 Mar 2018 11:20:47 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::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 66276124F57 for ; Wed, 7 Mar 2018 11:20:47 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id c11-v6so1903691plo.0 for ; Wed, 07 Mar 2018 11:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LXTDsq2T2/CgUrhk77/I4YxjARPmHsdusiWeGgrML78=; b=blXifC2cZO6PVe/+Ljlo/0PL4F083nK/JxQA2feFaOMblHTSPv3vDg7zzbpJlHabb7 Wl6CIT+xZWvBG0X4dLM0AP051gnonBHOJeUEpzr6j/oEYuW5svTe17FBp6yR5ZE8T+0k cdsclzry0jpDEGxCmA7mjGiYM7mFaTFgMbQVVhIdsClP6tvROVkSMyxKHqif2VmRkFhy HheP75SCJ4UXm2AypsLLSTyy6xBfpK22TpGcj/tuSgZRo74HyrDfK7yALH2eG8Bi8lSd RnXnBfJVDxEPeiPU+Oze8PuQYvVkwUMCioi+rPta3bzqzV2X0GVCv+l3QtSxXULhJ/Ui 4O+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LXTDsq2T2/CgUrhk77/I4YxjARPmHsdusiWeGgrML78=; b=dj0pzhA0C/bU1kdGQC44ulJtGxTz5MIzmeJLGS0z10ndX+K5rJdyjIYDshUu/bAHmu v8m3ZFSRPUZwW+gmVjPYGk9ZmXIpA8bAUXbbiAtZ+ApCO7P6H0DSPbiR7AjQtNvzPCh0 iJ3e9Iw8xOoNAaOA3246D1RGpE3gc7hKxSuQB8GUKbsC0BGsyXBd9JPRBGHH8rD/nWyC qzLljVnUnpwzHUEZci+1k2pv5N/HKHF7DMt0a1WR1Fx8HnxNaVX6N4M4imvssRiknd/g /SmHGqeGarjhHr6tKDa3UtB3NqmMysBeOys+kzLum3jG/8rvJRLwFagQC42PJTXImFad Axlg== X-Gm-Message-State: AElRT7GpVY1xVlvHSIEaPZXpA1LtbPXUP3wW9TAX9NbeBlfXAqAKDAoB CNet3/f57NOlrbjsnrBlZvV0u+4MzpE= X-Google-Smtp-Source: AG47ELsykSRcMheHBiT5IaXsh3K8XTNuv+mkkIdeDbpvP7fQ8vKyyTUNq8BRzewXI/CsEWhQOiz11g== X-Received: by 2002:a17:902:a5c2:: with SMTP id t2-v6mr18720298plq.244.1520450446686; Wed, 07 Mar 2018 11:20:46 -0800 (PST) Received: from [192.168.178.30] ([118.148.71.2]) by smtp.gmail.com with ESMTPSA id z64sm33377677pfi.58.2018.03.07.11.20.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 11:20:45 -0800 (PST) Sender: Brian Carpenter To: gorry@erg.abdn.ac.uk, "Black, David" Cc: "tsvwg@ietf.org" References: <5A9FA95C.20200@erg.abdn.ac.uk> From: Brian E Carpenter Message-ID: Date: Thu, 8 Mar 2018 08:20:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5A9FA95C.20200@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 19:20:49 -0000 > TAUS -> TAUS That one is a bit hard to parse out of context ;-) I'm curious to know which transformation tool Gorry used to make this par= ticular set of substitutions. However, apart from this set of nits, I think the document is in good shape and ready for the IESG. Regards Brian On 07/03/2018 21:57, Gorry Fairhurst wrote: > I am really sorry. That's quite a nuisance! >=20 > I now have a new revision -01 ready that resloves this issue. >=20 > Gorry >=20 >=20 > On 07/03/2018, 06:02, Black, David wrote: >> >> A first WGLC comment =E2=80=93 it looks like a bunch of acronyms were = >> corrupted in the initial WG -00 version of this draft. >> >> Changes needed include: >> >> IONA -> IANA >> >> DEC -> DSCP >> >> PB -> PHB >> >> RCS -> RFCs >> >> TAUS -> TAUS >> >> Thanks, --David >> >> ---------------------------------------------------------------- >> >> David L. Black, Distinguished Engineer >> >> Dell EMC, 176 South St., Hopkinton, MA 01748 >> >> +1 (508) 293-7953 Mobile: +1 (978) 394-7754 >> >> David.Black@dell.com >> >> ---------------------------------------------------------------- >> >=20 >=20 From nobody Wed Mar 7 13:13:10 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB99127863 for ; Wed, 7 Mar 2018 13:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=ovu4ysxy; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=LURZcdby 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 5UEWQIvAFNcj for ; Wed, 7 Mar 2018 13:13:06 -0800 (PST) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 660021277BB for ; Wed, 7 Mar 2018 13:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1520457183; x=1551993183; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fH62aI8bSFlxviHdHGNTrBLBv9DnOTNKSgu2JgUIoOg=; b=ovu4ysxyxL1s5yWWYa2NWdGSDfVxnFF02Rqv/2Fl8+NORxz5mIzrqPG9 osDG8f7iG/IVbcABHwdWhQO4tjFXDW8JyBE34nQmkQswbcMehF4z7tW85 CYOl+FhavBX+hqPOPYLikczpL4qGG+px36QOkA+NTU0WayrBBNbhpj4h0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HzAACZVKBah2Oa6ERbAw4LAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgnyBKoEAKAqDSpgfggKBFocjjmRCCoUwAhqCcCE3FQECAQE?= =?us-ascii?q?BAQEBAgECEAEBAQoLCQgoLoI4JAEOSyEGMgEBAQEBAQEBAQEBAQEBAQEBARcCP?= =?us-ascii?q?RMCGAEBAQQjBA0MHxoBCwQCAQgRBAEBAQICBh0DAgICHxEUAQgIAQEEAQ0FCIR?= =?us-ascii?q?7AxUBqiiBbTqDCIQiDYEwghkIgQ+EI4E1eYFYgWWDLYJqgjkVCiaCRDCCMognk?= =?us-ascii?q?hMxAwYCjUGSNoo3hnMCBAIEBQIagS40gXVwgxKCQYFMO3czijqBGAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2HzAACZVKBah2Oa6ERbAw4LAQEBAQEBAQEBAQEBBwEBAQE?= =?us-ascii?q?BgnyBKoEAKAqDSpgfggKBFocjjmRCCoUwAhqCcCE3FQECAQEBAQEBAgECEAEBA?= =?us-ascii?q?QoLCQgoLoI4JAEOSyEGMgEBAQEBAQEBAQEBAQEBAQEBARcCPRMCGAEBAQQjBA0?= =?us-ascii?q?MHxoBCwQCAQgRBAEBAQICBh0DAgICHxEUAQgIAQEEAQ0FCIR7AxUBqiiBbTqDC?= =?us-ascii?q?IQiDYEwghkIgQ+EI4E1eYFYgWWDLYJqgjkVCiaCRDCCMognkhMxAwYCjUGSNoo?= =?us-ascii?q?3hnMCBAIEBQIagS40gXVwgxKCQYFMO3czijqBGAEBAQ?= Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2018 15:13:01 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2018 03:13:01 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w27LCwTf005530 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Mar 2018 16:13:00 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com w27LCwTf005530 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1520457180; bh=mA2FNaj4T9G4fsfrof6n1AuZLGI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LURZcdbyJLhQjjjXTHDuVlVH5VzZZF/LRYTeAncDzX8tpg4lBhgCQzTlj9KjcpwBo rdi2xh+2xD/dfoEubBtBMBYOxM9KXHSGZIsgn67lQhaXw0QFsYOldsrvbiZIgZ+i7q BwZ1azgLnFyKELSRHy7zuoJI8qYISRn2fh3P8wRs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com w27LCwTf005530 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 7 Mar 2018 16:12:26 -0500 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w27LCgwj002487 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 7 Mar 2018 16:12:42 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0352.000; Wed, 7 Mar 2018 16:12:42 -0500 To: Brian E Carpenter , "gorry@erg.abdn.ac.uk" CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems Thread-Index: AdO12eq1F1y9sQDzRIWtX3v9rSNVsQAQj8QAABXJDoAABpP9sA== Date: Wed, 7 Mar 2018 21:12:41 +0000 Message-ID: References: <5A9FA95C.20200@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] 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: Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 21:13:09 -0000 VGhhdCB3YXMgc3VwcG9zZWQgdG8gYmUgVEFVUyAtPiBUT1MgLi4uDQoNClRoYW5rcywgLS1EYXZp ZA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gQ2FycGVu dGVyIFttYWlsdG86YmVjYXJwZW50ZXI0NkBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBCcmlhbiBF DQo+IENhcnBlbnRlcg0KPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDcsIDIwMTggMjoyMSBQTQ0K PiBUbzogZ29ycnlAZXJnLmFiZG4uYWMudWs7IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1j LmNvbT4NCj4gQ2M6IHRzdndnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIGRyYWZ0 LWlldGYtdHN2d2ctaWFuYS1kc2NwLXJlZ2lzdHJ5LTAwIC0gQWNyb255bSBwcm9ibGVtcw0KPiAN Cj4gPiBUQVVTIC0+IFRBVVMNCj4gDQo+IFRoYXQgb25lIGlzIGEgYml0IGhhcmQgdG8gcGFyc2Ug b3V0IG9mIGNvbnRleHQgOy0pDQo+IA0KPiBJJ20gY3VyaW91cyB0byBrbm93IHdoaWNoIHRyYW5z Zm9ybWF0aW9uIHRvb2wgR29ycnkgdXNlZCB0byBtYWtlIHRoaXMNCj4gcGFydGljdWxhcg0KPiBz ZXQgb2Ygc3Vic3RpdHV0aW9ucy4gSG93ZXZlciwgYXBhcnQgZnJvbSB0aGlzIHNldCBvZiBuaXRz LCBJIHRoaW5rIHRoZQ0KPiBkb2N1bWVudCBpcyBpbiBnb29kIHNoYXBlIGFuZCByZWFkeSBmb3Ig dGhlIElFU0cuDQo+IA0KPiBSZWdhcmRzDQo+ICAgIEJyaWFuDQo+IA0KPiBPbiAwNy8wMy8yMDE4 IDIxOjU3LCBHb3JyeSBGYWlyaHVyc3Qgd3JvdGU6DQo+ID4gSSBhbSByZWFsbHkgc29ycnkuIFRo YXQncyBxdWl0ZSBhIG51aXNhbmNlIQ0KPiA+DQo+ID4gSSBub3cgaGF2ZSBhIG5ldyByZXZpc2lv biAtMDEgcmVhZHkgdGhhdCByZXNsb3ZlcyB0aGlzIGlzc3VlLg0KPiA+DQo+ID4gR29ycnkNCj4g Pg0KPiA+DQo+ID4gT24gMDcvMDMvMjAxOCwgMDY6MDIsIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4g Pj4NCj4gPj4gQSBmaXJzdCBXR0xDIGNvbW1lbnQg4oCTIGl0IGxvb2tzIGxpa2UgYSBidW5jaCBv ZiBhY3JvbnltcyB3ZXJlDQo+ID4+IGNvcnJ1cHRlZCBpbiB0aGUgaW5pdGlhbCBXRyAtMDAgdmVy c2lvbiBvZiB0aGlzIGRyYWZ0Lg0KPiA+Pg0KPiA+PiBDaGFuZ2VzIG5lZWRlZCBpbmNsdWRlOg0K PiA+Pg0KPiA+PiBJT05BIC0+IElBTkENCj4gPj4NCj4gPj4gREVDIC0+IERTQ1ANCj4gPj4NCj4g Pj4gUEIgLT4gUEhCDQo+ID4+DQo+ID4+IFJDUyAtPiBSRkNzDQo+ID4+DQo+ID4+IFRBVVMgLT4g VEFVUw0KPiA+Pg0KPiA+PiBUaGFua3MsIC0tRGF2aWQNCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ Pg0KPiA+PiBEYXZpZCBMLiBCbGFjaywgRGlzdGluZ3Vpc2hlZCBFbmdpbmVlcg0KPiA+Pg0KPiA+ PiBEZWxsIEVNQywgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9uLCBNQSAwMTc0OA0KPiA+Pg0KPiA+ PiArMSAoNTA4KSAyOTMtNzk1MyBNb2JpbGU6ICsxICg5NzgpIDM5NC03NzU0DQo+ID4+DQo+ID4+ IERhdmlkLkJsYWNrQGRlbGwuY29tIDxtYWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb20+DQo+ID4+ DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPg0KPiA+DQoNCg== From nobody Thu Mar 8 00:17:52 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2BB12426E for ; Thu, 8 Mar 2018 00:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=Ay6Dx/ja; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=iZJM6s+6 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 kbNAQX5lRwyf for ; Thu, 8 Mar 2018 00:17:48 -0800 (PST) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 E55211205F0 for ; Thu, 8 Mar 2018 00:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1520497068; x=1552033068; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qKHAVIrKruO+cg5FASjHE1f2TUGdBk6BQcEJTvOqOSo=; b=Ay6Dx/jafNEHQSdVu9xFJd7pvVs/7kc9D4wC+KbwEVJnailxUdVo0pED s9P9gGHK8AalFU4I2BTFNyfxxRaOARgIBDOck6omtQzsqsUx3ybVnQA3j G8EicMraGQi0qYdzFQz57PFz0+oHzjgJbPTftsCbuNApLrBJ3F8HXj+XZ A5ORAw86MmSNX5pstp87NRgbsi49xQhHX4D9P/tcNEMpF/Y0cBtFspOyj 0wWYdo6mXuPTBuqiQ1eHxs7+yZLjBqA7ssytcXmAhdyhDp2adUBuG+oIS ogNwYeRhPVvC7KoM6LDAuP+mxU0qKp6ZLkZ4hcXVHslndGqeiV+6/iATP g==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2018 09:17:45 +0100 X-IronPort-AV: E=Sophos;i="5.47,440,1515452400"; d="scan'208";a="187964169" Received: from he105701.emea1.cds.t-internal.com ([10.169.119.22]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 08 Mar 2018 09:17:45 +0100 Received: from HE106158.EMEA1.cds.t-internal.com (10.169.119.88) by HE105701.emea1.cds.t-internal.com (10.169.119.22) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 8 Mar 2018 09:17:44 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106158.EMEA1.cds.t-internal.com (10.169.119.88) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Thu, 8 Mar 2018 09:17:45 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.15) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 8 Mar 2018 09:16:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qKHAVIrKruO+cg5FASjHE1f2TUGdBk6BQcEJTvOqOSo=; b=iZJM6s+6asj1vRPs6ifHNyuRvvVODVUacI0+R9cY2AOqIo2qluRVNsCwM1JkgW+qLtFswAsJg3VmMl7A9Wqx+/oLqOXlaozqPtGIfwukJOMYYRV1euchiX0RM9UfLBIL7qBU6cKjN0ZFT4UHNiu2fK8MkX+9QZbUTg6qttvuUck= Received: from FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.18) by FRAPR01MB0034.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Thu, 8 Mar 2018 08:17:42 +0000 Received: from FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d8eb:3ded:e3fc:5d00]) by FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d8eb:3ded:e3fc:5d00%14]) with mapi id 15.20.0567.012; Thu, 8 Mar 2018 08:17:42 +0000 From: To: CC: , Thread-Topic: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems Thread-Index: AdO12eq1F1y9sQDzRIWtX3v9rSNVsQAGFY4AABXJD4AAGa2JsA== Date: Thu, 8 Mar 2018 08:17:42 +0000 Message-ID: References: <5A9FA95C.20200@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.93] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0034; 7:LSuW0v00YHW5zHbs8pO9HlgOyQuvW5fKMNH9rGoUP9Te95ueFtZ9cHmh5ufXO9TB7FUtZC+Ls1BCcHnRm724123JU8prjq82frQ+8GrjIgY7V5c+h1zV5D9SN1rZ7a/Fx0cn9OIk39c6404c13y323/h0GvzGWjfu/5HYkCw+c2yI3upJDVK5gJvfcIp84bbQEK1XMWaEm5pimYgCWeJW5VdRZAkcw8+W8kF3nZzN1x9DbXjkJMUM8xh9SlOfSjr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 918e717d-1d95-45f9-ca33-08d584cd10d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0034; x-ms-traffictypediagnostic: FRAPR01MB0034: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231220)(944501244)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041288)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:FRAPR01MB0034; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0034; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(39380400002)(366004)(396003)(189003)(199004)(2900100001)(478600001)(296002)(3280700002)(85182001)(8936002)(72206003)(86362001)(55016002)(316002)(14454004)(66066001)(5660300001)(74482002)(102836004)(7736002)(2906002)(97736004)(9686003)(305945005)(53936002)(76176011)(68736007)(6116002)(3846002)(6916009)(2950100002)(4326008)(8676002)(85202003)(54906003)(106356001)(1730700003)(2351001)(75402003)(33656002)(3660700001)(81166006)(5250100002)(81156014)(7696005)(52396003)(26005)(5640700003)(8666007)(105586002)(186003)(2501003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0034; H:FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: sAK4TqtwdV5Z3JegQY0Ruv1XiWZaxyKNzynxntGeMhke+se3qslFU/qu3y3jrAMfzHjH/lFHeEVf3RtWDspXtPY7Ism6yPKYcnzIU456zxtiUhtE3EeEwmwjYy0AbgqcbhpbVyR6dBY1ASui81L4GUC46um2JDK8tqix3HdBI9BzPFLO3Jp07A4KAY8QI36dD8uYMqCAO6eM6qh/Bb1oQ11Z55L7iGLTXr5/RcjTIq9vhIS7oBrBF/lSYlTwY9MWkvvdtARD7cWj3yrc9iR7XseGpZEewhHm/yZoKF0qyOty3Rxy+xXFeSYHZS+yHiwDHpLtjLtKns/NlkSskJrQOA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 918e717d-1d95-45f9-ca33-08d584cd10d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2018 08:17:42.7449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0034 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 08:17:51 -0000 SGkgR29ycnksDQoNCkkgYWdyZWUgd2l0aCBCcmlhbiBvbiB0aGUgcmVhZGluZXNzIGZvciBJRVNH Lg0KDQpPbmUgZWRpdG9yaWFsIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gYSBxdW90ZToNCg0KNS4gIElB TkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgICAgMyB4eHh4MDEgRXhwZXJpbWVudGFsIG9yIExvY2Fs IFVzZSBNYXkgYmUgdXRpbGl6ZWQgZm9yIGZ1dHVyZQ0KICAgICAgU3RhbmRhcmRzIEFjdGlvbiBh bGxvY2F0aW9ucyBhcyBuZWNlc3NhcnkuDQoNClRoZSBjYXBpdGFsIGxldHRlciAiTSIgaXMgYSBi aXQgc3RyYW5nZS4gUkZDMjQ3NCBhZGRzIHRoZSBzZW50ZW5jZSANCmJ5IGEgc2VwYXJhdGUgZm9v dG5vdGUgIigqKSBtYXkuLi4uIi4gSXMgYSBjb21tYSBvayBoZXJlPyANCg0KICAgICAgMyB4eHh4 MDEgRXhwZXJpbWVudGFsIG9yIExvY2FsIFVzZSwgbWF5IGJlIHV0aWxpemVkIGZvciBmdXR1cmUN CiAgICAgIFN0YW5kYXJkcyBBY3Rpb24gYWxsb2NhdGlvbnMgYXMgbmVjZXNzYXJ5Lg0KDQpSZWdh cmRzLA0KDQpSdWVkaWdlcg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpW b246IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24g QnJpYW4gRSBDYXJwZW50ZXINCg0KW3NuaXBdDQoNCkhvd2V2ZXIsIGFwYXJ0IGZyb20gdGhpcyBz ZXQgb2Ygbml0cywgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgaW4gZ29vZCBzaGFwZSBhbmQgcmVh ZHkgZm9yIHRoZSBJRVNHLg0KDQpSZWdhcmRzDQogICBCcmlhbg0KDQoNCg== From nobody Thu Mar 8 00:23:09 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB2612426E for ; Thu, 8 Mar 2018 00:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOfQLS7LONMS for ; Thu, 8 Mar 2018 00:23:06 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 164201205F0 for ; Thu, 8 Mar 2018 00:23:06 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id D1E5C1B001B9; Thu, 8 Mar 2018 08:22:31 +0000 (GMT) Message-ID: <5AA0F2C7.3010300@erg.abdn.ac.uk> Date: Thu, 08 Mar 2018 08:22:31 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de CC: tsvwg@ietf.org, David.Black@dell.com References: <5A9FA95C.20200@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-dscp-registry-00 - Acronym problems X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 08:23:07 -0000 On 08/03/2018, 08:17, Ruediger.Geib@telekom.de wrote: > Hi Gorry, > > I agree with Brian on the readiness for IESG. > > One editorial question related to a quote: > > 5. IANA Considerations > > 3 xxxx01 Experimental or Local Use May be utilized for future > Standards Action allocations as necessary. > The capital letter "M" is a bit strange. RFC2474 adds the sentence > by a separate footnote "(*) may....". Is a comma ok here? > > 3 xxxx01 Experimental or Local Use, may be utilized for future > Standards Action allocations as necessary. Yes - I agree. This "May" certainly should be chnaged in case. I will do that in my version. > Regards, > > Ruediger Gorry > -----Ursprüngliche Nachricht----- > Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Brian E Carpenter > > [snip] > > However, apart from this set of nits, I think the document is in good shape and ready for the IESG. > > Regards > Brian > > From nobody Thu Mar 8 06:54:58 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDF31241F8 for ; Thu, 8 Mar 2018 06:54:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSk0Z1ar3f_y for ; Thu, 8 Mar 2018 06:54:55 -0800 (PST) Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDAD9120713 for ; Thu, 8 Mar 2018 06:54:54 -0800 (PST) Received: from supmail (supmail.isae.fr [10.132.1.9]) by smtpextng.isae.fr (Postfix) with ESMTP id 6F50570CAB for ; Thu, 8 Mar 2018 15:57:22 +0100 (CET) Received: from wali-edu.isae.fr (wali-edu.isae.fr [10.132.1.38]) by supmail (Postfix) with ESMTP id B9FC0C88195 for ; Thu, 8 Mar 2018 15:39:18 +0100 (CET) From: "FINZI Anais" X-Forward: 94.46.13.133, 10.132.1.63 Content-Type: text/plain; charset="utf-8" Date: Thu, 08 Mar 2018 15:55:03 +0100 MIME-Version: 1.0 To: tsvwg@ietf.org Message-ID: <3e1c-5aa14f00-449-42f05a80@83412217> User-Agent: SOGoMail 2.3.22 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [tsvwg] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-finzi?= =?utf-8?q?-priority-switching-scheduler-01=2Etxt?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 14:54:57 -0000 Dear all, I have submitted a new version of the draft about a new scheduler: the = Priority Switching Scheduler. Comments are welcome! Ana=C3=AFs Finzi A new version of I-D, draft-finzi-priority-switching-scheduler-01.txt has been successfully submitted by Anais Finzi and posted to the IETF repository. Name: draft-finzi-priority-switching-scheduler Revision: 01 Title: Priority Switching Scheduler Document date: 2018-03-05 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-finzi-priori= ty-switching-scheduler-01.txt Status: https://datatracker.ietf.org/doc/draft-finzi-priority-s= witching-scheduler/ Htmlized: https://tools.ietf.org/html/draft-finzi-priority-switch= ing-scheduler-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-finzi-prior= ity-switching-scheduler-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-finzi-priorit= y-switching-scheduler-01 Abstract: We detail the implementation of a network scheduler that switches th= e priority of one or several queues. This scheduler aims at carrying= and isolating time constrained and elastic traffic flows from best-= effort traffic. We claim that the usual implementations with rate schedulers (such as WRR, DRR,...) do not allow to efficiently quantify the reserved capacity of the different classes. By using this credit based scheduler mechanism called Priority Switching Scheduler, we provide a more predictable available capacity. = Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 12 03:25:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE37A126CC7 for ; Mon, 12 Mar 2018 03:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=aaGDNc+s; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=ny2NN9kT 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 xy0XNsTWejVJ for ; Mon, 12 Mar 2018 03:25:44 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 8CD7A127275 for ; Mon, 12 Mar 2018 03:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1520850343; x=1552386343; h=from:to:cc:subject:date:message-id:mime-version; bh=MkeOzp9tNuJFRtq13JLnaSkdLJrBl7xz+QBlHV1TWdg=; b=aaGDNc+sostcxPejEeJtSlqSTWOU5gKhAQdtRGWv1jzNXcgoOlJgEf6t 7i85cwl4rxIFeOi2aWmMKsC/KQ8BsxGMYg32uLS5uAFjFCXx7obaBcxRZ DfGEBqTjpN/EW458xLQ6aQu3h14ZoTNX8rOqIj10ejgxfpWL5eIKJmZbt +2kxsOLkkGGZ+mNTED6JFBSxjDrjLvn5+jS5kjlodV1qCP2lGL8029rhD XHRNv0bTECdBCDVJJWJ9NvZ6/QkDHQXnLEgg1MHljgOTCbK2DvqBlRxBm FQN01TfHDL/z9Hsto9qRelIN3yj9oAPcLu8Euso72+6hgfGO4hLk6g7hl w==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2018 11:25:39 +0100 X-IronPort-AV: E=Sophos;i="5.47,460,1515452400"; d="scan'208,217";a="191181777" Received: from he101941.emea1.cds.t-internal.com ([10.169.119.81]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 12 Mar 2018 11:25:39 +0100 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE101941.emea1.cds.t-internal.com (10.169.119.81) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 12 Mar 2018 11:25:39 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Mon, 12 Mar 2018 11:25:39 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.19) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 12 Mar 2018 11:24:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MkeOzp9tNuJFRtq13JLnaSkdLJrBl7xz+QBlHV1TWdg=; b=ny2NN9kTSffwe8wc+nAJnhZhFlgCKTrf9PF6+WjQKiWwAQ/FR4fC7MRzn1e9yQKtVHHTuBuF3BKK65ZsFpzt3z3//CmsQlDIt60nAb2Njbn7aXlHDkEQuzq7t11AMbQBIN3Aidk5o47WzBijD+WaZCeu/v9UiVJWLj4chQBvx2o= Received: from FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.18) by FRAPR01MB0033.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Mon, 12 Mar 2018 10:25:36 +0000 Received: from FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d8eb:3ded:e3fc:5d00]) by FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d8eb:3ded:e3fc:5d00%14]) with mapi id 15.20.0567.018; Mon, 12 Mar 2018 10:25:36 +0000 From: To: CC: Thread-Topic: Comments on draft-ietf-tsvwg-le-phb-04.txt Thread-Index: AdO55NnduyAxjA2JTo2KhgS9TOFVEg== Date: Mon, 12 Mar 2018 10:25:36 +0000 Message-ID: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.210] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0033; 7:wgm8B1fO4oSfyzMub0HNfj0WYfuDmc0AHkq0OcX+QBgbV0wE0Rg5z5RVHOaPJ+Nc23GiqvKSv4vfsuAiUAXWIm61/BrNK03FPS0EWqm91eAWqzfZmbuQ+geRsec8VZsljww75Vsw9ygZ4jjMvqN4O2SbyGv5H7E4HFJDkmcmnjVsk1j5jSYgLC4hrBCpD5JzM4fcdvv+EV7Vv3J+FwMZHNIdxcO6YMO9ji0IlVHfBM8wKxD0VqqG5VkxI6gCji4L x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bac613a7-e1fe-4689-a392-08d588039867 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0033; x-ms-traffictypediagnostic: FRAPR01MB0033: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(192374486261705)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:FRAPR01MB0033; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0033; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(346002)(39860400002)(39380400002)(189003)(199004)(3280700002)(6306002)(54896002)(33656002)(2906002)(3846002)(790700001)(6116002)(8676002)(81166006)(75402003)(81156014)(8936002)(7736002)(2351001)(86362001)(106356001)(5640700003)(53936002)(55016002)(74482002)(9686003)(5250100002)(2171002)(2501003)(105586002)(2900100001)(6916009)(5660300001)(4326008)(102836004)(7696005)(52396003)(316002)(59450400001)(3660700001)(68736007)(14454004)(66066001)(26005)(97736004)(478600001)(186003)(72206003)(5630700001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0033; H:FRAPR01MB0036.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: L5ldWivGbIAfyR30FONooY1+K12pPwTKKT7Cp4YmB4HAygSVjwNhtQVOEHR6F8Ln3iU9tn+R1+dk5C9r6RqqvU42NQQ/z/ag7cojwnevIcPcPBdfN3k6v7Rvn8b9YLD2MZXlO17DlwXwXzes/VrJMq+nJteZOGLY33/Ww/VrtpY4E+BGedE2N/B6piyTk0R2Btp/JpDuqGtkBbP81J197xgP0o9MtpUluB5YT8nUWxGDtN4FZkDIxB3lQHDTA54cKBMLlW6s5udhZz4t6wT0zIQbmmiqR0bgO6hOxZPyP/vp7aDY8yiC/USqvb9TMW6jWl6rgmUbSZiSn7epz4dA+A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB00364A937086CB294A52245D9CD30FRAPR01MB0036DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bac613a7-e1fe-4689-a392-08d588039867 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2018 10:25:36.5376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0033 X-OriginatorOrg: telekom.de Archived-At: Subject: [tsvwg] Comments on draft-ietf-tsvwg-le-phb-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 10:25:47 -0000 --_000_FRAPR01MB00364A937086CB294A52245D9CD30FRAPR01MB0036DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roland, nice to see your draft making progress. I'm having some minor an editorial= comment below. Regards, Ruediger Minor comments: Section 3. Applicability The LE PHB allows networks to protect themselves from selected types of traffic as a complement to giving preferential treatment to other selected traffic aggregates. Might only one of either "traffic" or "aggregate" be sufficient (instead of= traffic aggregate)? --------- Section 5. Traffic Conditioning Actions Please insert a reference to section 8, as section 8 allows for LE policing= at domain-boundaries by a MAY. --------- Section 8. Remarking to other DSCPs/PHBs >From this section on, the "user" seems to be able to set the LE DSCP ("user= sets DSCP" or the like appears in 3 or 4 instances from there on) . Prior = to this section, providers or applications seemed to be the ones to set the= LE DSCP. If the concept of users setting the LE DSCP should be allowed in = general, please add text prior to this section. If not, please adapt text f= rom here on. ------- Section 12. Security Consideration There are no specific security exposures for this PHB. Since it defines a new class of low forwarding priority, I'd suggest to replace "class" by "behavior aggregate" here, as class isn't= well defined. ##################### Editorial comments. Section 3. Applicability Replace LE traffic SHOULD be congestion controlled (i.e., use a congestion controlled transport or implement a congestion control method [RFC8085]). By LE traffic SHOULD use a congestion controlled transport or implement a congestion control method [RFC8085]. ---------------- Replace In the case of multicast traffic packets from untrusted sources are forwarded as LE traffic, they will not harm traffic from non-LE behavior aggregates. By If multicast traffic from untrusted sources is forwarded as LE traffic, it will not harm traffic from non-LE behavior aggregates. --------- Section 8. Remarking to other DSCPs/PHBs Replace The reason for this is that later traversed DS domains may then have still the possibility to treat such packets according the LE PHB. By The reason for this is to enable LE PHB compliant forwarding by downstream diffserv domains. -------- Applications that want to ensure the lower precedence compared to BE traffic SHOULD use additionally a corresponding Lower- than-Best-Effort transport protocol [RFC6297], e.g., LEDBAT [RFC6817]. "use additionally" --> "additionally use" ---------- Replace A DS domain that still uses DSCP CS1 for marking LE traffic (including Low Priority-Data as defined in [RFC4594].... By A DS domain that still continues to mark LE traffic by CS1 (including Low Priority-Data as defined in [RFC4594].... ----------- Section 9. The Update to RFC 4594 Replace by 9. Update to RFC 4594 ----------- Replace [RFC4594] recommended to use CS1 as codepoint in, By Section 4.10 of [RFC4594] recommended to use CS1 as LE DSCP, --------- Replace Therefore, every occurrence of the CS1 DSCP is replaced by the LE DSCP. By Therefore, every occurrence of the CS1 DSCP within RFC 4594 is replaced = by the LE DSCP. ---------- The text from there on multiple times reads: This update to RFC 4594 removes the following entry .... and replaces this by the following entry: I tend to and replaces it by the following entry: Please check with a native spreaker. --_000_FRAPR01MB00364A937086CB294A52245D9CD30FRAPR01MB0036DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roland,

 

nice to see your draft making progress. I’m havin= g  some minor an editorial comment below.

 

Regards,   Ruediger

 

 

 

Minor comments:

 

Section 3. Applicability

 

   The LE PHB allows networks to protect themse= lves from selected types

   of traffic as a complement to giving prefere= ntial treatment to other

   selected traffic aggregates. 

 

Might only one of either “= ;traffic” or “aggregate” be sufficient (instead of traffi= c aggregate)?

 

---------

 

Section 5.   Traffic = Conditioning Actions

 

Please insert a reference = to section 8, as section 8 allows for LE policing at domain-boundaries by a= MAY.

---------

Section 8.   Remarkin= g to other DSCPs/PHBs

 

From this section on, the ̶= 0;user” seems to be able to set the LE DSCP (“user sets DSCP= 221; or the like appears in 3 or 4 instances from there on) . Prior to this= section, providers or applications seemed to be the ones to set the LE DSCP. If the concept of users setting the LE DSCP should be all= owed in general, please add text prior to this section. If not, please adap= t text from here on.

 

-------

 

Section 12.   Securit= y Consideration

 

   There are no specific security exposures for= this PHB. Since it

   defines a new class of low forwarding priority,

 

I’d suggest to replace &#= 8220;class” by “behavior aggregate” here, as class isn= 217;t well defined.

 

#####################

 

Editorial comments.<= /span>

 

Section 3.  Applicability<= o:p>

 

Replace

   LE traffic SHOULD be congestion controlled (= i.e., use a congestion

   controlled transport or implement a congesti= on control method

   [RFC8085]).

 

By

   LE traffic SHOULD use a congestion

   controlled transport or implement a congesti= on control method

   [RFC8085].

 

----------------

 

Replace

 

   In the case of

   multicast traffic packets from untrusted sou= rces are forwarded as LE

   traffic, they will not harm traffic from non-LE= behavior aggregates.

 

By

 

   If multicast traffic from untrusted sources = is forwarded as LE

   traffic, it will not harm traffic from non-LE b= ehavior aggregates.

 

---------

 

Section   8.  Re= marking to other DSCPs/PHBs

 

Replace

   The reason for

   this is that later traversed DS domains may = then have still the

   possibility to treat such packets according the= LE PHB.

 

By

   The reason for

   this is to enable LE PHB compliant forwardin= g by downstream

   diffserv domains.

 

--------

 

   Applications that want to ensure the lower p= recedence

   compared to BE traffic SHOULD use additional= ly a corresponding Lower-

   than-Best-Effort transport protocol [RFC6297= ], e.g., LEDBAT

   [RFC6817].

 

use ad= ditionally” --> “additionally use”

 

----------

 

Replace

   A DS domain that still uses DSCP CS1 for mar= king LE traffic

  (including Low Priority-Data as defined in [RFC4594]&= #8230;.

 

By

   A DS domain that still continues to mark LE traffic by C= S1
    
(including Low Priority-Data as defined in [RFC4594]= ….

 

-----------

 

Section 9.  The Update to = RFC 4594

 

Replace by

 

9.  Update to RFC 4594

 

-----------

Replace

[RFC4594] recommended to use CS1 as codepoint in,

 

By

 

Section 4.10 of [RFC4594] recommended to use CS1 as LE DSCP,=

 

---------

 

Replace

    Therefore, every occurrence of the CS1= DSCP is replaced by

    the LE DSCP.

 <= /o:p>

By

   Therefore, every occurrence of the CS1 DSCP = within RFC 4594 is replaced by

   the LE DSCP.

 <= /o:p>

----------

 

The text from there on multiple times reads:

 

This update to RFC 4594 removes the following entry

….

and replaces this by the following entry:

 

I tend to

 

and replaces it by the following entry:

 

Please check with a native spreaker.

 

 

 

 

 

 

 

 

 

 

 

--_000_FRAPR01MB00364A937086CB294A52245D9CD30FRAPR01MB0036DEUP_-- From nobody Mon Mar 12 10:04:50 2018 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 C51AA1200C5; Mon, 12 Mar 2018 10:04:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152087428375.10743.7719173048614568590@ietfa.amsl.com> Date: Mon, 12 Mar 2018 10:04:43 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-iana-dscp-registry-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 17:04:44 -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 WG of the IETF. Title : IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC Author : Godred Fairhurst Filename : draft-ietf-tsvwg-iana-dscp-registry-01.txt Pages : 7 Date : 2018-03-12 Abstract: The Differentiated Services (Diffserv) architecture specifies use of the field in the IPv4 and IPv6 packet header to carry the Diffserv Code point (DSCP). The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment method for Pool 3 of the registry (i.e., DSCP's of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and Local Use of the code points that form Pool 3 of the DSCP registry; Pool 1 code points (i.e., DEC's of the form xxxx11) remain available for these purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-01 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-iana-dscp-registry-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-iana-dscp-registry-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 12 13:28:53 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DD912704A; Mon, 12 Mar 2018 13:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcJtarUBKWAI; Mon, 12 Mar 2018 13:28:45 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119A3129515; Mon, 12 Mar 2018 13:28:44 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C862658C500; Mon, 12 Mar 2018 21:28:40 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id AF359B0DCE8; Mon, 12 Mar 2018 21:28:40 +0100 (CET) Date: Mon, 12 Mar 2018 21:28:40 +0100 From: Toerless Eckert To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: Yingzhen Qu , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , Thomas Nadeau , "tcpm@ietf.org" Message-ID: <20180312202840.GA25534@faui40p.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [tsvwg] draft-han-tsvwg-cc (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 20:28:51 -0000 Thanks, Michael, On Sun, Mar 04, 2018 at 10:34:29AM +0000, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > In the IETF, I believe the expertise for this specific document would be in TCPM, which in CC. If the authors are interested in feedback on the proposed mechanism, I would recommend to ask TCPM. TCPM might be actually a good idea, and that WG's feedback would be highly welcome. Let me send a separate email to the chairs and ask if they could consider presenting this in TCPM. > From the abstract: ?????? This draft proposes a new TCP congestion control algorithm used in bandwidth guaranteed networks. It is an extension to the current TCP standards.??? The way i would describe it: This memo defines simple extensions to TCP-Reno CC to support and leverage a pre-known network guaranteed (minimum) bandwidth (CIR) and pre-known maximumum needed bandwidth (PIR). IMHO, this work is very much orthogonal to how you would determine PIR and CIR, the draft mentions some IMHO cool new ideas how to do this, but this CC draft by itself would be a great benefit to application developers today (assume CIR/PIR API extensions to transport service -> TAPS, etc. pp). My most simple deployment scenario is simple GUI on video devices/apps, e.g.: in home (STB) where i could select guaranted minimum qualiy (translated by app into CIR), and (optional) maximum quality (PIR). On the parents living room STB CIR would be set according to 4k, and maybe in one other room to FullHD, and the rest has to start compete for available bandwidth all the way from *yuck* QCIF). Of course, with more and more high-bitrate apps like AR/VR and others, the problem to support easy policy differentiation for different apps will increase, but i always like to look first at the most common use case that could profit today. I feel like we have discussed this problem forever, but i am not aware of any actual progress that app developers could use. We really need to break through the chicken & egg circle. IMHO we first need to enable the host stacks to do something like this, and then folks will see a lot easier the need to have better in-network mechanisms to actually guarantee CIR. So, i wouldn't know something more pragmatic & simple than this proposal based on TFP reno. > Alternatively, corresponding research could perhaps be performed in the ICCRG. ICCRG has published RFC 6077 to document some of the open research issues in this space. Nice overview for researchers. Can't quite find from browsing a section related to this CIR/PIR knowledge issue, admission control is mentioned only once in passing. Let me know what you think i should specifically look into, and we'll be happy to relate to that RFC6077 work in the draft. > Michael > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Yingzhen Qu > Sent: Sunday, March 04, 2018 6:55 AM > To: tsvwg@ietf.org; tsvwg-chairs@ietf.org > Cc: Thomas Nadeau > Subject: [tsvwg] Agenda requests for TSVWG@IETF101 > > Dear Chairs, > > A new draft (The draft was suggested by TSVWG @IETF100) was just submitted, and we???d like to request a time slot to present it @IETF101. > > Title: A New Congestion Control in Bandwidth Guaranteed Network > Presenter: Yingzhen Qu (Huawei) > Time required (including Q/A): 10 mins > Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > > If there is any question, please kindly let us know. > > Thanks, > Yingzhen -- --- tte@cs.fau.de From nobody Mon Mar 12 13:58:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6C1126DD9; Mon, 12 Mar 2018 13:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4EcbHgstUx5; Mon, 12 Mar 2018 13:58:22 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDFE126CF9; Mon, 12 Mar 2018 13:58:22 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7D25358C505; Mon, 12 Mar 2018 21:58:18 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5DCFDB0DCE8; Mon, 12 Mar 2018 21:58:18 +0100 (CET) Date: Mon, 12 Mar 2018 21:58:18 +0100 From: Toerless Eckert To: Emmanuel Lochin Cc: tsvwg@ietf.org, tcpm@ietf.org Message-ID: <20180312205818.GC25534@faui40p.informatik.uni-erlangen.de> References: <419905ca-305b-594d-2958-fb468e6e5bb0@isae-supaero.fr> <9ef0cc0b-7bbc-d266-2410-b03265b8c2a1@isae-supaero.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9ef0cc0b-7bbc-d266-2410-b03265b8c2a1@isae-supaero.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [tsvwg] draft-han-tsvwg-cc (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 20:58:25 -0000 On Mon, Mar 05, 2018 at 10:16:19AM +0100, Emmanuel Lochin wrote: > What I remember (looking back IETF archives) is that Sally Floyd > answered she had no objection concerning the proposal if it was > clearly written that the gTFRC mechanism must be used only in the > context of a QoS network. And if history serves me right, that draft of yours was before the IETF figured out that there was and is a lot of traffic assuming bandwidth guaranteees without sufficient network guarantees provided - and ultimately, the concept of circuit breakers was born. I think for these mechanisms we're proposing one could equally refine their applicability to "badly QoS supported" networks by making them automatically fall back to standard congestion control (in our drafts case Reno without CIR). > Sally Floyd also asked questions related > to the algorithm and proposed enhancements about the slow-start > behavior of the mechanism. We answered that we fully agreed with > this hypothesis and justified the choice of our design concerning > the slow-start method. > Therefore, a second discussion started with Mark Allman on potential > security issues raised by this mechanism. Basically, Mark asked us > to add a part concerning the reaction to the congestion in the > guaranteed part (the ???g??? part) even if we are in a context of a > QoS network. We have discussed this point and following this emails > exchange, published a new version of the draft. Right, your -02 section 3.4.2. I told the authors of our draft that that was also a piece i felt is missing in our draft. See above - i would today rephrase it in terms of a "soft circuit breaker" - not breaking the flow at all, but just breaking the assumption of have a CIR. > We also talked about the best way to publish this proposal, it > seemed to be well-accepted to publish a new draft rather than > inserting this contribution inside the new TFRC draft (now RFC > 5348). As a result, we extended the gTFRC draft in order to detail a > complete protocol for QoS networks. > > Finally I left the laboratory I worked during the elaboration of > this draft in 2007 and I assume that this work has not been pursued. Right. > Considering your proposal, I reckon you'll be face to the same > questions in particular the one on the security issue. > But I'm quite > interesting in discussing this proposal on the mailing-list while > even doing something more generic about transport protocol > extensions for QoS networks. Great. Toerless > > EL > > > > > > >BTW, yes, AR/VR means Augmented Reality/Virtual Reality. I'll add > >the acronyms to the next version. > > > >Thanks, > >Yingzhen > > > > > >On Sun, Mar 4, 2018 at 3:45 AM, Emmanuel Lochin > > >> wrote: > > > > Hi Yingzhen > > > > Just for your information, you might be interested in gTFRC : > > https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02 > > > > which is a similar solution i.e. a CC for bandwidth guaranteed > > networks with TFRC. > > Furthermore just a quick question : in your draft does AR/VR > > stands for Augmented/Real Virtuality ? > > > > Regards > > > > Emmanuel > > > > > > On 04/03/2018 06:54, Yingzhen Qu wrote: > >> > >> Dear Chairs, > >> > >> A new draft (The draft was suggested by TSVWG @IETF100) was just > >> submitted, and we???d like to request a time slot to present it > >> @IETF101. > >> > >> Title:A New Congestion Control in Bandwidth Guaranteed Network > >> > >> Presenter: Yingzhen Qu (Huawei) > >> > >> Time required (including Q/A): 10 mins > >> > >> Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > >> > >> > >> If there is any question, please kindly let us know. > >> > >> Thanks, > >> > >> Yingzhen > >> > > > > -- Emmanuel LOCHIN > > Professeur ISAE > > > > ISAE SUPAERO - Institut Suprieur de l'Aronautique et de l'Espace > > 10 avenue Edouard Belin > > - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http://www.isae-supaero.fr > > Tel+33 5 61 33 84 85 - Fax(+33) 5 61 33 83 30 > > > > > > -- > Emmanuel LOCHIN > Professeur ISAE > ISAE SUPAERO - Institut Suprieur de l'Aronautique et de l'Espace > 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - > http://www.isae-supaero.fr > Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 > Web : http://personnel.isae.fr/emmanuel-lochin/ > From nobody Mon Mar 12 23:43:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C69126DFF; Mon, 12 Mar 2018 23:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pjzo5hCnCC8; Mon, 12 Mar 2018 23:43:30 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 F1FC1126DCA; Mon, 12 Mar 2018 23:43:29 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z184so12709978qkc.1; Mon, 12 Mar 2018 23:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pfCUUGQ7Ngq5CS0bbjmrzdqS4iHFNOkLyFSy4kpqF60=; b=EgMnulmOZkl5I4YcAKhgpsPi9OuGirG7Rq/wvMJYWhVWBUxF1lDzZNGK8Fs033Yv99 mAjxO6KX7TKs4TiRt7I3mcdzv37ixfpJ+I9H3xYP3GWanCyq1C5vQykiaK8eLaStWAsu le7GI7CSCff4NWVf2/I+YDiAeN/nE9RvKgWwZbtEjiWa2g1BR19AgxsJXa9f+py1on5l YUKZC7nYXovgbvER4IywIkv9bV1Kr8I8JZJ/cvkGbJhAqyECcYJOFEhcMDThvyM59gXq gKpTrZXKGP12pH2W2AyWQyTbgBVq3//YVr1pvGUMS2Oaxq9pD71bqJl5HDYdkqruu8Td ctgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pfCUUGQ7Ngq5CS0bbjmrzdqS4iHFNOkLyFSy4kpqF60=; b=oAd1wsumQC2N32b7pz9zQk36DyMCfOfAeoLF4m62lTx1cU6SLj5LrnfX6aUhOj/xyp D9obIkMRBPdnax6dwOspmebzG8V4fQaD94fizIUiRWWG3rQfzzeULuAZ6zMO3QP9cfdf I8onfvjEzRHWqHFWAGbY3q21rkSAI0hj68O61JDkCnU0SrlLhJziaxFdHoTWZseCm5VY hwb32aqcELWYNdNF58Azeuci+GtMlUEgaMAaEjWGI7ab9d2fwC7krtpbqYKbj9E/AMce 5zRdvMN/OXRe3u5yDG27MYCScnFl5g2+shZLXzCqommMMng4bmCpEOvhakWs1dRlmQU5 j7zw== X-Gm-Message-State: AElRT7FczBqssqeHnc5uezXzJ2hqLnWPSO6nzysQAS+4Ty0Di1OutHGU S5kNkCj9TjNZ7PfAVrzmhEEknr3qr+QjA9xGkA== X-Google-Smtp-Source: AG47ELs4Cn+lTJE59UnQ8j7hgYSgw5t5oKn/9OfiYUxy/5a/346OhADcLbbxY+3jJKbq5CmCPJy4tlCGns4Sym1xdus= X-Received: by 10.55.64.21 with SMTP id n21mr15668858qka.186.1520923409060; Mon, 12 Mar 2018 23:43:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.60.123 with HTTP; Mon, 12 Mar 2018 23:43:28 -0700 (PDT) In-Reply-To: References: <5A9BEB65.6010102@erg.abdn.ac.uk> From: Yingzhen Qu Date: Mon, 12 Mar 2018 23:43:28 -0700 Message-ID: To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: "gorry@erg.abdn.ac.uk" , Thomas Nadeau , "tcpm@ietf.org" , Yingzhen Qu , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a114e528687167c056745930c" Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 06:43:33 -0000 --001a114e528687167c056745930c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, Sorry for the late response. Thanks for pointing out that we missed this important reference. You're right, Quick-Start and our proposal do have lots of similarities, for example both of them require that end-points and routers to work together. But they are also different in details. For example, in our proposal in-band signaling proposal bandwidth is reserved on routers along the path. In next version of this draft, We'll add discussions about RFC 4728 and 6077. BTW, can I request a slot to present this draft in TCPM if time allows? Thanks, Yingzhen On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - DE/Stuttgart) < michael.scharf@nokia.com> wrote: > I believe that this proposal is similar to QuickStart TCP (RFC 4782), > which is not cited in draft-han-tsvwg-cc, and the reference is also missi= ng > in draft-han-6man-in-band-signaling-for-transport-qos. > > > > RFC 6077 explains some of the issues that an in-band signaling mechanism > like Quick-Start has to solve. As far as I can tell, the fundamental > challenge is neither the protocol specification nor a prototype > implementation. For instance, it has been proven that QuickStart TCP can = be > implemented e.g. in network processors (see http://www.ikr.uni-stuttgart. > de/Content/Publications/Archive/Sf_Diss_40112.pdf). > > > > So, when updating the documents, I suggest to add a discussion of how the > open research issues explained in RFC 6077 are addressed. > > > > Michael > > > > > > *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com] > *Sent:* Sunday, March 04, 2018 9:59 PM > *To:* gorry@erg.abdn.ac.uk > *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) ; > Thomas Nadeau ; tcpm@ietf.org; Yingzhen Qu < > yingzhen.qu@huawei.com>; tsvwg@ietf.org; tsvwg-chairs@ietf.org > *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 > > > > Hi Gorry and Michael, > > > > Thanks for the suggestion, I'll request a presentation in ICCRG. > Meanwhile, I think since the in-band signaling draft was presented in > TSVWG, if time allows it still makes sense to present this draft in TSVWG= . > > > > The in-band signaling draft covers lots of aspects, and the required > changes include network layer and transport layer. We're working on > updating the draft, and may break it into pieces to fit different WGs. > > > > Your comments and help are very much appreciated. > > > > Thanks, > > Yingzhen > > > > On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst > wrote: > > I am unsure yet what the correct group of people world be to explore a > "Bandwidth Guaranteed Network". The presentation last IETF looked like th= e > work could imply a need for changes proposed to the network layer (using > OAM exchnages) to set the sending rate and make those bandwidth > reservations. In the end, it could result in a protocol quite different = to > TCP, I think this sort of change may possibly have a home in TSVWG - but > first I'd agree with Michaeland would encourage a presentation of the > problem statement in ICCRG to explore the issues. > > Gorry > > On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > > Hi all, > > From the abstract: =E2=80=9C=E2=80=A6This draft proposes a new TCP conges= tion control > algorithm used in bandwidth guaranteed networks. It is an extension to t= he > current TCP standards.=E2=80=9D > > In the IETF, I believe the expertise for this specific document would be > in TCPM, which in CC. If the authors are interested in feedback on the > proposed mechanism, I would recommend to ask TCPM. > > Alternatively, corresponding research could perhaps be performed in the > ICCRG. ICCRG has published RFC 6077 to document some of the open research > issues in this space. > > Michael > > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu > *Sent:* Sunday, March 04, 2018 6:55 AM > *To:* tsvwg@ietf.org; tsvwg-chairs@ietf.org > *Cc:* Thomas Nadeau > *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 > > Dear Chairs, > > A new draft (The draft was suggested by TSVWG @IETF100) was just > submitted, and we=E2=80=99d like to request a time slot to present it @IE= TF101. > > Title:A New Congestion Control in Bandwidth Guaranteed Network > > Presenter: Yingzhen Qu (Huawei) > > Time required (including Q/A): 10 mins > > Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > > If there is any question, please kindly let us know. > > Thanks, > > Yingzhen > > > > > --001a114e528687167c056745930c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,
=C2=A0
Sorry for the late respon= se.=C2=A0

Thanks for pointing out that we missed t= his important reference. You're right, Quick-Start and our proposal do = have lots of similarities, for example both of them require that end-points= and routers to work together. But they are also different in details. For = example, in our proposal in-band signaling proposal bandwidth is reserved o= n routers along the path.

In next version of this = draft, We'll add discussions about RFC 4728 and 6077.

BTW, can I request a slot to present this draft in TCPM if time all= ows?

Thanks,
Yingzhen

On Mon, Mar 5, 2018 at 1= 2:09 AM, Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nok= ia.com> wrote:

I believe that this proposal is similar to QuickStar= t TCP (RFC 4782), which is not cited in draft-han-tsvwg-cc, and the referen= ce is also missing in draft-han-6man-in-band-signaling-for-transport-q= os.

=C2=A0

RFC 6077 explains some of the issues that an in-band= signaling mechanism like Quick-Start has to solve. As far as I can tell, t= he fundamental challenge is neither the protocol specification nor a protot= ype implementation. For instance, it has been proven that QuickStart TCP can be implemented e.g. in network = processors (see http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_D= iss_40112.pdf).

=C2=A0

So, when updating the documents, I suggest to add a = discussion of how the open research issues explained in RFC 6077 are addres= sed.

=C2=A0

Michael

=C2=A0

=C2=A0

From: Yingzhen Qu [mailto:yingzhen.ietf@gmail.com]=
Sent: Sunday, March 04, 2018 9:59 PM
To: gorry@= erg.abdn.ac.uk
Cc: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>; = Thomas Nadeau <tnadeau@lucidvision.com>; tcpm@ietf.org; Yingzhen Qu <yingzhen.qu@huawei.com>; tsvwg@ietf.org; tsvwg-chairs@ietf.org
Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101=

=C2=A0

Hi Gorry and Michael,

=C2=A0

Thanks for the suggestion, I'll request a presen= tation in ICCRG. Meanwhile, I think since the in-band signaling draft was p= resented in TSVWG, if time allows it still makes sense to present this draf= t in TSVWG.=C2=A0

=C2=A0

The in-band signaling draft covers lots of aspects, = and the required changes include network layer and transport layer. We'= re working on updating the draft, and may break it into pieces to fit diffe= rent WGs.

=C2=A0

Your comments and help are very much appreciated.=

=C2=A0

Thanks,

Yingzhen

=C2=A0

On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst <= gorry@erg.abdn.ac= .uk> wrote:

I am unsure yet what the correct group of people wor= ld be to explore a "Bandwidth Guaranteed Network". The presentati= on last IETF looked like the work could imply a need for changes proposed t= o the network layer (using OAM exchnages) to set the sending rate and make those bandwidth reservations.=C2=A0 In the e= nd, it could result in a protocol quite different to TCP, I think this sort= of change may possibly have a home in TSVWG=C2=A0 - but first I'd agre= e with Michaeland would encourage a presentation of the problem statement in ICCRG to explore the issues.

Gorry

On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote:<= u>


Hi all,

>From the abstract: =E2=80=9C=E2=80=A6This draft proposes a new TCP congesti= on control algorithm used in bandwidth guaranteed networks.=C2=A0 It is an = extension to the current TCP standards.=E2=80=9D

In the IETF, I believe the expertise for this specific document would be in= TCPM, which in CC. If the authors are interested in feedback on the propos= ed mechanism, I would recommend to ask TCPM.

Alternatively, corresponding research could perhaps be performed in the ICC= RG. ICCRG has published RFC 6077 to document some of the open research issu= es in this space.

Michael

*From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu
*Sent:* Sunday, March 04, 2018 6:55 AM
*To:* tsvwg@ietf.org; tsvwg-chairs@ietf.org
*Cc:* Thomas Nadeau <tnadeau@lucidvision.com>
*Subject:* [tsvwg] Agenda requests for TSVWG@IETF101

Dear Chairs,

A new draft (The draft was suggested by TSVWG @IETF100) was just submitted,= and we=E2=80=99d like to request a time slot to present it @IETF101.

Title:A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/

If there is any question, please kindly let us know.

Thanks,

Yingzhen

=C2=A0

=C2=A0


--001a114e528687167c056745930c-- From nobody Tue Mar 13 02:39:45 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E027812D7FC; Tue, 13 Mar 2018 02:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BduBsR4tgPnn; Tue, 13 Mar 2018 02:39:35 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDEF12D86A; Tue, 13 Mar 2018 02:39:35 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 31C0E1B00081; Tue, 13 Mar 2018 09:38:55 +0000 (GMT) Message-ID: <5AA79C2E.1040808@erg.abdn.ac.uk> Date: Tue, 13 Mar 2018 09:38:54 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Katsushi Kobayashi CC: Yingzhen Qu , "Scharf, Michael (Nokia - DE/Stuttgart)" , Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , Yingzhen Qu References: <5A9BEB65.6010102@erg.abdn.ac.uk> <050065D2-5F2E-4E79-9BD1-E1DC03F13900@acm.org> In-Reply-To: <050065D2-5F2E-4E79-9BD1-E1DC03F13900@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 09:39:39 -0000 Maybe I'm saying what is obvious, but to be sure: The way I see QS is: - The router tracks the unutilised link capacity at the current time, and uses this as some estimate of what may be available to new flows in the near future. - The router responds to QS requests and can accept them if there is "unutilised capacity" remaining. - When accepted router updates it's count of the total unutilised capacity reducing by the accepted QS requests. (i.e., Subsequent QS requests in the same interval will currently have a smaller pool of unutilised capacity available). - After the end of the interval all "QS requests" expire and the router again makes a measure of the unutilised capacity at the current time. None of this implies a "reservation" of link resource in my thinking. In QS, the whole link capacity is intended to be shared using congestion control, and if flows start to send more using normal CC within the interval where QS is operating, they would simply receive a larger share of the capacity. That is: QS request didn't "allocate" any link resource. Gorry On 13/03/2018, 06:58, Katsushi Kobayashi wrote: > Hi, > > I think TCP QS router on the path also reserves bandwidth resource, > if it accepts a request. > > RFC4782 says: > If the router approves the Quick-Start Request, this approval SHOULD > be taken into account in the router's decision to accept or reject > subsequent Quick-Start Requests (e.g., using a variable that tracks > the recent aggregate of accepted Quick-Start Requests). > > > --- > Katsushi Kobayashi > >> 2018/03/13 午後3:43、Yingzhen Qu > > のメール: >> >> Hi Michael, >> Sorry for the late response. >> >> Thanks for pointing out that we missed this important reference. >> You're right, Quick-Start and our proposal do have lots of >> similarities, for example both of them require that end-points and >> routers to work together. But they are also different in details. For >> example, in our proposal in-band signaling proposal bandwidth is >> reserved on routers along the path. >> >> In next version of this draft, We'll add discussions about RFC 4728 >> and 6077. >> >> BTW, can I request a slot to present this draft in TCPM if time allows? >> >> Thanks, >> Yingzhen >> >> On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - >> DE/Stuttgart) > > wrote: >> >> I believe that this proposal is similar to QuickStart TCP (RFC >> 4782), which is not cited in draft-han-tsvwg-cc, and the >> reference is also missing in >> draft-han-6man-in-band-signaling-for-transport-qos. >> >> RFC 6077 explains some of the issues that an in-band signaling >> mechanism like Quick-Start has to solve. As far as I can tell, >> the fundamental challenge is neither the protocol specification >> nor a prototype implementation. For instance, it has been proven >> that QuickStart TCP can be implemented e.g. in network processors >> (see >> http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf >> ). >> >> So, when updating the documents, I suggest to add a discussion of >> how the open research issues explained in RFC 6077 are addressed. >> >> Michael >> >> *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com >> ] >> *Sent:* Sunday, March 04, 2018 9:59 PM >> *To:* gorry@erg.abdn.ac.uk >> *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) >> >; >> Thomas Nadeau > >; tcpm@ietf.org >> ; Yingzhen Qu > >; tsvwg@ietf.org >> ; tsvwg-chairs@ietf.org >> >> *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 >> >> Hi Gorry and Michael, >> >> Thanks for the suggestion, I'll request a presentation in ICCRG. >> Meanwhile, I think since the in-band signaling draft was >> presented in TSVWG, if time allows it still makes sense to >> present this draft in TSVWG. >> >> The in-band signaling draft covers lots of aspects, and the >> required changes include network layer and transport layer. We're >> working on updating the draft, and may break it into pieces to >> fit different WGs. >> >> Your comments and help are very much appreciated. >> >> Thanks, >> >> Yingzhen >> >> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst >> > wrote: >> >> I am unsure yet what the correct group of people world be to >> explore a "Bandwidth Guaranteed Network". The presentation >> last IETF looked like the work could imply a need for changes >> proposed to the network layer (using OAM exchnages) to set >> the sending rate and make those bandwidth reservations. In >> the end, it could result in a protocol quite different to >> TCP, I think this sort of change may possibly have a home in >> TSVWG - but first I'd agree with Michaeland would encourage >> a presentation of the problem statement in ICCRG to explore >> the issues. >> >> Gorry >> >> On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) >> wrote: >> >> >> Hi all, >> >> >From the abstract: “…This draft proposes a new TCP >> congestion control algorithm used in bandwidth guaranteed >> networks. It is an extension to the current TCP standards.” >> >> In the IETF, I believe the expertise for this specific >> document would be in TCPM, which in CC. If the authors >> are interested in feedback on the proposed mechanism, I >> would recommend to ask TCPM. >> >> Alternatively, corresponding research could perhaps be >> performed in the ICCRG. ICCRG has published RFC 6077 to >> document some of the open research issues in this space. >> >> Michael >> >> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org >> ] *On Behalf Of *Yingzhen Qu >> *Sent:* Sunday, March 04, 2018 6:55 AM >> *To:* tsvwg@ietf.org ; >> tsvwg-chairs@ietf.org >> *Cc:* Thomas Nadeau > > >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 >> >> Dear Chairs, >> >> A new draft (The draft was suggested by TSVWG @IETF100) >> was just submitted, and we’d like to request a time slot >> to present it @IETF101. >> >> Title:A New Congestion Control in Bandwidth Guaranteed >> Network >> >> Presenter: Yingzhen Qu (Huawei) >> >> Time required (including Q/A): 10 mins >> >> Draft: >> https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ >> >> >> If there is any question, please kindly let us know. >> >> Thanks, >> >> Yingzhen >> >> > From nobody Tue Mar 13 02:45:23 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5875F12D7FC; Tue, 13 Mar 2018 02:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRP72oOC8qxc; Tue, 13 Mar 2018 02:45:15 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E6912D72F; Tue, 13 Mar 2018 02:45:14 -0700 (PDT) Received: from [IPv6:2003:cd:6bea:8000:6010:e1fa:597e:6ad7] (p200300CD6BEA80006010E1FA597E6AD7.dip0.t-ipconnect.de [IPv6:2003:cd:6bea:8000:6010:e1fa:597e:6ad7]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 00F10721E280C; Tue, 13 Mar 2018 10:45:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: Date: Tue, 13 Mar 2018 10:45:09 +0100 Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , Yingzhen Qu Content-Transfer-Encoding: quoted-printable Message-Id: <430A7C48-DA1D-4D73-AB40-F2B30A8E8580@lurchi.franken.de> References: <5A9BEB65.6010102@erg.abdn.ac.uk> To: Yingzhen Qu X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 09:45:18 -0000 > On 13. Mar 2018, at 07:43, Yingzhen Qu = wrote: >=20 > Hi Michael, > =20 > Sorry for the late response.=20 >=20 > Thanks for pointing out that we missed this important reference. = You're right, Quick-Start and our proposal do have lots of similarities, = for example both of them require that end-points and routers to work = together. But they are also different in details. For example, in our = proposal in-band signaling proposal bandwidth is reserved on routers = along the path. >=20 > In next version of this draft, We'll add discussions about RFC 4728 = and 6077. >=20 > BTW, can I request a slot to present this draft in TCPM if time = allows? How much time would you need? Best regards Michael >=20 > Thanks, > Yingzhen >=20 > On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - = DE/Stuttgart) wrote: > I believe that this proposal is similar to QuickStart TCP (RFC 4782), = which is not cited in draft-han-tsvwg-cc, and the reference is also = missing in draft-han-6man-in-band-signaling-for-transport-qos. >=20 > =20 >=20 > RFC 6077 explains some of the issues that an in-band signaling = mechanism like Quick-Start has to solve. As far as I can tell, the = fundamental challenge is neither the protocol specification nor a = prototype implementation. For instance, it has been proven that = QuickStart TCP can be implemented e.g. in network processors (see = http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112= .pdf). >=20 > =20 >=20 > So, when updating the documents, I suggest to add a discussion of how = the open research issues explained in RFC 6077 are addressed. >=20 > =20 >=20 > Michael >=20 > =20 >=20 > =20 >=20 > From: Yingzhen Qu [mailto:yingzhen.ietf@gmail.com]=20 > Sent: Sunday, March 04, 2018 9:59 PM > To: gorry@erg.abdn.ac.uk > Cc: Scharf, Michael (Nokia - DE/Stuttgart) ; = Thomas Nadeau ; tcpm@ietf.org; Yingzhen Qu = ; tsvwg@ietf.org; tsvwg-chairs@ietf.org > Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 >=20 > =20 >=20 > Hi Gorry and Michael, >=20 > =20 >=20 > Thanks for the suggestion, I'll request a presentation in ICCRG. = Meanwhile, I think since the in-band signaling draft was presented in = TSVWG, if time allows it still makes sense to present this draft in = TSVWG.=20 >=20 > =20 >=20 > The in-band signaling draft covers lots of aspects, and the required = changes include network layer and transport layer. We're working on = updating the draft, and may break it into pieces to fit different WGs. >=20 > =20 >=20 > Your comments and help are very much appreciated. >=20 > =20 >=20 > Thanks, >=20 > Yingzhen >=20 > =20 >=20 > On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst = wrote: >=20 > I am unsure yet what the correct group of people world be to explore a = "Bandwidth Guaranteed Network". The presentation last IETF looked like = the work could imply a need for changes proposed to the network layer = (using OAM exchnages) to set the sending rate and make those bandwidth = reservations. In the end, it could result in a protocol quite different = to TCP, I think this sort of change may possibly have a home in TSVWG - = but first I'd agree with Michaeland would encourage a presentation of = the problem statement in ICCRG to explore the issues. >=20 > Gorry >=20 > On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >=20 >=20 > Hi all, >=20 > >=46rom the abstract: =E2=80=9C=E2=80=A6This draft proposes a new TCP = congestion control algorithm used in bandwidth guaranteed networks. It = is an extension to the current TCP standards.=E2=80=9D >=20 > In the IETF, I believe the expertise for this specific document would = be in TCPM, which in CC. If the authors are interested in feedback on = the proposed mechanism, I would recommend to ask TCPM. >=20 > Alternatively, corresponding research could perhaps be performed in = the ICCRG. ICCRG has published RFC 6077 to document some of the open = research issues in this space. >=20 > Michael >=20 > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen = Qu > *Sent:* Sunday, March 04, 2018 6:55 AM > *To:* tsvwg@ietf.org; tsvwg-chairs@ietf.org > *Cc:* Thomas Nadeau > *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 >=20 > Dear Chairs, >=20 > A new draft (The draft was suggested by TSVWG @IETF100) was just = submitted, and we=E2=80=99d like to request a time slot to present it = @IETF101. >=20 > Title:A New Congestion Control in Bandwidth Guaranteed Network >=20 > Presenter: Yingzhen Qu (Huawei) >=20 > Time required (including Q/A): 10 mins >=20 > Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ >=20 > If there is any question, please kindly let us know. >=20 > Thanks, >=20 > Yingzhen >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From shikob@gmail.com Tue Mar 13 03:22:28 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90812D878; Tue, 13 Mar 2018 03:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD8-cWaAe1j4; Tue, 13 Mar 2018 03:22:27 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::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 DC86F12711E; Tue, 13 Mar 2018 03:22:26 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id w12-v6so11047078plp.4; Tue, 13 Mar 2018 03:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M97VC3o7Y3QI3Dyn13dAGsnP6oe51NYoAjHHS0KYJyQ=; b=DMamXygvI+kOHieUMlzMXIcPStTecrrXDlR3QHL4tizRkkRROpq1N+3PXT/T2P0NRk nxvSllmRLEOkhgumwuse23aJoTtkv8e9iqzzMNrQGdkXPtLJMeCkAXL6sl8Y8r6/tUOq D0zIe5xmyO70gPOBGEjaTmP3t3G4RHBYoUOqp8pT1kIQtf5xvhR7B9ktUw1n81qUN0wv Ouhk0ICoCei2rbvHpxCQrHNlGX5ajxaCvU9EZCsBs3ppK+VFkmVH87ITFZklKCnCCFzY JQu/skAQFRu37rfz9a24LjrN9c+yR4LTxs5qJQfHhXdExvpp+dLzP5KWaNNH2G6vEeau 6Ezw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=M97VC3o7Y3QI3Dyn13dAGsnP6oe51NYoAjHHS0KYJyQ=; b=o6J4UtOomzE5mfIBLedJFva6yUWAShFlM2exN4seoS4HRnZk0kCqFOkrMLBMvj5jiY Z1/ioDard7hAh+G3RGqRW/QuzBD9wjxgT0OkD52e+v6+jghr/ZWA6A7dVYBg3QwOyKIh A2/TAKt60DOa5DcYiPZH0BWuge44SG6DXTnsnyJqFhqTefKi4zuj/dtL//EJxwqmqR7r E7KXvbIyaThGiX5KyjEt6vAHjFiy5czQCqfhHe0vxV0y6Rw1ZApcZLWt/Dmhl9yCT/DY no5fpLmfEgJCshcyc+e/pXH91Qt5q9th9Fl2wJbPJYRbGwR+jLd3VEsV9juVke4PQcO9 49/g== X-Gm-Message-State: AElRT7ExdoMYJMOb3nqfgfGc14aE7PAzDNZfZNArCeWtE5JXUeuPONKP 43d3ky2TB/SYPi3NQ7drgDY= X-Google-Smtp-Source: AG47ELt6mk9LxjBMhuGeHi4umaVmXMcGorGM5rJ2kmrTUBIq2O9v16KfpX+CMJIKOsXc1D3SVS2jbQ== X-Received: by 2002:a17:902:5588:: with SMTP id g8-v6mr51224pli.73.1520936546167; Tue, 13 Mar 2018 03:22:26 -0700 (PDT) Received: from [157.82.200.243] ([157.82.200.243]) by smtp.gmail.com with ESMTPSA id x14sm71400pgc.13.2018.03.13.03.22.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 03:22:25 -0700 (PDT) Sender: Katsushi Kobayashi Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Katsushi Kobayashi In-Reply-To: <5AA79C2E.1040808@erg.abdn.ac.uk> Date: Tue, 13 Mar 2018 19:22:21 +0900 Cc: Yingzhen Qu , "Scharf, Michael (Nokia - DE/Stuttgart)" , Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , Yingzhen Qu Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A9BEB65.6010102@erg.abdn.ac.uk> <050065D2-5F2E-4E79-9BD1-E1DC03F13900@acm.org> <5AA79C2E.1040808@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 10:28:42 -0000 Gorry,=20 Thank you for clarification. I completely agree with you in terns of bandwidth resource reservation. --- Katsushi Kobayashi > 2018/03/13 =E5=8D=88=E5=BE=8C6:38=E3=80=81Gorry Fairhurst = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > Maybe I'm saying what is obvious, but to be sure: >=20 > The way I see QS is: > - The router tracks the unutilised link capacity at the current time, = and uses this as some estimate of what may be available to new flows in = the near future. > - The router responds to QS requests and can accept them if there is = "unutilised capacity" remaining. > - When accepted router updates it's count of the total unutilised = capacity reducing by the accepted QS requests. (i.e., Subsequent QS = requests in the same interval will currently have a smaller pool of = unutilised capacity available). > - After the end of the interval all "QS requests" expire and the = router again makes a measure of the unutilised capacity at the current = time. >=20 > None of this implies a "reservation" of link resource in my thinking. = In QS, the whole link capacity is intended to be shared using congestion = control, and if flows start to send more using normal CC within the = interval where QS is operating, they would simply receive a larger share = of the capacity. That is: QS request didn't "allocate" any link = resource. >=20 > Gorry >=20 >=20 > On 13/03/2018, 06:58, Katsushi Kobayashi wrote: >> Hi, >>=20 >> I think TCP QS router on the path also reserves bandwidth resource, >> if it accepts a request. >>=20 >> RFC4782 says: >> If the router approves the Quick-Start Request, this approval = SHOULD >> be taken into account in the router's decision to accept or reject >> subsequent Quick-Start Requests (e.g., using a variable that tracks >> the recent aggregate of accepted Quick-Start Requests). >>=20 >>=20 >> --- >> Katsushi Kobayashi >>=20 >>> 2018/03/13 =E5=8D=88=E5=BE=8C3:43=E3=80=81Yingzhen Qu = > =E3=81=AE=E3=83= =A1=E3=83=BC=E3=83=AB: >>>=20 >>> Hi Michael, >>> Sorry for the late response. >>>=20 >>> Thanks for pointing out that we missed this important reference. = You're right, Quick-Start and our proposal do have lots of similarities, = for example both of them require that end-points and routers to work = together. But they are also different in details. For example, in our = proposal in-band signaling proposal bandwidth is reserved on routers = along the path. >>>=20 >>> In next version of this draft, We'll add discussions about RFC 4728 = and 6077. >>>=20 >>> BTW, can I request a slot to present this draft in TCPM if time = allows? >>>=20 >>> Thanks, >>> Yingzhen >>>=20 >>> On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - = DE/Stuttgart) > wrote: >>>=20 >>> I believe that this proposal is similar to QuickStart TCP (RFC >>> 4782), which is not cited in draft-han-tsvwg-cc, and the >>> reference is also missing in >>> draft-han-6man-in-band-signaling-for-transport-qos. >>>=20 >>> RFC 6077 explains some of the issues that an in-band signaling >>> mechanism like Quick-Start has to solve. As far as I can tell, >>> the fundamental challenge is neither the protocol specification >>> nor a prototype implementation. For instance, it has been proven >>> that QuickStart TCP can be implemented e.g. in network processors >>> (see >>> = http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112= .pdf >>> = ). >>>=20 >>> So, when updating the documents, I suggest to add a discussion of >>> how the open research issues explained in RFC 6077 are addressed. >>>=20 >>> Michael >>>=20 >>> *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com >>> ] >>> *Sent:* Sunday, March 04, 2018 9:59 PM >>> *To:* gorry@erg.abdn.ac.uk >>> *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) >>> >; >>> Thomas Nadeau >> >; tcpm@ietf.org >>> ; Yingzhen Qu >> >; tsvwg@ietf.org >>> ; tsvwg-chairs@ietf.org >>> >>> *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 >>>=20 >>> Hi Gorry and Michael, >>>=20 >>> Thanks for the suggestion, I'll request a presentation in ICCRG. >>> Meanwhile, I think since the in-band signaling draft was >>> presented in TSVWG, if time allows it still makes sense to >>> present this draft in TSVWG. >>>=20 >>> The in-band signaling draft covers lots of aspects, and the >>> required changes include network layer and transport layer. We're >>> working on updating the draft, and may break it into pieces to >>> fit different WGs. >>>=20 >>> Your comments and help are very much appreciated. >>>=20 >>> Thanks, >>>=20 >>> Yingzhen >>>=20 >>> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst >>> > wrote: >>>=20 >>> I am unsure yet what the correct group of people world be to >>> explore a "Bandwidth Guaranteed Network". The presentation >>> last IETF looked like the work could imply a need for changes >>> proposed to the network layer (using OAM exchnages) to set >>> the sending rate and make those bandwidth reservations. In >>> the end, it could result in a protocol quite different to >>> TCP, I think this sort of change may possibly have a home in >>> TSVWG - but first I'd agree with Michaeland would encourage >>> a presentation of the problem statement in ICCRG to explore >>> the issues. >>>=20 >>> Gorry >>>=20 >>> On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) >>> wrote: >>>=20 >>>=20 >>> Hi all, >>>=20 >>> >=46rom the abstract: =E2=80=9C=E2=80=A6This draft = proposes a new TCP >>> congestion control algorithm used in bandwidth guaranteed >>> networks. It is an extension to the current TCP = standards.=E2=80=9D >>>=20 >>> In the IETF, I believe the expertise for this specific >>> document would be in TCPM, which in CC. If the authors >>> are interested in feedback on the proposed mechanism, I >>> would recommend to ask TCPM. >>>=20 >>> Alternatively, corresponding research could perhaps be >>> performed in the ICCRG. ICCRG has published RFC 6077 to >>> document some of the open research issues in this space. >>>=20 >>> Michael >>>=20 >>> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org >>> ] *On Behalf Of *Yingzhen = Qu >>> *Sent:* Sunday, March 04, 2018 6:55 AM >>> *To:* tsvwg@ietf.org ; >>> tsvwg-chairs@ietf.org >>> *Cc:* Thomas Nadeau >> > >>> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 >>>=20 >>> Dear Chairs, >>>=20 >>> A new draft (The draft was suggested by TSVWG @IETF100) >>> was just submitted, and we=E2=80=99d like to request a = time slot >>> to present it @IETF101. >>>=20 >>> Title:A New Congestion Control in Bandwidth Guaranteed >>> Network >>>=20 >>> Presenter: Yingzhen Qu (Huawei) >>>=20 >>> Time required (including Q/A): 10 mins >>>=20 >>> Draft: >>> https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ >>> >>>=20 >>> If there is any question, please kindly let us know. >>>=20 >>> Thanks, >>>=20 >>> Yingzhen >>>=20 >>>=20 >>=20 >=20 From nobody Tue Mar 13 09:49:49 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562BE124D37; Tue, 13 Mar 2018 09:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir6wnE2XEzvx; Tue, 13 Mar 2018 09:49:39 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644241275FD; Tue, 13 Mar 2018 09:49:33 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 477FE58C50D; Tue, 13 Mar 2018 17:49:28 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2DDE3B0DD00; Tue, 13 Mar 2018 17:49:28 +0100 (CET) Date: Tue, 13 Mar 2018 17:49:28 +0100 From: Toerless Eckert To: Gorry Fairhurst Cc: Katsushi Kobayashi , Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tsvwg-chairs@ietf.org" , Yingzhen Qu Message-ID: <20180313164928.GA17042@faui40p.informatik.uni-erlangen.de> References: <5A9BEB65.6010102@erg.abdn.ac.uk> <050065D2-5F2E-4E79-9BD1-E1DC03F13900@acm.org> <5AA79C2E.1040808@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5AA79C2E.1040808@erg.abdn.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 16:49:42 -0000 Thanks, Gory, nice explanation TCP Quickstart is rfc4782 btw. i think there was a buggy number in the thread. TCP quickstart really relates IMHO primarily to draft-han-6man-in-band-signaling-for-transport-qos, but not to draft-han-tsvwg-cc. The latter one is really meant to modify TCP assuming a known guaranteed CIR - whatever mechanism is used to provide that guarantee. TCP quickstart is an interesting example for inband signaling, which is what Lin's in-band-signaling draft does too. The main difference is that our draft focusses on high-value traffic where per-flow state is feasible and beneficial, if not necessary. And TCP quickstart seems more targeted to ANY TCP flow. Which raises a complete different scalability challenge to TCP quickstart. This type of comparison discussion will go into draft updates on our side. Would be interested in any more data points about the history of TCP quickstart, eg: where it was observed in the wild in deployments. Cheers Toerless On Tue, Mar 13, 2018 at 09:38:54AM +0000, Gorry Fairhurst wrote: > Maybe I'm saying what is obvious, but to be sure: > > The way I see QS is: > - The router tracks the unutilised link capacity at the current > time, and uses this as some estimate of what may be available to new > flows in the near future. > - The router responds to QS requests and can accept them if there is > "unutilised capacity" remaining. > - When accepted router updates it's count of the total unutilised > capacity reducing by the accepted QS requests. (i.e., Subsequent QS > requests in the same interval will currently have a smaller pool of > unutilised capacity available). > - After the end of the interval all "QS requests" expire and the > router again makes a measure of the unutilised capacity at the > current time. > > None of this implies a "reservation" of link resource in my > thinking. In QS, the whole link capacity is intended to be shared > using congestion control, and if flows start to send more using > normal CC within the interval where QS is operating, they would > simply receive a larger share of the capacity. That is: QS request > didn't "allocate" any link resource. > > Gorry > > > On 13/03/2018, 06:58, Katsushi Kobayashi wrote: > >Hi, > > > >I think TCP QS router on the path also reserves bandwidth resource, > >if it accepts a request. > > > >RFC4782 says: > > If the router approves the Quick-Start Request, this approval SHOULD > > be taken into account in the router's decision to accept or reject > > subsequent Quick-Start Requests (e.g., using a variable that tracks > > the recent aggregate of accepted Quick-Start Requests). > > > > > >--- > >Katsushi Kobayashi > > > >>2018/03/13 ??????3:43???Yingzhen Qu >>> ????????????: > >> > >>Hi Michael, > >>Sorry for the late response. > >> > >>Thanks for pointing out that we missed this important reference. > >>You're right, Quick-Start and our proposal do have lots of > >>similarities, for example both of them require that end-points > >>and routers to work together. But they are also different in > >>details. For example, in our proposal in-band signaling proposal > >>bandwidth is reserved on routers along the path. > >> > >>In next version of this draft, We'll add discussions about RFC > >>4728 and 6077. > >> > >>BTW, can I request a slot to present this draft in TCPM if time allows? > >> > >>Thanks, > >>Yingzhen > >> > >>On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - > >>DE/Stuttgart) >>> wrote: > >> > >> I believe that this proposal is similar to QuickStart TCP (RFC > >> 4782), which is not cited in draft-han-tsvwg-cc, and the > >> reference is also missing in > >> draft-han-6man-in-band-signaling-for-transport-qos. > >> > >> RFC 6077 explains some of the issues that an in-band signaling > >> mechanism like Quick-Start has to solve. As far as I can tell, > >> the fundamental challenge is neither the protocol specification > >> nor a prototype implementation. For instance, it has been proven > >> that QuickStart TCP can be implemented e.g. in network processors > >> (see > >> http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf > >> ). > >> > >> So, when updating the documents, I suggest to add a discussion of > >> how the open research issues explained in RFC 6077 are addressed. > >> > >> Michael > >> > >> *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com > >> ] > >> *Sent:* Sunday, March 04, 2018 9:59 PM > >> *To:* gorry@erg.abdn.ac.uk > >> *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) > >> >; > >> Thomas Nadeau >> >; tcpm@ietf.org > >> ; Yingzhen Qu >> >; tsvwg@ietf.org > >> ; tsvwg-chairs@ietf.org > >> > >> *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 > >> > >> Hi Gorry and Michael, > >> > >> Thanks for the suggestion, I'll request a presentation in ICCRG. > >> Meanwhile, I think since the in-band signaling draft was > >> presented in TSVWG, if time allows it still makes sense to > >> present this draft in TSVWG. > >> > >> The in-band signaling draft covers lots of aspects, and the > >> required changes include network layer and transport layer. We're > >> working on updating the draft, and may break it into pieces to > >> fit different WGs. > >> > >> Your comments and help are very much appreciated. > >> > >> Thanks, > >> > >> Yingzhen > >> > >> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst > >> > wrote: > >> > >> I am unsure yet what the correct group of people world be to > >> explore a "Bandwidth Guaranteed Network". The presentation > >> last IETF looked like the work could imply a need for changes > >> proposed to the network layer (using OAM exchnages) to set > >> the sending rate and make those bandwidth reservations. In > >> the end, it could result in a protocol quite different to > >> TCP, I think this sort of change may possibly have a home in > >> TSVWG - but first I'd agree with Michaeland would encourage > >> a presentation of the problem statement in ICCRG to explore > >> the issues. > >> > >> Gorry > >> > >> On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) > >> wrote: > >> > >> > >> Hi all, > >> > >> >From the abstract: ??????This draft proposes a new TCP > >> congestion control algorithm used in bandwidth guaranteed > >> networks. It is an extension to the current TCP standards.??? > >> > >> In the IETF, I believe the expertise for this specific > >> document would be in TCPM, which in CC. If the authors > >> are interested in feedback on the proposed mechanism, I > >> would recommend to ask TCPM. > >> > >> Alternatively, corresponding research could perhaps be > >> performed in the ICCRG. ICCRG has published RFC 6077 to > >> document some of the open research issues in this space. > >> > >> Michael > >> > >> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org > >> ] *On Behalf Of *Yingzhen Qu > >> *Sent:* Sunday, March 04, 2018 6:55 AM > >> *To:* tsvwg@ietf.org ; > >> tsvwg-chairs@ietf.org > >> *Cc:* Thomas Nadeau >> > > >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 > >> > >> Dear Chairs, > >> > >> A new draft (The draft was suggested by TSVWG @IETF100) > >> was just submitted, and we???d like to request a time slot > >> to present it @IETF101. > >> > >> Title:A New Congestion Control in Bandwidth Guaranteed > >> Network > >> > >> Presenter: Yingzhen Qu (Huawei) > >> > >> Time required (including Q/A): 10 mins > >> > >> Draft: > >> https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > >> > >> > >> If there is any question, please kindly let us know. > >> > >> Thanks, > >> > >> Yingzhen > >> > >> > > -- --- tte@cs.fau.de From nobody Tue Mar 13 12:27:35 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1053E12D7E5; Tue, 13 Mar 2018 12:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLyB4yi8eHe7; Tue, 13 Mar 2018 12:27:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 EFA96129C56; Tue, 13 Mar 2018 12:27:30 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AA20B674D50A2; Tue, 13 Mar 2018 19:27:26 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 13 Mar 2018 19:27:28 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 12:27:19 -0700 From: Lin Han To: Toerless Eckert , Gorry Fairhurst CC: Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tsvwg-chairs@ietf.org" , Katsushi Kobayashi , Yingzhen Qu Thread-Topic: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) Thread-Index: AQHTuwFM3r3WTfYLEkqWf3ecaDUj6g== Date: Tue, 13 Mar 2018 19:27:18 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CDB9BA3@sjceml521-mbs.china.huawei.com> References: <5A9BEB65.6010102@erg.abdn.ac.uk> <050065D2-5F2E-4E79-9BD1-E1DC03F13900@acm.org> <5AA79C2E.1040808@erg.abdn.ac.uk> <20180313164928.GA17042@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180313164928.GA17042@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 19:27:34 -0000 Hi, Gorry/Toerless Here is some explanation and clarification for two drafts (draft-han-tsvwg-= cc and draft-han-6man-in-band-signaling-for-transport-qos) 1. About draft-han-tsvwg-cc compared with other CC for bandwidth guaranteed= network, such as gTFRC. draft-han-tsvwg-cc is a split draft from draft-han-6man-in-band-signaling-f= or-transport-qos . It proposes a new CC for a network if the TCP session's = bandwidth is guaranteed. Here the guaranteed bandwidth is per TCP session = and described by PIR/CIR and given directly by TCP end user.=20 2. About TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos >From my understanding, TCP-QS and draft-han-6man-in-band-signaling-for-tran= sport-qos do have similarity, both are kind of using in-band signaling for = the resource reservation. But they still have big difference. 1). draft-han-6man-in-band-signaling-for-transport-qos is more general in-b= and signaling method, it not only applies to TCP, but also UDP or other upp= er layer of protocol, even the draft only exemplifies the method to TCP. 2). draft-han-6man-in-band-signaling-for-transport-qos provides reserved re= source for bandwidth and latency for the whole life of TCP session. It give= s more flavors and more granularity for the QoS (unlike TCP-QS only has 16 = values of starting bandwidth). Moreover, it can support the "worst case lat= ency" at each hop; also, it can support the OAM to detect the congestion st= ates, and support the "forwarding state" for host to be notified in real-ti= me about if the resource reservation or QoS forwarding is interrupted by ab= normal situation such as link/node failures. Best regards Lin -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Toerless Eckert Sent: Tuesday, March 13, 2018 9:49 AM To: Gorry Fairhurst Cc: Thomas Nadeau ; tcpm@ietf.org; tsvwg@ietf.org;= Scharf, Michael (Nokia - DE/Stuttgart) ; tsvwg-c= hairs@ietf.org; Katsushi Kobayashi ; Yingzhen Qu Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@I= ETF101) Thanks, Gory, nice explanation TCP Quickstart is rfc4782 btw. i think there was a buggy number in the thre= ad. TCP quickstart really relates IMHO primarily to draft-han-6man-in-band-sign= aling-for-transport-qos, but not to draft-han-tsvwg-cc. The latter one is r= eally meant to modify TCP assuming a known guaranteed CIR - whatever mechan= ism is used to provide that guarantee. TCP quickstart is an interesting example for inband signaling, which is wha= t Lin's in-band-signaling draft does too. The main difference is that our d= raft focusses on high-value traffic where per-flow state is feasible and be= neficial, if not necessary. And TCP quickstart seems more targeted to ANY T= CP flow. Which raises a complete different scalability challenge to TCP qui= ckstart. This type of comparison discussion will go into draft updates on our side. Would be interested in any more data points about the history of TCP quicks= tart, eg: where it was observed in the wild in deployments. Cheers Toerless On Tue, Mar 13, 2018 at 09:38:54AM +0000, Gorry Fairhurst wrote: > Maybe I'm saying what is obvious, but to be sure: >=20 > The way I see QS is: > - The router tracks the unutilised link capacity at the current time,=20 > and uses this as some estimate of what may be available to new flows=20 > in the near future. > - The router responds to QS requests and can accept them if there is=20 > "unutilised capacity" remaining. > - When accepted router updates it's count of the total unutilised=20 > capacity reducing by the accepted QS requests. (i.e., Subsequent QS=20 > requests in the same interval will currently have a smaller pool of=20 > unutilised capacity available). > - After the end of the interval all "QS requests" expire and the=20 > router again makes a measure of the unutilised capacity at the current=20 > time. >=20 > None of this implies a "reservation" of link resource in my thinking.=20 > In QS, the whole link capacity is intended to be shared using=20 > congestion control, and if flows start to send more using normal CC=20 > within the interval where QS is operating, they would simply receive a=20 > larger share of the capacity. That is: QS request didn't "allocate"=20 > any link resource. >=20 > Gorry >=20 >=20 > On 13/03/2018, 06:58, Katsushi Kobayashi wrote: > >Hi, > > > >I think TCP QS router on the path also reserves bandwidth resource,=20 > >if it accepts a request. > > > >RFC4782 says: > > If the router approves the Quick-Start Request, this approval SHOULD > > be taken into account in the router's decision to accept or reject > > subsequent Quick-Start Requests (e.g., using a variable that tracks > > the recent aggregate of accepted Quick-Start Requests). > > > > > >--- > >Katsushi Kobayashi > > > >>2018/03/13 ??????3:43???Yingzhen Qu >>> ????????????: > >> > >>Hi Michael, > >>Sorry for the late response. > >> > >>Thanks for pointing out that we missed this important reference. > >>You're right, Quick-Start and our proposal do have lots of=20 > >>similarities, for example both of them require that end-points and=20 > >>routers to work together. But they are also different in details.=20 > >>For example, in our proposal in-band signaling proposal bandwidth is=20 > >>reserved on routers along the path. > >> > >>In next version of this draft, We'll add discussions about RFC > >>4728 and 6077. > >> > >>BTW, can I request a slot to present this draft in TCPM if time allows? > >> > >>Thanks, > >>Yingzhen > >> > >>On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - > >>DE/Stuttgart) >>> wrote: > >> > >> I believe that this proposal is similar to QuickStart TCP (RFC > >> 4782), which is not cited in draft-han-tsvwg-cc, and the > >> reference is also missing in > >> draft-han-6man-in-band-signaling-for-transport-qos. > >> > >> RFC 6077 explains some of the issues that an in-band signaling > >> mechanism like Quick-Start has to solve. As far as I can tell, > >> the fundamental challenge is neither the protocol specification > >> nor a prototype implementation. For instance, it has been proven > >> that QuickStart TCP can be implemented e.g. in network processors > >> (see > >> http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Dis= s_40112.pdf > >> ). > >> > >> So, when updating the documents, I suggest to add a discussion of > >> how the open research issues explained in RFC 6077 are addressed. > >> > >> Michael > >> > >> *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com > >> ] > >> *Sent:* Sunday, March 04, 2018 9:59 PM > >> *To:* gorry@erg.abdn.ac.uk > >> *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) > >> >; > >> Thomas Nadeau >> >; tcpm@ietf.org > >> ; Yingzhen Qu >> >; tsvwg@ietf.org > >> ; tsvwg-chairs@ietf.org > >> > >> *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 > >> > >> Hi Gorry and Michael, > >> > >> Thanks for the suggestion, I'll request a presentation in ICCRG. > >> Meanwhile, I think since the in-band signaling draft was > >> presented in TSVWG, if time allows it still makes sense to > >> present this draft in TSVWG. > >> > >> The in-band signaling draft covers lots of aspects, and the > >> required changes include network layer and transport layer. We're > >> working on updating the draft, and may break it into pieces to > >> fit different WGs. > >> > >> Your comments and help are very much appreciated. > >> > >> Thanks, > >> > >> Yingzhen > >> > >> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst > >> > wrote: > >> > >> I am unsure yet what the correct group of people world be to > >> explore a "Bandwidth Guaranteed Network". The presentation > >> last IETF looked like the work could imply a need for changes > >> proposed to the network layer (using OAM exchnages) to set > >> the sending rate and make those bandwidth reservations. In > >> the end, it could result in a protocol quite different to > >> TCP, I think this sort of change may possibly have a home in > >> TSVWG - but first I'd agree with Michaeland would encourage > >> a presentation of the problem statement in ICCRG to explore > >> the issues. > >> > >> Gorry > >> > >> On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) > >> wrote: > >> > >> > >> Hi all, > >> > >> >From the abstract: ??????This draft proposes a new TCP > >> congestion control algorithm used in bandwidth guaranteed > >> networks. It is an extension to the current TCP standards.= ??? > >> > >> In the IETF, I believe the expertise for this specific > >> document would be in TCPM, which in CC. If the authors > >> are interested in feedback on the proposed mechanism, I > >> would recommend to ask TCPM. > >> > >> Alternatively, corresponding research could perhaps be > >> performed in the ICCRG. ICCRG has published RFC 6077 to > >> document some of the open research issues in this space. > >> > >> Michael > >> > >> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org > >> ] *On Behalf Of *Yingzhen Qu > >> *Sent:* Sunday, March 04, 2018 6:55 AM > >> *To:* tsvwg@ietf.org ; > >> tsvwg-chairs@ietf.org > >> *Cc:* Thomas Nadeau >> > > >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 > >> > >> Dear Chairs, > >> > >> A new draft (The draft was suggested by TSVWG @IETF100) > >> was just submitted, and we???d like to request a time slot > >> to present it @IETF101. > >> > >> Title:A New Congestion Control in Bandwidth Guaranteed > >> Network > >> > >> Presenter: Yingzhen Qu (Huawei) > >> > >> Time required (including Q/A): 10 mins > >> > >> Draft: > >> https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > >> > >> > >> If there is any question, please kindly let us know. > >> > >> Thanks, > >> > >> Yingzhen > >> > >> > > -- --- tte@cs.fau.de From nobody Tue Mar 13 14:17:51 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCC126CF6; Tue, 13 Mar 2018 14:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfQVGUylVnXf; Tue, 13 Mar 2018 14:17:45 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7472126CD6; Tue, 13 Mar 2018 14:17:44 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 82B7B58C538; Tue, 13 Mar 2018 22:17:39 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6B790B0DD05; Tue, 13 Mar 2018 22:17:39 +0100 (CET) Date: Tue, 13 Mar 2018 22:17:39 +0100 From: Toerless Eckert To: Lin Han Cc: Gorry Fairhurst , Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tsvwg-chairs@ietf.org" , Katsushi Kobayashi , Yingzhen Qu Message-ID: <20180313211739.GA19333@faui40p.informatik.uni-erlangen.de> References: <5A9BEB65.6010102@erg.abdn.ac.uk> <050065D2-5F2E-4E79-9BD1-E1DC03F13900@acm.org> <5AA79C2E.1040808@erg.abdn.ac.uk> <20180313164928.GA17042@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CDB9BA3@sjceml521-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162CDB9BA3@sjceml521-mbs.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 21:17:49 -0000 Thanks, Lin Let me also try another angle of comparison: Having worked on RSVP for a long time, your inband signaling draft is IMHO very easy to vet - lightweight inband signaling, replacing/simplifying/scaling the Intserv QoS model model for deterministic services. I think inband signaling could really be the antidote for what i would call the IETFs intserv "second system syndrom" trauma from NSIS and many ever more complex RSVP extensions never deployed. Compared to the work on inband signaling for DiffServ, i think we did not really have good attempts to do it for intserv. And ultimately, DiffServ inband signaling has been quite successful, and we also understand the dynamics needed to deploy it in various type of networks. last but not least ECN in the Internet. In fact, i think we are seeing with DiffServ a lot more difficult experiments, struggling with the complexities of control loops. TCP-QS is a great example: How do you even try to optimize in the real world a control loop with N-nodes on the path using their own "likely-best-useable-free-bandwidth" prediction based on a local algorithm ? I also did not see in the TCP-QS docs references to the impact of TCP behavior, (bursts), but its clear that the result will be different with most-bursty (classic TCP CC), DV, or even rate predictive (BBR etc.). How long are we working on bufferload reduction in our 'aqm' groups ? Give intserv a chance ;-) Cheers toerless On Tue, Mar 13, 2018 at 07:27:18PM +0000, Lin Han wrote: > Hi, Gorry/Toerless > > Here is some explanation and clarification for two drafts (draft-han-tsvwg-cc and draft-han-6man-in-band-signaling-for-transport-qos) > > 1. About draft-han-tsvwg-cc compared with other CC for bandwidth guaranteed network, such as gTFRC. > draft-han-tsvwg-cc is a split draft from draft-han-6man-in-band-signaling-for-transport-qos . It proposes a new CC for a network if the TCP session's bandwidth is guaranteed. Here the guaranteed bandwidth is per TCP session and described by PIR/CIR and given directly by TCP end user. > > 2. About TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos > >From my understanding, TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos do have similarity, both are kind of using in-band signaling for the resource reservation. But they still have big difference. > 1). draft-han-6man-in-band-signaling-for-transport-qos is more general in-band signaling method, it not only applies to TCP, but also UDP or other upper layer of protocol, even the draft only exemplifies the method to TCP. > 2). draft-han-6man-in-band-signaling-for-transport-qos provides reserved resource for bandwidth and latency for the whole life of TCP session. It gives more flavors and more granularity for the QoS (unlike TCP-QS only has 16 values of starting bandwidth). Moreover, it can support the "worst case latency" at each hop; also, it can support the OAM to detect the congestion states, and support the "forwarding state" for host to be notified in real-time about if the resource reservation or QoS forwarding is interrupted by abnormal situation such as link/node failures. > > Best regards > > Lin > > > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: Tuesday, March 13, 2018 9:49 AM > To: Gorry Fairhurst > Cc: Thomas Nadeau ; tcpm@ietf.org; tsvwg@ietf.org; Scharf, Michael (Nokia - DE/Stuttgart) ; tsvwg-chairs@ietf.org; Katsushi Kobayashi ; Yingzhen Qu > Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) > > Thanks, Gory, nice explanation > > TCP Quickstart is rfc4782 btw. i think there was a buggy number in the thread. > > TCP quickstart really relates IMHO primarily to draft-han-6man-in-band-signaling-for-transport-qos, but not to draft-han-tsvwg-cc. The latter one is really meant to modify TCP assuming a known guaranteed CIR - whatever mechanism is used to provide that guarantee. > > TCP quickstart is an interesting example for inband signaling, which is what Lin's in-band-signaling draft does too. The main difference is that our draft focusses on high-value traffic where per-flow state is feasible and beneficial, if not necessary. And TCP quickstart seems more targeted to ANY TCP flow. Which raises a complete different scalability challenge to TCP quickstart. > > This type of comparison discussion will go into draft updates on our side. > > Would be interested in any more data points about the history of TCP quickstart, eg: where it was observed in the wild in deployments. > > Cheers > Toerless > > On Tue, Mar 13, 2018 at 09:38:54AM +0000, Gorry Fairhurst wrote: > > Maybe I'm saying what is obvious, but to be sure: > > > > The way I see QS is: > > - The router tracks the unutilised link capacity at the current time, > > and uses this as some estimate of what may be available to new flows > > in the near future. > > - The router responds to QS requests and can accept them if there is > > "unutilised capacity" remaining. > > - When accepted router updates it's count of the total unutilised > > capacity reducing by the accepted QS requests. (i.e., Subsequent QS > > requests in the same interval will currently have a smaller pool of > > unutilised capacity available). > > - After the end of the interval all "QS requests" expire and the > > router again makes a measure of the unutilised capacity at the current > > time. > > > > None of this implies a "reservation" of link resource in my thinking. > > In QS, the whole link capacity is intended to be shared using > > congestion control, and if flows start to send more using normal CC > > within the interval where QS is operating, they would simply receive a > > larger share of the capacity. That is: QS request didn't "allocate" > > any link resource. > > > > Gorry > > > > > > On 13/03/2018, 06:58, Katsushi Kobayashi wrote: > > >Hi, > > > > > >I think TCP QS router on the path also reserves bandwidth resource, > > >if it accepts a request. > > > > > >RFC4782 says: > > > If the router approves the Quick-Start Request, this approval SHOULD > > > be taken into account in the router's decision to accept or reject > > > subsequent Quick-Start Requests (e.g., using a variable that tracks > > > the recent aggregate of accepted Quick-Start Requests). > > > > > > > > >--- > > >Katsushi Kobayashi > > > > > >>2018/03/13 ??????3:43???Yingzhen Qu > >>> ????????????: > > >> > > >>Hi Michael, > > >>Sorry for the late response. > > >> > > >>Thanks for pointing out that we missed this important reference. > > >>You're right, Quick-Start and our proposal do have lots of > > >>similarities, for example both of them require that end-points and > > >>routers to work together. But they are also different in details. > > >>For example, in our proposal in-band signaling proposal bandwidth is > > >>reserved on routers along the path. > > >> > > >>In next version of this draft, We'll add discussions about RFC > > >>4728 and 6077. > > >> > > >>BTW, can I request a slot to present this draft in TCPM if time allows? > > >> > > >>Thanks, > > >>Yingzhen > > >> > > >>On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - > > >>DE/Stuttgart) > >>> wrote: > > >> > > >> I believe that this proposal is similar to QuickStart TCP (RFC > > >> 4782), which is not cited in draft-han-tsvwg-cc, and the > > >> reference is also missing in > > >> draft-han-6man-in-band-signaling-for-transport-qos. > > >> > > >> RFC 6077 explains some of the issues that an in-band signaling > > >> mechanism like Quick-Start has to solve. As far as I can tell, > > >> the fundamental challenge is neither the protocol specification > > >> nor a prototype implementation. For instance, it has been proven > > >> that QuickStart TCP can be implemented e.g. in network processors > > >> (see > > >> http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf > > >> ). > > >> > > >> So, when updating the documents, I suggest to add a discussion of > > >> how the open research issues explained in RFC 6077 are addressed. > > >> > > >> Michael > > >> > > >> *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com > > >> ] > > >> *Sent:* Sunday, March 04, 2018 9:59 PM > > >> *To:* gorry@erg.abdn.ac.uk > > >> *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) > > >> >; > > >> Thomas Nadeau > >> >; tcpm@ietf.org > > >> ; Yingzhen Qu > >> >; tsvwg@ietf.org > > >> ; tsvwg-chairs@ietf.org > > >> > > >> *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 > > >> > > >> Hi Gorry and Michael, > > >> > > >> Thanks for the suggestion, I'll request a presentation in ICCRG. > > >> Meanwhile, I think since the in-band signaling draft was > > >> presented in TSVWG, if time allows it still makes sense to > > >> present this draft in TSVWG. > > >> > > >> The in-band signaling draft covers lots of aspects, and the > > >> required changes include network layer and transport layer. We're > > >> working on updating the draft, and may break it into pieces to > > >> fit different WGs. > > >> > > >> Your comments and help are very much appreciated. > > >> > > >> Thanks, > > >> > > >> Yingzhen > > >> > > >> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst > > >> > wrote: > > >> > > >> I am unsure yet what the correct group of people world be to > > >> explore a "Bandwidth Guaranteed Network". The presentation > > >> last IETF looked like the work could imply a need for changes > > >> proposed to the network layer (using OAM exchnages) to set > > >> the sending rate and make those bandwidth reservations. In > > >> the end, it could result in a protocol quite different to > > >> TCP, I think this sort of change may possibly have a home in > > >> TSVWG - but first I'd agree with Michaeland would encourage > > >> a presentation of the problem statement in ICCRG to explore > > >> the issues. > > >> > > >> Gorry > > >> > > >> On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) > > >> wrote: > > >> > > >> > > >> Hi all, > > >> > > >> >From the abstract: ??????This draft proposes a new TCP > > >> congestion control algorithm used in bandwidth guaranteed > > >> networks. It is an extension to the current TCP standards.??? > > >> > > >> In the IETF, I believe the expertise for this specific > > >> document would be in TCPM, which in CC. If the authors > > >> are interested in feedback on the proposed mechanism, I > > >> would recommend to ask TCPM. > > >> > > >> Alternatively, corresponding research could perhaps be > > >> performed in the ICCRG. ICCRG has published RFC 6077 to > > >> document some of the open research issues in this space. > > >> > > >> Michael > > >> > > >> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org > > >> ] *On Behalf Of *Yingzhen Qu > > >> *Sent:* Sunday, March 04, 2018 6:55 AM > > >> *To:* tsvwg@ietf.org ; > > >> tsvwg-chairs@ietf.org > > >> *Cc:* Thomas Nadeau > >> > > > >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 > > >> > > >> Dear Chairs, > > >> > > >> A new draft (The draft was suggested by TSVWG @IETF100) > > >> was just submitted, and we???d like to request a time slot > > >> to present it @IETF101. > > >> > > >> Title:A New Congestion Control in Bandwidth Guaranteed > > >> Network > > >> > > >> Presenter: Yingzhen Qu (Huawei) > > >> > > >> Time required (including Q/A): 10 mins > > >> > > >> Draft: > > >> https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > > >> > > >> > > >> If there is any question, please kindly let us know. > > >> > > >> Thanks, > > >> > > >> Yingzhen > > >> > > >> > > > > > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Tue Mar 13 14:53:14 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559EC126CF9; Tue, 13 Mar 2018 14:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDKShlm9u0Gb; Tue, 13 Mar 2018 14:53:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 DCDB8126CD6; Tue, 13 Mar 2018 14:52:45 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8E1057745657A; Tue, 13 Mar 2018 21:52:41 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 13 Mar 2018 21:52:43 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 14:52:35 -0700 From: Lin Han To: Toerless Eckert CC: Gorry Fairhurst , Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tsvwg-chairs@ietf.org" , Katsushi Kobayashi , Yingzhen Qu Thread-Topic: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) Thread-Index: AQHTuwFM3r3WTfYLEkqWf3ecaDUj6qPPIMSA//+TNEA= Date: Tue, 13 Mar 2018 21:52:34 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CDB9CE7@sjceml521-mbs.china.huawei.com> References: <5A9BEB65.6010102@erg.abdn.ac.uk> <050065D2-5F2E-4E79-9BD1-E1DC03F13900@acm.org> <5AA79C2E.1040808@erg.abdn.ac.uk> <20180313164928.GA17042@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CDB9BA3@sjceml521-mbs.china.huawei.com> <20180313211739.GA19333@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180313211739.GA19333@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 21:53:12 -0000 Right, Toerless. You gave a very good comparison.=20 If we must use a simplest sentence to describe our work, it would be "Intse= rv Renaissance by in-band signaling" Regards Lin -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de]=20 Sent: Tuesday, March 13, 2018 2:18 PM To: Lin Han Cc: Gorry Fairhurst ; Thomas Nadeau ; tcpm@ietf.org; tsvwg@ietf.org; Scharf, Michael (Nokia - DE/Stuttg= art) ; tsvwg-chairs@ietf.org; Katsushi Kobayashi = ; Yingzhen Qu Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@I= ETF101) Thanks, Lin Let me also try another angle of comparison:=20 Having worked on RSVP for a long time, your inband signaling draft is IMHO = very easy to vet - lightweight inband signaling, replacing/simplifying/scal= ing the Intserv QoS model model for deterministic services. I think inband signaling could really be the antidote for what i would call= the IETFs intserv "second system syndrom" trauma from NSIS and many ever m= ore complex RSVP extensions never deployed. Compared to the work on inband signaling for DiffServ, i think we did not r= eally have good attempts to do it for intserv. And ultimately, DiffServ inb= and signaling has been quite successful, and we also understand the dynamic= s needed to deploy it in various type of networks. last but not least ECN in the Internet. In fact, i think we are seeing with DiffServ a lot more difficult experimen= ts, struggling with the complexities of control loops. TCP-QS is a great example: How do you even try to optimize in the real worl= d a control loop with N-nodes on the path using their own "likely-best-usea= ble-free-bandwidth" prediction based on a local algorithm ? I also did not = see in the TCP-QS docs references to the impact of TCP behavior, (bursts), = but its clear that the result will be different with most-bursty (classic T= CP CC), DV, or even rate predictive (BBR etc.). How long are we working on = bufferload reduction in our 'aqm' groups ? Give intserv a chance ;-) Cheers toerless On Tue, Mar 13, 2018 at 07:27:18PM +0000, Lin Han wrote: > Hi, Gorry/Toerless >=20 > Here is some explanation and clarification for two drafts=20 > (draft-han-tsvwg-cc and=20 > draft-han-6man-in-band-signaling-for-transport-qos) >=20 > 1. About draft-han-tsvwg-cc compared with other CC for bandwidth guarante= ed network, such as gTFRC. > draft-han-tsvwg-cc is a split draft from draft-han-6man-in-band-signaling= -for-transport-qos . It proposes a new CC for a network if the TCP session'= s bandwidth is guaranteed. Here the guaranteed bandwidth is per TCP sessio= n and described by PIR/CIR and given directly by TCP end user.=20 >=20 > 2. About TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos > >From my understanding, TCP-QS and draft-han-6man-in-band-signaling-for-t= ransport-qos do have similarity, both are kind of using in-band signaling f= or the resource reservation. But they still have big difference. > 1). draft-han-6man-in-band-signaling-for-transport-qos is more general in= -band signaling method, it not only applies to TCP, but also UDP or other u= pper layer of protocol, even the draft only exemplifies the method to TCP. > 2). draft-han-6man-in-band-signaling-for-transport-qos provides reserved = resource for bandwidth and latency for the whole life of TCP session. It gi= ves more flavors and more granularity for the QoS (unlike TCP-QS only has 1= 6 values of starting bandwidth). Moreover, it can support the "worst case l= atency" at each hop; also, it can support the OAM to detect the congestion = states, and support the "forwarding state" for host to be notified in real-= time about if the resource reservation or QoS forwarding is interrupted by = abnormal situation such as link/node failures. >=20 > Best regards >=20 > Lin >=20 >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Toerless=20 > Eckert > Sent: Tuesday, March 13, 2018 9:49 AM > To: Gorry Fairhurst > Cc: Thomas Nadeau ; tcpm@ietf.org;=20 > tsvwg@ietf.org; Scharf, Michael (Nokia - DE/Stuttgart)=20 > ; tsvwg-chairs@ietf.org; Katsushi Kobayashi=20 > ; Yingzhen Qu > Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for=20 > TSVWG@IETF101) >=20 > Thanks, Gory, nice explanation >=20 > TCP Quickstart is rfc4782 btw. i think there was a buggy number in the th= read. >=20 > TCP quickstart really relates IMHO primarily to draft-han-6man-in-band-si= gnaling-for-transport-qos, but not to draft-han-tsvwg-cc. The latter one is= really meant to modify TCP assuming a known guaranteed CIR - whatever mech= anism is used to provide that guarantee. >=20 > TCP quickstart is an interesting example for inband signaling, which is w= hat Lin's in-band-signaling draft does too. The main difference is that our= draft focusses on high-value traffic where per-flow state is feasible and = beneficial, if not necessary. And TCP quickstart seems more targeted to ANY= TCP flow. Which raises a complete different scalability challenge to TCP q= uickstart. >=20 > This type of comparison discussion will go into draft updates on our side= . >=20 > Would be interested in any more data points about the history of TCP quic= kstart, eg: where it was observed in the wild in deployments. >=20 > Cheers > Toerless >=20 > On Tue, Mar 13, 2018 at 09:38:54AM +0000, Gorry Fairhurst wrote: > > Maybe I'm saying what is obvious, but to be sure: > >=20 > > The way I see QS is: > > - The router tracks the unutilised link capacity at the current=20 > > time, and uses this as some estimate of what may be available to new=20 > > flows in the near future. > > - The router responds to QS requests and can accept them if there is=20 > > "unutilised capacity" remaining. > > - When accepted router updates it's count of the total unutilised=20 > > capacity reducing by the accepted QS requests. (i.e., Subsequent QS=20 > > requests in the same interval will currently have a smaller pool of=20 > > unutilised capacity available). > > - After the end of the interval all "QS requests" expire and the=20 > > router again makes a measure of the unutilised capacity at the=20 > > current time. > >=20 > > None of this implies a "reservation" of link resource in my thinking.=20 > > In QS, the whole link capacity is intended to be shared using=20 > > congestion control, and if flows start to send more using normal CC=20 > > within the interval where QS is operating, they would simply receive=20 > > a larger share of the capacity. That is: QS request didn't "allocate" > > any link resource. > >=20 > > Gorry > >=20 > >=20 > > On 13/03/2018, 06:58, Katsushi Kobayashi wrote: > > >Hi, > > > > > >I think TCP QS router on the path also reserves bandwidth resource,=20 > > >if it accepts a request. > > > > > >RFC4782 says: > > > If the router approves the Quick-Start Request, this approval SHOUL= D > > > be taken into account in the router's decision to accept or reject > > > subsequent Quick-Start Requests (e.g., using a variable that tracks > > > the recent aggregate of accepted Quick-Start Requests). > > > > > > > > >--- > > >Katsushi Kobayashi > > > > > >>2018/03/13 ??????3:43???Yingzhen Qu > >>> ????????????: > > >> > > >>Hi Michael, > > >>Sorry for the late response. > > >> > > >>Thanks for pointing out that we missed this important reference. > > >>You're right, Quick-Start and our proposal do have lots of=20 > > >>similarities, for example both of them require that end-points and=20 > > >>routers to work together. But they are also different in details. > > >>For example, in our proposal in-band signaling proposal bandwidth=20 > > >>is reserved on routers along the path. > > >> > > >>In next version of this draft, We'll add discussions about RFC > > >>4728 and 6077. > > >> > > >>BTW, can I request a slot to present this draft in TCPM if time allow= s? > > >> > > >>Thanks, > > >>Yingzhen > > >> > > >>On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - > > >>DE/Stuttgart) > >>> wrote: > > >> > > >> I believe that this proposal is similar to QuickStart TCP (RFC > > >> 4782), which is not cited in draft-han-tsvwg-cc, and the > > >> reference is also missing in > > >> draft-han-6man-in-band-signaling-for-transport-qos. > > >> > > >> RFC 6077 explains some of the issues that an in-band signaling > > >> mechanism like Quick-Start has to solve. As far as I can tell, > > >> the fundamental challenge is neither the protocol specification > > >> nor a prototype implementation. For instance, it has been proven > > >> that QuickStart TCP can be implemented e.g. in network processors > > >> (see > > >> http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_D= iss_40112.pdf > > >> ). > > >> > > >> So, when updating the documents, I suggest to add a discussion of > > >> how the open research issues explained in RFC 6077 are addressed. > > >> > > >> Michael > > >> > > >> *From:* Yingzhen Qu [mailto:yingzhen.ietf@gmail.com > > >> ] > > >> *Sent:* Sunday, March 04, 2018 9:59 PM > > >> *To:* gorry@erg.abdn.ac.uk > > >> *Cc:* Scharf, Michael (Nokia - DE/Stuttgart) > > >> >; > > >> Thomas Nadeau > >> >; tcpm@ietf.org > > >> ; Yingzhen Qu > >> >; tsvwg@ietf.org > > >> ; tsvwg-chairs@ietf.org > > >> > > >> *Subject:* Re: [tsvwg] Agenda requests for TSVWG@IETF101 > > >> > > >> Hi Gorry and Michael, > > >> > > >> Thanks for the suggestion, I'll request a presentation in ICCRG. > > >> Meanwhile, I think since the in-band signaling draft was > > >> presented in TSVWG, if time allows it still makes sense to > > >> present this draft in TSVWG. > > >> > > >> The in-band signaling draft covers lots of aspects, and the > > >> required changes include network layer and transport layer. We're > > >> working on updating the draft, and may break it into pieces to > > >> fit different WGs. > > >> > > >> Your comments and help are very much appreciated. > > >> > > >> Thanks, > > >> > > >> Yingzhen > > >> > > >> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst > > >> > wrote: > > >> > > >> I am unsure yet what the correct group of people world be to > > >> explore a "Bandwidth Guaranteed Network". The presentation > > >> last IETF looked like the work could imply a need for changes > > >> proposed to the network layer (using OAM exchnages) to set > > >> the sending rate and make those bandwidth reservations. In > > >> the end, it could result in a protocol quite different to > > >> TCP, I think this sort of change may possibly have a home in > > >> TSVWG - but first I'd agree with Michaeland would encourage > > >> a presentation of the problem statement in ICCRG to explore > > >> the issues. > > >> > > >> Gorry > > >> > > >> On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) > > >> wrote: > > >> > > >> > > >> Hi all, > > >> > > >> >From the abstract: ??????This draft proposes a new TCP > > >> congestion control algorithm used in bandwidth guaranteed > > >> networks. It is an extension to the current TCP standard= s.??? > > >> > > >> In the IETF, I believe the expertise for this specific > > >> document would be in TCPM, which in CC. If the authors > > >> are interested in feedback on the proposed mechanism, I > > >> would recommend to ask TCPM. > > >> > > >> Alternatively, corresponding research could perhaps be > > >> performed in the ICCRG. ICCRG has published RFC 6077 to > > >> document some of the open research issues in this space. > > >> > > >> Michael > > >> > > >> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org > > >> ] *On Behalf Of *Yingzhen = Qu > > >> *Sent:* Sunday, March 04, 2018 6:55 AM > > >> *To:* tsvwg@ietf.org ; > > >> tsvwg-chairs@ietf.org > > >> *Cc:* Thomas Nadeau > >> > > > >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 > > >> > > >> Dear Chairs, > > >> > > >> A new draft (The draft was suggested by TSVWG @IETF100) > > >> was just submitted, and we???d like to request a time slo= t > > >> to present it @IETF101. > > >> > > >> Title:A New Congestion Control in Bandwidth Guaranteed > > >> Network > > >> > > >> Presenter: Yingzhen Qu (Huawei) > > >> > > >> Time required (including Q/A): 10 mins > > >> > > >> Draft: > > >> https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ > > >> > > >> > > >> If there is any question, please kindly let us know. > > >> > > >> Thanks, > > >> > > >> Yingzhen > > >> > > >> > > > >=20 > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Tue Mar 13 15:30:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C473D12DA1A for ; Tue, 13 Mar 2018 15:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW3aKqSEiSEM for ; Tue, 13 Mar 2018 15:30:36 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 3B15A124D68 for ; Tue, 13 Mar 2018 15:30:36 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D796BD81BCBDA for ; Tue, 13 Mar 2018 22:30:31 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 13 Mar 2018 22:30:33 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 15:30:27 -0700 From: John Kaippallimalil To: Tom Herbert , "tsvwg@ietf.org" , "panrg@irtf.org" Thread-Topic: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt Thread-Index: AQHTiyCYglhdXUh09ku6IE/yZDJKraPPAZxg Date: Tue, 13 Mar 2018 22:30:26 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171F965700@sjceml521-mbs.china.huawei.com> References: <151569998986.1808.5962574573199407272.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 22:30:38 -0000 VG9tLA0KSSByZWFkIHRoaXMgZHJhZnQgYW5kIGxpa2UgdGhlIG92ZXJhbGwgYXBwcm9hY2ggKG15 IHBvaW50IG9mIHZpZXcgaXMgdGhlIG1vYmlsZSBuZXR3b3JrKS4NCg0KQSBmZXcgb2YgcXVlc3Rp b25zOg0KMS4gIEkgc3VwcG9zZSB0aGF0IHRoZXNlIHRpY2tldHMgZG8gbm90IGhhdmUgdG8gYmUg c2VudCBpbiBldmVyeSBwYWNrZXQuDQpBcmUgdGhleSBzZW50IHN0YXRpc3RpY2FsbHksIG9yIGp1 c3QgaW4gYSBmZXcgcGFja2V0cyBhZnRlciBhIGNoYW5nZSBvciBzb21lIGV2ZW50Lg0KDQoyLiBt eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgcm91dGVycyBvbiBwYXRoIHdvdWxkIHRyeSB0byBpbnNw ZWN0IGFsbCB0aWNrZXRzIHRvIGRldGVybWluZSB3aGljaCBvbmVzIGFyZSBmb3IgdGhhdCBzZXJ2 aWNlIHByb3ZpZGVyLiAgDQpXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGV4cGxpY2l0bHkgY29udmV5 IHRoYXQgaW4gT3B0aW9uIEZvcm1hdC9UaWNrZXQgKDQuMSkgLSBsaWtlIGEgcmVhbG0gLyBkb21h aW4gbmFtZSBvZiB0aGUgc2VydmljZSBwcm92aWRlci4NCk9yIGNhbiB0aGlzIGJlIGRlcml2ZWQg ZnJvbSBzb21lIGNvbWJpbmF0aW9uIG9mIHRoZSBvcHRpb24gdHlwZSAoaG9wLWJ5LWhvcC8gZGVz dGluYXRpb24pIGFuZCAiVHlwZSIgZmllbGRzLg0KDQozLiBBZnRlciBhbiBJUCBhZGRyZXNzIGNo YW5nZSAobW9iaWxpdHkgZXZlbnQpLCBUQ1AgcmFtcCB1cCBhZmZlY3RzIHRoZSBmbG93IHJhdGUu DQpBc3N1bWluZyB1c2UgY2FzZXMgbGlrZSBWMlggKGFuZCBJTEEpIHdoZXJlIG1vYmlsaXR5IGV2 ZW50cyBhcmUgZnJlcXVlbnQgLSANCkNvdWxkIGEgcGFja2V0IHdpdGggdGlja2V0IGNvbnZleWlu ZyBlc3RhYmxpc2hlZCBmbG93ICsgUW9TIGluZm8gYmUgdXNlZCB0byBzYWZlbHkgY29udGludWUv bm90IGhhdmUgdG8gcmFtcCB1cCBldmVyeSB0aW1lIHRoZXJlIGlzIGEgY2hhbmdlIG9mIElQIGF0 dGFjaG1lbnQgcG9pbnQuDQoNClRoYW5rcywNCkpvaG4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBUb20gSGVyYmVydA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTgg MzowOSBQTQ0KVG86IHRzdndnQGlldGYub3JnOyBwYW5yZ0BpcnRmLm9yZw0KU3ViamVjdDogW3Rz dndnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGVyYmVydC1mYXN0 LTAwLnR4dA0KDQpIZWxsbywNCg0KSSBwb3N0ZWQgdGhpcyBkcmFmdCBvbiAiRmlyZXdhbGwgYW5k IFNlcnZpY2UgVGlja2V0cyIgZHJhZnQuIFRoaXMgaXMgYSBwcm9wb3NlZCBtZXRob2QgdG8gYWxs b3cgaG9zdHMgYW5kIGFwcGxpY2F0aW9ucyB0byBzaWduYWwgdGhlIG5ldHdvcmsgdG8gbWFrZSBy ZXF1ZXN0cyBmb3Igc2VydmljZXMgdG8gYmUgYXBwbGllZCB0byBmbG93cy4gVGhlIGNvbmNlcHQg b2YgYSByaWNoIGFuZCBleHRlbnNpYmxlICBwcm90b2NvbCB0byBzaWduYWwgdGhlIG5ldHdvcmsg d2FzIGluc3BpcmVkIGJ5IHRoZSBTUFVEL1BMVVMgd29yaywgaG93ZXZlciB0aGlzIHByb3Bvc2Fs IHVzZXMgSVB2NiBleHRlbnNpb24gaGVhZGVycyBpbnN0ZWFkIG9mIFVEUCBzaGltIGhlYWRlcnMg YW5kIHRyaWVzIHRvIHN0cmljdGx5IGNvbnRyb2wgZXhwb3N1cmUgYXBwbGljYXRpb24gY2hhcmFj dGVyaXN0aWNzIG9yIGNvbnRlbnQgdG8gdW50cnVzdGVkIHBhcnRpZXMuDQoNCkkndmUgY3Jvc3Mg cG9zdGVkIHRoaXMgdGkgdHN2d2cgYW4gcGFucmcgYXMgSSdtIG5vdCB5ZXQgc3VyZSB3aGVyZSB0 aGlzIHdvcmsgd291bGQgYmVsb25nLg0KDQpBbnkgZmVlZGJhY2sgaXMgdmVyeSB3ZWxjb21lIQ0K DQpUaGFua3MsDQpUb20NCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0t DQpGcm9tOiAgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkRhdGU6IFRodSwgSmFuIDExLCAy MDE4IGF0IDExOjQ2IEFNDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWhlcmJlcnQtZmFzdC0wMC50eHQNClRvOiBUb20gSGVyYmVydCA8dG9tQHF1YW50b25pdW0u bmV0Pg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhlcmJlcnQtZmFzdC0wMC50 eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUb20gSGVyYmVydCBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1oZXJi ZXJ0LWZhc3QNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIEZpcmV3YWxsIGFu ZCBTZXJ2aWNlIFRpY2tldHMNCkRvY3VtZW50IGRhdGU6ICAyMDE4LTAxLTExDQpHcm91cDogICAg ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMjENClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGVyYmVy dC1mYXN0LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWhlcmJlcnQtZmFzdC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaGVyYmVydC1mYXN0LTAwDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oZXJiZXJ0LWZhc3QtMDAN Cg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBGaXJld2FsbHMg YW5kIFNlcnZpY2UgVGlja2V0cyBwcm90b2NvbC4gQQ0KICAgdGlja2V0IGlzIGRhdGEgdGhhdCBh Y2NvbXBhbmllcyBhIHBhY2tldCBhbmQgaW5kaWNhdGVzIGEgZ3JhbnRlZA0KICAgcmlnaHQgdG8g dHJhdmVyc2UgYSBuZXR3b3JrIG9yIGEgcmVxdWVzdCBmb3IgbmV0d29yayBzZXJ2aWNlIHRvIGJl DQogICBhcHBsaWVkLiBBcHBsaWNhdGlvbnMgcmVxdWVzdCB0aWNrZXRzIGZyb20gYSBsb2NhbCBh Z2VudCBpbiB0aGUNCiAgIG5ldHdvcmsgYW5kIGF0dGFjaCBpc3N1ZWQgdGlja2V0cyB0byBwYWNr ZXRzLiBGaXJld2FsbCB0aWNrZXRzIGFyZQ0KICAgaXNzdWVkIHRvIGdyYW50IHBhY2tldHMgdGhl IHJpZ2h0IHRvIHRyYXZlcnNlIGEgbmV0d29yazsgc2VydmljZQ0KICAgdGlja2V0cyBpbmRpY2F0 ZSB0aGUgZGVzaXJlZCBzZXJ2aWNlIHRvIGJlIGFwcGxpZWQgdG8gYSBwYWNrZXRzLiBBDQogICBz aW5nbGUgdGlja2V0IG1heSBwcm92aWRlIGJvdGggZmlyZXdhbGwgYW5kIHNlcnZpY2UgdGlja2V0 DQogICBpbmZvcm1hdGlvbi4gVGlja2V0cyBhcmUgc2VudCBpbiBlaXRoZXIgSVB2NiBEZXN0aW5h dGlvbiBvcHRpb25zIG9yDQogICBIb3AtYnktSG9wIG9wdGlvbnMuDQoNCg0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Mar 13 16:05:09 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95D12D881 for ; Tue, 13 Mar 2018 16:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrHK8XZzT43m for ; Tue, 13 Mar 2018 16:05:04 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 9DDEB12D86C for ; Tue, 13 Mar 2018 16:05:04 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id n12so2600975wra.2 for ; Tue, 13 Mar 2018 16:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=doISyMaLrztI8at5bHa2a4VU6nlmLGub6+JO+590Cjg=; b=dRuYY+yjgqT59e0c6eEbZvaOF2xF84LpMIF7LHIswGs1oAGdHvBJB9T7YXto2PGhuU 8Fv2Iy1uK7JZF/bTmcdz0NAE731vIIjdf+JsLnFAhycpRoSqQk6TlpGduxteaSvbhrbF FTvRhQ0nC09FYFKpeifYm07EC7vGTlX7zFExL4fjCqOcr69QpCBOLHnSatGCF1U1b3wv pOZ+VayPFEMQMa64L7jRGtQU58KzLGztrazolsdDJ2K6R7e+oMVilPil9Xet8FfsxlBe aMxeo4fnVr55D6dwzR2/jhm+ToaNeTguWV02M4QOI8pO+4KdUOb4vSfalosEDF8hSI3y J3JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=doISyMaLrztI8at5bHa2a4VU6nlmLGub6+JO+590Cjg=; b=FsWJuD64XveL259sdtegvlPRktZr0pQa7Y9ooRIGP0nqFS/O1502ikBdM3AJYqf5lP Oled+yJm7G4OxOHGBFZJ1rNeLUEVAT2KITd7UuGb+Nq5VtKAiLzDScHFN2Phm3lxWnET iCz6HfHwKf4amMvGBJMiQ+0UfIV69aCnnT+L7m3n4eHyrzeEiMvzoC0n2eJTujYb56hV rjWrY8EKh7WSyOsPSzFRkXbkq2jDP0ekcVYKeA+8MZiXAFy2LSeiLJRdhsD888GlMqNL riLaJoOPQEWQeQB/qxjoTMknZiFX6LTJB9W6NjBR1157br2eaOi/i32cfeNngc1tUJEj bh9Q== X-Gm-Message-State: AElRT7G6IZ5EmOviD34ZmS6yfodQ5upoI1nOvMVIToSvAlVVRjwD3tu4 3c9EgRBVMwAW4McMhWrtgCYm9BDvz4/owcBd2gbX/Q== X-Google-Smtp-Source: AG47ELufIctiBrCixESyVpGW9MstpUF8Q2SJZ2vJi/dhmc4zg851f4tAsjgHltWHuNAmlDdDP3TcePeJr6Ws9LqDAe4= X-Received: by 10.223.165.67 with SMTP id j3mr1966356wrb.111.1520982302927; Tue, 13 Mar 2018 16:05:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.74 with HTTP; Tue, 13 Mar 2018 16:05:02 -0700 (PDT) In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171F965700@sjceml521-mbs.china.huawei.com> References: <151569998986.1808.5962574573199407272.idtracker@ietfa.amsl.com> <6561EABF52675C45BCDACA1B4D7AA1171F965700@sjceml521-mbs.china.huawei.com> From: Tom Herbert Date: Tue, 13 Mar 2018 16:05:02 -0700 Message-ID: To: John Kaippallimalil Cc: "tsvwg@ietf.org" , "panrg@irtf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 23:05:07 -0000 On Tue, Mar 13, 2018 at 3:30 PM, John Kaippallimalil wrote: > Tom, > I read this draft and like the overall approach (my point of view is the = mobile network). > Hi John, Thanks for your questions! > A few of questions: > 1. I suppose that these tickets do not have to be sent in every packet. > Are they sent statistically, or just in a few packets after a change or s= ome event. > In every packet. This way the network does not need to create flow state, it just reads and processes the tickets as they presented. > 2. my understanding is that routers on path would try to inspect all tick= ets to determine which ones are for that service provider. > Would it make sense to explicitly convey that in Option Format/Ticket (4.= 1) - like a realm / domain name of the service provider. > Or can this be derived from some combination of the option type (hop-by-h= op/ destination) and "Type" fields. > I thought about adding an identifier to tickets (like AS number), but I think that is probably not needed. Tickets are probably only applicable in edge provider networks, not in core Internet. So there might be up to two tickets in a packet, one that is relevant to the source provider and one that is relevant to the remote provider (a reflected ticket). Tickets also need to be verified probably through decryption so that would also be able to detect whether it ticket is valid in the network processing it. It will be an interesting challenge to see how small the tickets can be made without losing security or expressiveness. > 3. After an IP address change (mobility event), TCP ramp up affects the f= low rate. > Assuming use cases like V2X (and ILA) where mobility events are frequent = - > Could a packet with ticket conveying established flow + QoS info be used = to safely continue/not have to ramp up every time there is a change of IP a= ttachment point. Yes, they should be. In the case of ILA for instance, the ticket is created based on identifier addresses which don't change across a mobile event. Tom > > Thanks, > John > > > > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Tom Herbert > Sent: Thursday, January 11, 2018 3:09 PM > To: tsvwg@ietf.org; panrg@irtf.org > Subject: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.= txt > > Hello, > > I posted this draft on "Firewall and Service Tickets" draft. This is a pr= oposed method to allow hosts and applications to signal the network to make= requests for services to be applied to flows. The concept of a rich and ex= tensible protocol to signal the network was inspired by the SPUD/PLUS work= , however this proposal uses IPv6 extension headers instead of UDP shim hea= ders and tries to strictly control exposure application characteristics or = content to untrusted parties. > > I've cross posted this ti tsvwg an panrg as I'm not yet sure where this w= ork would belong. > > Any feedback is very welcome! > > Thanks, > Tom > > ---------- Forwarded message ---------- > From: > Date: Thu, Jan 11, 2018 at 11:46 AM > Subject: New Version Notification for draft-herbert-fast-00.txt > To: Tom Herbert > > > > A new version of I-D, draft-herbert-fast-00.txt has been successfully sub= mitted by Tom Herbert and posted to the IETF repository. > > Name: draft-herbert-fast > Revision: 00 > Title: Firewall and Service Tickets > Document date: 2018-01-11 > Group: Individual Submission > Pages: 21 > URL: https://www.ietf.org/internet-drafts/draft-herbert-fast-0= 0.txt > Status: https://datatracker.ietf.org/doc/draft-herbert-fast/ > Htmlized: https://tools.ietf.org/html/draft-herbert-fast-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-fast-= 00 > > > Abstract: > This document describes the Firewalls and Service Tickets protocol. A > ticket is data that accompanies a packet and indicates a granted > right to traverse a network or a request for network service to be > applied. Applications request tickets from a local agent in the > network and attach issued tickets to packets. Firewall tickets are > issued to grant packets the right to traverse a network; service > tickets indicate the desired service to be applied to a packets. A > single ticket may provide both firewall and service ticket > information. Tickets are sent in either IPv6 Destination options or > Hop-by-Hop options. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Wed Mar 14 00:56:20 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396EA1200C5 for ; Wed, 14 Mar 2018 00:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=OK5JHd63; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kvYbUJHP 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 xew-WuYWnqKM for ; Wed, 14 Mar 2018 00:56:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 EDA3B126DFF for ; Wed, 14 Mar 2018 00:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521014163; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HSDP46kdrJhHmw6hAdei3t/jMEvvgKd3EENenqajn3g=; b=OK5JHd63ZIvipZfOvWIxbBfOySDFiGWGzEF9aNWS1cYZwF1uZr3I5jNBjzYoHPDh 7FwjwjuVChkT3Q/sXQ0/7hExR+bX+GA+Z4lv486YUVDljr+42qKoomgcOkwrQ+M5 FWJBXWCQwS37q8XF9Hs7IQVfoYAJS5hRi7lkGfX3q30=; X-AuditID: c1b4fb2d-499ff70000005540-d1-5aa8d592f477 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 89.B1.21824.295D8AA5; Wed, 14 Mar 2018 08:56:03 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSHC013.ericsson.se (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 14 Mar 2018 08:56:02 +0100 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Wed, 14 Mar 2018 08:56:02 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Wed, 14 Mar 2018 08:56:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jqqHDPNWcQmZ7r0IH634ZstRVbtjNhLmZH/z69lYY+I=; b=kvYbUJHP7tkoZVYXqkYNRM4oRyFv9vxm0v950yaPzipzPUJZ2pnXHdwhNKa8GhHLIIFJMJhR3Zy6lF2g0fdmhawURQML5W3V4x408k6puzegZOSDil9jAl3ORFScpSI9BEG6OZobkNST1SZjJtUxIdVSk8E4J/pxQVYUBQeJX58= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3740.eurprd07.prod.outlook.com (52.133.6.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.7; Wed, 14 Mar 2018 07:56:00 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::2ca4:c7f5:8d2a:f180]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::2ca4:c7f5:8d2a:f180%2]) with mapi id 15.20.0588.013; Wed, 14 Mar 2018 07:56:00 +0000 From: Ingemar Johansson S To: "Lin.Han@huawei.com" , "tte@cs.fau.de" CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , "'iccrg@irtf.org'" , Ingemar Johansson S Thread-Topic: [tcpm] [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) Thread-Index: AdO7ZqLf99MPKZX+ToKs31yM2w2JXQ== Date: Wed, 14 Mar 2018 07:55:59 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3740; 7:IncOdhEOPCl6S7qxyu351AJKDE6B6glo+PNvYDJoJ6ydTbDfAFT6PtpNtX6FBZrwYrr2RC4jZGIVRUSyuab+ToXn5OG853q7jefMYOzGvOOg2O9kr7CINyJZrrVBN7pCe2G+mNE9iCeHyvFptany31epvKeNwHHvDpAhWV59XAclQY6MMTsR52FaO+2BeBxUvx7p57sGIKmdciM5ErIGOuKBgae6Ib1+ssR9dflrRbAiD7IV1ojqDP8SVoIjxQGC x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(39380400002)(376002)(346002)(199004)(189003)(3846002)(6116002)(6506007)(106356001)(107886003)(2900100001)(316002)(55016002)(86362001)(53936002)(9686003)(33656002)(3280700002)(26005)(305945005)(7736002)(25786009)(14454004)(186003)(6246003)(229853002)(4326008)(105586002)(74316002)(99286004)(7696005)(54906003)(81166006)(5660300001)(81156014)(102836004)(6436002)(8676002)(2906002)(8936002)(66066001)(2501003)(59450400001)(478600001)(5250100002)(68736007)(110136005)(3660700001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3740; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 6d7babf2-0824-4640-bfc3-08d5898106db x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0702MB3740; x-ms-traffictypediagnostic: HE1PR0702MB3740: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(82608151540597)(130329453890623)(213716511872227); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501244)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0702MB3740; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3740; x-forefront-prvs: 0611A21987 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bketSgYxKTTN4oU2Gbs0I3hNeHY3eAFL1oCLKVG9C6mziMz9TsKTz9PeHqVGp/VwB3e/3k9WK3mniyb5Zwib6zne9WmoqFWcQgDHS6OHuy7jrL5g1i07Kvt+9+/dnMN6/Ywq1hFoleZyuWjroYH4AX85D4Eq0ee+ud9bvjsJra1ZZqdw/foNT2mAr3yn/rOv7tHhHVZsxdHb+VP8xJrgFtckB55vl9dbSj60f3AIfY+1JgSqEpe9ULqDfoBXGrBKveMRgn42IY0erCozRYBXRULI52gOEYEniOMjOhM6UgTg4+n4NjNN8rnRto8zSq70GWoEbcD3Nju79gkTTxKyjw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d7babf2-0824-4640-bfc3-08d5898106db X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2018 07:56:00.0273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3740 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c7N42p08oIvXqIGQd6mlsQqsaI/XFeKCGIWufSg0pyyY0Ml wkuZrEKZKEyxLZjzklTa1CJN20pdkXkLU7NCxVITbZCXdJHbWdB/v+d9Ht7Lx0fjXnrSn05V ZrIqpVwhogSE7nzrvvDSD7WyyOYXuKTT8MxD8kZPSFpsekzS9WOckvQOr+GHSKmucR5Jb7ya J6VG4yomLW20UqcJmSAmiVWkqllVRGyCIKV9yUpltAdldQ0OY7lIDxrkSQMTDfVTbZgGCWgv xorAYbSRvDAj6O83e/BiGcFKfr47Vo1ByWudSxCMHYOq7nKCd7QYNK7fo3gxjaAsz0E5x1BM DNRZlpGTfZhTMFO76JqCMzUI1gyLuNPwZuKhpMe8YdAboQugK9rB58Ww0L9IOJlgdsLN4gLM yUImAZaKta6eiAmCL8ufXRmc8YPRKT3Gn8eAse09zrMvzEz+Ifl8IthH7pJ8fTusD0xQPAfB gP424rkFA+M4wXMUdNd1uPv0kVBtvMzzSejQdrqeApgxBL8Ge9yNwqCqrNDN6TCSP+teSAET ujL34Docpu1xJSii4r+9eQ4Dw3M7xXMomO7P4RWum7eCTTdFGBBRj3w5luPSknfvEbOq1ESO S1eKlWxmE9r4Ni/Na+FP0YO5wxbE0Ei0Wajpr5V5kXI1l51mQUDjIh9hc+BGSZgkz85hVemX VFcVLGdBATQh8hPajgplXkyyPJO9wrIZrOqfi9Ge/rnIZFfH3Wkbf/TxWnZDw4EcI1m5en1g 197Z6IKsi00hxf6m2O+jT4bEx7f09lklo630tOzTCYdA2BbZ/rP33O+Z1E1DfWMxpZ2OmlDD ilrSEfiOHN6v1DjyVsvZIu3CwVsBlcE+x75uOxOcXTn57WFhfEONqOexyYQVIO+3Z0dbjogI LkUeFYKrOPlfQpHSyTIDAAA= Archived-At: Subject: Re: [tsvwg] [tcpm] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 07:56:09 -0000 Hi This subject pops up every once in a while.=20 I would like to add my perspective, given how I understand that 3GPP techno= logy works. The 3GPP QoS framework can be used to offer for instance a Guar= anteed bandwidth (GBR) to applications. The operation is that the "bearer" = gets increased scheduling priority once the throughput is below the GBR val= ue. In simulations I have verified that this framework can deliver a GBR to TCP= flows when the network load increases, at least as long it is possible to = push back other bearers with a lower priority. So, seen from my experience = so far I am not fully confident that additional inband signaling is needed.= =20 There can however be a benefit to e.g. determine an appropriate bitrate for= a DASH session, depending on network load and/or coverage, but I would arg= ue that out of band signaling is better in this case. As regards to "worst case latency", I am not sure that I follow here, are w= e discussing TSN/Detnet technology here, general link failures, or is it ab= out means to control the queue delay in the network ?. As to the latter, I = believe that it is worthwhile to look more closely at L4S.=20 Regards Ingemar Johansson > Message: 2 > Date: Tue, 13 Mar 2018 19:27:18 +0000 > From: Lin Han > To: Toerless Eckert , Gorry Fairhurst > > Cc: Thomas Nadeau , "tcpm@ietf.org" > , "tsvwg@ietf.org" , "Scharf, > Michael > (Nokia - DE/Stuttgart)" , > "tsvwg-chairs@ietf.org" , Katsushi Kobayashi > , Yingzhen Qu > Subject: Re: [tcpm] [tsvwg] inband signaling (was: Re: Agenda requests > for TSVWG@IETF101) > Message-ID: > <1D30AF33624CDD4A99E8C395069A2A162CDB9BA3@sjceml521- > mbs.china.huawei.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi, Gorry/Toerless >=20 > Here is some explanation and clarification for two drafts (draft-han-tsvw= g-cc > and draft-han-6man-in-band-signaling-for-transport-qos) >=20 > 1. About draft-han-tsvwg-cc compared with other CC for bandwidth > guaranteed network, such as gTFRC. > draft-han-tsvwg-cc is a split draft from draft-han-6man-in-band-signaling= -for- > transport-qos . It proposes a new CC for a network if the TCP session's > bandwidth is guaranteed. Here the guaranteed bandwidth is per TCP sessio= n > and described by PIR/CIR and given directly by TCP end user. >=20 > 2. About TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos > >From my understanding, TCP-QS and draft-han-6man-in-band-signaling-for- > transport-qos do have similarity, both are kind of using in-band signalin= g for > the resource reservation. But they still have big difference. > 1). draft-han-6man-in-band-signaling-for-transport-qos is more general in= - > band signaling method, it not only applies to TCP, but also UDP or other > upper layer of protocol, even the draft only exemplifies the method to TC= P. > 2). draft-han-6man-in-band-signaling-for-transport-qos provides reserved > resource for bandwidth and latency for the whole life of TCP session. It = gives > more flavors and more granularity for the QoS (unlike TCP-QS only has 16 > values of starting bandwidth). Moreover, it can support the "worst case > latency" at each hop; also, it can support the OAM to detect the congesti= on > states, and support the "forwarding state" for host to be notified in rea= l-time > about if the resource reservation or QoS forwarding is interrupted by > abnormal situation such as link/node failures. >=20 > Best regards >=20 > Lin >=20 From nobody Wed Mar 14 02:31:44 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4269127876; Wed, 14 Mar 2018 02:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=vodafone.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4_gipXeYjPK; Wed, 14 Mar 2018 02:31:41 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.110]) (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 3CBA3127077; Wed, 14 Mar 2018 02:31:40 -0700 (PDT) Received: from [193.109.255.99] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-6.messagelabs.com id 7E/04-19828-BFBE8AA5; Wed, 14 Mar 2018 09:31:39 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSWUwTURT1dZYOyOijoFwrRG1ECUqlLtjEhJg Yk2o00bh81IVOdaSVaSGdajDxAxNcYl0jwVSNRQVC3BEFquKGVakLihtBMQiGAJVIjKhAXGY6 iDpf59xz3r3nTi5DaO7RWobPdfMuJyfo6Ehy2gLBkzIQKjOnBg5HGG8V+dVGb6iSNAZ9pLGyz qcy3vvYTBufvB4g5tImb3k3MvX3vqRN+Xe7KVNxcZ/KdKi8ll5CmSm705qda6Fs+7wX1TkXJu ceKyih89DRCbtRJKPBVQjyrnwjFFKL4GnNXmpI6WkpRQp5hqDifZ9KIYUqOOYtlUiERFoQeE6 NlTGN50Pg6lu1bIrFOxEcLqmhZIHAApzMD5C7EcPEYDNUXV4kl2PxKqjf9ouSy7F4OvgLZsll EidCVU0tLWMWr4bg51a1MsoCLx9eJWQcgTn42iN3jGAQToAv284QyqQ4aPrgC0cDjKH4ej2h4 FHQ2fYzvBmLByg47umjlcdm8LfvohXTeLj/5PEgToAGnye8PeDLKijruEUpgh6uHOxGCl4Mb3 sb1IqpFcGnPbsGxyVDU0ve4IMsuBloR/KWgLdC7+O1ir+EgOD3F9QBZDjyT3IFT4Wia59pBU+ B0hMh4kj4b0RDnfcDWYTI0yhJ5F2beVeKYabe6rJn2twOzi6kGFLT9A5eFLlMXuCson5dtuMS kq5pmPRVo9flS+6gMYxKN4q9WVBm1oywZq/fYuNEW4Zrk8CLd1A8w+iAHS9dnSbaxWfyuRvsg nSSf2RgonSx7MMuSWbFHM4h2jMVKYhmME1tnTsIprEjtIPQkM5sJ6+NY/2yFctW2ybnUKM/59 2AErQxLJKiaaJyeJfD7v5f70JxDNLFsNVylyi70z00r0uKopKi2CvDUdzcX0mbhyal03PG5A9 j3VbDAWxctbF2ujloEdIaxRvpyxPrmp+PY6N/TCALV8bVDby7YHnjf7Qs/cGbVxP3x+tHxq/p XxrasqI962CgsC1pedrG21WjO09XnJ/nGK7tOdnztCLDb+vb3rK+RPAsVGdQBWmz53U0Rlq26 vae9dc7KvvP+V50PNCRoo0zJBMukfsNJACgVtkDAAA= X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-10.tower-48.messagelabs.com!1521019889!124133746!4 X-Originating-IP: [47.73.108.139] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20994 invoked from network); 14 Mar 2018 09:31:38 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.139) by server-10.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 14 Mar 2018 09:31:38 -0000 Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 14 Mar 2018 10:31:21 +0100 Received: from voxe03hw.internal.vodafone.com (195.232.244.48) by VOEXH09W.internal.vodafone.com (47.73.211.207) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 14 Mar 2018 10:31:21 +0100 Received: from VOEXH07W.internal.vodafone.com (47.73.211.205) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 14 Mar 2018 10:31:19 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (172.17.213.46) by VOEXH07W.internal.vodafone.com (47.73.211.211) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 14 Mar 2018 10:31:17 +0100 Received: from HE1PR05MB3180.eurprd05.prod.outlook.com (10.170.242.154) by HE1PR05MB1306.eurprd05.prod.outlook.com (10.162.250.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 14 Mar 2018 09:31:15 +0000 Received: from HE1PR05MB3180.eurprd05.prod.outlook.com ([fe80::d089:adeb:8614:3774]) by HE1PR05MB3180.eurprd05.prod.outlook.com ([fe80::d089:adeb:8614:3774%13]) with mapi id 15.20.0588.013; Wed, 14 Mar 2018 09:31:15 +0000 From: "Smith, Kevin, (R&D) Vodafone Group" To: Ingemar Johansson S , "Lin.Han@huawei.com" , "tte@cs.fau.de" CC: "tcpm@ietf.org" , "tsvwg@ietf.org" , "'iccrg@irtf.org'" Thread-Topic: [tsvwg] [tcpm] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) Thread-Index: AdO7ZqLf99MPKZX+ToKs31yM2w2JXQADj8pQ Date: Wed, 14 Mar 2018 09:31:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Ref=https://api.informationprotection.azure.com/api/68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Kevin.Smith@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2018-03-14T09:31:13.2478936+00:00; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=[C2] - Internal; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; Sensitivity=[C2] - Internal x-originating-ip: [82.44.224.71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR05MB1306; 7:B0C5zIxjwgExV3tk3lmGvU0wcjXYv3AfFKB2uCSaVb8Yi4natoG1s5Gg5PNXP9ScGyYk7yeBNs4Fjztxjl3mEO1Xcuk9EQJHEC27YJbooYmyo/LGf8EscRzu5/kThz2BC86GP6wPkNZn8M1h4mgZmTQ8BaRXZJMkYwEdeiYJKRa5YnCen1H9sla35VvJLQJ2Yj7EkblvHcXaMPEDHiJvPqjxPH9ezT8UgIbK/BFfISPof1EaC22q8yMgS/9Ceiej x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8038049b-8d32-47d2-79ac-08d5898e55aa x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR05MB1306; x-ms-traffictypediagnostic: HE1PR05MB1306: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(130329453890623)(213716511872227); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:HE1PR05MB1306; BCL:0; PCL:0; RULEID:; SRVR:HE1PR05MB1306; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39380400002)(366004)(39860400002)(396003)(13464003)(199004)(189003)(6246003)(8936002)(53546011)(102836004)(2900100001)(59450400001)(33656002)(26005)(105586002)(106356001)(305945005)(74316002)(55236004)(2950100002)(229853002)(6506007)(76176011)(53936002)(97736004)(3660700001)(5250100002)(81166006)(9686003)(14454004)(55016002)(3280700002)(4326008)(6436002)(186003)(25786009)(316002)(7696005)(2501003)(2201001)(8676002)(7736002)(6116002)(2906002)(68736007)(5660300001)(110136005)(72206003)(3846002)(54906003)(66066001)(99286004)(86362001)(81156014)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR05MB1306; H:HE1PR05MB3180.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XSe9JwBXy3YUhA0TTq1arwgyvIuCdQkUZ8AB2Bsk14Uj6AvcC8PRSQR+p3ijAsA6o2iAoyZr9Av9G+MQDP1xExe532pYa0dDSCLKWyp+A3feeUuEnGAPRLQbDNz9U/szyIuG8YtO4vh1FBw3B6a3ypwu7MFH/eXP9bxKNltO6yNnl+Mqm8mTs/7KtJS1tNhuBmNU9b2gBRHqtw9ZK7by5jQY2l3PA+9TDd/u+VqL7TiBNuI7VrvGFt6eNHkvnQzaAVxoFQQ3Cf9SX0kzYvf49t+qjgNUOhTPciq0QWP+Ctz32Wv2Zqcbfk31w4l42pdlXCbu7ByH0Spo1d5ePq2m4w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafone.onmicrosoft.com; s=selector1-vodafone-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tVpQ2hz9Li4vFmAtyfQXNNirUBn8yyePajiJU16iuhE=; b=Mi8V7ecWbhhJB31hSnxj76EBpeq6Bq2tACG4JMswX1wlMiswtr3SRbRKB+rT5Yb5hCOhRyD8jITQEq8ADhz+APSfvUNFINGBfNcY/DyLmL5jlxEw9hqMxXgV5UtxMfswGIyFtfVtVJZCxRaOUMqkZxnqQjvrg83wADI9RKxbM0A= x-ms-exchange-crosstenant-network-message-id: 8038049b-8d32-47d2-79ac-08d5898e55aa x-ms-exchange-crosstenant-originalarrivaltime: 14 Mar 2018 09:31:15.6827 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893 x-ms-exchange-transport-crosstenantheadersstamped: HE1PR05MB1306 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: vodafone.com Archived-At: Subject: Re: [tsvwg] [tcpm] inband signaling (was: Re: Agenda requests for TSVWG@IETF101) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 09:31:44 -0000 HI Ingemar, > The 3GPP QoS framework can be used to offer for instance a Guaranteed ban= dwidth (GBR) to applications. The operation is that the "bearer" gets incre= ased scheduling priority once the throughput is below the GBR value. That is technically correct: but a consideration to note here is that in LT= E, operators typically operate only two bearers - one for IMS/VoLTE, which = is GBR; and one 'best effort' (non-GBR) bearer for Internet traffic. This = is likely due to non-technical reasons. Hence I also favour a bearer*-agnostic approach such as L4S, but appreciate= that L4S will also have to operate within the constraints of the radio sch= eduler (which will still be 'best effort') For 5G, certainly there can be more flexible and holistic scheduling approa= ches. For practical implementation though, all 'prioritisations' will need = to meet regulatory directives on traffic management. * i.e. GBR vs non-GBR bearer All best, Kevin Vodafone Proprietary classified as C2 - Internal -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ingemar Johansson = S Sent: 14 March 2018 07:56 To: Lin.Han@huawei.com; tte@cs.fau.de Cc: Ingemar Johansson S ; tcpm@ietf.org; = tsvwg@ietf.org; 'iccrg@irtf.org' Subject: Re: [tsvwg] [tcpm] inband signaling (was: Re: Agenda requests for = TSVWG@IETF101) Hi This subject pops up every once in a while. I would like to add my perspective, given how I understand that 3GPP techno= logy works. The 3GPP QoS framework can be used to offer for instance a Guar= anteed bandwidth (GBR) to applications. The operation is that the "bearer" = gets increased scheduling priority once the throughput is below the GBR val= ue. In simulations I have verified that this framework can deliver a GBR to TCP= flows when the network load increases, at least as long it is possible to = push back other bearers with a lower priority. So, seen from my experience = so far I am not fully confident that additional inband signaling is needed. There can however be a benefit to e.g. determine an appropriate bitrate for= a DASH session, depending on network load and/or coverage, but I would arg= ue that out of band signaling is better in this case. As regards to "worst case latency", I am not sure that I follow here, are w= e discussing TSN/Detnet technology here, general link failures, or is it ab= out means to control the queue delay in the network ?. As to the latter, I = believe that it is worthwhile to look more closely at L4S. Regards Ingemar Johansson > Message: 2 > Date: Tue, 13 Mar 2018 19:27:18 +0000 > From: Lin Han > To: Toerless Eckert , Gorry Fairhurst > > Cc: Thomas Nadeau , "tcpm@ietf.org" > , "tsvwg@ietf.org" , "Scharf, Michael > (Nokia - DE/Stuttgart)" , > "tsvwg-chairs@ietf.org" , Katsushi Kobayashi > , Yingzhen Qu > Subject: Re: [tcpm] [tsvwg] inband signaling (was: Re: Agenda requests > for TSVWG@IETF101) > Message-ID: > <1D30AF33624CDD4A99E8C395069A2A162CDB9BA3@sjceml521- > mbs.china.huawei.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi, Gorry/Toerless > > Here is some explanation and clarification for two drafts > (draft-han-tsvwg-cc and > draft-han-6man-in-band-signaling-for-transport-qos) > > 1. About draft-han-tsvwg-cc compared with other CC for bandwidth > guaranteed network, such as gTFRC. > draft-han-tsvwg-cc is a split draft from > draft-han-6man-in-band-signaling-for- > transport-qos . It proposes a new CC for a network if the TCP > session's bandwidth is guaranteed. Here the guaranteed bandwidth is > per TCP session and described by PIR/CIR and given directly by TCP end us= er. > > 2. About TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos > >From my understanding, TCP-QS and > >draft-han-6man-in-band-signaling-for- > transport-qos do have similarity, both are kind of using in-band > signaling for the resource reservation. But they still have big differenc= e. > 1). draft-han-6man-in-band-signaling-for-transport-qos is more general > in- band signaling method, it not only applies to TCP, but also UDP or > other upper layer of protocol, even the draft only exemplifies the method= to TCP. > 2). draft-han-6man-in-band-signaling-for-transport-qos provides > reserved resource for bandwidth and latency for the whole life of TCP > session. It gives more flavors and more granularity for the QoS > (unlike TCP-QS only has 16 values of starting bandwidth). Moreover, it > can support the "worst case latency" at each hop; also, it can support > the OAM to detect the congestion states, and support the "forwarding > state" for host to be notified in real-time about if the resource > reservation or QoS forwarding is interrupted by abnormal situation such a= s link/node failures. > > Best regards > > Lin > From nobody Wed Mar 14 09:42:06 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B7312D0C3 for ; Wed, 14 Mar 2018 09:42:00 -0700 (PDT) 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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI4ijz1TZAyp for ; Wed, 14 Mar 2018 09:41:59 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1D612D778 for ; Wed, 14 Mar 2018 09:41:57 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id y127so2388419vky.9 for ; Wed, 14 Mar 2018 09:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NgufUYOCuD/nQpCno1XG5E5kgLwWZwXg6Sz7GEfJTio=; b=XwtHOA/UflS+ECjIap5zpmk3uxlK73jV8kddrf7xDFCenTJxPthlp6Y1Jtz9kU0t/z KQWzLhU/8mgb8kJ7pj9ECedCkePuz/fR8z6z0D/77QspGpJfGrz0LhuzwLLQ3SEYq6wM LByvcktcJV5dTyh22Yz1LT3QACOfKknSAgMVo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NgufUYOCuD/nQpCno1XG5E5kgLwWZwXg6Sz7GEfJTio=; b=s1/7PhzuNMAUUL6LoXlvmn6GfVKr4RBUiPKhYVuNZyAJStf6kePneSquYf1yhcGdky Hl5MFluFghHLlgwJ0OqL6mEBs3Kl2F/fxOdtu1irztRo5M7+QZ+0NC9cYYrWp8lNynty TMSb8n+Zfoa9aw0cr7h/BaUbOQNceJYtp8/pmUZjGAZFYQGJ5j/9jA11mGh+cudHo1CR hw8TMoSXemeEc1z7HO842RrTyOrAzcTRPzbQkRHChgbBTws0+1bn+OZTxAg7tp44f9RP veX1Tzt2k34KYc0apPQAyt5PUv4VJm3ONq7py63yWzQ5SII6ZuTRv1idLr3b/M2tbr/8 +Htg== X-Gm-Message-State: AElRT7EcsXeB7oGCTKVdxoFfRx7LiA4L5hJ1KkRu4eRUMzk7qnhc7WGQ jLlAivPuskW4Gjt7+nZoxwtMeHecxcPX5wVFCfwywQ== X-Google-Smtp-Source: AG47ELv0RAGXISXU0kZrUlCUgMCJtIFODANSvobVh+g2HFw30A0AdtWt59ZdRT7wx4kI5Ov5edCJqnoQP/uL2hwENaY= X-Received: by 10.31.138.129 with SMTP id m123mr3788202vkd.13.1521045716132; Wed, 14 Mar 2018 09:41:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.196 with HTTP; Wed, 14 Mar 2018 09:41:55 -0700 (PDT) In-Reply-To: <5A9BEB65.6010102@erg.abdn.ac.uk> References: <5A9BEB65.6010102@erg.abdn.ac.uk> From: Pat Thaler Date: Wed, 14 Mar 2018 09:41:55 -0700 Message-ID: To: Gorry Fairhurst Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , Thomas Nadeau , "tcpm@ietf.org" , Yingzhen Qu , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , DetNet Chairs Content-Type: multipart/alternative; boundary="001a1145762299574e0567620d53" Archived-At: Subject: Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 16:42:01 -0000 --001a1145762299574e0567620d53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There work underway in detnet WG in the routing area for " point-to-point (unicast) and point-to-multipoint (multicast) flows which can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no longer required." The purpose is to provide for bounded latency, loss and delay variation along with high reliability. The current charter is focused on defining the data plane aspects. I hope that that will be followed by work to define the control plane. I've only had a quick glance at the draft. It isn't clear to me that it would be compatible with a network providing reservations for guaranteed bandwidth because it allows for sending at a rate higher than the bandwidth guarantee; (i.e. a peak rate higher than the committed rate). If flows are allowed to consume more than their reserved resources, they may interfere with the resources committed to other flows. Pat On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst wrote: > I am unsure yet what the correct group of people world be to explore a > "Bandwidth Guaranteed Network". The presentation last IETF looked like th= e > work could imply a need for changes proposed to the network layer (using > OAM exchnages) to set the sending rate and make those bandwidth > reservations. In the end, it could result in a protocol quite different = to > TCP, I think this sort of change may possibly have a home in TSVWG - but > first I'd agree with Michaeland would encourage a presentation of the > problem statement in ICCRG to explore the issues. > > Gorry > > On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > >> >> Hi all, >> >> From the abstract: =E2=80=9C=E2=80=A6This draft proposes a new TCP conge= stion control >> algorithm used in bandwidth guaranteed networks. It is an extension to = the >> current TCP standards.=E2=80=9D >> >> In the IETF, I believe the expertise for this specific document would be >> in TCPM, which in CC. If the authors are interested in feedback on the >> proposed mechanism, I would recommend to ask TCPM. >> >> Alternatively, corresponding research could perhaps be performed in the >> ICCRG. ICCRG has published RFC 6077 to document some of the open researc= h >> issues in this space. >> >> Michael >> >> *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu >> *Sent:* Sunday, March 04, 2018 6:55 AM >> *To:* tsvwg@ietf.org; tsvwg-chairs@ietf.org >> *Cc:* Thomas Nadeau >> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101 >> >> Dear Chairs, >> >> A new draft (The draft was suggested by TSVWG @IETF100) was just >> submitted, and we=E2=80=99d like to request a time slot to present it @I= ETF101. >> >> Title:A New Congestion Control in Bandwidth Guaranteed Network >> >> Presenter: Yingzhen Qu (Huawei) >> >> Time required (including Q/A): 10 mins >> >> Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/ >> >> If there is any question, please kindly let us know. >> >> Thanks, >> >> Yingzhen >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a1145762299574e0567620d53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There work underway in detnet WG in the routing area for= =C2=A0" point-to-point (unicast) and point-to-multipoint (multicast) f= lows which can be characterized in a manner that allows the network to 1) r= eserve the appropriate resources for the flows in advance, and 2) release/r= euse the resources when they are no longer required."=C2=A0 The purpos= e is to provide for bounded latency, loss and delay variation along with hi= gh reliability. The current charter is focused on defining the data plane a= spects. I hope that that will be followed by work to define the control pla= ne.

I've only had a quick glance at the draft. It is= n't clear to me that it would be compatible with a network providing re= servations for guaranteed bandwidth because it allows for sending at a rate= higher than the bandwidth guarantee; (i.e. a peak rate higher than the com= mitted rate). If flows are allowed to consume more than their reserved reso= urces, they may interfere with the resources committed to other flows.=C2= =A0

Pat

<= div class=3D"gmail_quote">On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst <= span dir=3D"ltr"><gorry@erg.abdn.ac.uk> wrote:
I am unsure yet what the correct group of people world be to explore = a "Bandwidth Guaranteed Network". The presentation last IETF look= ed like the work could imply a need for changes proposed to the network lay= er (using OAM exchnages) to set the sending rate and make those bandwidth r= eservations.=C2=A0 In the end, it could result in a protocol quite differen= t to TCP, I think this sort of change may possibly have a home in TSVWG=C2= =A0 - but first I'd agree with Michaeland would encourage a presentatio= n of the problem statement in ICCRG to explore the issues.

Gorry

On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

Hi all,

>From the abstract: =E2=80=9C=E2=80=A6This draft proposes a new TCP congesti= on control algorithm used in bandwidth guaranteed networks.=C2=A0 It is an = extension to the current TCP standards.=E2=80=9D

In the IETF, I believe the expertise for this specific document would be in= TCPM, which in CC. If the authors are interested in feedback on the propos= ed mechanism, I would recommend to ask TCPM.

Alternatively, corresponding research could perhaps be performed in the ICC= RG. ICCRG has published RFC 6077 to document some of the open research issu= es in this space.

Michael

*From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Yingzhen Qu
*Sent:* Sunday, March 04, 2018 6:55 AM
*To:* tsvwg@ietf.org; tsvwg-chairs@= ietf.org
*Cc:* Thomas Nadeau <tnadeau@lucidvision.com>
*Subject:* [tsvwg] Agenda requests for TSVWG@IETF101

Dear Chairs,

A new draft (The draft was suggested by TSVWG @IETF100) was just submitted,= and we=E2=80=99d like to request a time slot to present it @IETF101.

Title:A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/dra= ft-han-tsvwg-cc/

If there is any question, please kindly let us know.

Thanks,

Yingzhen


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

--001a1145762299574e0567620d53-- From nobody Wed Mar 14 11:03:15 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00360126C19 for ; Wed, 14 Mar 2018 11:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km6ke9u-QCs4 for ; Wed, 14 Mar 2018 11:03:12 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 16E0C120047 for ; Wed, 14 Mar 2018 11:03:12 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 26CCB35272C8C for ; Wed, 14 Mar 2018 18:03:08 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 14 Mar 2018 18:03:09 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 11:03:07 -0700 From: John Kaippallimalil To: Tom Herbert CC: "tsvwg@ietf.org" , "panrg@irtf.org" Thread-Topic: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt Thread-Index: AQHTiyCYglhdXUh09ku6IE/yZDJKraPPAZxggACc6gCAAIIGQA== Date: Wed, 14 Mar 2018 18:03:06 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171F965A81@sjceml521-mbs.china.huawei.com> References: <151569998986.1808.5962574573199407272.idtracker@ietfa.amsl.com> <6561EABF52675C45BCDACA1B4D7AA1171F965700@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 18:03:14 -0000 SGksIFRvbSwNClRoYW5rcyBmb3IgdGhlIGFuc3dlcnMgLSBzb21lIGZvbGxvdyB1cCBxbnMgJiBj b21tZW50cyBiZWxvdy4NCg0KPiAgICAgICAgSW4gZXZlcnkgcGFja2V0LiBUaGlzIHdheSB0aGUg bmV0d29yayBkb2VzIG5vdCBuZWVkIHRvIGNyZWF0ZSBmbG93IHN0YXRlLCBpdCBqdXN0IHJlYWRz IGFuZCBwcm9jZXNzZXMgdGhlIHRpY2tldHMgYXMgdGhleSBwcmVzZW50ZWQuDQpGb3IgZWFjaCBw YWNrZXQgdGhlIHJvdXRlciB3b3VsZCBuZWVkIHRvIGRlY3J5cHQgYW5kIHRoZW4gYXBwbHkgdGhh dCBwb2xpY3kgZm9yIGFkbWlzc2lvbiBjb250cm9sL3NoYXBpbmcvc2NoZWR1bGluZy4NClRoZSBj b3N0IG9mIGRlY3J5cHRpbmcgcGVyIHBhY2tldCB2cy4gbWVtb3J5IGxvb2t1cCBvZiBzdGF0ZSBp bmZvIHNlZW0gdG8gaGF2ZSBkaWZmZXJlbnQgdHJhZGUtb2Zmcy4NCkZvciBpbmZyZXF1ZW50IHBh Y2tldHMgLyBkYXRhZ3JhbXMgLSBjYXJyeWluZyBzdGF0ZSBpbiBlYWNoIHRpY2tldCB3b3VsZCBi ZSBlZmZpY2llbnQsIGJ1dCBtYXkgbm90IGJlIHRoZSBzYW1lIGZvciBhIGhpZ2ggYmFuZHdpZHRo IGZsb3cuDQpBbHNvIHJvdXRlcnMgKGxpa2UgbW9iaWxlIG5ldHdvcmsgVVBGcykgaG9sZCBzdGF0 ZSBhbnl3YXkgZm9yIGltcGxlbWVudGluZyBmb3J3YXJkaW5nIHBvbGljeSBiYXNlZCBvbiBzdWJz Y3JpcHRpb24gKGJhbmR3aWR0aCwgZGVsYXksIGppdHRlciBjbGFzc2VzIGJhc2VkIG9uIFFDSSku DQoNCk15IGludGVudGlvbiB3aXRoIEZBU1QgdGlja2V0IHdhcyB0byBjb252ZXkgcmVsYXRpdmUg aGFuZGxpbmcgcHJlZmVyZW5jZXMgZm9yIGEgY29ubmVjdGlvbiBzZXNzaW9uIChQRFUpIHRoYXQg aGFzIG11bHRpcGxlIGZsb3dzIChjb25uZWN0aW9uIHNlc3Npb24gaGFzIHBvbGljeSwgYnV0IG5v dCBlYWNoIGZsb3cpIA0KQXMgZG9jdW1lbnRlZCBpbiB0aGUgZHJhZnQsIHRoZSBjdXJyZW50IG1l Y2hhbmlzbSBvZiB1c2luZyBEUEkgZm9yIHRoaXMgd291bGQgbm90IHdvcmsgaWYgdGhlIHBhY2tl dHMgYXJlIGVuY3J5cHRlZC4NCg0KDQo+ICAgICAgICBZZXMsIHRoZXkgc2hvdWxkIGJlLiBJbiB0 aGUgY2FzZSBvZiBJTEEgZm9yIGluc3RhbmNlLCB0aGUgdGlja2V0IGlzIGNyZWF0ZWQgYmFzZWQg b24gaWRlbnRpZmllciBhZGRyZXNzZXMgd2hpY2ggZG9uJ3QgY2hhbmdlIGFjcm9zcyBhIG1vYmls ZSBldmVudC4NClRoZSBpZGVudGlmaWVyIGFkZHJlc3MgZG9uJ3QgY2hhbmdlLCBidXQgdGhlIHVu ZGVybHlpbmcgcmVzb3VyY2UgL2xpbmtzIGFuZCByb3V0ZXJzIGNoYW5nZSAtIGFuZCB3aXRoIHNs b3cvc3RhcnQgdGhhdCB3b3VsZCBiZSB0YWtlbiBpbnRvIGNvbnNpZGVyYXRpb24uDQpJcyB0aGUg cG9pbnQgdGhhdCB0aGUgdGlja2V0IHdvdWxkIGJlIHZhbGlkIGZvciB0aGF0IGlkZW50aWZpZXIu IEFuZCB3aGVuIHByZXNlbnRlZCB0byB0aGUgbmV3IHJvdXRlciwgaXQgd291bGQgZ3JhbnQgcmVz b3VyY2VzIGFjY29yZGluZ2x5IGFuZCB0aHVzIHNsb3cgc3RhcnQgaXMgbm90IG5lZWRlZC4NCg0K QnV0IEknbSBub3Qgc3VyZSBpdHMgdGhhdCBzaW1wbGUgLSB0aGUgc2NoZWR1bGVyIHdvdWxkIHdh bnQgdG8gbWF4aW1pemUgdXRpbGl6YXRpb24gd2hpbGUgYmVpbmcgZmFpciAtIHNvIGlmIG5ldyBm bG93cyBjb21lIGluIHN1ZGRlbmx5IGR1cmluZyBoaWdoIHV0aWxpemF0aW9uLCBpdCB3b3VsZCBu ZWVkIG1vcmUgdGhhbiB0aGlzIEkgdGhpbms/DQoNCkJSLA0KSm9obiANCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBxdWFudG9u aXVtLm5ldF0gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAxOCA2OjA1IFBNDQpUbzogSm9o biBLYWlwcGFsbGltYWxpbCA8Sm9obi5LYWlwcGFsbGltYWxpbEBodWF3ZWkuY29tPg0KQ2M6IHRz dndnQGlldGYub3JnOyBwYW5yZ0BpcnRmLm9yZw0KU3ViamVjdDogUmU6IFt0c3Z3Z10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhlcmJlcnQtZmFzdC0wMC50eHQNCg0K T24gVHVlLCBNYXIgMTMsIDIwMTggYXQgMzozMCBQTSwgSm9obiBLYWlwcGFsbGltYWxpbCA8Sm9o bi5LYWlwcGFsbGltYWxpbEBodWF3ZWkuY29tPiB3cm90ZToNCj4gVG9tLA0KPiBJIHJlYWQgdGhp cyBkcmFmdCBhbmQgbGlrZSB0aGUgb3ZlcmFsbCBhcHByb2FjaCAobXkgcG9pbnQgb2YgdmlldyBp cyB0aGUgbW9iaWxlIG5ldHdvcmspLg0KPg0KSGkgSm9obiwNCg0KVGhhbmtzIGZvciB5b3VyIHF1 ZXN0aW9ucyENCg0KPiBBIGZldyBvZiBxdWVzdGlvbnM6DQo+IDEuICBJIHN1cHBvc2UgdGhhdCB0 aGVzZSB0aWNrZXRzIGRvIG5vdCBoYXZlIHRvIGJlIHNlbnQgaW4gZXZlcnkgcGFja2V0Lg0KPiBB cmUgdGhleSBzZW50IHN0YXRpc3RpY2FsbHksIG9yIGp1c3QgaW4gYSBmZXcgcGFja2V0cyBhZnRl ciBhIGNoYW5nZSBvciBzb21lIGV2ZW50Lg0KPg0KSW4gZXZlcnkgcGFja2V0LiBUaGlzIHdheSB0 aGUgbmV0d29yayBkb2VzIG5vdCBuZWVkIHRvIGNyZWF0ZSBmbG93IHN0YXRlLCBpdCBqdXN0IHJl YWRzIGFuZCBwcm9jZXNzZXMgdGhlIHRpY2tldHMgYXMgdGhleSBwcmVzZW50ZWQuDQoNCj4gMi4g bXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHJvdXRlcnMgb24gcGF0aCB3b3VsZCB0cnkgdG8gaW5z cGVjdCBhbGwgdGlja2V0cyB0byBkZXRlcm1pbmUgd2hpY2ggb25lcyBhcmUgZm9yIHRoYXQgc2Vy dmljZSBwcm92aWRlci4NCj4gV291bGQgaXQgbWFrZSBzZW5zZSB0byBleHBsaWNpdGx5IGNvbnZl eSB0aGF0IGluIE9wdGlvbiBGb3JtYXQvVGlja2V0ICg0LjEpIC0gbGlrZSBhIHJlYWxtIC8gZG9t YWluIG5hbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIuDQo+IE9yIGNhbiB0aGlzIGJlIGRlcml2 ZWQgZnJvbSBzb21lIGNvbWJpbmF0aW9uIG9mIHRoZSBvcHRpb24gdHlwZSAoaG9wLWJ5LWhvcC8g ZGVzdGluYXRpb24pIGFuZCAiVHlwZSIgZmllbGRzLg0KPg0KSSB0aG91Z2h0IGFib3V0IGFkZGlu ZyBhbiBpZGVudGlmaWVyIHRvIHRpY2tldHMgKGxpa2UgQVMgbnVtYmVyKSwgYnV0IEkgdGhpbmsg dGhhdCBpcyBwcm9iYWJseSBub3QgbmVlZGVkLiBUaWNrZXRzIGFyZSBwcm9iYWJseSBvbmx5IGFw cGxpY2FibGUgaW4gZWRnZSBwcm92aWRlciBuZXR3b3Jrcywgbm90IGluIGNvcmUgSW50ZXJuZXQu IFNvIHRoZXJlIG1pZ2h0IGJlIHVwIHRvIHR3byB0aWNrZXRzIGluIGEgcGFja2V0LCBvbmUgdGhh dCBpcyByZWxldmFudCB0byB0aGUgc291cmNlIHByb3ZpZGVyIGFuZCBvbmUgdGhhdCBpcyByZWxl dmFudCB0byB0aGUgcmVtb3RlIHByb3ZpZGVyIChhIHJlZmxlY3RlZCB0aWNrZXQpLiBUaWNrZXRz IGFsc28gbmVlZCB0byBiZSB2ZXJpZmllZCBwcm9iYWJseSB0aHJvdWdoIGRlY3J5cHRpb24gc28g dGhhdCB3b3VsZCBhbHNvIGJlIGFibGUgdG8gZGV0ZWN0IHdoZXRoZXIgaXQgdGlja2V0IGlzIHZh bGlkIGluIHRoZSBuZXR3b3JrIHByb2Nlc3NpbmcgaXQuIEl0IHdpbGwgYmUgYW4gaW50ZXJlc3Rp bmcgY2hhbGxlbmdlIHRvIHNlZSBob3cgc21hbGwgdGhlIHRpY2tldHMgY2FuIGJlIG1hZGUgd2l0 aG91dCBsb3Npbmcgc2VjdXJpdHkgb3IgZXhwcmVzc2l2ZW5lc3MuDQoNCj4gMy4gQWZ0ZXIgYW4g SVAgYWRkcmVzcyBjaGFuZ2UgKG1vYmlsaXR5IGV2ZW50KSwgVENQIHJhbXAgdXAgYWZmZWN0cyB0 aGUgZmxvdyByYXRlLg0KPiBBc3N1bWluZyB1c2UgY2FzZXMgbGlrZSBWMlggKGFuZCBJTEEpIHdo ZXJlIG1vYmlsaXR5IGV2ZW50cyBhcmUgDQo+IGZyZXF1ZW50IC0gQ291bGQgYSBwYWNrZXQgd2l0 aCB0aWNrZXQgY29udmV5aW5nIGVzdGFibGlzaGVkIGZsb3cgKyBRb1MgaW5mbyBiZSB1c2VkIHRv IHNhZmVseSBjb250aW51ZS9ub3QgaGF2ZSB0byByYW1wIHVwIGV2ZXJ5IHRpbWUgdGhlcmUgaXMg YSBjaGFuZ2Ugb2YgSVAgYXR0YWNobWVudCBwb2ludC4NCg0KWWVzLCB0aGV5IHNob3VsZCBiZS4g SW4gdGhlIGNhc2Ugb2YgSUxBIGZvciBpbnN0YW5jZSwgdGhlIHRpY2tldCBpcyBjcmVhdGVkIGJh c2VkIG9uIGlkZW50aWZpZXIgYWRkcmVzc2VzIHdoaWNoIGRvbid0IGNoYW5nZSBhY3Jvc3MgYSBt b2JpbGUgZXZlbnQuDQoNClRvbQ0KDQo+DQo+IFRoYW5rcywNCj4gSm9obg0KPg0KPg0KPg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb20gSGVyYmVydA0KPiBTZW50OiBUaHVyc2Rh eSwgSmFudWFyeSAxMSwgMjAxOCAzOjA5IFBNDQo+IFRvOiB0c3Z3Z0BpZXRmLm9yZzsgcGFucmdA aXJ0Zi5vcmcNCj4gU3ViamVjdDogW3RzdndnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgDQo+IGRyYWZ0LWhlcmJlcnQtZmFzdC0wMC50eHQNCj4NCj4gSGVsbG8sDQo+DQo+IEkg cG9zdGVkIHRoaXMgZHJhZnQgb24gIkZpcmV3YWxsIGFuZCBTZXJ2aWNlIFRpY2tldHMiIGRyYWZ0 LiBUaGlzIGlzIGEgcHJvcG9zZWQgbWV0aG9kIHRvIGFsbG93IGhvc3RzIGFuZCBhcHBsaWNhdGlv bnMgdG8gc2lnbmFsIHRoZSBuZXR3b3JrIHRvIG1ha2UgcmVxdWVzdHMgZm9yIHNlcnZpY2VzIHRv IGJlIGFwcGxpZWQgdG8gZmxvd3MuIFRoZSBjb25jZXB0IG9mIGEgcmljaCBhbmQgZXh0ZW5zaWJs ZSAgcHJvdG9jb2wgdG8gc2lnbmFsIHRoZSBuZXR3b3JrIHdhcyBpbnNwaXJlZCBieSB0aGUgU1BV RC9QTFVTIHdvcmssIGhvd2V2ZXIgdGhpcyBwcm9wb3NhbCB1c2VzIElQdjYgZXh0ZW5zaW9uIGhl YWRlcnMgaW5zdGVhZCBvZiBVRFAgc2hpbSBoZWFkZXJzIGFuZCB0cmllcyB0byBzdHJpY3RseSBj b250cm9sIGV4cG9zdXJlIGFwcGxpY2F0aW9uIGNoYXJhY3RlcmlzdGljcyBvciBjb250ZW50IHRv IHVudHJ1c3RlZCBwYXJ0aWVzLg0KPg0KPiBJJ3ZlIGNyb3NzIHBvc3RlZCB0aGlzIHRpIHRzdndn IGFuIHBhbnJnIGFzIEknbSBub3QgeWV0IHN1cmUgd2hlcmUgdGhpcyB3b3JrIHdvdWxkIGJlbG9u Zy4NCj4NCj4gQW55IGZlZWRiYWNrIGlzIHZlcnkgd2VsY29tZSENCj4NCj4gVGhhbmtzLA0KPiBU b20NCj4NCj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQo+IEZyb206 ICA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiBEYXRlOiBUaHUsIEphbiAxMSwgMjAxOCBh dCAxMTo0NiBBTQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWhlcmJlcnQtZmFzdC0wMC50eHQNCj4gVG86IFRvbSBIZXJiZXJ0IDx0b21AcXVhbnRvbml1bS5u ZXQ+DQo+DQo+DQo+DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oZXJiZXJ0LWZhc3Qt MDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9tIEhlcmJlcnQgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPg0KPiBOYW1lOiAgICAgICAgICAgZHJh ZnQtaGVyYmVydC1mYXN0DQo+IFJldmlzaW9uOiAgICAgICAwMA0KPiBUaXRsZTogICAgICAgICAg RmlyZXdhbGwgYW5kIFNlcnZpY2UgVGlja2V0cw0KPiBEb2N1bWVudCBkYXRlOiAgMjAxOC0wMS0x MQ0KPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAg ICAgICAyMQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWhlcmJlcnQtZmFzdC0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhlcmJlcnQtZmFzdC8NCj4gSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZXJiZXJ0LWZhc3Qt MDANCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaGVyYmVydC1mYXN0LTAwDQo+DQo+DQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgRmlyZXdhbGxzIGFuZCBTZXJ2aWNlIFRpY2tldHMgcHJvdG9j b2wuIEENCj4gICAgdGlja2V0IGlzIGRhdGEgdGhhdCBhY2NvbXBhbmllcyBhIHBhY2tldCBhbmQg aW5kaWNhdGVzIGEgZ3JhbnRlZA0KPiAgICByaWdodCB0byB0cmF2ZXJzZSBhIG5ldHdvcmsgb3Ig YSByZXF1ZXN0IGZvciBuZXR3b3JrIHNlcnZpY2UgdG8gYmUNCj4gICAgYXBwbGllZC4gQXBwbGlj YXRpb25zIHJlcXVlc3QgdGlja2V0cyBmcm9tIGEgbG9jYWwgYWdlbnQgaW4gdGhlDQo+ICAgIG5l dHdvcmsgYW5kIGF0dGFjaCBpc3N1ZWQgdGlja2V0cyB0byBwYWNrZXRzLiBGaXJld2FsbCB0aWNr ZXRzIGFyZQ0KPiAgICBpc3N1ZWQgdG8gZ3JhbnQgcGFja2V0cyB0aGUgcmlnaHQgdG8gdHJhdmVy c2UgYSBuZXR3b3JrOyBzZXJ2aWNlDQo+ICAgIHRpY2tldHMgaW5kaWNhdGUgdGhlIGRlc2lyZWQg c2VydmljZSB0byBiZSBhcHBsaWVkIHRvIGEgcGFja2V0cy4gQQ0KPiAgICBzaW5nbGUgdGlja2V0 IG1heSBwcm92aWRlIGJvdGggZmlyZXdhbGwgYW5kIHNlcnZpY2UgdGlja2V0DQo+ICAgIGluZm9y bWF0aW9uLiBUaWNrZXRzIGFyZSBzZW50IGluIGVpdGhlciBJUHY2IERlc3RpbmF0aW9uIG9wdGlv bnMgb3INCj4gICAgSG9wLWJ5LUhvcCBvcHRpb25zLg0KPg0KPg0KPg0KPg0KPiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo= From nobody Wed Mar 14 11:59:46 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A205126DED for ; Wed, 14 Mar 2018 11:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUZgCmGIks6j for ; Wed, 14 Mar 2018 11:59:42 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 9B44A126C26 for ; Wed, 14 Mar 2018 11:59:41 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id f14so5825981wre.8 for ; Wed, 14 Mar 2018 11:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5LPwKBYdFqQWm5IZM6HF4rKqQOAu2BDXo7pzouQKwYA=; b=BJBtVwoalFSTlESXSkBvkvBOAq/2yor6psSraRdlJzZQnfgUgXHp1mSeekUnmmB1t9 LMFhr4dROgEte+BRKcAYqK04CLXE6bsEZZK8AoIkoTXkX9+bF4D+yZFHH3Eqybq2IeCf mMKAfw0B9mfAAYUaA8CohuMhEeALK/Rbgpk9DNm/Xg3U+l4dyumqLGxaSirDNtKgJi4N a/XC60Fs8PHouontKWSA27w04KB6HSlMHghhTiI1UM2H36qR/kEZzl7E41c5QR4tngev 8pCKI10oWnAWRH2bCdfmWPTLf4iHK2ZTIv+acEyNYaE+3jmTIqJdLSJpxkTGeM7bjlbV QsGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5LPwKBYdFqQWm5IZM6HF4rKqQOAu2BDXo7pzouQKwYA=; b=YPOsUjE5WC6Vs0bwkSIT2G3XjbCYkNcQ7e4lU7MUX58odx1LVqOQvQYcIIzyeEXLpF P1Fq/j2PFQaPwdPgkfhr1or0VVbsuI2xHekZoVLcSAi6ZEXcu+NyhsC9P0T4Kbym/bND lnxmqYlsi7SCUu4/yBkrSMFwVHEf+tu6p1K8YRH5HW/WJXkdq0AJ0Q3Qqrio+X0m4E2n DLg9PcfYGIjXAYot2Bu939c6Yr5cRMYRFUkYUd5TRyKvdfbXlNlMdnj8dgVc99dBZbGM RPGqG1geOg0TA57vBQL47vCeHp0l46lxI+e9lhchPacG37hIowJ/ArFReC1CmoypENcQ g0PA== X-Gm-Message-State: AElRT7FT0nRdSjDWqV8odcRie3kqjVB71s6CYbQZh72OTjLllIyX40by OpnX6VfLSZ58DNdsfteprJ2Sfr/xK2wEAuWRge4dDQ== X-Google-Smtp-Source: AG47ELvMnytXH7DScrPed9nlImCb4dmZfMFiP97GQ3LIEnNhh3HUzgA7OUrS56yWFgnivVMKqZOqBqkpRSF+/h3jlzo= X-Received: by 10.223.150.117 with SMTP id c50mr4936939wra.196.1521053979843; Wed, 14 Mar 2018 11:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.74 with HTTP; Wed, 14 Mar 2018 11:59:39 -0700 (PDT) In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171F965A81@sjceml521-mbs.china.huawei.com> References: <151569998986.1808.5962574573199407272.idtracker@ietfa.amsl.com> <6561EABF52675C45BCDACA1B4D7AA1171F965700@sjceml521-mbs.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171F965A81@sjceml521-mbs.china.huawei.com> From: Tom Herbert Date: Wed, 14 Mar 2018 11:59:39 -0700 Message-ID: To: John Kaippallimalil Cc: "tsvwg@ietf.org" , "panrg@irtf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 18:59:44 -0000 On Wed, Mar 14, 2018 at 11:03 AM, John Kaippallimalil wrote: > Hi, Tom, > Thanks for the answers - some follow up qns & comments below. > >> In every packet. This way the network does not need to create flo= w state, it just reads and processes the tickets as they presented. > For each packet the router would need to decrypt and then apply that poli= cy for admission control/shaping/scheduling. > The cost of decrypting per packet vs. memory lookup of state info seem to= have different trade-offs. > For infrequent packets / datagrams - carrying state in each ticket would = be efficient, but may not be the same for a high bandwidth flow. > Also routers (like mobile network UPFs) hold state anyway for implementin= g forwarding policy based on subscription (bandwidth, delay, jitter classes= based on QCI). > > My intention with FAST ticket was to convey relative handling preferences= for a connection session (PDU) that has multiple flows (connection session= has policy, but not each flow) > As documented in the draft, the current mechanism of using DPI for this w= ould not work if the packets are encrypted. > SInce tickets are not transferable the identity of the bearer needs to be checked. Minimally this would be the source address in the network that ticket was created. It should also include the remote address so that remote peers can't easily reuse tickets to other destination. Anything more specific would require DPI. > >> Yes, they should be. In the case of ILA for instance, the ticket = is created based on identifier addresses which don't change across a mobile= event. > The identifier address don't change, but the underlying resource /links a= nd routers change - and with slow/start that would be taken into considerat= ion. > Is the point that the ticket would be valid for that identifier. And when= presented to the new router, it would grant resources accordingly and thus= slow start is not needed. No, it's independent of slow start. I don't foresee tickets being very dynamic, altough the underlying routing could be. > > But I'm not sure its that simple - the scheduler would want to maximize u= tilization while being fair - so if new flows come in suddenly during high = utilization, it would need more than this I think? > I'm not sure. I think congestion control is still valid. > BR, > John > > > > -----Original Message----- > From: Tom Herbert [mailto:tom@quantonium.net] > Sent: Tuesday, March 13, 2018 6:05 PM > To: John Kaippallimalil > Cc: tsvwg@ietf.org; panrg@irtf.org > Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast= -00.txt > > On Tue, Mar 13, 2018 at 3:30 PM, John Kaippallimalil wrote: >> Tom, >> I read this draft and like the overall approach (my point of view is the= mobile network). >> > Hi John, > > Thanks for your questions! > >> A few of questions: >> 1. I suppose that these tickets do not have to be sent in every packet. >> Are they sent statistically, or just in a few packets after a change or = some event. >> > In every packet. This way the network does not need to create flow state,= it just reads and processes the tickets as they presented. > >> 2. my understanding is that routers on path would try to inspect all tic= kets to determine which ones are for that service provider. >> Would it make sense to explicitly convey that in Option Format/Ticket (4= .1) - like a realm / domain name of the service provider. >> Or can this be derived from some combination of the option type (hop-by-= hop/ destination) and "Type" fields. >> > I thought about adding an identifier to tickets (like AS number), but I t= hink that is probably not needed. Tickets are probably only applicable in e= dge provider networks, not in core Internet. So there might be up to two ti= ckets in a packet, one that is relevant to the source provider and one that= is relevant to the remote provider (a reflected ticket). Tickets also need= to be verified probably through decryption so that would also be able to d= etect whether it ticket is valid in the network processing it. It will be a= n interesting challenge to see how small the tickets can be made without lo= sing security or expressiveness. > >> 3. After an IP address change (mobility event), TCP ramp up affects the = flow rate. >> Assuming use cases like V2X (and ILA) where mobility events are >> frequent - Could a packet with ticket conveying established flow + QoS i= nfo be used to safely continue/not have to ramp up every time there is a ch= ange of IP attachment point. > > Yes, they should be. In the case of ILA for instance, the ticket is creat= ed based on identifier addresses which don't change across a mobile event. > > Tom > >> >> Thanks, >> John >> >> >> >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Tom Herbert >> Sent: Thursday, January 11, 2018 3:09 PM >> To: tsvwg@ietf.org; panrg@irtf.org >> Subject: [tsvwg] Fwd: New Version Notification for >> draft-herbert-fast-00.txt >> >> Hello, >> >> I posted this draft on "Firewall and Service Tickets" draft. This is a p= roposed method to allow hosts and applications to signal the network to mak= e requests for services to be applied to flows. The concept of a rich and e= xtensible protocol to signal the network was inspired by the SPUD/PLUS wor= k, however this proposal uses IPv6 extension headers instead of UDP shim he= aders and tries to strictly control exposure application characteristics or= content to untrusted parties. >> >> I've cross posted this ti tsvwg an panrg as I'm not yet sure where this = work would belong. >> >> Any feedback is very welcome! >> >> Thanks, >> Tom >> >> ---------- Forwarded message ---------- >> From: >> Date: Thu, Jan 11, 2018 at 11:46 AM >> Subject: New Version Notification for draft-herbert-fast-00.txt >> To: Tom Herbert >> >> >> >> A new version of I-D, draft-herbert-fast-00.txt has been successfully su= bmitted by Tom Herbert and posted to the IETF repository. >> >> Name: draft-herbert-fast >> Revision: 00 >> Title: Firewall and Service Tickets >> Document date: 2018-01-11 >> Group: Individual Submission >> Pages: 21 >> URL: https://www.ietf.org/internet-drafts/draft-herbert-fast-= 00.txt >> Status: https://datatracker.ietf.org/doc/draft-herbert-fast/ >> Htmlized: https://tools.ietf.org/html/draft-herbert-fast-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-fast= -00 >> >> >> Abstract: >> This document describes the Firewalls and Service Tickets protocol. A >> ticket is data that accompanies a packet and indicates a granted >> right to traverse a network or a request for network service to be >> applied. Applications request tickets from a local agent in the >> network and attach issued tickets to packets. Firewall tickets are >> issued to grant packets the right to traverse a network; service >> tickets indicate the desired service to be applied to a packets. A >> single ticket may provide both firewall and service ticket >> information. Tickets are sent in either IPv6 Destination options or >> Hop-by-Hop options. >> >> >> >> >> 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 Mar 14 12:03:39 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFBC126C26; Wed, 14 Mar 2018 12:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LViyjZQwzUc4; Wed, 14 Mar 2018 12:03:28 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 1B80B126B72; Wed, 14 Mar 2018 12:03:28 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 23AC9529744C8; Wed, 14 Mar 2018 19:03:24 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 14 Mar 2018 19:03:25 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 12:03:15 -0700 From: Yingzhen Qu To: Pat Thaler , Gorry Fairhurst CC: "Scharf, Michael (Nokia - DE/Stuttgart)" , Thomas Nadeau , "tcpm@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , DetNet Chairs Thread-Topic: [tcpm] Agenda requests for TSVWG@IETF101 Thread-Index: AQHTs31He8dVfiO+dEamE9tKlKhCoqO/3CkggACxfoCAD+dwgIAAJ3wA Date: Wed, 14 Mar 2018 19:03:15 +0000 Message-ID: <1DA14EFC-86A3-4EC4-B583-0FA7AFDAD751@huawei.com> References: <5A9BEB65.6010102@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.167] Content-Type: multipart/alternative; boundary="_000_1DA14EFC86A34EC4B5830FA7AFDAD751huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] [tcpm] Agenda requests for TSVWG@IETF101 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 19:03:31 -0000 --_000_1DA14EFC86A34EC4B5830FA7AFDAD751huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF0LA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4NCg0KRXhhY3RseSB3aGF0IHRoZSBR b1MgcGFyYW1ldGVycyB0byBiZSB1c2VkIGlzIFRCRC4gSW4gdGhlIGRyYWZ0LCB3ZSBkZWZpbmVk IGEgbWluaW11bSBzZXQgc3VjaCBhcyBQSVIvQ0lSL0JTL2xhdGVuY3ksIHNvIGhhcmR3YXJlIHBy b2dyYW1taW5nIG1heSB1c2Ugb25lIG9yIG1vcmUgcGFyYW1ldGVycyBkZXBlbmRpbmcgb24gdGhl IGZlYXR1cmUgcmVxdWlyZW1lbnQuIEZvciBleGFtcGxlLCBmb3IgYmFuZHdpZHRoIHNlbnNpdGl2 ZSBhcHBsaWNhdGlvbiwgY3VzdG9tZXIgY2FuIGdpdmUgUElSL0NJUiAoZXZlbiB5b3UgY2FuIGhh dmUgUElSPUNJUiwgaXQgbWVhbnMgZGV2aWNlIG9ubHkgZ3VhcmFudGVlcyB0aGUgZm9yd2FyZGlu ZyBvZiB0aGUgdHJhZmZpYyBsZXNzIHRoYW4gQ0lSKTsgZm9yIGxhdGVuY3kgc2Vuc2l0aXZlIGFw cGxpY2F0aW9uLCB3ZSBjYW4gaGF2ZSBDSVIgYW5kL29yIGJvdW5kZWQgbGF0ZW5jeSBmb3IgdGhl IHRyYWZmaWMgbGlrZSBDQlIgaW4gVFNOLg0KDQpUaGFua3MsDQpZaW5nemhlbg0KDQpGcm9tOiBQ YXQgVGhhbGVyIDxwYXQudGhhbGVyQGJyb2FkY29tLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgTWFy Y2ggMTQsIDIwMTggYXQgOTo0MiBBTQ0KVG86IEdvcnJ5IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFi ZG4uYWMudWs+DQpDYzogIlNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIiA8 bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPiwgVGhvbWFzIE5hZGVhdSA8dG5hZGVhdUBsdWNpZHZp c2lvbi5jb20+LCAidGNwbUBpZXRmLm9yZyIgPHRjcG1AaWV0Zi5vcmc+LCBZaW5nemhlbiBRdSA8 eWluZ3poZW4ucXVAaHVhd2VpLmNvbT4sICJ0c3Z3Z0BpZXRmLm9yZyIgPHRzdndnQGlldGYub3Jn PiwgInRzdndnLWNoYWlyc0BpZXRmLm9yZyIgPHRzdndnLWNoYWlyc0BpZXRmLm9yZz4sIERldE5l dCBDaGFpcnMgPGRldG5ldC1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIEFn ZW5kYSByZXF1ZXN0cyBmb3IgVFNWV0dASUVURjEwMQ0KDQpUaGVyZSB3b3JrIHVuZGVyd2F5IGlu IGRldG5ldCBXRyBpbiB0aGUgcm91dGluZyBhcmVhIGZvciAiIHBvaW50LXRvLXBvaW50ICh1bmlj YXN0KSBhbmQgcG9pbnQtdG8tbXVsdGlwb2ludCAobXVsdGljYXN0KSBmbG93cyB3aGljaCBjYW4g YmUgY2hhcmFjdGVyaXplZCBpbiBhIG1hbm5lciB0aGF0IGFsbG93cyB0aGUgbmV0d29yayB0byAx KSByZXNlcnZlIHRoZSBhcHByb3ByaWF0ZSByZXNvdXJjZXMgZm9yIHRoZSBmbG93cyBpbiBhZHZh bmNlLCBhbmQgMikgcmVsZWFzZS9yZXVzZSB0aGUgcmVzb3VyY2VzIHdoZW4gdGhleSBhcmUgbm8g bG9uZ2VyIHJlcXVpcmVkLiIgIFRoZSBwdXJwb3NlIGlzIHRvIHByb3ZpZGUgZm9yIGJvdW5kZWQg bGF0ZW5jeSwgbG9zcyBhbmQgZGVsYXkgdmFyaWF0aW9uIGFsb25nIHdpdGggaGlnaCByZWxpYWJp bGl0eS4gVGhlIGN1cnJlbnQgY2hhcnRlciBpcyBmb2N1c2VkIG9uIGRlZmluaW5nIHRoZSBkYXRh IHBsYW5lIGFzcGVjdHMuIEkgaG9wZSB0aGF0IHRoYXQgd2lsbCBiZSBmb2xsb3dlZCBieSB3b3Jr IHRvIGRlZmluZSB0aGUgY29udHJvbCBwbGFuZS4NCg0KSSd2ZSBvbmx5IGhhZCBhIHF1aWNrIGds YW5jZSBhdCB0aGUgZHJhZnQuIEl0IGlzbid0IGNsZWFyIHRvIG1lIHRoYXQgaXQgd291bGQgYmUg Y29tcGF0aWJsZSB3aXRoIGEgbmV0d29yayBwcm92aWRpbmcgcmVzZXJ2YXRpb25zIGZvciBndWFy YW50ZWVkIGJhbmR3aWR0aCBiZWNhdXNlIGl0IGFsbG93cyBmb3Igc2VuZGluZyBhdCBhIHJhdGUg aGlnaGVyIHRoYW4gdGhlIGJhbmR3aWR0aCBndWFyYW50ZWU7IChpLmUuIGEgcGVhayByYXRlIGhp Z2hlciB0aGFuIHRoZSBjb21taXR0ZWQgcmF0ZSkuIElmIGZsb3dzIGFyZSBhbGxvd2VkIHRvIGNv bnN1bWUgbW9yZSB0aGFuIHRoZWlyIHJlc2VydmVkIHJlc291cmNlcywgdGhleSBtYXkgaW50ZXJm ZXJlIHdpdGggdGhlIHJlc291cmNlcyBjb21taXR0ZWQgdG8gb3RoZXIgZmxvd3MuDQoNClBhdA0K DQpPbiBTdW4sIE1hciA0LCAyMDE4IGF0IDQ6NDkgQU0sIEdvcnJ5IEZhaXJodXJzdCA8Z29ycnlA ZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj4gd3JvdGU6DQpJIGFt IHVuc3VyZSB5ZXQgd2hhdCB0aGUgY29ycmVjdCBncm91cCBvZiBwZW9wbGUgd29ybGQgYmUgdG8g ZXhwbG9yZSBhICJCYW5kd2lkdGggR3VhcmFudGVlZCBOZXR3b3JrIi4gVGhlIHByZXNlbnRhdGlv biBsYXN0IElFVEYgbG9va2VkIGxpa2UgdGhlIHdvcmsgY291bGQgaW1wbHkgYSBuZWVkIGZvciBj aGFuZ2VzIHByb3Bvc2VkIHRvIHRoZSBuZXR3b3JrIGxheWVyICh1c2luZyBPQU0gZXhjaG5hZ2Vz KSB0byBzZXQgdGhlIHNlbmRpbmcgcmF0ZSBhbmQgbWFrZSB0aG9zZSBiYW5kd2lkdGggcmVzZXJ2 YXRpb25zLiAgSW4gdGhlIGVuZCwgaXQgY291bGQgcmVzdWx0IGluIGEgcHJvdG9jb2wgcXVpdGUg ZGlmZmVyZW50IHRvIFRDUCwgSSB0aGluayB0aGlzIHNvcnQgb2YgY2hhbmdlIG1heSBwb3NzaWJs eSBoYXZlIGEgaG9tZSBpbiBUU1ZXRyAgLSBidXQgZmlyc3QgSSdkIGFncmVlIHdpdGggTWljaGFl bGFuZCB3b3VsZCBlbmNvdXJhZ2UgYSBwcmVzZW50YXRpb24gb2YgdGhlIHByb2JsZW0gc3RhdGVt ZW50IGluIElDQ1JHIHRvIGV4cGxvcmUgdGhlIGlzc3Vlcy4NCg0KR29ycnkNCg0KT24gMDQvMDMv MjAxOCwgMTA6MzQsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3Rl Og0KDQpIaSBhbGwsDQoNCkZyb20gdGhlIGFic3RyYWN0OiDigJzigKZUaGlzIGRyYWZ0IHByb3Bv c2VzIGEgbmV3IFRDUCBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtIHVzZWQgaW4gYmFuZHdp ZHRoIGd1YXJhbnRlZWQgbmV0d29ya3MuICBJdCBpcyBhbiBleHRlbnNpb24gdG8gdGhlIGN1cnJl bnQgVENQIHN0YW5kYXJkcy7igJ0NCg0KSW4gdGhlIElFVEYsIEkgYmVsaWV2ZSB0aGUgZXhwZXJ0 aXNlIGZvciB0aGlzIHNwZWNpZmljIGRvY3VtZW50IHdvdWxkIGJlIGluIFRDUE0sIHdoaWNoIGlu IENDLiBJZiB0aGUgYXV0aG9ycyBhcmUgaW50ZXJlc3RlZCBpbiBmZWVkYmFjayBvbiB0aGUgcHJv cG9zZWQgbWVjaGFuaXNtLCBJIHdvdWxkIHJlY29tbWVuZCB0byBhc2sgVENQTS4NCg0KQWx0ZXJu YXRpdmVseSwgY29ycmVzcG9uZGluZyByZXNlYXJjaCBjb3VsZCBwZXJoYXBzIGJlIHBlcmZvcm1l ZCBpbiB0aGUgSUNDUkcuIElDQ1JHIGhhcyBwdWJsaXNoZWQgUkZDIDYwNzcgdG8gZG9jdW1lbnQg c29tZSBvZiB0aGUgb3BlbiByZXNlYXJjaCBpc3N1ZXMgaW4gdGhpcyBzcGFjZS4NCg0KTWljaGFl bA0KDQoqRnJvbToqdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0 c3Z3Zy1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAqWWluZ3poZW4gUXUNCipTZW50 OiogU3VuZGF5LCBNYXJjaCAwNCwgMjAxOCA2OjU1IEFNDQoqVG86KiB0c3Z3Z0BpZXRmLm9yZzxt YWlsdG86dHN2d2dAaWV0Zi5vcmc+OyB0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRzdndn LWNoYWlyc0BpZXRmLm9yZz4NCipDYzoqIFRob21hcyBOYWRlYXUgPHRuYWRlYXVAbHVjaWR2aXNp b24uY29tPG1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4+DQoqU3ViamVjdDoqIFt0c3Z3 Z10gQWdlbmRhIHJlcXVlc3RzIGZvciBUU1ZXR0BJRVRGMTAxDQoNCkRlYXIgQ2hhaXJzLA0KDQpB IG5ldyBkcmFmdCAoVGhlIGRyYWZ0IHdhcyBzdWdnZXN0ZWQgYnkgVFNWV0cgQElFVEYxMDApIHdh cyBqdXN0IHN1Ym1pdHRlZCwgYW5kIHdl4oCZZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1lIHNsb3Qg dG8gcHJlc2VudCBpdCBASUVURjEwMS4NCg0KVGl0bGU6QSBOZXcgQ29uZ2VzdGlvbiBDb250cm9s IGluIEJhbmR3aWR0aCBHdWFyYW50ZWVkIE5ldHdvcmsNCg0KUHJlc2VudGVyOiBZaW5nemhlbiBR dSAoSHVhd2VpKQ0KDQpUaW1lIHJlcXVpcmVkIChpbmNsdWRpbmcgUS9BKTogMTAgbWlucw0KDQpE cmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFuLXRzdndnLWNj Lw0KDQpJZiB0aGVyZSBpcyBhbnkgcXVlc3Rpb24sIHBsZWFzZSBraW5kbHkgbGV0IHVzIGtub3cu DQoNClRoYW5rcywNCg0KWWluZ3poZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnPG1haWx0 bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 Y3BtDQoNCg== --_000_1DA14EFC86A34EC4B5830FA7AFDAD751huaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <5299E1542407EF4B9A2566CF5BFA0AC7@huawei.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUGF0LDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBjb21tZW50cy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RXhhY3RseSB3aGF0IHRoZSBRb1MgcGFyYW1ldGVycyB0byBiZSB1c2VkIGlz IFRCRC4gSW4gdGhlIGRyYWZ0LCB3ZSBkZWZpbmVkIGEgbWluaW11bSBzZXQgc3VjaCBhcyBQSVIv Q0lSL0JTL2xhdGVuY3ksIHNvIGhhcmR3YXJlIHByb2dyYW1taW5nIG1heSB1c2Ugb25lIG9yIG1v cmUgcGFyYW1ldGVycyBkZXBlbmRpbmcgb24gdGhlIGZlYXR1cmUgcmVxdWlyZW1lbnQuIEZvciBl eGFtcGxlLCBmb3IgYmFuZHdpZHRoDQogc2Vuc2l0aXZlIGFwcGxpY2F0aW9uLCBjdXN0b21lciBj YW4gZ2l2ZSBQSVIvQ0lSIChldmVuIHlvdSBjYW4gaGF2ZSBQSVI9Q0lSLCBpdCBtZWFucyBkZXZp Y2Ugb25seSBndWFyYW50ZWVzIHRoZSBmb3J3YXJkaW5nIG9mIHRoZSB0cmFmZmljIGxlc3MgdGhh biBDSVIpOyBmb3IgbGF0ZW5jeSBzZW5zaXRpdmUgYXBwbGljYXRpb24sIHdlIGNhbiBoYXZlIENJ UiBhbmQvb3IgYm91bmRlZCBsYXRlbmN5IGZvciB0aGUgdHJhZmZpYyBsaWtlIENCUiBpbg0KIFRT Ti48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllpbmd6aGVuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+UGF0IFRoYWxlciAmbHQ7cGF0LnRoYWxlckBicm9hZGNvbS5j b20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgTWFyY2ggMTQsIDIwMTggYXQgOTo0 MiBBTTxicj4NCjxiPlRvOiA8L2I+R29ycnkgRmFpcmh1cnN0ICZsdDtnb3JyeUBlcmcuYWJkbi5h Yy51ayZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O1NjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE RS9TdHV0dGdhcnQpJnF1b3Q7ICZsdDttaWNoYWVsLnNjaGFyZkBub2tpYS5jb20mZ3Q7LCBUaG9t YXMgTmFkZWF1ICZsdDt0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSZndDssICZxdW90O3RjcG1AaWV0 Zi5vcmcmcXVvdDsgJmx