From nobody Wed Jun 1 06:19:34 2016 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 BB59012D0B9 for ; Wed, 1 Jun 2016 06:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aMMQTAJuCJJT for ; Wed, 1 Jun 2016 06:19:31 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 CA9C212D1DE for ; Wed, 1 Jun 2016 06:19:30 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id a20so26763094wma.1 for ; Wed, 01 Jun 2016 06:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=zVe1Dgw8HNKpqDyEP6ZQhE5pB6WOViFKhDE/cbZSh64=; b=GLm8uD1/o1ZPw6s8GOxv5AMKcHK0cNyZ4wfWT2Y9BS9AnOLwqBy1Py7e3n0bWC4kpH hZ8hP4jHSL1DrAnaIUIWb+pL1dIc0MLSFFRdxv4ZyFVv4RsUjpyi7n/B0JQCsaB1aW4Y bH4FGj6Qk7H0N0vZDEfeNdxarUUIV2TIb2lPfs7wVnQ5Lxh2OwBIyyFHmXFq7crh+6ic HXidLqk1fz7hgNBujct1vzJ3yZjZpc6xXlZyBZ/McrMVC2kVg/Xnol1hVLUBDnJUNNAm UQIRdvfY2j1XpaC4bsrOxCIupVyngJnQK6LcBzaeGr3V01unpWq3qpTJcYPjCTPvHBgY hvAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=zVe1Dgw8HNKpqDyEP6ZQhE5pB6WOViFKhDE/cbZSh64=; b=cNep5QoSg66Cq6Yt6AMKBw0xuTbv8SLKeXVVYMqHesBRddmysybC+a8wKHLPRCqCvN UKU6KwpsMu5+iT+SVkALWoUnELqX+02deDqvPezQ1SseQu8r1N6fbM2Drgzc/Sh5lADi yj1WvluNadIzAsfmEjf3Hgf+GeqxVBtt3lhsV5GHr7QAQLFeN1IUyOkb2p7Ua4smvDwD lPBZRdP4rkP/bK+FWClEc5HaC3V1YFcH2VWfpck6aF/OdGYTPORuKxu1B4downW37QV9 2ywFp+2gYQybZQs5llsjQy5UuoZTxUTY2fbuwEZY31xvLcW9ahbvfZNkHzyqZfkkOBwW LDNw== X-Gm-Message-State: ALyK8tIlPUjM578+JwctHINHqFpeAm2C0v6du2v9OCn899G4nk68ldgrtTACDDUhP+/Y9w== X-Received: by 10.28.45.9 with SMTP id t9mr22670266wmt.89.1464787169244; Wed, 01 Jun 2016 06:19:29 -0700 (PDT) Received: from mn-mn0F.local ([2001:41b8:9bf:fda6:2c82:75d8:95ec:d1ca]) by smtp.googlemail.com with ESMTPSA id d7sm35078907wmd.11.2016.06.01.06.19.28 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 06:19:28 -0700 (PDT) From: Martin Stiemerling To: tsvwg@ietf.org Message-ID: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> Date: Wed, 1 Jun 2016 15:19:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 13:19:33 -0000 Dear all, Please find here my review of draft-ietf-tsvwg-gre-in-udp-encap-11. General: The draft is ready to with a few smaller issues. Issues: - The text says in multiple places "avoid congestion". However, I do not see that, for instance, rate limiters, will avoid congestion. A rate limiter will cause congestion for affected flows but potentially keep congestion away from other parts of the network. (A bit more) correct would be something along the line of "to detect congestion and to mitigate congestion". - This document uses RFC5405bis as reference in many places, though RFC 5405 is the only stable anchor at this point of time. I am not sure how far RFC 5405bis is right now or asked differently, is there a need to wait for RFC 5405 to complete? - I do disagree with "IP-traffic can be assumed to be congestion-controlled.", even though it is stated in RFC 5405, as there is a lot of IP traffic that is not congestion controlled, such as multicast traffic... Section 4, even states that multicast and broadcast traffic can be carried over GRE-UDP! None of both is in general congestion controlled! - Section 2.1.1 on page 5, point 7 "it MUST set the same DSCP value to all fragments." From what value the DSCP must be set? This isn't stated here. - Section 4.1, first sentence: " Regarding packet fragmentation, an encapsulator/decapsulator SHOULD be compliant with [RFC7588] and perform fragmentation before the encapsulation." RFC 7588 is mentioned here and the SHOULD implies that a reader/implementer has to read RFC 7588. However, RFC 7588 is not listed under normative references and it is anyhow an informational document, which would require a down-ref in the last call. Editorials: - There are multiple occurences in the text "IANA Note: Replace TBD1 and TBD2 with the IANA-assigned numbers". I suggest to remove these notes and just to say in the IANA considerations section that IANA is requested to replace these labels with the appropriate port numbers. And tell in the IANA considerations section where to find these labels. - TBD1/TBD2 in figures: replace with a different labels and say that these labels do correspondent to the IANA assigned port numbers. The figures do not need to state the actual port numbers, as they will do, if the text and the IANA text stays as it is right now. - Section 1.1: Move TMCE up in the list, as it used in the terminology even before it is defined. Thanks, Martin From nobody Wed Jun 1 06:24:52 2016 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 1C01812D1F0 for ; Wed, 1 Jun 2016 06:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 v-FUdmq5jHrC for ; Wed, 1 Jun 2016 06:24:48 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897B212D10F for ; Wed, 1 Jun 2016 06:24:48 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u51DOlcu018367 for ; Wed, 1 Jun 2016 06:24:48 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BE2C349EB88A for ; Wed, 1 Jun 2016 09:24:47 -0400 (EDT) To: tsvwg@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Rock and Roll Fantasy X-URL-0: http://www.icir.org/mallman-files/Document99947.docx X-URL-1: http://www.icir.org/mallman-files/Document94844.html X-URL-2: http://www.icir.org/mallman-files/Document47840.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 01 Jun 2016 09:24:47 -0400 Message-ID: <99415.1464787487@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: [tsvwg] soliciting comments on draft-ietf-tcpm-rto-consider X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 13:24:52 -0000 --=-------459435943823349593450 Content-Type: text/plain Folks- A long time ago we started a document in TCPM that sought to synthesize what we have figured out over the years about the RTO estimator. Basically, we have learned that an RTO estimator needs a few aspects for network safety, but does not need to be nailed down as concretely as we have done in the past (e.g., in RFC 6298). As this effort evolved it seems like the high-level principles and requirements are actually not tied to TCP, but are in fact protocol agnostic. E.g., before we have some notion of an RTT across a specific path, an RTO scheme needs to use some initial length of time to trigger a retransmit. This equally applies to TCP, SCTP, RTP, UDP-based apps, etc. The draft name includes "ietf-tcpm", but is actually broader. My own assessment is that the draft enjoys pretty wide consensus in TCPM. But, I am looking for technical comments to ensure that the document doesn't suffer from TCP blinders as it has evolved. The draft is: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-03 Happy to hear comments on the list or off the list. Many thanks! allman -- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEUEARECAAYFAldO4h8ACgkQWyrrWs4yIs7sEgCYrhQfwowJIopCR/QUZIFJJgXN /wCgjxeA5VBIRuboYa1Lq+M+/ew1ly8= =jLg/ -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jun 1 13:19:32 2016 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 A239712B014 for ; Wed, 1 Jun 2016 13:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 p8vAcG1hbqUl for ; Wed, 1 Jun 2016 13:19:29 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A0A12D0B3 for ; Wed, 1 Jun 2016 13:11:16 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u51KBDXs027475 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 16:11:14 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u51KBDXs027475 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1464811874; bh=Ai8A22+lCGudCWIZA1AQk8/5iN0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=n6TNIjxgomOZEbUQGHDqVZWdjdutc6F0RTvq4NFmfbnQWfNkajYuvoUba2IHwVT7C FEvla1YgPLRgS4sD68FqBnyhN7/ciaCuXGJ+3r/74I4Ehhaprb77iP3AyGws7xH0b0 VV1bGeHtzWbH3n7sjnYrz1JCafhC5TdYygFCr7q0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u51KBDXs027475 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 1 Jun 2016 16:10:59 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u51KB1mC002855 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 1 Jun 2016 16:11:03 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0266.001; Wed, 1 Jun 2016 16:11:01 -0400 From: "Black, David" To: Martin Stiemerling , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11 Thread-Index: AQHRvAg/bSnzj/PZlkOEn5ypRjqkzJ/VBrjA Date: Wed, 1 Jun 2016 20:11:00 +0000 Message-ID: References: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> In-Reply-To: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.64] 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] Review of draft-ietf-tsvwg-gre-in-udp-encap-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 20:19:30 -0000 TWFydGluLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcgLSBJJ2xsIHRha2UgYSBjb3VwbGUgb2Yg dGhlIGhpZ2hlci1sZXZlbCBpc3N1ZXMgYXMNCmRyYWZ0IHNoZXBoZXJkIC4uLg0KDQpbMV0gSXMg cmZjNTQwNWJpcyBkcmFmdCByZWZlcmVuY2UgYXBwcm9wcmlhdGU/DQoNCj4gLSBUaGlzIGRvY3Vt ZW50IHVzZXMgUkZDNTQwNWJpcyBhcyByZWZlcmVuY2UgaW4gbWFueSBwbGFjZXMsIHRob3VnaCBS RkMNCj4gNTQwNSBpcyB0aGUgb25seSBzdGFibGUgYW5jaG9yIGF0IHRoaXMgcG9pbnQgb2YgdGlt ZS4gSSBhbSBub3Qgc3VyZSBob3cNCj4gZmFyIFJGQyA1NDA1YmlzIGlzIHJpZ2h0IG5vdyBvciBh c2tlZCBkaWZmZXJlbnRseSwgaXMgdGhlcmUgYSBuZWVkIHRvDQo+IHdhaXQgZm9yIFJGQyA1NDA1 IHRvIGNvbXBsZXRlPw0KDQpZZXMgdGhlcmUgaXMgYSBuZWVkIHRvIHJlZmVyZW5jZSB0aGUgcmZj NTQwNWJpcyBkcmFmdCAtIHRoaXMgR1JFL1VEUCBkcmFmdA0KbmVlZHMgdG8gcmVmZXJlbmNlIHRo ZSBDb250cm9sbGVkIEVudmlyb25tZW50IG1hdGVyaWFsIGluIFNlY3Rpb24gMy42IG9mIHRoZQ0K cmZjNTQwNWJpcyBkcmFmdC4gIFRoYXQgcmZjNTQwNWJpcyBkcmFmdCBpcyByZWFzb25hYmx5IHN0 YWJsZSwgaG93ZXZlciAuLi4NCg0KWzJdIElQIHRyYWZmaWMgY29uZ2VzdGlvbiBjb250cm9sIGFz c3VtcHRpb25zLg0KDQo+IC0gSSBkbyBkaXNhZ3JlZSB3aXRoICJJUC10cmFmZmljIGNhbiBiZSBh c3N1bWVkIHRvIGJlDQo+IGNvbmdlc3Rpb24tY29udHJvbGxlZC4iLCBldmVuIHRob3VnaCBpdCBp cyBzdGF0ZWQgaW4gUkZDIDU0MDUsIGFzIHRoZXJlDQo+IGlzIGEgbG90IG9mIElQIHRyYWZmaWMg dGhhdCBpcyBub3QgY29uZ2VzdGlvbiBjb250cm9sbGVkLCBzdWNoIGFzDQo+IG11bHRpY2FzdCB0 cmFmZmljLi4uDQo+IFNlY3Rpb24gNCwgZXZlbiBzdGF0ZXMgdGhhdCBtdWx0aWNhc3QgYW5kIGJy b2FkY2FzdCB0cmFmZmljIGNhbiBiZQ0KPiBjYXJyaWVkIG92ZXIgR1JFLVVEUCEgTm9uZSBvZiBi b3RoIGlzIGluIGdlbmVyYWwgY29uZ2VzdGlvbiBjb250cm9sbGVkIQ0KDQpXZWxsLCB0aGlzIGlz IGFjdHVhbGx5IGFuIGlzc3VlIHdpdGggdGhlIHJmYzU0MDViaXMgZHJhZnQsIGFuZCB0aGlzIGlz c3VlIG5lZWRzDQp0byBiZSBmaXhlZCB0aGVyZSwgYXMgUkZDIDU0MDUgaXMgKGFuZCB0aGUgcmZj NTQwNWJpcyBkcmFmdCB3aWxsIGJlKSB0aGUNClRyYW5zcG9ydCBBcmVhJ3Mgc3RhdGVtZW50IHRv IHRoZSByZXN0IG9mIHRoZSBJRVRGIG9uIGNvbmdlc3Rpb24gY29udHJvbA0KZ3VpZGVsaW5lcyBh bmQgcmVxdWlyZW1lbnRzIGZvciBVRFAgdXNhZ2UuDQoNCkknbSBnb2luZyB0byBhdHRlbXB0IHRv IHRha2UgYWR2YW50YWdlIG9mIHlvdXIgZXgtVFNWLUFEIHN0YXR1cyB0byBwdWxsIGENCiJubyBn b29kIGRlZWQgZ29lcyB1bnB1bmlzaGVkIiB0cmljayA7LSkgYW5kIGFzayB5b3UgdG8gc3VnZ2Vz dCBtb2RpZmljYXRpb25zDQp0byB0aGUgdHdvIGNydWNpYWwgcGFyYWdyYXBocyBpbiB0aGUgcmZj NTQwNWJpcyBkcmFmdCBvbiB0aGlzIHRvcGljIChJJ20gaGFwcHkNCnRvIHdvcmsgdy95b3Ugb2Zm LWxpc3QgdG8gZGV2ZWxvcCBwcm9wb3NlZCB0ZXh0KS4gIFRob3NlIHR3byBjcnVjaWFsIHBhcmFn cmFwaHMNCmFyZSBpbiBTZWN0aW9uIDMuMS4xMSBvZiB0aGUgcmZjNTQwNWJpcyBkcmFmdDoNCg0K ICAgSVAtYmFzZWQgdHJhZmZpYyBpcyBnZW5lcmFsbHkgYXNzdW1lZCB0byBiZSBjb25nZXN0aW9u LWNvbnRyb2xsZWQsDQogICBpLmUuLCBpdCBpcyBhc3N1bWVkIHRoYXQgdGhlIHRyYW5zcG9ydCBw cm90b2NvbHMgZ2VuZXJhdGluZyBJUC1iYXNlZA0KICAgdHJhZmZpYyBhdCB0aGUgc2VuZGVyIGFs cmVhZHkgZW1wbG95IG1lY2hhbmlzbXMgdGhhdCBhcmUgc3VmZmljaWVudA0KICAgdG8gYWRkcmVz cyBjb25nZXN0aW9uIG9uIHRoZSBwYXRoLiAgQ29uc2VxdWVudGx5LCBhIHR1bm5lbCBjYXJyeWlu Zw0KICAgSVAtYmFzZWQgdHJhZmZpYyBzaG91bGQgYWxyZWFkeSBpbnRlcmFjdCBhcHByb3ByaWF0 ZWx5IHdpdGggb3RoZXINCiAgIHRyYWZmaWMgc2hhcmluZyB0aGUgcGF0aCwgYW5kIHNwZWNpZmlj IGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc21zDQogICBmb3IgdGhlIHR1bm5lbCBhcmUgbm90 IG5lY2Vzc2FyeS4NCg0KICAgSG93ZXZlciwgaWYgdGhlIElQIHRyYWZmaWMgaW4gdGhlIHR1bm5l bCBpcyBrbm93biB0byBub3QgYmUNCiAgIGNvbmdlc3Rpb24tY29udHJvbGxlZCwgYWRkaXRpb25h bCBtZWFzdXJlcyBhcmUgUkVDT01NRU5ERUQgdG8gbGltaXQNCiAgIHRoZSBpbXBhY3Qgb2YgdGhl IHR1bm5lbGVkIHRyYWZmaWMgb24gb3RoZXIgdHJhZmZpYyBzaGFyaW5nIHRoZSBwYXRoLg0KDQpU aGFua3MgaW4gYWR2YW5jZSAtIHdlIG5lZWQgdG8gZ2V0IHRoaXMgcmlnaHQsIElNSE8uDQoNClRo aXMgd2lsbCBhbHNvIGRlZmluaXRpdmVseSByZXNvbHZlIHRoZSBmaXJzdCBpc3N1ZSA7LSksIGFz IGFmdGVyIHRoaXMNCnJmYzU0MDViaXMgdGV4dCBjaGFuZ2UsIHRoZSBHUkUvVURQIGRyYWZ0IHdp bGwgaGF2ZSB0byByZWZlcmVuY2UNCihub3JtYXRpdmVseSkgdGhlIHJmYzQ1MDViaXMgZHJhZnQg KHdoaWNoIGlzIHdoYXQgaXQgYWxyZWFkeSBkb2VzKS4NCg0KVGhhbmtzLCAtLURhdmlkIChhcyBz aGVwaGVyZCBmb3IgYm90aCB0aGUgR1JFL1VEUCBhbmQgcmZjNTQwNWJpcyBkcmFmdHMpLg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2d2ct Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiBTdGllbWVybGluZw0KPiBTZW50 OiBXZWRuZXNkYXksIEp1bmUgMDEsIDIwMTYgOToxOSBBTQ0KPiBUbzogdHN2d2dAaWV0Zi5vcmcN Cj4gU3ViamVjdDogW3RzdndnXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1ncmUtaW4tdWRw LWVuY2FwLTExDQo+IA0KPiBEZWFyIGFsbCwNCj4gDQo+IFBsZWFzZSBmaW5kIGhlcmUgbXkgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC0xMS4NCj4gDQo+IEdlbmVy YWw6IFRoZSBkcmFmdCBpcyByZWFkeSB0byB3aXRoIGEgZmV3IHNtYWxsZXIgaXNzdWVzLg0KPiAN Cj4gSXNzdWVzOg0KPiAtIFRoZSB0ZXh0IHNheXMgaW4gbXVsdGlwbGUgcGxhY2VzICJhdm9pZCBj b25nZXN0aW9uIi4NCj4gSG93ZXZlciwgSSBkbyBub3Qgc2VlIHRoYXQsIGZvciBpbnN0YW5jZSwg cmF0ZSBsaW1pdGVycywgd2lsbCBhdm9pZA0KPiBjb25nZXN0aW9uLiBBIHJhdGUgbGltaXRlciB3 aWxsIGNhdXNlIGNvbmdlc3Rpb24gZm9yIGFmZmVjdGVkIGZsb3dzIGJ1dA0KPiBwb3RlbnRpYWxs eSBrZWVwIGNvbmdlc3Rpb24gYXdheSBmcm9tIG90aGVyIHBhcnRzIG9mIHRoZSBuZXR3b3JrLg0K PiAoQSBiaXQgbW9yZSkgY29ycmVjdCB3b3VsZCBiZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmUg b2YgInRvIGRldGVjdA0KPiBjb25nZXN0aW9uIGFuZCB0byBtaXRpZ2F0ZSBjb25nZXN0aW9uIi4N Cj4gDQo+IC0gVGhpcyBkb2N1bWVudCB1c2VzIFJGQzU0MDViaXMgYXMgcmVmZXJlbmNlIGluIG1h bnkgcGxhY2VzLCB0aG91Z2ggUkZDDQo+IDU0MDUgaXMgdGhlIG9ubHkgc3RhYmxlIGFuY2hvciBh dCB0aGlzIHBvaW50IG9mIHRpbWUuIEkgYW0gbm90IHN1cmUgaG93DQo+IGZhciBSRkMgNTQwNWJp cyBpcyByaWdodCBub3cgb3IgYXNrZWQgZGlmZmVyZW50bHksIGlzIHRoZXJlIGEgbmVlZCB0bw0K PiB3YWl0IGZvciBSRkMgNTQwNSB0byBjb21wbGV0ZT8NCj4gDQo+IC0gSSBkbyBkaXNhZ3JlZSB3 aXRoICJJUC10cmFmZmljIGNhbiBiZSBhc3N1bWVkIHRvIGJlDQo+IGNvbmdlc3Rpb24tY29udHJv bGxlZC4iLCBldmVuIHRob3VnaCBpdCBpcyBzdGF0ZWQgaW4gUkZDIDU0MDUsIGFzIHRoZXJlDQo+ IGlzIGEgbG90IG9mIElQIHRyYWZmaWMgdGhhdCBpcyBub3QgY29uZ2VzdGlvbiBjb250cm9sbGVk LCBzdWNoIGFzDQo+IG11bHRpY2FzdCB0cmFmZmljLi4uDQo+IFNlY3Rpb24gNCwgZXZlbiBzdGF0 ZXMgdGhhdCBtdWx0aWNhc3QgYW5kIGJyb2FkY2FzdCB0cmFmZmljIGNhbiBiZQ0KPiBjYXJyaWVk IG92ZXIgR1JFLVVEUCEgTm9uZSBvZiBib3RoIGlzIGluIGdlbmVyYWwgY29uZ2VzdGlvbiBjb250 cm9sbGVkIQ0KPiANCj4gLSBTZWN0aW9uIDIuMS4xIG9uIHBhZ2UgNSwgcG9pbnQgNyAiaXQgTVVT VCBzZXQgdGhlIHNhbWUgRFNDUCB2YWx1ZSB0bw0KPiBhbGwgZnJhZ21lbnRzLiIgRnJvbSB3aGF0 IHZhbHVlIHRoZSBEU0NQIG11c3QgYmUgc2V0PyBUaGlzIGlzbid0IHN0YXRlZA0KPiBoZXJlLg0K PiANCj4gLSBTZWN0aW9uIDQuMSwgZmlyc3Qgc2VudGVuY2U6DQo+ICIgICBSZWdhcmRpbmcgcGFj a2V0IGZyYWdtZW50YXRpb24sIGFuIGVuY2Fwc3VsYXRvci9kZWNhcHN1bGF0b3IgU0hPVUxEDQo+ ICAgICBiZSBjb21wbGlhbnQgd2l0aCBbUkZDNzU4OF0gYW5kIHBlcmZvcm0gZnJhZ21lbnRhdGlv biBiZWZvcmUgdGhlDQo+ICAgICBlbmNhcHN1bGF0aW9uLiINCj4gUkZDIDc1ODggaXMgbWVudGlv bmVkIGhlcmUgYW5kIHRoZSBTSE9VTEQgaW1wbGllcyB0aGF0IGENCj4gcmVhZGVyL2ltcGxlbWVu dGVyIGhhcyB0byByZWFkIFJGQyA3NTg4LiBIb3dldmVyLCBSRkMgNzU4OCBpcyBub3QgbGlzdGVk DQo+IHVuZGVyIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGFuZCBpdCBpcyBhbnlob3cgYW4gaW5mb3Jt YXRpb25hbCBkb2N1bWVudCwNCj4gd2hpY2ggd291bGQgcmVxdWlyZSBhIGRvd24tcmVmIGluIHRo ZSBsYXN0IGNhbGwuDQo+IA0KPiANCj4gRWRpdG9yaWFsczoNCj4gLSBUaGVyZSBhcmUgbXVsdGlw bGUgb2NjdXJlbmNlcyBpbiB0aGUgdGV4dCAiSUFOQSBOb3RlOiBSZXBsYWNlIFRCRDEgYW5kDQo+ IFRCRDIgd2l0aCB0aGUgSUFOQS1hc3NpZ25lZCBudW1iZXJzIi4gSSBzdWdnZXN0IHRvIHJlbW92 ZSB0aGVzZSBub3Rlcw0KPiBhbmQganVzdCB0byBzYXkgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiB0aGF0IElBTkEgaXMNCj4gcmVxdWVzdGVkIHRvIHJlcGxhY2UgdGhlc2UgbGFi ZWxzIHdpdGggdGhlIGFwcHJvcHJpYXRlIHBvcnQgbnVtYmVycy4gQW5kDQo+IHRlbGwgaW4gdGhl IElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB3aGVyZSB0byBmaW5kIHRoZXNlIGxhYmVscy4N Cj4gDQo+IC0gVEJEMS9UQkQyIGluIGZpZ3VyZXM6IHJlcGxhY2Ugd2l0aCBhIGRpZmZlcmVudCBs YWJlbHMgYW5kIHNheSB0aGF0DQo+IHRoZXNlIGxhYmVscyBkbyBjb3JyZXNwb25kZW50IHRvIHRo ZSBJQU5BIGFzc2lnbmVkIHBvcnQgbnVtYmVycy4gVGhlDQo+IGZpZ3VyZXMgZG8gbm90IG5lZWQg dG8gc3RhdGUgdGhlIGFjdHVhbCBwb3J0IG51bWJlcnMsIGFzIHRoZXkgd2lsbCBkbywNCj4gaWYg dGhlIHRleHQgYW5kIHRoZSBJQU5BIHRleHQgc3RheXMgYXMgaXQgaXMgcmlnaHQgbm93Lg0KPiAN Cj4gLSBTZWN0aW9uIDEuMTogTW92ZSBUTUNFIHVwIGluIHRoZSBsaXN0LCBhcyBpdCB1c2VkIGlu IHRoZSB0ZXJtaW5vbG9neQ0KPiBldmVuIGJlZm9yZSBpdCBpcyBkZWZpbmVkLg0KPiANCj4gVGhh bmtzLA0KPiANCj4gICAgTWFydGluDQoNCg== From nobody Thu Jun 2 02:06:35 2016 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 E34E512D66F for ; Thu, 2 Jun 2016 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 Yku5A_mJ86Km for ; Thu, 2 Jun 2016 02:06:31 -0700 (PDT) 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 34A7012D668 for ; Thu, 2 Jun 2016 02:06:31 -0700 (PDT) Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:444f:5470:7f7d:7bcf]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 262801B0020E for ; Thu, 2 Jun 2016 10:18:51 +0100 (BST) References: <99415.1464787487@lawyers.icir.org> To: tsvwg@ietf.org From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Thu, 2 Jun 2016 10:06:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <99415.1464787487@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] soliciting comments on draft-ietf-tcpm-rto-consider X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 09:06:34 -0000 Mark, As I previously said, I think this is a useful document. However, I do think we need to be careful here when we use terms like "retransmission timer algorithms" and "RTO". See below. On 01/06/2016 14:24, Mark Allman wrote: > > Folks- > > A long time ago we started a document in TCPM that sought to > synthesize what we have figured out over the years about the RTO > estimator. Basically, we have learned that an RTO estimator needs a > few aspects for network safety, but does not need to be nailed down > as concretely as we have done in the past (e.g., in RFC 6298). > > As this effort evolved it seems like the high-level principles and > requirements are actually not tied to TCP, but are in fact protocol > agnostic. E.g., before we have some notion of an RTT across a > specific path, an RTO scheme needs to use some initial length of > time to trigger a retransmit. This equally applies to TCP, SCTP, > RTP, UDP-based apps, etc. > > The draft name includes "ietf-tcpm", but is actually broader. My > own assessment is that the draft enjoys pretty wide consensus in > TCPM. But, I am looking for technical comments to ensure that the > document doesn't suffer from TCP blinders as it has evolved. > > The draft is: > > https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-03 > > Happy to hear comments on the list or off the list. > > Many thanks! > > allman > > > -- > http://www.icir.org/mallman/ > For TCP/SCTP these terms are fairly well-specified for TCP/SCTP and I also agree on what TCP/SCTP should do. The draft uses the term "RTO" ... As I understand, an RTO expires in TCP when there is a lack of confirmed delivery across a network path. To me, this detects times when the sender can no longer be confident that data is being received -- i.e., there is risk that congestion has been detected. To be "safe", the network needs to reduce the volume of traffic it sends in response to detecting this potential congestion. Exponential backoff of the RTO is an important part of the TCP response. However, to make these recommendations applicable to other protocols, I think we need to agree about what we mean by timers, retransmission and the term "RTO" in the context of all protocols, and make sure the draft says what it understands by these terms. I'll try to explain why I think this is a new problem for UDP - my hope is that this will paint a picture against which we can agree some simple definitions that apply beyond TCP, it's long and tutorial (and I'm typing over breakfast coffee, so maybe has some oversights, but I'm hoping the resulting introductory text is concise, once we understand each other's starting points). --- There are very important differences in the way TCP and UDP handle retransmission and timers: * TCP organises data as a reliable byte stream, UDP does not. This means that a modern TCP flow typically can (and does) use other methods to detect loss and hence retransmit, and the timer-based RTO mechanism is not usually the primary retransmission mechanism. Current thinking is that this should not be triggered often in normal operation. * UDP applications can use timers for retransmission: They need to respond "similarly" to TCP when they detect loss, in that they must reduce their volume of traffic sent in response when they detect congestion. They also can use timers for various reasons. Timers can also provide retransmission (in UDP, this is not always of the original data). Transmission (and retransmission) are often also controlled by timers. The term RTO is not used widely in UDP (and note defined in DCCP). this sort of retransmission timer expiry is not necessarily equivalent to a TCP RTO. * Applications can attach different priorities to different UDP datagrams they send: All data does not need to be equal, some data may be considered more important or more time-critical (e.g., think of data from a video codec using UDP). It's quite OK for such an application to set a short delivery deadline for some data (more responsive), and to care much less about loss of other data. If a timer triggers, the app can decide which data to retransmit (or send some sort of repair request to compensate for the loss), and when to send this. This includes the possibility to use timers for critical datagrams, or to use other methods. The thing I think that is important is that an app must reduce the total volume of data sent went it experiences loss, it is nothing to do with whether timers are used. A re-ransmission timeout can be different to a TCP RTO. I disagree for UDP with: (draft-ietf-tcpm-rto-consider-03.txt says: "Ideally, if we know a segment will be lost before reaching the destination, a second copy of it would be sent immediately after the first transmission." The draft says this is a tradeoff, I think this becomes one of many design decisions for a partially reliable datagram service. The second copy part is purely dependent on the app, etc) * Frequency of RTT measurement: Many UDP apps do not make per RTT measurements of the path. These have some functions that resemble RTO expiry in TCP, but they are not the same. They mayuse less frequent feedback messages to confirm the path they use (e.g., RTCP often used with reporting intervals greater than 1 RTT). This is usually a conscious decision based on application processing or network capacity tradeoff. A lack of reception feedback still needs to be regarded as a trigger for a congestion response (aka rate reduction or flow termination). These methods work on longer timescales than a TCP RTO would operate (and often react differently to a TCP CC , e.g., TFRC). This use seems to slightly contradict the current draft, (e.g., I doubt if there would be RAI consensus that RTP is wrong.) * Low volume: Some UDP apps do not implement feedback indicating the RTT and volume of successful data transmitted across the path needs special consideration (RFC5405 talks about this, SIP is an example - this usage resembles TCP SYN transmission, and could probably be handled similarly). If the app does not know that data is successfully reaching the remote endpoint it needs to take other action (such an app can not calculate a safe reduction, e.g., halving the rate) - exponentially-backed off request messages from a starting value are commonly used in this way. This has similarities with the use by TCP of the RTO during Open, where a lack of feedback results in a RTO expiry. Methods are described in the UDP Guidelines (RFC5405)to cope with senders that send very few packets per RTT, or ones do not measure RTT, etc. * Low volume: Some UDP applications use a keep alive message to confirm their path (STUN is an example, there are others). The IETF circuit breaker documents also define a set of last-resort methods for detecting what i will call persistent congestion for UDP. These methods work on longer timescales than a TCP RTO would operate (and react more vigourously than CC), but have similaeity in provide a method of last resort. However, I think this use of timers I think does not fall within the scope of the document, but the Guidelines need to note these timers need to backoff. * Backoff - and timer retransmission not harmful: UDP needs to avoid congestion collapse. For UDP, the best trade-off (whether it is worth risking to send a particular retransmission early or not) is best known by the application (e.g., for transaction-based apps - DNS?, exponential back-off for each failed retransmission would seem appropriate; in contrast for multimedia streaming, fast retransmission of key data is often vital, and some unnecessary retransmissions may be desirable - even if that then means less lower priority data can be sent; there are likely other cases). If an app sends early, then it MUST be considered as a segment that is congestion-controlled (i.e., I think equivalent to consuming one MSS of cwnd, in TCP language - the acknowledgment ambiguity that would happen in TCP should not occur in a protocol designed for this, that's a result of TCP choosing to use culmulative ACKs). To me, the first important thing is not whether timers are used to trigger retransmissions, but that data transmission avoids congestion collapse. The second important thing, is that this use does not confirm the path capacity - hence this does not replace the need for a method of detecting congestion in the last resort. This sort of use seems outside the scope of your draft. * efficiency and timers: I agree there can be an efficiency trade-off when using timers (noted as you say for TCP - true also of keep-alives, etc), if the RTT isn't measured accurately and then not used correctly to calculate a suitable timeout, then early retransmissions will add volume to the data sent by an app. That absolutely needs to be taken into consideration. If all data were equal, it would be really wise to avoid sending data in early retransmissions (e.g., >RTT but 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 43BE812D6CC; Thu, 2 Jun 2016 03:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, 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 afgUNFLibfq7; Thu, 2 Jun 2016 03:12:11 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id E272412D6C8; Thu, 2 Jun 2016 03:12:10 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 47B951A0B37; Thu, 2 Jun 2016 12:11:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> Date: Thu, 2 Jun 2016 12:11:40 +0200 Message-Id: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-tsvwg-rfc5405bis@ietf.org, quic@ietf.org, tsvwg-chairs@ietf.org, spud , tsvwg WG Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 10:12:13 -0000 --Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Apologies for the late last call comment; I have only one, relatively = minor. I hope it's still useful. I understand that Section 3 was written to encourage application = developers not to roll their own transports ("trust us when we say this = is hard, this document is a list of reasons why") but as written it = would seem to discourage transport innovation atop UDP (e.g. QUIC, the = RTCWEB data channel, anything-over-PLUS), which I very much hope was not = the intent. The problematic recommendation is in the second paragraph: These mechanisms are difficult to implement correctly. For most applications, the use of one of the existing IETF transport protocols is the simplest method of acquiring the required mechanisms. Doing so also avoids issues that protocols using a new IP protocol number face when being deployed over the Internet, where middleboxes that only support TCP and UDP are not rare. Consequently, the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol such as TCP [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control Protocol (DCCP) [RFC4340] with its different congestion control types [RFC4341][RFC4342][RFC5622]. First, this paragraph ignores potential deployment issues with any of = these other than TCP, which risks seeming out of touch, but this is a = minor point and probably not worth a late edit. Second, I'm concerned = this recommendation could be taken as broader than intended, against the = definition of any new transport protocol encapsulated within UDP that = performs substantially the same function as the listed protocols. I think this can be made clearer by simply adding to the list of = examples: NEW: These mechanisms are difficult to implement correctly. For most applications, the use of one of the existing IETF transport protocols is the simplest method of acquiring the required mechanisms. Doing so also avoids issues that protocols using a new IP protocol number face when being deployed over the Internet, where middleboxes that only support TCP and UDP are not rare. Consequently, the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol such as TCP [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control Protocol (DCCP) [RFC4340] with its different congestion control types [RFC4341][RFC4342][RFC5622], or transport protocols specified by the IETF in the future. and removing the examples from the summary in section 7: OLD: | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | NEW: | SHOULD use a full-featured transport | | Thanks, cheers, Brian > On 18 May 2016, at 02:17, The IESG wrote: >=20 >=20 > The IESG has received a request from the Transport Area Working Group = WG > (tsvwg) to consider the following document: > - 'UDP Usage Guidelines' > as Best Current Practice >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The User Datagram Protocol (UDP) provides a minimal message-passing > transport that has no inherent congestion control mechanisms. This > document provides guidelines on the use of UDP for the designers of > applications, tunnels and other protocols that use UDP. Congestion > control guidelines are a primary focus, but the document also > provides guidance on other topics, including message sizes, > reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > and ports. >=20 > Because congestion control is critical to the stable operation of = the > Internet, applications and other protocols that choose to use UDP as > an Internet transport must employ mechanisms to prevent congestion > collapse and to establish some degree of fairness with concurrent > traffic. They may also need to implement additional mechanisms, > depending on how they use UDP. >=20 > Some guidance is also applicable to the design of other protocols > (e.g., protocols layered directly on IP or via IP-based tunnels), > especially when these protocols do not themselves provide congestion > control. >=20 > This document obsoletes RFC5405 and adds guidelines for multicast = UDP > usage. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 --Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXUAZcAAoJEIoSt78L6kajg0sP/05YYUgj6zyRY90XlrwTCYhF uLYouDERANLIRVa+Mwx1Ipk0D/tCrBj/jeuWmlxqakzW7wPm9NfF97UTweqpRwaW KjmOEEMm5QVIuRmnTOZUyKvF0s66xxiMpkhlpS4qxmLmL1R/Ff8Pd+v9UdEenZR7 ZYRdo8hGRacQt22Fhgr5G88lmuRrDwEcDNHpuSNYkcE1LQRgKZuSrp70J78aaHQV Hclxaejz8IzIj4HJt2+jNB512mELM455EfogH3Lcc3ue7lkgBT8Z4+d9A5lAyjjk SjwsvnOdKlRpi6An7KfPOttyg34OBX3WhrGmjbdrJyrIGWDPTjzdINgNd0cBNF3B Bl5wtNOYSz6I0cwtUX1zNxYzR/RRadgA1Wp8mWu6dItCf8yTYHWbTVXQMbt0vBYf 1B6WkvqjH1uLyNV2iXRpyruMol/Uq/C8T7R3c9gY7zEqVd44PRBO+QkjVMokLJLA bUyDGGMcX1OxRKII2ChSKm3zF4q3PnW5XYUofAVSFB8TJkvkI6NB4XWCbY4thFf+ HT9mFih0SEi3vc3bBw42UsIOjVX8O6zNiR9T1yForJJDBfQQHmcl9xq3lGDWGPuD ZnlHol0rOcxO5DF8q4b/+8KpuTgzx12/lHs7eGsMjMNJuzFg33nQJ0eafWS15Wls KgJrXNhdnlUY4WNZm6Lx =FJ3i -----END PGP SIGNATURE----- --Apple-Mail=_E2BE0042-0198-4C1F-9748-FB7454C09868-- From nobody Thu Jun 2 11:09:24 2016 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 AF6A312B04C; Thu, 2 Jun 2016 11:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 068xYN7sL5jT; Thu, 2 Jun 2016 11:09:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111AC12B022; Thu, 2 Jun 2016 11:09:06 -0700 (PDT) Received: from [128.9.184.178] ([128.9.184.178]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u52I8JFa001915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Jun 2016 11:08:21 -0700 (PDT) To: otroan@employees.org, Xuxiaohu References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> From: Joe Touch Message-ID: <57507611.5010801@isi.edu> Date: Thu, 2 Jun 2016 11:08:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Softwires WG , "nvo3@ietf.org" , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:09:08 -0000 On 5/27/2016 3:50 AM, otroan@employees.org wrote: > It is not possible to implement reassembly complying with IETF RFCs. a) ATM does this at ridiculously high fragment rates. Granted IP frags can come out of order, but the fragments are generally much larger. b) What is the alternative, given we have minimum MTU requirements? If you're limiting yourself to IPv4 payloads where DF=0, sure, there there is an alternative. But you've just disabled IPv6 and IPv4 with DF=1. I.e., it's not possible to NOT implement this and comply with IETF RFCs. Joe From nobody Thu Jun 2 11:21:25 2016 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 F050812D7BE for ; Thu, 2 Jun 2016 11:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 Njanft7aX6KE for ; Thu, 2 Jun 2016 11:21:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A827212D0FC for ; Thu, 2 Jun 2016 11:21:22 -0700 (PDT) Received: from [128.9.184.178] ([128.9.184.178]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u52IH4A7004334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Jun 2016 11:17:05 -0700 (PDT) To: Martin Stiemerling , tsvwg@ietf.org References: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> <57507784.50207@isi.edu> From: Joe Touch Message-ID: <5750781E.1020604@isi.edu> Date: Thu, 2 Jun 2016 11:17:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57507784.50207@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:21:24 -0000 On 6/2/2016 11:14 AM, Joe Touch wrote: > > On 6/1/2016 6:19 AM, Martin Stiemerling wrote: >> - Section 4.1, first sentence: >> " Regarding packet fragmentation, an encapsulator/decapsulator SHOULD >> be compliant with [RFC7588] and perform fragmentation before the >> encapsulation." >> RFC 7588 is mentioned here and the SHOULD implies that a >> reader/implementer has to read RFC 7588. However, RFC 7588 is not >> listed under normative references and it is anyhow an informational >> document, which would require a down-ref in the last call. > RFC7588 *describes* how existing deployments operate. It does not > specify requirements. > > It doesn't seem appropriate to refer to being "compliant" with a > description. FWIW - correction to the following: > Further, RFC7588 indicates problems with that configuration and > describes how its use is thus limited. At best, you would need to copy > those restrictions as well, but that further begs the question of > needing a copy of GRE without the benefits of the GRE header. Too many drafts ;-) In this case, you do need to copy the caveats in RFC7588, but the doc already elsewhere justifies the GRE in UDP approach sufficiently. Joe From nobody Thu Jun 2 11:24:32 2016 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 3D77A12B01E for ; Thu, 2 Jun 2016 11:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 yDi49c-MG7yG for ; Thu, 2 Jun 2016 11:24:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0943F12D7B5 for ; Thu, 2 Jun 2016 11:15:30 -0700 (PDT) Received: from [128.9.184.178] ([128.9.184.178]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u52IEVSS003619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Jun 2016 11:14:33 -0700 (PDT) To: Martin Stiemerling , tsvwg@ietf.org References: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> From: Joe Touch Message-ID: <57507784.50207@isi.edu> Date: Thu, 2 Jun 2016 11:14:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:24:31 -0000 On 6/1/2016 6:19 AM, Martin Stiemerling wrote: > - Section 4.1, first sentence: > " Regarding packet fragmentation, an encapsulator/decapsulator SHOULD > be compliant with [RFC7588] and perform fragmentation before the > encapsulation." > RFC 7588 is mentioned here and the SHOULD implies that a > reader/implementer has to read RFC 7588. However, RFC 7588 is not > listed under normative references and it is anyhow an informational > document, which would require a down-ref in the last call. RFC7588 *describes* how existing deployments operate. It does not specify requirements. It doesn't seem appropriate to refer to being "compliant" with a description. Further, RFC7588 indicates problems with that configuration and describes how its use is thus limited. At best, you would need to copy those restrictions as well, but that further begs the question of needing a copy of GRE without the benefits of the GRE header. Joe From nobody Thu Jun 2 14:17:14 2016 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 E87C212D8AA; Thu, 2 Jun 2016 14:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, RP_MATCHES_RCVD=-1.426, 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 LbeKeLPLCmaK; Thu, 2 Jun 2016 14:17:00 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 9A6DD12D8A2; Thu, 2 Jun 2016 14:17:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u52LHBJa011253; Thu, 2 Jun 2016 14:17:11 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u52LH6TG011226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2016 14:17:06 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Jun 2016 14:16:53 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 2 Jun 2016 14:16:53 -0700 From: "Templin, Fred L" To: Joe Touch , "otroan@employees.org" , Xuxiaohu Thread-Topic: [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. Thread-Index: AQHRvPnkfjHsPaf//UOpMMLUhxA5mJ/Wra5A Date: Thu, 2 Jun 2016 21:16:53 +0000 Message-ID: References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> In-Reply-To: <57507611.5010801@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: Softwires WG , "nvo3@ietf.org" , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:17:03 -0000 Agree with Joe, and also just to mention that RFC4459 discusses tunnel MTU and fragmentation considerations. Thanks - Fred > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Thursday, June 02, 2016 11:08 AM > To: otroan@employees.org; Xuxiaohu > Cc: Softwires WG ; nvo3@ietf.org; int-area@ietf.org; = lisp@ietf.org; tsvwg@ietf.org > Subject: Re: [Int-area] [nvo3] [Softwires] Is it feasible to perform frag= mentation on UDP encapsulated packets. >=20 >=20 >=20 > On 5/27/2016 3:50 AM, otroan@employees.org wrote: > > It is not possible to implement reassembly complying with IETF RFCs. >=20 > a) ATM does this at ridiculously high fragment rates. Granted IP frags > can come out of order, but the fragments are generally much larger. >=20 > b) What is the alternative, given we have minimum MTU requirements? >=20 > If you're limiting yourself to IPv4 payloads where DF=3D0, sure, there > there is an alternative. But you've just disabled IPv6 and IPv4 with DF= =3D1. >=20 > I.e., it's not possible to NOT implement this and comply with IETF RFCs. >=20 > Joe >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Jun 2 19:53:56 2016 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 5465912D131; Thu, 2 Jun 2016 19:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, RP_MATCHES_RCVD=-1.426, 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 B7Jyu9rhZXhE; Thu, 2 Jun 2016 19:53:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741A9128874; Thu, 2 Jun 2016 19:53:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLH32864; Fri, 03 Jun 2016 02:53:44 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 3 Jun 2016 03:53:43 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 3 Jun 2016 10:53:38 +0800 From: Xuxiaohu To: Joe Touch , "otroan@employees.org" Thread-Topic: [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. Thread-Index: AQHRvPncHcsWng18N0qPKCUQaW4bNp/W96xA Date: Fri, 3 Jun 2016 02:53:37 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> In-Reply-To: <57507611.5010801@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5750F138.01B3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b6ae068aa12793195ecad703a67f441c Archived-At: Cc: Softwires WG , "nvo3@ietf.org" , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 02:53:52 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, June 03, 2016 2:08 AM > To: otroan@employees.org; Xuxiaohu > Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; > tsvwg@ietf.org > Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation o= n UDP > encapsulated packets. >=20 >=20 >=20 > On 5/27/2016 3:50 AM, otroan@employees.org wrote: > > It is not possible to implement reassembly complying with IETF RFCs. >=20 > a) ATM does this at ridiculously high fragment rates. Granted IP frags ca= n come > out of order, but the fragments are generally much larger. As pointed in RFC4459, "At the time of reassembly, all the information (i.e., all the fragments) is normally not available; when the first fragment arrives to be reassembled, a buffer of the maximum possible size may have to be allocated because the total length of the reassembled datagram is not known at that time. Furthermore, as fragments might get lost, or be reordered or delayed, the reassembly engine has to wait with the partial packet for some time (e.g., 60 seconds [9]). When this would have to be done at the line rate, with, for example 10 Gbit/s speed, the length of the buffers that reassembly might require would be prohibitive. " Have you heard the wide adoption of 622M (STM-1) beyond ATM interfaces betw= een ATM switches in the previous ATM networks? If not, the highest non-ATM = interface in the past ATM networks was the FE interface which is 100M bps (= around the year of 2000), If I remembered it correctly. Furthermore, have y= ou heard the reordering issue with ATM cells? If no, that means once an ATM= cell of a given ALL PDU gets lost, all the received ATM cells of that AAL = PDU would be dropped and therefore the reassembly buffer for that AAL datag= ram would be released. In other words, there is no need to wait for the los= t or reordered fragment for a certain period of time before releasing the r= eassembly buffer. Such behavior is not possible for IP fragmentation and re= assembly. Last but not least, there is no need to assign a reassembly buffe= r per AAL PDU (as opposed to per IP datagram in the IP fragmentation and re= assembly case), instead, only one reassembly buffer per VC since all cells = within a given VC would be received in order. Since the SAR is only needed = on the edge of the ATM networks, the number of VCs is very limited. In a wo= rd, there are significant differences between IP fragmentation and ATM SAR.= =20 Best regards, Xiaohu > b) What is the alternative, given we have minimum MTU requirements? >=20 > If you're limiting yourself to IPv4 payloads where DF=3D0, sure, there th= ere is an > alternative. But you've just disabled IPv6 and IPv4 with DF=3D1. >=20 > I.e., it's not possible to NOT implement this and comply with IETF RFCs. >=20 > Joe >=20 >=20 From nobody Thu Jun 2 21:35:05 2016 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 3854B12D1A0; Thu, 2 Jun 2016 21:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 a3Tat0PeYypF; Thu, 2 Jun 2016 21:34:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5E312D15C; Thu, 2 Jun 2016 21:34:55 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u534YTp3015947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Jun 2016 21:34:31 -0700 (PDT) To: Xuxiaohu , "otroan@employees.org" References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> From: Joe Touch Message-ID: <575108D3.3010506@isi.edu> Date: Thu, 2 Jun 2016 21:34:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Softwires WG , "nvo3@ietf.org" , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 04:34:57 -0000 On 6/2/2016 7:53 PM, Xuxiaohu wrote: > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, June 03, 2016 2:08 AM >> To: otroan@employees.org; Xuxiaohu >> Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; >> tsvwg@ietf.org >> Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP >> encapsulated packets. >> >> >> >> On 5/27/2016 3:50 AM, otroan@employees.org wrote: >>> It is not possible to implement reassembly complying with IETF RFCs. >> a) ATM does this at ridiculously high fragment rates. Granted IP frags can come >> out of order, but the fragments are generally much larger. > As pointed in RFC4459, > > "At the time of reassembly, all the information (i.e., all the > fragments) is normally not available; when the first fragment > arrives to be reassembled, a buffer of the maximum possible size > may have to be allocated because the total length of the > reassembled datagram is not known at that time. Furthermore, as > fragments might get lost, or be reordered or delayed, the > reassembly engine has to wait with the partial packet for some > time (e.g., 60 seconds [9]). When this would have to be done at > the line rate, with, for example 10 Gbit/s speed, the length of > the buffers that reassembly might require would be prohibitive. " Yes, but the alternative of declaring that you don't reassemble has a cost in terms of dropped segments too. Taking that drop into account, buffering for a smaller amount of potential reordering and accounting for reasonable reassembly sizes (for IPv6, the smallest "max" that's required is 1500) need not be prohibitive. > Have you heard the wide adoption of 622M (STM-1) beyond ATM interfaces between ATM switches in the previous ATM networks? If not, the highest non-ATM interface in the past ATM networks was the FE interface which is 100M bps (around the year of 2000), If I remembered it correctly. OC12 ATM NICs were commonly available in 1998. That was back when ethernet was pushing 100M and the only other near-gigabit tech was Myricom (a spin-off of USC/ISI and Caltech). I.e., with the tech available at that time, 600Mbps SAR was possible. > Furthermore, have you heard the reordering issue with ATM cells? If no, that means once an ATM cell of a given ALL PDU gets lost, all the received ATM cells of that AAL PDU would be dropped and therefore the reassembly buffer for that AAL datagram would be released. In other words, there is no need to wait for the lost or reordered fragment for a certain period of time before releasing the reassembly buffer. Reordered no, but just because they arrive in order does not mean they are required to arrive *adjacent*. The same requirement applies in terms of needing reassembly buffers for a number of interleaved segments. > Such behavior is not possible for IP fragmentation and reassembly. Last but not least, there is no need to assign a reassembly buffer per AAL PDU (as opposed to per IP datagram in the IP fragmentation and reassembly case), instead, only one reassembly buffer per VC since all cells within a given VC would be received in order. Since the SAR is only needed on the edge of the ATM networks, the number of VCs is very limited. You could easily decide to allocate a fixed number of reassembly buffers per IP flow to conserve resources too. The amount of reordering, together with the number of flows supported would determine your ability to avoid packet drops -- but recall that drops at high load are not unusual for IP. Joe From nobody Fri Jun 3 00:38:59 2016 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 1BB7512D670; Fri, 3 Jun 2016 00:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, RP_MATCHES_RCVD=-1.426, 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 R3Qiwwov-_9K; Fri, 3 Jun 2016 00:38:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A9012D0DE; Fri, 3 Jun 2016 00:38:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLH62853; Fri, 03 Jun 2016 07:38:43 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 3 Jun 2016 08:38:42 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 3 Jun 2016 15:38:40 +0800 From: Xuxiaohu To: Joe Touch , "otroan@employees.org" Thread-Topic: [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. Thread-Index: AQHRvPncHcsWng18N0qPKCUQaW4bNp/W96xA//+qsICAAKCTIA== Date: Fri, 3 Jun 2016 07:38:40 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> <575108D3.3010506@isi.edu> In-Reply-To: <575108D3.3010506@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57513404.004D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b6ae068aa12793195ecad703a67f441c Archived-At: Cc: Softwires WG , "nvo3@ietf.org" , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:38:51 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, June 03, 2016 12:34 PM > To: Xuxiaohu; otroan@employees.org > Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; > tsvwg@ietf.org > Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation o= n UDP > encapsulated packets. >=20 >=20 >=20 > On 6/2/2016 7:53 PM, Xuxiaohu wrote: > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Friday, June 03, 2016 2:08 AM > >> To: otroan@employees.org; Xuxiaohu > >> Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; > >> tsvwg@ietf.org > >> Subject: Re: [nvo3] [Softwires] Is it feasible to perform > >> fragmentation on UDP encapsulated packets. > >> > >> > >> > >> On 5/27/2016 3:50 AM, otroan@employees.org wrote: > >>> It is not possible to implement reassembly complying with IETF RFCs. > >> a) ATM does this at ridiculously high fragment rates. Granted IP > >> frags can come out of order, but the fragments are generally much larg= er. > > As pointed in RFC4459, > > > > "At the time of reassembly, all the information (i.e., all the > > fragments) is normally not available; when the first fragment > > arrives to be reassembled, a buffer of the maximum possible size > > may have to be allocated because the total length of the > > reassembled datagram is not known at that time. Furthermore, as > > fragments might get lost, or be reordered or delayed, the > > reassembly engine has to wait with the partial packet for some > > time (e.g., 60 seconds [9]). When this would have to be done at > > the line rate, with, for example 10 Gbit/s speed, the length of > > the buffers that reassembly might require would be prohibitive. " >=20 > Yes, but the alternative of declaring that you don't reassemble has a cos= t in > terms of dropped segments too. The alternative is to configure the MTU of the core large enough to accommo= date the added encapsulation header. This is a feasible and proven approach= in well-managed SP networks. No packet loss and no forwarding performance = degradation. > Taking that drop into account, buffering for a smaller amount of potentia= l > reordering and accounting for reasonable reassembly sizes (for IPv6, the > smallest "max" that's required is 1500) need not be prohibitive. In the IPv6-in-IPv4 Software network case, assume the MTU of the core is no= t large enough than 1280+20, all the IPv6 traffic across the tunnels would = have to be fragmented and then reassembled. Not a small amount. > > Have you heard the wide adoption of 622M (STM-1) beyond ATM interfaces > between ATM switches in the previous ATM networks? If not, the highest > non-ATM interface in the past ATM networks was the FE interface which is = 100M > bps (around the year of 2000), If I remembered it correctly. >=20 > OC12 ATM NICs were commonly available in 1998. That was back when Sorry, there was a spelling mistake ( s/STM-1/STM-4). OC12/STM-4=3D622M. My question is have you heard the wide adoption of 622M = (STM-4) BEYOND ATM interfaces (e.g., STM-16/OC48) at that time? > ethernet was pushing 100M and the only other near-gigabit tech was Myrico= m > (a spin-off of USC/ISI and Caltech). I.e., with the tech available at tha= t time, > 600Mbps SAR was possible. Was that 600Mbps SAR capability proved in real networks? And for what servi= ce? > > Furthermore, have you heard the reordering issue with ATM cells? If no,= that > means once an ATM cell of a given ALL PDU gets lost, all the received ATM= cells > of that AAL PDU would be dropped and therefore the reassembly buffer for = that > AAL datagram would be released. In other words, there is no need to wait = for > the lost or reordered fragment for a certain period of time before releas= ing the > reassembly buffer. > Reordered no, but just because they arrive in order does not mean they ar= e > required to arrive *adjacent*. The same requirement applies in terms of > needing reassembly buffers for a number of interleaved segments. However, the reassembly buffer requirement is limited due to the fact that = only one buffer is needed per VC and the total number of VCs is not large o= n the edge of ATM networks. In contrast, the number of IP flows is uncontro= llable. > > Such behavior is not possible for IP fragmentation and reassembly. Las= t but > not least, there is no need to assign a reassembly buffer per AAL PDU (as > opposed to per IP datagram in the IP fragmentation and reassembly case), > instead, only one reassembly buffer per VC since all cells within a given= VC would > be received in order. Since the SAR is only needed on the edge of the ATM > networks, the number of VCs is very limited. > You could easily decide to allocate a fixed number of reassembly buffers = per IP > flow to conserve resources too. The amount of reordering, together with t= he What about in the DDoS attack case? Do you believe that SPs would allow the= existence of that obvious DDoS attack risk in their networks and afford th= e significant forwarding performance degradation? especially when there has= been a feasible and proven solution to the MTU issue (i.e., configure the = MTU of the core large enough)? Best regards, Xiaohu > number of flows supported would determine your ability to avoid packet dr= ops > -- but recall that drops at high load are not unusual for IP. >=20 > Joe From nobody Fri Jun 3 05:48:32 2016 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 3325E12D146; Fri, 3 Jun 2016 05:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 W_zYmls8QhWz; Fri, 3 Jun 2016 05:48:16 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) (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 4343612D127; Fri, 3 Jun 2016 05:48:15 -0700 (PDT) Received: from [192.168.0.29] (unknown [78.193.136.169]) by smtp3-g21.free.fr (Postfix) with ESMTPS id 4646A13F6B0; Fri, 3 Jun 2016 12:50:21 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-A1535E92-481B-4573-B233-780626C5AB2B Mime-Version: 1.0 (1.0) From: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: iPad Mail (13E238) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> Date: Fri, 3 Jun 2016 14:48:04 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7C3B0012-D5B9-4857-BE5E-9579265C76DF@laposte.net> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> <575108D3.3010506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> To: Softwires WG Archived-At: Cc: "nvo3@ietf.org" , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [Softwires] [nvo3] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:48:20 -0000 --Apple-Mail-A1535E92-481B-4573-B233-780626C5AB2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > 2016-06-03 09:38, Xuxiaohu : >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, June 03, 2016 12:34 PM ... >> Yes, but the alternative of declaring that you don't reassemble has a cos= t in >> terms of dropped segments too. >=20 > The alternative is to configure the MTU of the core large enough to accomm= odate the added encapsulation header. This is a feasible and proven approach= in well-managed SP networks. No packet loss and no forwarding performance d= egradation. Just for information on this subject, an earlier analysis is a available in h= ttps://tools.ietf.org/html/rfc6751#section-6.4. (No plan to participate again in IETF technical debates.) Regards to all, RD --Apple-Mail-A1535E92-481B-4573-B233-780626C5AB2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

2016-06-03 09:38, Xuxia= ohu <xuxiaohu@huawei.com> :=

-----Original Message-----
From: Joe Touch [mailto:touch@= isi.edu]
Sent: Fri= day, June 03, 2016 12:34 PM
...
<= /span>
Yes, but the= alternative of declaring that you don't reassemble has a cost in
=
terms of dropped segments too.<= /span>

The alternative is to configur= e the MTU of the core large enough to accommodate the added encapsulation he= ader. This is a feasible and proven approach in well-managed SP networks. No= packet loss and no forwarding performance degradation.

Just for information on this subject, an earlier analysis= is a available in https://tools.ietf.org/html/rfc6751#section-6.4.
= (No plan to participate again in IETF technical debates.)

Regards to all,
RD
=
= --Apple-Mail-A1535E92-481B-4573-B233-780626C5AB2B-- From nobody Fri Jun 3 08:15:44 2016 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 B7C6012D555; Fri, 3 Jun 2016 08:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 hLxetBeWhNaA; Fri, 3 Jun 2016 08:15:35 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 BD98C12D1C7; Fri, 3 Jun 2016 08:15:34 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n184so706673wmn.1; Fri, 03 Jun 2016 08:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DsKBy/rkNOl9/IhJfvmjz+gnhN/+rL8EgdGzi4TOAMk=; b=KVW6TXCpd1y399d/T9rxXm6De6xNJNi/Oq489yzicEwLpEuN+OKGikRAznK5xoDfot +5R/P6TaFB2hBiHvQA7AA8q7yOAeB3EA9BPIB7S+Bx3X3ItYGbAdZ09QGap68lBQi6Ua sO9MaFr5ob1NJgUbRtEapV1CHuS1+69O1BEEmJlY2529N2tFfFAmpJWyJKgz32YSt+/h N/so35JmfmAMOQC7uHDnp3JEjXzsBKYjCJbiaR7Fsy0xPg66rKuqosMESQ54Xw9oCBfK EMHGH3Lgumlv0Zk+yvBQKb5bzUMQzbxVoC2bDCMO0xu7gHUor5M6jcFMP/vDH3TPPZY2 cpwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DsKBy/rkNOl9/IhJfvmjz+gnhN/+rL8EgdGzi4TOAMk=; b=Cv+edS36S4gpZPw8chODlSgH+3yGUczftFdFkerpnIjkRJJKrsBfm6Rasvzn5SgmA8 ddCVghYoKtBdvA2mNuqUOHDZNT0ybBMZWzAvJ22bZGIcV/AylZlwxmcx5JNd/WrrBtKK QvxLpJtXbNO+bQAIO6N5BGTXPiG5aB7/anyCYmeDM1uRGWt6tohvy/YxU2buxSQEs+4F W3LltnRoVHP/oM0wXSZRptmnfZmJCHUxq/eU73ZdCNsndgQ7q5TWAvO8A7nzaLvC9EY2 wYbLUWbdt8F6bWx61GLI0UZpkFLF7RK0S8sRqhnWegcadHgZxOHc5JC0Jw3bjoxvygIW cEGQ== X-Gm-Message-State: ALyK8tJWQdk86VlXnmn9xr484fMCXwyRkjIDcElDM/Ij+W9NYlJM7+chIfUdjEwL4833ZiRrKUZRunGvYW10mQ== MIME-Version: 1.0 X-Received: by 10.28.25.129 with SMTP id 123mr84041wmz.10.1464966933220; Fri, 03 Jun 2016 08:15:33 -0700 (PDT) Received: by 10.28.234.13 with HTTP; Fri, 3 Jun 2016 08:15:33 -0700 (PDT) In-Reply-To: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> Date: Fri, 3 Jun 2016 08:15:33 -0700 Message-ID: From: Ca By To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114d3ceea9a1010534613197 Archived-At: Cc: tsvwg WG , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , "quic@ietf.org" , "ietf@ietf.org" Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:15:40 -0000 --001a114d3ceea9a1010534613197 Content-Type: text/plain; charset=UTF-8 On Thursday, June 2, 2016, Brian Trammell wrote: > Greetings, all, > > Apologies for the late last call comment; I have only one, relatively > minor. I hope it's still useful. > > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say this is > hard, this document is a list of reasons why") but as written it would seem > to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data > channel, anything-over-PLUS), which I very much hope was not the intent. > The problematic recommendation is in the second paragraph: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622]. > > First, this paragraph ignores potential deployment issues with any of > these other than TCP, which risks seeming out of touch, but this is a minor > point and probably not worth a late edit. Second, I'm concerned this > recommendation could be taken as broader than intended, against the > definition of any new transport protocol encapsulated within UDP that > performs substantially the same function as the listed protocols. > > I think this can be made clearer by simply adding to the list of examples: > > NEW: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622], or transport > protocols specified by the IETF in the future. > > and removing the examples from the summary in section 7: > > OLD: > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | > > NEW: > > | SHOULD use a full-featured transport | | > > Thanks, cheers, > > Brian > > > > On 18 May 2016, at 02:17, The IESG > wrote: > > > > > > The IESG has received a request from the Transport Area Working Group WG > > (tsvwg) to consider the following document: > > - 'UDP Usage Guidelines' > > as Best Current Practice > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2016-05-31. > Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, please > retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The User Datagram Protocol (UDP) provides a minimal message-passing > > transport that has no inherent congestion control mechanisms. This > > document provides guidelines on the use of UDP for the designers of > > applications, tunnels and other protocols that use UDP. Congestion > > control guidelines are a primary focus, but the document also > > provides guidance on other topics, including message sizes, > > reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > > and ports. > > > > Because congestion control is critical to the stable operation of the > > Internet, applications and other protocols that choose to use UDP as > > an Internet transport must employ mechanisms to prevent congestion > > collapse and to establish some degree of fairness with concurrent > > traffic. They may also need to implement additional mechanisms, > > depending on how they use UDP. > > > > Some guidance is also applicable to the design of other protocols > > (e.g., protocols layered directly on IP or via IP-based tunnels), > > especially when these protocols do not themselves provide congestion > > control. > > > > This document obsoletes RFC5405 and adds guidelines for multicast UDP > > usage. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > I disagree. The text as-is is best and represents a prudent period of review in the WG. As suggested many times to both spud and quic, extending udp is not recommended. We have multiple L4 transport protocols for a reason, you should innovative in that space without UDP. CB --001a114d3ceea9a1010534613197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, June 2, 2016, Brian Trammell <ietf@trammell.ch> wrote:
Greetings, all,

Apologies for the late last call comment; I have only one, relatively minor= . I hope it's still useful.

I understand that Section 3 was written to encourage application developers= not to roll their own transports ("trust us when we say this is hard,= this document is a list of reasons why") but as written it would seem= to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data ch= annel, anything-over-PLUS), which I very much hope was not the intent. The = problematic recommendation is in the second paragraph:

=C2=A0 =C2=A0These mechanisms are difficult to implement correctly.=C2=A0 F= or most
=C2=A0 =C2=A0applications, the use of one of the existing IETF transport pr= otocols
=C2=A0 =C2=A0is the simplest method of acquiring the required mechanisms.= =C2=A0 Doing
=C2=A0 =C2=A0so also avoids issues that protocols using a new IP protocol n= umber
=C2=A0 =C2=A0face when being deployed over the Internet, where middleboxes = that
=C2=A0 =C2=A0only support TCP and UDP are not rare.=C2=A0 Consequently, the= RECOMMENDED
=C2=A0 =C2=A0alternative to the UDP usage described in the remainder of thi= s
=C2=A0 =C2=A0section is the use of an IETF transport protocol such as TCP =C2=A0 =C2=A0[RFC0793], Stream Control Transmission Protocol (SCTP) [RFC496= 0], and
=C2=A0 =C2=A0SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Dat= agram
=C2=A0 =C2=A0Congestion Control Protocol (DCCP) [RFC4340] with its differen= t
=C2=A0 =C2=A0congestion control types [RFC4341][RFC4342][RFC5622].

First, this paragraph ignores potential deployment issues with any of these= other than TCP, which risks seeming out of touch, but this is a minor poin= t and probably not worth a late edit. Second, I'm concerned this recomm= endation could be taken as broader than intended, against the definition of= any new transport protocol encapsulated within UDP that performs substanti= ally the same function as the listed protocols.

I think this can be made clearer by simply adding to the list of examples:<= br>
NEW:

=C2=A0 =C2=A0These mechanisms are difficult to implement correctly.=C2=A0 F= or most
=C2=A0 =C2=A0applications, the use of one of the existing IETF transport pr= otocols
=C2=A0 =C2=A0is the simplest method of acquiring the required mechanisms.= =C2=A0 Doing
=C2=A0 =C2=A0so also avoids issues that protocols using a new IP protocol n= umber
=C2=A0 =C2=A0face when being deployed over the Internet, where middleboxes = that
=C2=A0 =C2=A0only support TCP and UDP are not rare.=C2=A0 Consequently, the= RECOMMENDED
=C2=A0 =C2=A0alternative to the UDP usage described in the remainder of thi= s
=C2=A0 =C2=A0section is the use of an IETF transport protocol such as TCP =C2=A0 =C2=A0[RFC0793], Stream Control Transmission Protocol (SCTP) [RFC496= 0], and
=C2=A0 =C2=A0SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Dat= agram
=C2=A0 =C2=A0Congestion Control Protocol (DCCP) [RFC4340] with its differen= t
=C2=A0 =C2=A0congestion control types [RFC4341][RFC4342][RFC5622], or trans= port
=C2=A0 =C2=A0protocols specified by the IETF in the future.

and removing the examples from the summary in section 7:

OLD:

=C2=A0 =C2=A0| SHOULD use a full-featured transport (TCP, SCTP, DCCP)=C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

NEW:

=C2=A0 =C2=A0| SHOULD use a full-featured transport=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|

Thanks, cheers,

Brian


> On 18 May 2016, at 02:17, The IESG <iesg-sec= retary@ietf.org> wrote:
>
>
> The IESG has received a request from the Transport Area Working Group = WG
> (tsvwg) to consider the following document:
> - 'UDP Usage Guidelines'
>=C2=A0 <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current Pract= ice
>
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 2016-05-31. Exceptiona= lly, comments may be
> sent to iesg@ietf.org instead. In either case, please= retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>=C2=A0 =C2=A0The User Datagram Protocol (UDP) provides a minimal messag= e-passing
>=C2=A0 =C2=A0transport that has no inherent congestion control mechanis= ms.=C2=A0 This
>=C2=A0 =C2=A0document provides guidelines on the use of UDP for the des= igners of
>=C2=A0 =C2=A0applications, tunnels and other protocols that use UDP.=C2= =A0 Congestion
>=C2=A0 =C2=A0control guidelines are a primary focus, but the document a= lso
>=C2=A0 =C2=A0provides guidance on other topics, including message sizes= ,
>=C2=A0 =C2=A0reliability, checksums, middlebox traversal, the use of EC= N, DSCPs,
>=C2=A0 =C2=A0and ports.
>
>=C2=A0 =C2=A0Because congestion control is critical to the stable opera= tion of the
>=C2=A0 =C2=A0Internet, applications and other protocols that choose to = use UDP as
>=C2=A0 =C2=A0an Internet transport must employ mechanisms to prevent co= ngestion
>=C2=A0 =C2=A0collapse and to establish some degree of fairness with con= current
>=C2=A0 =C2=A0traffic.=C2=A0 They may also need to implement additional = mechanisms,
>=C2=A0 =C2=A0depending on how they use UDP.
>
>=C2=A0 =C2=A0Some guidance is also applicable to the design of other pr= otocols
>=C2=A0 =C2=A0(e.g., protocols layered directly on IP or via IP-based tu= nnels),
>=C2=A0 =C2=A0especially when these protocols do not themselves provide = congestion
>=C2=A0 =C2=A0control.
>
>=C2=A0 =C2=A0This document obsoletes RFC5405 and adds guidelines for mu= lticast UDP
>=C2=A0 =C2=A0usage.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc= 5405bis/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-ts= vwg-rfc5405bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

I disagree.=C2=A0 The text as-is is=C2= =A0best and represents a prudent period of review in the WG.=C2=A0=C2=A0As = suggested many times to both spud and quic, extending udp is not recommende= d. We have multiple=C2=A0L4 transport protocols for a reason, you should in= novative in that space without UDP.=C2=A0

CB
--001a114d3ceea9a1010534613197-- From nobody Fri Jun 3 08:28:29 2016 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 6CAD612D1BD; Fri, 3 Jun 2016 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 52pLwdu_uaHa; Fri, 3 Jun 2016 08:28:20 -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 4BFB712D6D4; Fri, 3 Jun 2016 08:28:20 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id B75A41B00259; Fri, 3 Jun 2016 16:40:30 +0100 (BST) Message-ID: <5751A209.70601@erg.abdn.ac.uk> Date: Fri, 03 Jun 2016 16:28:09 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ca By References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ietf@ietf.org" , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , "quic@ietf.org" , tsvwg WG Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:28:23 -0000 It is certainly not too late, many thanks - to both Brian and you! We have various pending comments to look through, and will make sure all comments are also taken into consideration, - next week we'll be resolving the conflicts between comments and seeing how best to accommodate these in updated text, comments then may be late! Gorry On 03/06/2016 16:15, Ca By wrote: > > > On Thursday, June 2, 2016, Brian Trammell > wrote: > > Greetings, all, > > Apologies for the late last call comment; I have only one, > relatively minor. I hope it's still useful. > > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say > this is hard, this document is a list of reasons why") but as > written it would seem to discourage transport innovation atop UDP > (e.g. QUIC, the RTCWEB data channel, anything-over-PLUS), which I > very much hope was not the intent. The problematic recommendation > is in the second paragraph: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport > protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the > RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) > [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622]. > > First, this paragraph ignores potential deployment issues with any > of these other than TCP, which risks seeming out of touch, but > this is a minor point and probably not worth a late edit. Second, > I'm concerned this recommendation could be taken as broader than > intended, against the definition of any new transport protocol > encapsulated within UDP that performs substantially the same > function as the listed protocols. > > I think this can be made clearer by simply adding to the list of > examples: > > NEW: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport > protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the > RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) > [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622], or transport > protocols specified by the IETF in the future. > > and removing the examples from the summary in section 7: > > OLD: > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | > | > > NEW: > > | SHOULD use a full-featured transport | > | > > Thanks, cheers, > > Brian > > > > On 18 May 2016, at 02:17, The IESG > wrote: > > > > > > The IESG has received a request from the Transport Area Working > Group WG > > (tsvwg) to consider the following document: > > - 'UDP Usage Guidelines' > > as Best Current Practice > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final comments on this action. Please send substantive comments > to the > > ietf@ietf.org mailing lists by 2016-05-31. > Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, > please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The User Datagram Protocol (UDP) provides a minimal > message-passing > > transport that has no inherent congestion control mechanisms. > This > > document provides guidelines on the use of UDP for the > designers of > > applications, tunnels and other protocols that use UDP. > Congestion > > control guidelines are a primary focus, but the document also > > provides guidance on other topics, including message sizes, > > reliability, checksums, middlebox traversal, the use of ECN, > DSCPs, > > and ports. > > > > Because congestion control is critical to the stable operation > of the > > Internet, applications and other protocols that choose to use > UDP as > > an Internet transport must employ mechanisms to prevent congestion > > collapse and to establish some degree of fairness with concurrent > > traffic. They may also need to implement additional mechanisms, > > depending on how they use UDP. > > > > Some guidance is also applicable to the design of other protocols > > (e.g., protocols layered directly on IP or via IP-based tunnels), > > especially when these protocols do not themselves provide > congestion > > control. > > > > This document obsoletes RFC5405 and adds guidelines for > multicast UDP > > usage. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > I disagree. The text as-is is best and represents a prudent period of > review in the WG. As suggested many times to both spud and quic, > extending udp is not recommended. We have multiple L4 transport > protocols for a reason, you should innovative in that space without UDP. > > CB From nobody Fri Jun 3 09:27:26 2016 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 0043112D702; Fri, 3 Jun 2016 09:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, RP_MATCHES_RCVD=-1.426, 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 Oy5WGvqFclwk; Fri, 3 Jun 2016 09:27:13 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 64A6F12D5AC; Fri, 3 Jun 2016 09:27:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u53GRODW011554; Fri, 3 Jun 2016 09:27:25 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u53GRJlP011406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 09:27:19 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 3 Jun 2016 09:27:06 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 3 Jun 2016 09:27:06 -0700 From: "Templin, Fred L" To: Xuxiaohu , Joe Touch , "otroan@employees.org" Thread-Topic: [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. Thread-Index: AQHRvWr/d3+tgL34oUSVk+7sP6lEoZ/X6QAw Date: Fri, 3 Jun 2016 16:27:06 +0000 Message-ID: <528400d44d934332bf7382e062f13d73@XCH15-05-05.nw.nos.boeing.com> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> <575108D3.3010506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: Softwires WG , "nvo3@ietf.org" , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:27:16 -0000 > The alternative is to configure the MTU of the core large enough to accom= modate the added encapsulation header. But what if you can't do that? All it takes is one link with a small and/or misconfigured MTU... Fred fred.l.templin@boeing.com > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Friday, June 03, 2016 12:39 AM > To: Joe Touch ; otroan@employees.org > Cc: Softwires WG ; nvo3@ietf.org; int-area@ietf.org; = lisp@ietf.org; tsvwg@ietf.org > Subject: Re: [Int-area] [nvo3] [Softwires] Is it feasible to perform frag= mentation on UDP encapsulated packets. >=20 >=20 >=20 > > -----Original Message----- > > From: Joe Touch [mailto:touch@isi.edu] > > Sent: Friday, June 03, 2016 12:34 PM > > To: Xuxiaohu; otroan@employees.org > > Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; > > tsvwg@ietf.org > > Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation= on UDP > > encapsulated packets. > > > > > > > > On 6/2/2016 7:53 PM, Xuxiaohu wrote: > > > > > >> -----Original Message----- > > >> From: Joe Touch [mailto:touch@isi.edu] > > >> Sent: Friday, June 03, 2016 2:08 AM > > >> To: otroan@employees.org; Xuxiaohu > > >> Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; > > >> tsvwg@ietf.org > > >> Subject: Re: [nvo3] [Softwires] Is it feasible to perform > > >> fragmentation on UDP encapsulated packets. > > >> > > >> > > >> > > >> On 5/27/2016 3:50 AM, otroan@employees.org wrote: > > >>> It is not possible to implement reassembly complying with IETF RFCs= . > > >> a) ATM does this at ridiculously high fragment rates. Granted IP > > >> frags can come out of order, but the fragments are generally much la= rger. > > > As pointed in RFC4459, > > > > > > "At the time of reassembly, all the information (i.e., all the > > > fragments) is normally not available; when the first fragment > > > arrives to be reassembled, a buffer of the maximum possible siz= e > > > may have to be allocated because the total length of the > > > reassembled datagram is not known at that time. Furthermore, as > > > fragments might get lost, or be reordered or delayed, the > > > reassembly engine has to wait with the partial packet for some > > > time (e.g., 60 seconds [9]). When this would have to be done a= t > > > the line rate, with, for example 10 Gbit/s speed, the length of > > > the buffers that reassembly might require would be prohibitive.= " > > > > Yes, but the alternative of declaring that you don't reassemble has a c= ost in > > terms of dropped segments too. >=20 > The alternative is to configure the MTU of the core large enough to accom= modate the added encapsulation header. This is a feasible > and proven approach in well-managed SP networks. No packet loss and no fo= rwarding performance degradation. >=20 > > Taking that drop into account, buffering for a smaller amount of potent= ial > > reordering and accounting for reasonable reassembly sizes (for IPv6, th= e > > smallest "max" that's required is 1500) need not be prohibitive. >=20 > In the IPv6-in-IPv4 Software network case, assume the MTU of the core is = not large enough than 1280+20, all the IPv6 traffic across > the tunnels would have to be fragmented and then reassembled. Not a small= amount. >=20 > > > Have you heard the wide adoption of 622M (STM-1) beyond ATM interface= s > > between ATM switches in the previous ATM networks? If not, the highest > > non-ATM interface in the past ATM networks was the FE interface which i= s 100M > > bps (around the year of 2000), If I remembered it correctly. > > > > OC12 ATM NICs were commonly available in 1998. That was back when >=20 > Sorry, there was a spelling mistake ( s/STM-1/STM-4). >=20 > OC12/STM-4=3D622M. My question is have you heard the wide adoption of 622= M (STM-4) BEYOND ATM interfaces (e.g., STM-16/OC48) > at that time? >=20 > > ethernet was pushing 100M and the only other near-gigabit tech was Myri= com > > (a spin-off of USC/ISI and Caltech). I.e., with the tech available at t= hat time, > > 600Mbps SAR was possible. >=20 > Was that 600Mbps SAR capability proved in real networks? And for what ser= vice? >=20 > > > Furthermore, have you heard the reordering issue with ATM cells? If n= o, that > > means once an ATM cell of a given ALL PDU gets lost, all the received A= TM cells > > of that AAL PDU would be dropped and therefore the reassembly buffer fo= r that > > AAL datagram would be released. In other words, there is no need to wai= t for > > the lost or reordered fragment for a certain period of time before rele= asing the > > reassembly buffer. > > Reordered no, but just because they arrive in order does not mean they = are > > required to arrive *adjacent*. The same requirement applies in terms of > > needing reassembly buffers for a number of interleaved segments. >=20 > However, the reassembly buffer requirement is limited due to the fact tha= t only one buffer is needed per VC and the total number of > VCs is not large on the edge of ATM networks. In contrast, the number of = IP flows is uncontrollable. >=20 > > > Such behavior is not possible for IP fragmentation and reassembly. L= ast but > > not least, there is no need to assign a reassembly buffer per AAL PDU (= as > > opposed to per IP datagram in the IP fragmentation and reassembly case)= , > > instead, only one reassembly buffer per VC since all cells within a giv= en VC would > > be received in order. Since the SAR is only needed on the edge of the A= TM > > networks, the number of VCs is very limited. > > You could easily decide to allocate a fixed number of reassembly buffer= s per IP > > flow to conserve resources too. The amount of reordering, together with= the >=20 > What about in the DDoS attack case? Do you believe that SPs would allow t= he existence of that obvious DDoS attack risk in their > networks and afford the significant forwarding performance degradation? e= specially when there has been a feasible and proven > solution to the MTU issue (i.e., configure the MTU of the core large enou= gh)? >=20 > Best regards, > Xiaohu >=20 > > number of flows supported would determine your ability to avoid packet = drops > > -- but recall that drops at high load are not unusual for IP. > > > > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 3 09:44:56 2016 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 824A212D729 for ; Fri, 3 Jun 2016 09:44:53 -0700 (PDT) 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 YymAyMJVQH_M for ; Fri, 3 Jun 2016 09:44:42 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C348C12D724 for ; Fri, 3 Jun 2016 09:44:41 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id z123so2937553itg.0 for ; Fri, 03 Jun 2016 09:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=diFCe03zfS80dDcGfVJMpj9HUrKCetL0y9rfjiTu5PE=; b=GsWtyA+LbeeB5aqaNW1fel3aGmlKNMT/rj0Mi6+/W2cQ0QdDqGqvVLk0373lS/PG3b ZL/KK4J5UFvbbtQcesm0zbudw/R3WKA7SLNvX47V4tVhks0DzwkvP8Ksp/yNLDKuOBik lwPcZkpXFxrqGfYOpR1xPtEs4+Q67tdbI9AxnPmzSA2woS84atbKeTmhplU9BE04TpP8 NE8PlgN8kglUIJcW6kjpxVFsI5CuepdGlhHHODXg+3ihKBNfHDdIkS4aTDQZrEbpub0l mfm1Q6RRY2WJdlaBTAIX68CqTq40Oj0p7HFVdyKuIrUZ4+VVLWqw8wPJjQiOfImq1FO3 6twg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=diFCe03zfS80dDcGfVJMpj9HUrKCetL0y9rfjiTu5PE=; b=k/AaDvSeic5G52O2BUGG4X5Wqqv8tqh2tnHrTmIOQggIowKAHcH2+fQOG9vvIPDX6j oz0rXsv8aqa1xV0rdymRuy4Bo2Zib/IBPIPlR2JPbskbio+7z1fMiQ3RRQNIaOf9VBQy jcmkSo8VQcUJRQ6xu9gTthkvwYEZVPi/yXcReifIZ5uIYHw3TD2QCHXQ6bg/nYSwNyss 5VFICjmZpd/xEMFV8xnrk23IAoXM/CVYKvi7kbQAD9Aa2ikKnciy6h95KzSGszA9kbUu 0GpZL4/0D2TRNfKBq8VhGWWw3RtDLemkY1iYAmKdNkp4mJZ2uNNNl3RZnfnhMm1j7xv9 gR6Q== X-Gm-Message-State: ALyK8tLJxi5MLXntQM1tqoLH03u9FcTK3uYLlcmQDTVG8ag/XSZaeXX13uTC85cZgVSW3V9qwJZXvI3C2HakrQ== MIME-Version: 1.0 X-Received: by 10.36.66.68 with SMTP id i65mr676252itb.91.1464972281013; Fri, 03 Jun 2016 09:44:41 -0700 (PDT) Received: by 10.107.11.20 with HTTP; Fri, 3 Jun 2016 09:44:40 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> <575108D3.3010506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> Date: Fri, 3 Jun 2016 09:44:40 -0700 Message-ID: From: Tom Herbert To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "int-area@ietf.org" , "lisp@ietf.org" , Joe Touch , "nvo3@ietf.org" , "otroan@employees.org" , Softwires WG , "tsvwg@ietf.org" Subject: Re: [tsvwg] [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:44:53 -0000 On Fri, Jun 3, 2016 at 12:38 AM, Xuxiaohu wrote: > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, June 03, 2016 12:34 PM >> To: Xuxiaohu; otroan@employees.org >> Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; >> tsvwg@ietf.org >> Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation = on UDP >> encapsulated packets. >> >> >> >> On 6/2/2016 7:53 PM, Xuxiaohu wrote: >> > >> >> -----Original Message----- >> >> From: Joe Touch [mailto:touch@isi.edu] >> >> Sent: Friday, June 03, 2016 2:08 AM >> >> To: otroan@employees.org; Xuxiaohu >> >> Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org; >> >> tsvwg@ietf.org >> >> Subject: Re: [nvo3] [Softwires] Is it feasible to perform >> >> fragmentation on UDP encapsulated packets. >> >> >> >> >> >> >> >> On 5/27/2016 3:50 AM, otroan@employees.org wrote: >> >>> It is not possible to implement reassembly complying with IETF RFCs. >> >> a) ATM does this at ridiculously high fragment rates. Granted IP >> >> frags can come out of order, but the fragments are generally much lar= ger. >> > As pointed in RFC4459, >> > >> > "At the time of reassembly, all the information (i.e., all the >> > fragments) is normally not available; when the first fragment >> > arrives to be reassembled, a buffer of the maximum possible size >> > may have to be allocated because the total length of the >> > reassembled datagram is not known at that time. Furthermore, as >> > fragments might get lost, or be reordered or delayed, the >> > reassembly engine has to wait with the partial packet for some >> > time (e.g., 60 seconds [9]). When this would have to be done at >> > the line rate, with, for example 10 Gbit/s speed, the length of >> > the buffers that reassembly might require would be prohibitive. = " >> >> Yes, but the alternative of declaring that you don't reassemble has a co= st in >> terms of dropped segments too. > > The alternative is to configure the MTU of the core large enough to accom= modate the added encapsulation header. This is a feasible and proven approa= ch in well-managed SP networks. No packet loss and no forwarding performanc= e degradation. > >> Taking that drop into account, buffering for a smaller amount of potenti= al >> reordering and accounting for reasonable reassembly sizes (for IPv6, the >> smallest "max" that's required is 1500) need not be prohibitive. > > In the IPv6-in-IPv4 Software network case, assume the MTU of the core is = not large enough than 1280+20, all the IPv6 traffic across the tunnels woul= d have to be fragmented and then reassembled. Not a small amount. > >> > Have you heard the wide adoption of 622M (STM-1) beyond ATM interfaces >> between ATM switches in the previous ATM networks? If not, the highest >> non-ATM interface in the past ATM networks was the FE interface which is= 100M >> bps (around the year of 2000), If I remembered it correctly. >> >> OC12 ATM NICs were commonly available in 1998. That was back when > > Sorry, there was a spelling mistake ( s/STM-1/STM-4). > > OC12/STM-4=3D622M. My question is have you heard the wide adoption of 622= M (STM-4) BEYOND ATM interfaces (e.g., STM-16/OC48) at that time? > >> ethernet was pushing 100M and the only other near-gigabit tech was Myric= om >> (a spin-off of USC/ISI and Caltech). I.e., with the tech available at th= at time, >> 600Mbps SAR was possible. > > Was that 600Mbps SAR capability proved in real networks? And for what ser= vice? > >> > Furthermore, have you heard the reordering issue with ATM cells? If no= , that >> means once an ATM cell of a given ALL PDU gets lost, all the received AT= M cells >> of that AAL PDU would be dropped and therefore the reassembly buffer for= that >> AAL datagram would be released. In other words, there is no need to wait= for >> the lost or reordered fragment for a certain period of time before relea= sing the >> reassembly buffer. >> Reordered no, but just because they arrive in order does not mean they a= re >> required to arrive *adjacent*. The same requirement applies in terms of >> needing reassembly buffers for a number of interleaved segments. > > However, the reassembly buffer requirement is limited due to the fact tha= t only one buffer is needed per VC and the total number of VCs is not large= on the edge of ATM networks. In contrast, the number of IP flows is uncont= rollable. > >> > Such behavior is not possible for IP fragmentation and reassembly. La= st but >> not least, there is no need to assign a reassembly buffer per AAL PDU (a= s >> opposed to per IP datagram in the IP fragmentation and reassembly case), >> instead, only one reassembly buffer per VC since all cells within a give= n VC would >> be received in order. Since the SAR is only needed on the edge of the AT= M >> networks, the number of VCs is very limited. >> You could easily decide to allocate a fixed number of reassembly buffers= per IP >> flow to conserve resources too. The amount of reordering, together with = the > > What about in the DDoS attack case? Do you believe that SPs would allow t= he existence of that obvious DDoS attack risk in their networks and afford = the significant forwarding performance degradation? especially when there h= as been a feasible and proven solution to the MTU issue (i.e., configure th= e MTU of the core large enough)? > That is precisely solution #3 in RFC4459: "Ensure that in the specific environment, the encapsulated packets will fit in all the paths in the network, e.g., by using MTU bigger than 1500 in the backbone used for encapsulation." If you're able to implement this in you network that's great, but it is not feasible in all situations and hence can't be the standard. We may not control all the underlay networks (definitely not over the Internet) and hence not be able to set all the MTUs large enough. Also an MTU greater than 1500 require jumbo frames, not all networks enabled those. One other point, when a device sources or sinks IP packets like in tunneling it is taking on the role of a host and so we expect host requirements apply. For instance, routers may perform fragmentation in IPv4, but they do not perform fragmentation for IPv6 or reassembly (those are hosts functionalities). There has been at least one attempt to carve out exceptions in applying host requirements to devices that perform tunneling, that is an allowance to send a zero UDP checksum in in IPv6. Documenting this took two RFCs and we still needed a whole lot of description in at least GRE/UDP on requirements that to use the non-zero checksum. I don't think standardizing exceptions in fragmentation for tunnels would be any easier. Tom > Best regards, > Xiaohu > >> number of flows supported would determine your ability to avoid packet d= rops >> -- but recall that drops at high load are not unusual for IP. >> >> Joe > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 3 10:01:00 2016 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 4ED6312D534 for ; Fri, 3 Jun 2016 10:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FSO5hmWW_zcH for ; Fri, 3 Jun 2016 10:00:54 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B071212D5A6 for ; Fri, 3 Jun 2016 10:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2095; q=dns/txt; s=iport; t=1464973253; x=1466182853; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gTmmSJzQsBjgGhrRb8JGSPy2HtbWdTRXjzQcvT/NumU=; b=mkRDGPFcVmZSDSiG6DnSQUbGBPUlddBhS/AxZTpQNQLD8uyHt81qhIZ7 1t/lCyJ6r+3Lpo4E9Vv6U27dJ03Z+yKauEGYoDGf/d0icoAvRT2gyrjPD G2rVTASp8MxnWix/VPVcR2VR3fo057gVQd6Pu10jxksrY0O8A+bu9J3z2 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0BQAnt1FX/49dJa1cDoMsgVMGuEmEC?= =?us-ascii?q?IYSAoE3OxEBAQEBAQEBZRwLhEUBAQEDAR1cBQsCAQgYLjIlAgQOBQ6IGQjCZwE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQ4OiB4Igk6HbIIuBZhFAYMsgWmJDoFphE+IZ?= =?us-ascii?q?IY2iRsBNCCDMztuiRN/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,413,1459814400"; d="asc'?scan'208";a="111292403" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2016 17:00:52 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u53H0qsT016231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Jun 2016 17:00:52 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 3 Jun 2016 12:00:52 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Fri, 3 Jun 2016 12:00:52 -0500 From: "Fred Baker (fred)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] TSVWG working group :: detailed status update on work items Thread-Index: AQHRvbl8Gfq3/1Zg6UyT9q5ou+JcwA== Date: Fri, 3 Jun 2016 17:00:52 +0000 Message-ID: References: <573D9B0D.2020307@erg.abdn.ac.uk> In-Reply-To: <573D9B0D.2020307@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_011E94C3-3D7A-48C4-9C87-B9B3045B4D14"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: tsvwg WG Subject: Re: [tsvwg] TSVWG working group :: detailed status update on work items X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:00:57 -0000 --Apple-Mail=_011E94C3-3D7A-48C4-9C87-B9B3045B4D14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 19, 2016, at 3:53 AM, Gorry Fairhurst = wrote: >=20 > Drafts under consideration by WG for adoption: > --- > draft-szigeti-tsvwg-ieee-802-11 - Document Shepherd: TBD > Mapping to 802.11 > - Initial presentation at Prague IETF (Summer 2014) > - Presentation at IETF Nov 2015. > Thought to fall within TSVWG charter > - No call issued for adoption at this time. > Chair Note: Does this need to reference RC4594 or an update to that = spec.? > There's some background work that's likely to surface as proposed = 4594bis and 5127bis drafts. > DUE: Please discuss on the TSVWG list. > DUE: Working Group call for adoption. What is the current status? We have not observed an adoption call, or = received any reviews. --Apple-Mail=_011E94C3-3D7A-48C4-9C87-B9B3045B4D14 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV1G3w0ayAOS/EQ8MAQJGHRAAjMbrmjz7s1V4lg9jNXIHPuy3kSvqNak7 N3/Lo+ElSjnkktzm1OFhhj8OF7jVLiYUIIymWjdgRrc97Nc2EIVZgalIRe7Yc0cE QiqH5AMgzxiAKu9vwdqw8XtDzsMJeOit3pzkUhJAVnwYdgnQCy0FW/YDfj9En3Dy oBqjc9e50GrdFfzqlw+/j7MCR1B3+aE0VJXsX84YfnwQDetLtFAwoOG4ciASpIOg Y6qa9ODvWCcSru6iyBczQzjOQJgcGC7E6XjWZaAnwlgztdbTyRL/svzLOONua/Ta 2AjiivHIAan4JCDnDu6tAjYoZUwfwHlpEek9H4WTsvLf4rCwC+5Qbeu5PyJiUn1S RxS1GLnmwm4ON1jEcysbvrKx4Re/QaB9jaQaVsqdjVEDF4CC4DoxQje3g2O1xggl z8CLmOT+zSxtJhqijwUYeFkgGXq/gPqmAqihAedfjXa6re7TZeuftU73Mlwi5Dkf Zyeth0f81G/hbrnUYBuqY+Ju85L355Gw0qky7SbhQnjK/N4U67dTp7RE/7Wg7djn OT79j3IHlwTpa5ark56HzZYKAogx0kgkrIRG7852DXe7V3jmUbl+Bg9Lgd8N43di I54/o8YxFW/SDdicGtJNCpHhJFOeZxPf6CfNyo6R5Gvx+XnM6VC1ExKSUpuJ/nrO XnmJUKZciYw= =Ie4G -----END PGP SIGNATURE----- --Apple-Mail=_011E94C3-3D7A-48C4-9C87-B9B3045B4D14-- From nobody Fri Jun 3 10:12:20 2016 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 C4FCD12D74B for ; Fri, 3 Jun 2016 10:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 eO0pkbJ89feP for ; Fri, 3 Jun 2016 10:12:16 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0A312D746 for ; Fri, 3 Jun 2016 10:12:16 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u53HC9MT027119 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Jun 2016 13:12:11 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u53HC9MT027119 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1464973931; bh=J3u01AuVwD5qi5yeyz1FJWD+Gzk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=FuVvJwqJKYUbQKiuO1g3UamVtJd2MUgRIx2P3a4FCfcy99HbRyBlUmsoVyRIDYolU p7EtsaDosNnqKw6sE8++zk4YaekpeB5zSnxWt9nkvW8Jp5cDVO7nsWuhkl5QVPejov 8T+oUtkKgKLEw4wdLx+XvQO7efYaXvNIu8yo1LX4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u53HC9MT027119 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 3 Jun 2016 13:11:25 -0400 Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u53HBnX8029747 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 3 Jun 2016 13:11:49 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0266.001; Fri, 3 Jun 2016 13:11:48 -0400 From: "Black, David" To: "Fred Baker (fred)" , "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] TSVWG working group :: detailed status update on work items Thread-Index: AQHRsbymYkpqHFmoKEqC+RfUEKLBgp/YUo0A//+/tZA= Date: Fri, 3 Jun 2016 17:11:48 +0000 Message-ID: References: <573D9B0D.2020307@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.238.45.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: tsvwg WG Subject: Re: [tsvwg] TSVWG working group :: detailed status update on work items X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:12:18 -0000 WG adoption call coming soon ... Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Friday, June 03, 2016 1:01 PM > To: gorry@erg.abdn.ac.uk > Cc: tsvwg WG > Subject: Re: [tsvwg] TSVWG working group :: detailed status update on wor= k > items >=20 >=20 > > On May 19, 2016, at 3:53 AM, Gorry Fairhurst wro= te: > > > > Drafts under consideration by WG for adoption: > > --- > > draft-szigeti-tsvwg-ieee-802-11 - Document Shepherd: TBD > > Mapping to 802.11 > > - Initial presentation at Prague IETF (Summer 2014) > > - Presentation at IETF Nov 2015. > > Thought to fall within TSVWG charter > > - No call issued for adoption at this time. > > Chair Note: Does this need to reference RC4594 or an update to that spe= c.? > > There's some background work that's likely to surface as proposed 4594b= is and > 5127bis drafts. > > DUE: Please discuss on the TSVWG list. > > DUE: Working Group call for adoption. >=20 > What is the current status? We have not observed an adoption call, or rec= eived > any reviews. From nobody Sat Jun 4 17:25:59 2016 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 0A19212D61D for ; Sat, 4 Jun 2016 17:25:46 -0700 (PDT) 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=unavailable 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 VbbK1gR6bmP0 for ; Sat, 4 Jun 2016 17:25:44 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7159212D56D for ; Sat, 4 Jun 2016 17:25:40 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id z189so17567477itg.0 for ; Sat, 04 Jun 2016 17:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Tr9nltT73o9INI2kp840W1290VmBxSOBrHWqjzzCmZE=; b=JbafQv+6RcTTveWpgFwnlmWjldtJijYi6YOkNX5czrV8ePdOx3GKDicjj7hJf9bQKI OBBeH+Hjiy/z82gRL1s3x0q1oBbn8dbk0TLoSBvRWJdRy7kvrM/15tbfZL1VbRBO02GF +LlKPvo20g2VRTr9uoJU36k5Uxfb8Aaj348w5W5GJFPNlTJQ2F+b35dfkDybA9JfQT/P fyrM4P4K7xss3JSfZflk1dqYaVdRCxVOmT0stuMdSmwTSgV158cGKCcQnb8hg6+mgzmi Q4IY8YG256gyLU2ZklcGlN0NqzrHFfb7SmBpOhe30YrpBljlIb99iZMGYXEOhQ9eFOa0 K51w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Tr9nltT73o9INI2kp840W1290VmBxSOBrHWqjzzCmZE=; b=l40zG4Slq2Gxxwc2+T34MPtkCj1AslVznz5zA4NXCXaooDh04pw+WFEX7u9YqJYWfc HmFFODexWU51snIymjlUinzQkjuTyyGFHn4TWgSaMYTbbWwcnIahPmXSh3+s4zeZqAew 2e4FNe69VOlj7++8QvnCsEtA/r04RRdB9eTfGvHaVk1fo+wFIrgjQrCkrm++7HbNSxug 2tjiEUv5BhZ8KtYt+Mj4rh4Vb+YEc1iYgQb3dy61h/7nn0RbWgrihtOHWnv1orISiwFj zye+2ncqANbjM3wImcthHJQVwiNyvvJRPv/FeLOAj5sYm6jWoZSgkhCj6roaRc8DGM6h nYBg== X-Gm-Message-State: ALyK8tJaUFYPbYVjRSPH13THcFXCKnhasCiN+Lo99wv3JimVZkQOHFemWpi6OJ9GNRSNPgxNoN25OIUtQCsNJw== MIME-Version: 1.0 X-Received: by 10.36.73.219 with SMTP id e88mr656270itd.88.1465086339582; Sat, 04 Jun 2016 17:25:39 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Sat, 4 Jun 2016 17:25:39 -0700 (PDT) In-Reply-To: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> Date: Sat, 4 Jun 2016 17:25:39 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tsvwg WG , draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud , quic@ietf.org, ietf@ietf.org Subject: Re: [tsvwg] [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 00:25:46 -0000 On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell wrote: > Greetings, all, > > Apologies for the late last call comment; I have only one, relatively min= or. I hope it's still useful. > > I understand that Section 3 was written to encourage application develope= rs not to roll their own transports ("trust us when we say this is hard, th= is document is a list of reasons why") but as written it would seem to disc= ourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data channel, a= nything-over-PLUS), which I very much hope was not the intent. The problema= tic recommendation is in the second paragraph: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622]. > > First, this paragraph ignores potential deployment issues with any of the= se other than TCP, which risks seeming out of touch, but this is a minor po= int and probably not worth a late edit. Second, I'm concerned this recommen= dation could be taken as broader than intended, against the definition of a= ny new transport protocol encapsulated within UDP that performs substantial= ly the same function as the listed protocols. > I would agree, this paragraph also seems a little self contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence recommends the use of several other protocols besides UDP and TCP. If I put these two together, the only congested controlled protocol that is recommended and expected to work on the Internet is TCP. Tom > I think this can be made clearer by simply adding to the list of examples= : > > NEW: > > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622], or transport > protocols specified by the IETF in the future. > > and removing the examples from the summary in section 7: > > OLD: > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | > > NEW: > > | SHOULD use a full-featured transport | | > > Thanks, cheers, > > Brian > > >> On 18 May 2016, at 02:17, The IESG wrote: >> >> >> The IESG has received a request from the Transport Area Working Group WG >> (tsvwg) to consider the following document: >> - 'UDP Usage Guidelines' >> as Best Current Practice >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The User Datagram Protocol (UDP) provides a minimal message-passing >> transport that has no inherent congestion control mechanisms. This >> document provides guidelines on the use of UDP for the designers of >> applications, tunnels and other protocols that use UDP. Congestion >> control guidelines are a primary focus, but the document also >> provides guidance on other topics, including message sizes, >> reliability, checksums, middlebox traversal, the use of ECN, DSCPs, >> and ports. >> >> Because congestion control is critical to the stable operation of the >> Internet, applications and other protocols that choose to use UDP as >> an Internet transport must employ mechanisms to prevent congestion >> collapse and to establish some degree of fairness with concurrent >> traffic. They may also need to implement additional mechanisms, >> depending on how they use UDP. >> >> Some guidance is also applicable to the design of other protocols >> (e.g., protocols layered directly on IP or via IP-based tunnels), >> especially when these protocols do not themselves provide congestion >> control. >> >> This document obsoletes RFC5405 and adds guidelines for multicast UDP >> usage. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Sun Jun 5 22:18:26 2016 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 E273312D1D2; Sun, 5 Jun 2016 22:18:21 -0700 (PDT) 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 aGD7uAuWsAlo; Sun, 5 Jun 2016 22:18:19 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 109AD12D0BD; Sun, 5 Jun 2016 22:18:19 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id i187so6596029qkd.1; Sun, 05 Jun 2016 22:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E9HUlQcDLaTPNu8n7gqY4Ei8O/K2BMxLCMiJSMC4HGg=; b=V8em/3XD5KukG1RhnW+prCbL4ht7tPb7w/oALvCBhl1WFBTluGY5WV++kC10dAHx+r oqYNt8MbalRqNOXlEHQHbBKTwYoJvdVBht+yZpgSI/Cd+wxgbSNjUFna4KQu4LWW0SXq q6WOPyJO+q/ZODJKLu4k9imJ5hWMwR9hYLqsmzR453lHDvgEYg6/EqyfeJobnGoqBbib UOQOVtrsTsN+UqrX4SojcNjP/Fn5z8VnKff1LJ4y9038ZPOkhts5Ne3nc7qM+HENSkFw Udv8d+q0Y1EylNHRJznLYCKi7ArkHikE6h4W4jQtWgxQR56XIHwgt/xDOBz+2b3yiJJv V8fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E9HUlQcDLaTPNu8n7gqY4Ei8O/K2BMxLCMiJSMC4HGg=; b=AGt6LBUf+1UZzXqyB4dWhWtXBwsMPCkmlxzOrPHfUtiESrlhv8Gx5Ytcm/Kr/d4zsk k4CvkoezubejIyxLx1ASSfyYuB25Y11mR8VGOBDgeOX+akK2K5Y9M9Svx5LaBEtG+0jm yavcYNkemMezOwohoKN8M5AgfT56jeQTXuw+9V7ZEchP4Tjt8sHWniWoiplzN0+FnAiD KsAYbq50LPA5nJe60gcYTKMZHLsCsYNumQOqugMvKtZj7wertX+wQAK8l+zLrQqJrvFg thuK/qtU2Rn89AirMiBY/FFsxmhZRb86yki6hVpL9gjiytX9VfXpvyswj9FszDGNUi0L qjwg== X-Gm-Message-State: ALyK8tIgxKWFckrXWmIt3diJ9p9//Jwyw5SQuKUUP+G8GaMiavRRlxYP6i5TK6RY/pVUqumvSKZIk5WEQ/P7JA== X-Received: by 10.55.170.75 with SMTP id t72mr14461835qke.100.1465190298163; Sun, 05 Jun 2016 22:18:18 -0700 (PDT) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.237.33.186 with HTTP; Sun, 5 Jun 2016 22:18:17 -0700 (PDT) In-Reply-To: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> From: Jim Roskind Date: Sun, 5 Jun 2016 22:18:17 -0700 X-Google-Sender-Auth: 5lF5b1hzSIq4fWy-bWzA7Kde6fs Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a114d8a20402fb30534953324 Archived-At: Cc: tsvwg WG , draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud , quic@ietf.org, ietf@ietf.org Subject: Re: [tsvwg] [QUIC] [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 05:18:22 -0000 --001a114d8a20402fb30534953324 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert wrote: > On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell wrote: > > Greetings, all, > > > > Apologies for the late last call comment; I have only one, relatively > minor. I hope it's still useful. > > > > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say this is > hard, this document is a list of reasons why") but as written it would seem > to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data > channel, anything-over-PLUS), which I very much hope was not the intent. > The problematic recommendation is in the second paragraph: > > > > These mechanisms are difficult to implement correctly. For most > > applications, the use of one of the existing IETF transport protocols > > is the simplest method of acquiring the required mechanisms. Doing > > so also avoids issues that protocols using a new IP protocol number > > face when being deployed over the Internet, where middleboxes that > > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > > alternative to the UDP usage described in the remainder of this > > section is the use of an IETF transport protocol such as TCP > > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > > Congestion Control Protocol (DCCP) [RFC4340] with its different > > congestion control types [RFC4341][RFC4342][RFC5622]. > > > > First, this paragraph ignores potential deployment issues with any of > these other than TCP, which risks seeming out of touch, but this is a minor > point and probably not worth a late edit. Second, I'm concerned this > recommendation could be taken as broader than intended, against the > definition of any new transport protocol encapsulated within UDP that > performs substantially the same function as the listed protocols. > > > I would agree, this paragraph also seems a little self > contradictory.There is an acknowledgment that "middleboxes that only > support TCP and UDP are not rare", but then the next sentence > recommends the use of several other protocols besides UDP and TCP. If > I put these two together, the only congested controlled protocol that > is recommended and expected to work on the Internet is TCP. > +1 TCP (implemented in kernel space) can't possibly evolve congestion avoidance as fast as the Internet has changed, or will change (example: good handling of middle boxes that use "policers" rather than some flavor of buffer-size based packet-drop). The rationale for using UDP for QUIC was indeed that a new IP number would never make it through the Internet (other protocol deployment attempts have commonly verified this). It turns out that even UDP is partially blocked (as recently as 2011) by paths to 5-7% of all chrome clients, which lead to the "automated fallback" elements of QUIC, Hopefully the benefits that QUIC is bringing to the Internet will not be outlawed (precluded by such commentary). Jim > > Tom > > > I think this can be made clearer by simply adding to the list of > examples: > > > > NEW: > > > > These mechanisms are difficult to implement correctly. For most > > applications, the use of one of the existing IETF transport protocols > > is the simplest method of acquiring the required mechanisms. Doing > > so also avoids issues that protocols using a new IP protocol number > > face when being deployed over the Internet, where middleboxes that > > only support TCP and UDP are not rare. Consequently, the RECOMMENDED > > alternative to the UDP usage described in the remainder of this > > section is the use of an IETF transport protocol such as TCP > > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and > > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > > Congestion Control Protocol (DCCP) [RFC4340] with its different > > congestion control types [RFC4341][RFC4342][RFC5622], or transport > > protocols specified by the IETF in the future. > > > > and removing the examples from the summary in section 7: > > > > OLD: > > > > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | > > > > NEW: > > > > | SHOULD use a full-featured transport | | > > > > Thanks, cheers, > > > > Brian > > > > > >> On 18 May 2016, at 02:17, The IESG wrote: > >> > >> > >> The IESG has received a request from the Transport Area Working Group WG > >> (tsvwg) to consider the following document: > >> - 'UDP Usage Guidelines' > >> as Best Current Practice > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >> final comments on this action. Please send substantive comments to the > >> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may > be > >> sent to iesg@ietf.org instead. In either case, please retain the > >> beginning of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> > >> The User Datagram Protocol (UDP) provides a minimal message-passing > >> transport that has no inherent congestion control mechanisms. This > >> document provides guidelines on the use of UDP for the designers of > >> applications, tunnels and other protocols that use UDP. Congestion > >> control guidelines are a primary focus, but the document also > >> provides guidance on other topics, including message sizes, > >> reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > >> and ports. > >> > >> Because congestion control is critical to the stable operation of the > >> Internet, applications and other protocols that choose to use UDP as > >> an Internet transport must employ mechanisms to prevent congestion > >> collapse and to establish some degree of fairness with concurrent > >> traffic. They may also need to implement additional mechanisms, > >> depending on how they use UDP. > >> > >> Some guidance is also applicable to the design of other protocols > >> (e.g., protocols layered directly on IP or via IP-based tunnels), > >> especially when these protocols do not themselves provide congestion > >> control. > >> > >> This document obsoletes RFC5405 and adds guidelines for multicast UDP > >> usage. > >> > >> > >> > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > >> > >> IESG discussion can be tracked via > >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> > > > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a114d8a20402fb30534953324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <tom@herbertland.com= > wrote:
On Thu, Jun 2, 2016= at 3:11 AM, Brian Trammell <ietf@tr= ammell.ch> wrote:
> Greetings, all,
>
> Apologies for the late last call comment; I have only one, relatively = minor. I hope it's still useful.
>
> I understand that Section 3 was written to encourage application devel= opers not to roll their own transports ("trust us when we say this is = hard, this document is a list of reasons why") but as written it would= seem to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB da= ta channel, anything-over-PLUS), which I very much hope was not the intent.= The problematic recommendation is in the second paragraph:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622].
>
> First, this paragraph ignores potential deployment issues with any of = these other than TCP, which risks seeming out of touch, but this is a minor= point and probably not worth a late edit. Second, I'm concerned this r= ecommendation could be taken as broader than intended, against the definiti= on of any new transport protocol encapsulated within UDP that performs subs= tantially the same function as the listed protocols.
>
I would agree, this paragraph also seems a little self
contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence
recommends the use of several other protocols besides UDP and TCP. If
I put these two together, the only congested controlled protocol that
is recommended and expected to work on the Internet is TCP.

+1 =C2=A0 TCP (implemented in kernel space) can't = possibly evolve congestion avoidance as fast as the Internet has changed, o= r will change (example: good handling of middle boxes that use "police= rs" rather than some flavor of buffer-size based packet-drop).=C2=A0
The rationale for using UDP for QUIC was indeed that a new IP numb= er would never make it through the Internet (other protocol deployment atte= mpts have commonly verified this).=C2=A0 It turns out that even UDP is part= ially blocked (as recently as 2011) by paths to 5-7% of all chrome clients,= which lead to the "automated fallback" elements of QUIC, =C2=A0= =C2=A0

Hopefully the benefits that QUIC is bringin= g to the Internet will not be outlawed (precluded by such commentary).

Jim
=C2=A0

Tom

> I think this can be made clearer by simply adding to the list of examp= les:
>
> NEW:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622], or = transport
>=C2=A0 =C2=A0 protocols specified by the IETF in the future.
>
> and removing the examples from the summary in section 7:
>
> OLD:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport (TCP, SCTP, DCCP)= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>
> NEW:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>
> Thanks, cheers,
>
> Brian
>
>
>> On 18 May 2016, at 02:17, The IESG <iesg-secretary@ietf.org> wrote:
>>
>>
>> The IESG has received a request from the Transport Area Working Gr= oup WG
>> (tsvwg) to consider the following document:
>> - 'UDP Usage Guidelines'
>>=C2=A0 <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current P= ractice
>>
>> The IESG plans to make a decision in the next few weeks, and solic= its
>> final comments on this action. Please send substantive comments to= the
>> ietf@ietf.org mailing lists b= y 2016-05-31. Exceptionally, comments may be
>> sent to iesg@ietf.org instead= . In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>=C2=A0 =C2=A0The User Datagram Protocol (UDP) provides a minimal me= ssage-passing
>>=C2=A0 =C2=A0transport that has no inherent congestion control mech= anisms.=C2=A0 This
>>=C2=A0 =C2=A0document provides guidelines on the use of UDP for the= designers of
>>=C2=A0 =C2=A0applications, tunnels and other protocols that use UDP= .=C2=A0 Congestion
>>=C2=A0 =C2=A0control guidelines are a primary focus, but the docume= nt also
>>=C2=A0 =C2=A0provides guidance on other topics, including message s= izes,
>>=C2=A0 =C2=A0reliability, checksums, middlebox traversal, the use o= f ECN, DSCPs,
>>=C2=A0 =C2=A0and ports.
>>
>>=C2=A0 =C2=A0Because congestion control is critical to the stable o= peration of the
>>=C2=A0 =C2=A0Internet, applications and other protocols that choose= to use UDP as
>>=C2=A0 =C2=A0an Internet transport must employ mechanisms to preven= t congestion
>>=C2=A0 =C2=A0collapse and to establish some degree of fairness with= concurrent
>>=C2=A0 =C2=A0traffic.=C2=A0 They may also need to implement additio= nal mechanisms,
>>=C2=A0 =C2=A0depending on how they use UDP.
>>
>>=C2=A0 =C2=A0Some guidance is also applicable to the design of othe= r protocols
>>=C2=A0 =C2=A0(e.g., protocols layered directly on IP or via IP-base= d tunnels),
>>=C2=A0 =C2=A0especially when these protocols do not themselves prov= ide congestion
>>=C2=A0 =C2=A0control.
>>
>>=C2=A0 =C2=A0This document obsoletes RFC5405 and adds guidelines fo= r multicast UDP
>>=C2=A0 =C2=A0usage.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/d= oc/draft-ietf-tsvwg-rfc5405bis/
>>
>> IESG discussion can be tracked via
>> https://datatracker.iet= f.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

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

--001a114d8a20402fb30534953324-- From nobody Mon Jun 6 13:38:28 2016 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 2D1C812D90F; Mon, 6 Jun 2016 13:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8cCpSW4nSNCq; Mon, 6 Jun 2016 13:38:14 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 DEF9C12D919; Mon, 6 Jun 2016 13:38:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u56Kc32B042972; Mon, 6 Jun 2016 13:38:03 -0700 Received: from XCH15-05-07.nw.nos.boeing.com (xch15-05-07.nw.nos.boeing.com [137.136.239.209]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u56KbxHG042832 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 6 Jun 2016 13:38:00 -0700 Received: from XCH15-05-11.nw.nos.boeing.com (2002:8988:efd5::8988:efd5) by XCH15-05-07.nw.nos.boeing.com (2002:8988:efd1::8988:efd1) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Jun 2016 13:37:58 -0700 Received: from XCH15-05-11.nw.nos.boeing.com ([137.136.239.213]) by XCH15-05-11.nw.nos.boeing.com ([137.136.239.213]) with mapi id 15.00.1178.000; Mon, 6 Jun 2016 13:37:59 -0700 From: "Templin, Fred L" To: Tom Herbert , Xuxiaohu Thread-Topic: [tsvwg] [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. Thread-Index: AQHRvbdPveimCbx8+kiS+Bdydthih5/c6X4w Date: Mon, 6 Jun 2016 20:37:58 +0000 Message-ID: <3d29bcbfc1f04033aee4285e4dae31f4@XCH15-05-11.nw.nos.boeing.com> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> <575108D3.3010506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "int-area@ietf.org" , "lisp@ietf.org" , Joe Touch , "nvo3@ietf.org" , "otroan@employees.org" , Softwires WG , "tsvwg@ietf.org" Subject: Re: [tsvwg] [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:38:17 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFtt YWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbSBIZXJiZXJ0DQo+ IFNlbnQ6IEZyaWRheSwgSnVuZSAwMywgMjAxNiA5OjQ1IEFNDQo+IFRvOiBYdXhpYW9odSA8eHV4 aWFvaHVAaHVhd2VpLmNvbT4NCj4gQ2M6IGludC1hcmVhQGlldGYub3JnOyBsaXNwQGlldGYub3Jn OyBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+OyBudm8zQGlldGYub3JnOyBvdHJvYW5AZW1wbG95 ZWVzLm9yZzsgU29mdHdpcmVzIFdHDQo+IDxzb2Z0d2lyZXNAaWV0Zi5vcmc+OyB0c3Z3Z0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3RzdndnXSBbSW50LWFyZWFdIFtudm8zXSBbU29mdHdpcmVz XSBJcyBpdCBmZWFzaWJsZSB0byBwZXJmb3JtIGZyYWdtZW50YXRpb24gb24gVURQIGVuY2Fwc3Vs YXRlZCBwYWNrZXRzLg0KPiANCj4gT24gRnJpLCBKdW4gMywgMjAxNiBhdCAxMjozOCBBTSwgWHV4 aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hA aXNpLmVkdV0NCj4gPj4gU2VudDogRnJpZGF5LCBKdW5lIDAzLCAyMDE2IDEyOjM0IFBNDQo+ID4+ IFRvOiBYdXhpYW9odTsgb3Ryb2FuQGVtcGxveWVlcy5vcmcNCj4gPj4gQ2M6IFNvZnR3aXJlcyBX RzsgbnZvM0BpZXRmLm9yZzsgaW50LWFyZWFAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmc7DQo+ID4+ IHRzdndnQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbbnZvM10gW1NvZnR3aXJlc10gSXMg aXQgZmVhc2libGUgdG8gcGVyZm9ybSBmcmFnbWVudGF0aW9uIG9uIFVEUA0KPiA+PiBlbmNhcHN1 bGF0ZWQgcGFja2V0cy4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gNi8yLzIwMTYgNzo1MyBQ TSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gPj4gRnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4g Pj4gPj4gU2VudDogRnJpZGF5LCBKdW5lIDAzLCAyMDE2IDI6MDggQU0NCj4gPj4gPj4gVG86IG90 cm9hbkBlbXBsb3llZXMub3JnOyBYdXhpYW9odQ0KPiA+PiA+PiBDYzogU29mdHdpcmVzIFdHOyBu dm8zQGlldGYub3JnOyBpbnQtYXJlYUBpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZzsNCj4gPj4gPj4g dHN2d2dAaWV0Zi5vcmcNCj4gPj4gPj4gU3ViamVjdDogUmU6IFtudm8zXSBbU29mdHdpcmVzXSBJ cyBpdCBmZWFzaWJsZSB0byBwZXJmb3JtDQo+ID4+ID4+IGZyYWdtZW50YXRpb24gb24gVURQIGVu Y2Fwc3VsYXRlZCBwYWNrZXRzLg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBP biA1LzI3LzIwMTYgMzo1MCBBTSwgb3Ryb2FuQGVtcGxveWVlcy5vcmcgd3JvdGU6DQo+ID4+ID4+ PiBJdCBpcyBub3QgcG9zc2libGUgdG8gaW1wbGVtZW50IHJlYXNzZW1ibHkgY29tcGx5aW5nIHdp dGggSUVURiBSRkNzLg0KPiA+PiA+PiBhKSBBVE0gZG9lcyB0aGlzIGF0IHJpZGljdWxvdXNseSBo aWdoIGZyYWdtZW50IHJhdGVzLiBHcmFudGVkIElQDQo+ID4+ID4+IGZyYWdzIGNhbiBjb21lIG91 dCBvZiBvcmRlciwgYnV0IHRoZSBmcmFnbWVudHMgYXJlIGdlbmVyYWxseSBtdWNoIGxhcmdlci4N Cj4gPj4gPiBBcyBwb2ludGVkIGluIFJGQzQ0NTksDQo+ID4+ID4NCj4gPj4gPiAgICAgICJBdCB0 aGUgdGltZSBvZiByZWFzc2VtYmx5LCBhbGwgdGhlIGluZm9ybWF0aW9uIChpLmUuLCBhbGwgdGhl DQo+ID4+ID4gICAgICAgZnJhZ21lbnRzKSBpcyBub3JtYWxseSBub3QgYXZhaWxhYmxlOyB3aGVu IHRoZSBmaXJzdCBmcmFnbWVudA0KPiA+PiA+ICAgICAgIGFycml2ZXMgdG8gYmUgcmVhc3NlbWJs ZWQsIGEgYnVmZmVyIG9mIHRoZSBtYXhpbXVtIHBvc3NpYmxlIHNpemUNCj4gPj4gPiAgICAgICBt YXkgaGF2ZSB0byBiZSBhbGxvY2F0ZWQgYmVjYXVzZSB0aGUgdG90YWwgbGVuZ3RoIG9mIHRoZQ0K PiA+PiA+ICAgICAgIHJlYXNzZW1ibGVkIGRhdGFncmFtIGlzIG5vdCBrbm93biBhdCB0aGF0IHRp bWUuIEZ1cnRoZXJtb3JlLCBhcw0KPiA+PiA+ICAgICAgIGZyYWdtZW50cyBtaWdodCBnZXQgbG9z dCwgb3IgYmUgcmVvcmRlcmVkIG9yIGRlbGF5ZWQsIHRoZQ0KPiA+PiA+ICAgICAgIHJlYXNzZW1i bHkgZW5naW5lIGhhcyB0byB3YWl0IHdpdGggdGhlIHBhcnRpYWwgcGFja2V0IGZvciBzb21lDQo+ ID4+ID4gICAgICAgdGltZSAoZS5nLiwgNjAgc2Vjb25kcyBbOV0pLiAgV2hlbiB0aGlzIHdvdWxk IGhhdmUgdG8gYmUgZG9uZSBhdA0KPiA+PiA+ICAgICAgIHRoZSBsaW5lIHJhdGUsIHdpdGgsIGZv ciBleGFtcGxlIDEwIEdiaXQvcyBzcGVlZCwgdGhlIGxlbmd0aCBvZg0KPiA+PiA+ICAgICAgIHRo ZSBidWZmZXJzIHRoYXQgcmVhc3NlbWJseSBtaWdodCByZXF1aXJlIHdvdWxkIGJlIHByb2hpYml0 aXZlLiAiDQo+ID4+DQo+ID4+IFllcywgYnV0IHRoZSBhbHRlcm5hdGl2ZSBvZiBkZWNsYXJpbmcg dGhhdCB5b3UgZG9uJ3QgcmVhc3NlbWJsZSBoYXMgYSBjb3N0IGluDQo+ID4+IHRlcm1zIG9mIGRy b3BwZWQgc2VnbWVudHMgdG9vLg0KPiA+DQo+ID4gVGhlIGFsdGVybmF0aXZlIGlzIHRvIGNvbmZp Z3VyZSB0aGUgTVRVIG9mIHRoZSBjb3JlIGxhcmdlIGVub3VnaCB0byBhY2NvbW1vZGF0ZSB0aGUg YWRkZWQgZW5jYXBzdWxhdGlvbiBoZWFkZXIuIFRoaXMgaXMgYSBmZWFzaWJsZQ0KPiBhbmQgcHJv dmVuIGFwcHJvYWNoIGluIHdlbGwtbWFuYWdlZCBTUCBuZXR3b3Jrcy4gTm8gcGFja2V0IGxvc3Mg YW5kIG5vIGZvcndhcmRpbmcgcGVyZm9ybWFuY2UgZGVncmFkYXRpb24uDQo+ID4NCj4gPj4gVGFr aW5nIHRoYXQgZHJvcCBpbnRvIGFjY291bnQsIGJ1ZmZlcmluZyBmb3IgYSBzbWFsbGVyIGFtb3Vu dCBvZiBwb3RlbnRpYWwNCj4gPj4gcmVvcmRlcmluZyBhbmQgYWNjb3VudGluZyBmb3IgcmVhc29u YWJsZSByZWFzc2VtYmx5IHNpemVzIChmb3IgSVB2NiwgdGhlDQo+ID4+IHNtYWxsZXN0ICJtYXgi IHRoYXQncyByZXF1aXJlZCBpcyAxNTAwKSBuZWVkIG5vdCBiZSBwcm9oaWJpdGl2ZS4NCj4gPg0K PiA+IEluIHRoZSBJUHY2LWluLUlQdjQgU29mdHdhcmUgbmV0d29yayBjYXNlLCBhc3N1bWUgdGhl IE1UVSBvZiB0aGUgY29yZSBpcyBub3QgbGFyZ2UgZW5vdWdoIHRoYW4gMTI4MCsyMCwgYWxsIHRo ZSBJUHY2IHRyYWZmaWMgYWNyb3NzDQo+IHRoZSB0dW5uZWxzIHdvdWxkIGhhdmUgdG8gYmUgZnJh Z21lbnRlZCBhbmQgdGhlbiByZWFzc2VtYmxlZC4gTm90IGEgc21hbGwgYW1vdW50Lg0KPiA+DQo+ ID4+ID4gSGF2ZSB5b3UgaGVhcmQgdGhlIHdpZGUgYWRvcHRpb24gb2YgNjIyTSAoU1RNLTEpIGJl eW9uZCBBVE0gaW50ZXJmYWNlcw0KPiA+PiBiZXR3ZWVuIEFUTSBzd2l0Y2hlcyBpbiB0aGUgcHJl dmlvdXMgQVRNIG5ldHdvcmtzPyBJZiBub3QsIHRoZSBoaWdoZXN0DQo+ID4+IG5vbi1BVE0gaW50 ZXJmYWNlIGluIHRoZSBwYXN0IEFUTSBuZXR3b3JrcyB3YXMgdGhlIEZFIGludGVyZmFjZSB3aGlj aCBpcyAxMDBNDQo+ID4+IGJwcyAoYXJvdW5kIHRoZSB5ZWFyIG9mIDIwMDApLCBJZiBJIHJlbWVt YmVyZWQgaXQgY29ycmVjdGx5Lg0KPiA+Pg0KPiA+PiBPQzEyIEFUTSBOSUNzIHdlcmUgY29tbW9u bHkgYXZhaWxhYmxlIGluIDE5OTguIFRoYXQgd2FzIGJhY2sgd2hlbg0KPiA+DQo+ID4gU29ycnks IHRoZXJlIHdhcyBhIHNwZWxsaW5nIG1pc3Rha2UgKCBzL1NUTS0xL1NUTS00KS4NCj4gPg0KPiA+ IE9DMTIvU1RNLTQ9NjIyTS4gTXkgcXVlc3Rpb24gaXMgaGF2ZSB5b3UgaGVhcmQgdGhlIHdpZGUg YWRvcHRpb24gb2YgNjIyTSAoU1RNLTQpIEJFWU9ORCBBVE0gaW50ZXJmYWNlcyAoZS5nLiwgU1RN LQ0KPiAxNi9PQzQ4KSBhdCB0aGF0IHRpbWU/DQo+ID4NCj4gPj4gZXRoZXJuZXQgd2FzIHB1c2hp bmcgMTAwTSBhbmQgdGhlIG9ubHkgb3RoZXIgbmVhci1naWdhYml0IHRlY2ggd2FzIE15cmljb20N Cj4gPj4gKGEgc3Bpbi1vZmYgb2YgVVNDL0lTSSBhbmQgQ2FsdGVjaCkuIEkuZS4sIHdpdGggdGhl IHRlY2ggYXZhaWxhYmxlIGF0IHRoYXQgdGltZSwNCj4gPj4gNjAwTWJwcyBTQVIgd2FzIHBvc3Np YmxlLg0KPiA+DQo+ID4gV2FzIHRoYXQgNjAwTWJwcyBTQVIgY2FwYWJpbGl0eSBwcm92ZWQgaW4g cmVhbCBuZXR3b3Jrcz8gQW5kIGZvciB3aGF0IHNlcnZpY2U/DQo+ID4NCj4gPj4gPiBGdXJ0aGVy bW9yZSwgaGF2ZSB5b3UgaGVhcmQgdGhlIHJlb3JkZXJpbmcgaXNzdWUgd2l0aCBBVE0gY2VsbHM/ IElmIG5vLCB0aGF0DQo+ID4+IG1lYW5zIG9uY2UgYW4gQVRNIGNlbGwgb2YgYSBnaXZlbiBBTEwg UERVIGdldHMgbG9zdCwgYWxsIHRoZSByZWNlaXZlZCBBVE0gY2VsbHMNCj4gPj4gb2YgdGhhdCBB QUwgUERVIHdvdWxkIGJlIGRyb3BwZWQgYW5kIHRoZXJlZm9yZSB0aGUgcmVhc3NlbWJseSBidWZm ZXIgZm9yIHRoYXQNCj4gPj4gQUFMIGRhdGFncmFtIHdvdWxkIGJlIHJlbGVhc2VkLiBJbiBvdGhl ciB3b3JkcywgdGhlcmUgaXMgbm8gbmVlZCB0byB3YWl0IGZvcg0KPiA+PiB0aGUgbG9zdCBvciBy ZW9yZGVyZWQgZnJhZ21lbnQgZm9yIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGltZSBiZWZvcmUgcmVs ZWFzaW5nIHRoZQ0KPiA+PiByZWFzc2VtYmx5IGJ1ZmZlci4NCj4gPj4gUmVvcmRlcmVkIG5vLCBi dXQganVzdCBiZWNhdXNlIHRoZXkgYXJyaXZlIGluIG9yZGVyIGRvZXMgbm90IG1lYW4gdGhleSBh cmUNCj4gPj4gcmVxdWlyZWQgdG8gYXJyaXZlICphZGphY2VudCouIFRoZSBzYW1lIHJlcXVpcmVt ZW50IGFwcGxpZXMgaW4gdGVybXMgb2YNCj4gPj4gbmVlZGluZyByZWFzc2VtYmx5IGJ1ZmZlcnMg Zm9yIGEgbnVtYmVyIG9mIGludGVybGVhdmVkIHNlZ21lbnRzLg0KPiA+DQo+ID4gSG93ZXZlciwg dGhlIHJlYXNzZW1ibHkgYnVmZmVyIHJlcXVpcmVtZW50IGlzIGxpbWl0ZWQgZHVlIHRvIHRoZSBm YWN0IHRoYXQgb25seSBvbmUgYnVmZmVyIGlzIG5lZWRlZCBwZXIgVkMgYW5kIHRoZSB0b3RhbCBu dW1iZXINCj4gb2YgVkNzIGlzIG5vdCBsYXJnZSBvbiB0aGUgZWRnZSBvZiBBVE0gbmV0d29ya3Mu IEluIGNvbnRyYXN0LCB0aGUgbnVtYmVyIG9mIElQIGZsb3dzIGlzIHVuY29udHJvbGxhYmxlLg0K PiA+DQo+ID4+ID4gIFN1Y2ggYmVoYXZpb3IgaXMgbm90IHBvc3NpYmxlIGZvciBJUCBmcmFnbWVu dGF0aW9uIGFuZCByZWFzc2VtYmx5LiBMYXN0IGJ1dA0KPiA+PiBub3QgbGVhc3QsIHRoZXJlIGlz IG5vIG5lZWQgdG8gYXNzaWduIGEgcmVhc3NlbWJseSBidWZmZXIgcGVyIEFBTCBQRFUgKGFzDQo+ ID4+IG9wcG9zZWQgdG8gcGVyIElQIGRhdGFncmFtIGluIHRoZSBJUCBmcmFnbWVudGF0aW9uIGFu ZCByZWFzc2VtYmx5IGNhc2UpLA0KPiA+PiBpbnN0ZWFkLCBvbmx5IG9uZSByZWFzc2VtYmx5IGJ1 ZmZlciBwZXIgVkMgc2luY2UgYWxsIGNlbGxzIHdpdGhpbiBhIGdpdmVuIFZDIHdvdWxkDQo+ID4+ IGJlIHJlY2VpdmVkIGluIG9yZGVyLiBTaW5jZSB0aGUgU0FSIGlzIG9ubHkgbmVlZGVkIG9uIHRo ZSBlZGdlIG9mIHRoZSBBVE0NCj4gPj4gbmV0d29ya3MsIHRoZSBudW1iZXIgb2YgVkNzIGlzIHZl cnkgbGltaXRlZC4NCj4gPj4gWW91IGNvdWxkIGVhc2lseSBkZWNpZGUgdG8gYWxsb2NhdGUgYSBm aXhlZCBudW1iZXIgb2YgcmVhc3NlbWJseSBidWZmZXJzIHBlciBJUA0KPiA+PiBmbG93IHRvIGNv bnNlcnZlIHJlc291cmNlcyB0b28uIFRoZSBhbW91bnQgb2YgcmVvcmRlcmluZywgdG9nZXRoZXIg d2l0aCB0aGUNCj4gPg0KPiA+IFdoYXQgYWJvdXQgaW4gdGhlIEREb1MgYXR0YWNrIGNhc2U/IERv IHlvdSBiZWxpZXZlIHRoYXQgU1BzIHdvdWxkIGFsbG93IHRoZSBleGlzdGVuY2Ugb2YgdGhhdCBv YnZpb3VzIEREb1MgYXR0YWNrIHJpc2sgaW4gdGhlaXINCj4gbmV0d29ya3MgYW5kIGFmZm9yZCB0 aGUgc2lnbmlmaWNhbnQgZm9yd2FyZGluZyBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbj8gZXNwZWNp YWxseSB3aGVuIHRoZXJlIGhhcyBiZWVuIGEgZmVhc2libGUgYW5kIHByb3Zlbg0KPiBzb2x1dGlv biB0byB0aGUgTVRVIGlzc3VlIChpLmUuLCBjb25maWd1cmUgdGhlIE1UVSBvZiB0aGUgY29yZSBs YXJnZSBlbm91Z2gpPw0KPiA+DQo+IFRoYXQgaXMgcHJlY2lzZWx5IHNvbHV0aW9uICMzIGluIFJG QzQ0NTk6DQo+IA0KPiAiRW5zdXJlIHRoYXQgaW4gdGhlIHNwZWNpZmljIGVudmlyb25tZW50LCB0 aGUgZW5jYXBzdWxhdGVkIHBhY2tldHMNCj4gd2lsbCBmaXQgaW4gYWxsIHRoZSBwYXRocyBpbiB0 aGUgbmV0d29yaywgZS5nLiwgYnkgdXNpbmcgTVRVIGJpZ2dlcg0KPiB0aGFuIDE1MDAgaW4gdGhl IGJhY2tib25lIHVzZWQgZm9yIGVuY2Fwc3VsYXRpb24uIg0KPiANCj4gSWYgeW91J3JlIGFibGUg dG8gaW1wbGVtZW50IHRoaXMgaW4geW91IG5ldHdvcmsgdGhhdCdzIGdyZWF0LCBidXQgaXQNCj4g aXMgbm90IGZlYXNpYmxlIGluIGFsbCBzaXR1YXRpb25zIGFuZCBoZW5jZSBjYW4ndCBiZSB0aGUg c3RhbmRhcmQuIFdlDQoNCkkgYWdyZWUuIFNvIHRoZW4sIHdoYXQgKnNob3VsZCogYmUgdGhlIHN0 YW5kYXJkIGlzIEdVRSBwbHVzIGZyYWdtZW50YXRpb24NCnBsdXMgZGlyZWN0IElQIGVuY2Fwc3Vs YXRpb24uIEkgdGhpbmsgdGhhdCBzaG91bGQgY292ZXIgYWxsIHVzZSBjYXNlcywgcmlnaHQ/DQoN ClRoYW5rcyAtIEZyZWQNCg0KPiBtYXkgbm90IGNvbnRyb2wgYWxsIHRoZSB1bmRlcmxheSBuZXR3 b3JrcyAoZGVmaW5pdGVseSBub3Qgb3ZlciB0aGUNCj4gSW50ZXJuZXQpIGFuZCBoZW5jZSBub3Qg YmUgYWJsZSB0byBzZXQgYWxsIHRoZSBNVFVzIGxhcmdlIGVub3VnaC4gQWxzbw0KPiBhbiBNVFUg Z3JlYXRlciB0aGFuIDE1MDAgcmVxdWlyZSBqdW1ibyBmcmFtZXMsIG5vdCBhbGwgbmV0d29ya3MN Cj4gZW5hYmxlZCB0aG9zZS4NCj4gDQo+IE9uZSBvdGhlciBwb2ludCwgd2hlbiBhIGRldmljZSBz b3VyY2VzIG9yIHNpbmtzIElQIHBhY2tldHMgbGlrZSBpbg0KPiB0dW5uZWxpbmcgaXQgaXMgdGFr aW5nIG9uIHRoZSByb2xlIG9mIGEgaG9zdCBhbmQgc28gd2UgZXhwZWN0IGhvc3QNCj4gcmVxdWly ZW1lbnRzIGFwcGx5LiBGb3IgaW5zdGFuY2UsIHJvdXRlcnMgbWF5IHBlcmZvcm0gZnJhZ21lbnRh dGlvbiBpbg0KPiBJUHY0LCBidXQgdGhleSBkbyBub3QgcGVyZm9ybSBmcmFnbWVudGF0aW9uIGZv ciBJUHY2IG9yIHJlYXNzZW1ibHkNCj4gKHRob3NlIGFyZSBob3N0cyBmdW5jdGlvbmFsaXRpZXMp LiBUaGVyZSBoYXMgYmVlbiBhdCBsZWFzdCBvbmUgYXR0ZW1wdA0KPiB0byBjYXJ2ZSBvdXQgZXhj ZXB0aW9ucyBpbiBhcHBseWluZyBob3N0IHJlcXVpcmVtZW50cyB0byBkZXZpY2VzIHRoYXQNCj4g cGVyZm9ybSB0dW5uZWxpbmcsIHRoYXQgaXMgYW4gYWxsb3dhbmNlIHRvIHNlbmQgYSB6ZXJvIFVE UCBjaGVja3N1bSBpbg0KPiBpbiBJUHY2LiBEb2N1bWVudGluZyB0aGlzIHRvb2sgdHdvIFJGQ3Mg YW5kIHdlIHN0aWxsIG5lZWRlZCBhIHdob2xlDQo+IGxvdCBvZiBkZXNjcmlwdGlvbiBpbiBhdCBs ZWFzdCBHUkUvVURQIG9uIHJlcXVpcmVtZW50cyB0aGF0IHRvIHVzZSB0aGUNCj4gbm9uLXplcm8g Y2hlY2tzdW0uIEkgZG9uJ3QgdGhpbmsgc3RhbmRhcmRpemluZyBleGNlcHRpb25zIGluDQo+IGZy YWdtZW50YXRpb24gZm9yIHR1bm5lbHMgd291bGQgYmUgYW55IGVhc2llci4NCj4gDQo+IFRvbQ0K PiANCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gbnVtYmVyIG9mIGZs b3dzIHN1cHBvcnRlZCB3b3VsZCBkZXRlcm1pbmUgeW91ciBhYmlsaXR5IHRvIGF2b2lkIHBhY2tl dCBkcm9wcw0KPiA+PiAtLSBidXQgcmVjYWxsIHRoYXQgZHJvcHMgYXQgaGlnaCBsb2FkIGFyZSBu b3QgdW51c3VhbCBmb3IgSVAuDQo+ID4+DQo+ID4+IEpvZQ0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJbnQtYXJlYSBtYWlsaW5n IGxpc3QNCj4gPiBJbnQtYXJlYUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaW50LWFyZWENCj4gDQoNCg== From nobody Mon Jun 6 13:48:15 2016 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 66CAE12D90D for ; Mon, 6 Jun 2016 13:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, RP_MATCHES_RCVD=-1.426, 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 qxsuJINnKW_X for ; Mon, 6 Jun 2016 13:48:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676F412D7E4 for ; Mon, 6 Jun 2016 13:48:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml701-cah.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAH69019; Mon, 06 Jun 2016 15:48:10 -0500 (CDT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 6 Jun 2016 21:48:04 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Mon, 6 Jun 2016 13:47:59 -0700 From: Lucy yong To: Martin Stiemerling , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11 Thread-Index: AQHRvAhGEL3FlcOGQEKvm4EeNsQBrp/c3dpw Date: Mon, 6 Jun 2016 20:47:58 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572937D5@dfweml501-mbb> References: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> In-Reply-To: <12c1a846-87cd-4311-265c-ce7ee911b81e@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:48:14 -0000 SGkgTWFyaW4sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1l bnRzLg0KU2VlIGlubGluZSBiZWxvdy4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TWFydGluIFN0aWVtZXJsaW5nDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMDEsIDIwMTYgODoxOSBB TQ0KVG86IHRzdndnQGlldGYub3JnDQpTdWJqZWN0OiBbdHN2d2ddIFJldmlldyBvZiBkcmFmdC1p ZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMTENCg0KRGVhciBhbGwsDQoNClBsZWFzZSBmaW5k IGhlcmUgbXkgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC0xMS4N Cg0KR2VuZXJhbDogVGhlIGRyYWZ0IGlzIHJlYWR5IHRvIHdpdGggYSBmZXcgc21hbGxlciBpc3N1 ZXMuDQoNCklzc3VlczoNCi0gVGhlIHRleHQgc2F5cyBpbiBtdWx0aXBsZSBwbGFjZXMgImF2b2lk IGNvbmdlc3Rpb24iLg0KSG93ZXZlciwgSSBkbyBub3Qgc2VlIHRoYXQsIGZvciBpbnN0YW5jZSwg cmF0ZSBsaW1pdGVycywgd2lsbCBhdm9pZCBjb25nZXN0aW9uLiBBIHJhdGUgbGltaXRlciB3aWxs IGNhdXNlIGNvbmdlc3Rpb24gZm9yIGFmZmVjdGVkIGZsb3dzIGJ1dCBwb3RlbnRpYWxseSBrZWVw IGNvbmdlc3Rpb24gYXdheSBmcm9tIG90aGVyIHBhcnRzIG9mIHRoZSBuZXR3b3JrLg0KKEEgYml0 IG1vcmUpIGNvcnJlY3Qgd291bGQgYmUgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lIG9mICJ0byBk ZXRlY3QgY29uZ2VzdGlvbiBhbmQgdG8gbWl0aWdhdGUgY29uZ2VzdGlvbiIuDQoNCi0gVGhpcyBk b2N1bWVudCB1c2VzIFJGQzU0MDViaXMgYXMgcmVmZXJlbmNlIGluIG1hbnkgcGxhY2VzLCB0aG91 Z2ggUkZDDQo1NDA1IGlzIHRoZSBvbmx5IHN0YWJsZSBhbmNob3IgYXQgdGhpcyBwb2ludCBvZiB0 aW1lLiBJIGFtIG5vdCBzdXJlIGhvdyBmYXIgUkZDIDU0MDViaXMgaXMgcmlnaHQgbm93IG9yIGFz a2VkIGRpZmZlcmVudGx5LCBpcyB0aGVyZSBhIG5lZWQgdG8gd2FpdCBmb3IgUkZDIDU0MDUgdG8g Y29tcGxldGU/DQoNCi0gSSBkbyBkaXNhZ3JlZSB3aXRoICJJUC10cmFmZmljIGNhbiBiZSBhc3N1 bWVkIHRvIGJlIGNvbmdlc3Rpb24tY29udHJvbGxlZC4iLCBldmVuIHRob3VnaCBpdCBpcyBzdGF0 ZWQgaW4gUkZDIDU0MDUsIGFzIHRoZXJlIGlzIGEgbG90IG9mIElQIHRyYWZmaWMgdGhhdCBpcyBu b3QgY29uZ2VzdGlvbiBjb250cm9sbGVkLCBzdWNoIGFzIG11bHRpY2FzdCB0cmFmZmljLi4uDQpT ZWN0aW9uIDQsIGV2ZW4gc3RhdGVzIHRoYXQgbXVsdGljYXN0IGFuZCBicm9hZGNhc3QgdHJhZmZp YyBjYW4gYmUgY2FycmllZCBvdmVyIEdSRS1VRFAhIE5vbmUgb2YgYm90aCBpcyBpbiBnZW5lcmFs IGNvbmdlc3Rpb24gY29udHJvbGxlZCENCltMdWN5XSBEYXZpZCBoYXMgYWRkcmVzc2VkIGFib3Zl IGNvbW1lbnRzLiBTZWVrIHRvIGFsaWduIHdpdGggUkZDNTQwNWJpcyB0ZXh0Lg0KDQotIFNlY3Rp b24gMi4xLjEgb24gcGFnZSA1LCBwb2ludCA3ICJpdCBNVVNUIHNldCB0aGUgc2FtZSBEU0NQIHZh bHVlIHRvIGFsbCBmcmFnbWVudHMuIiBGcm9tIHdoYXQgdmFsdWUgdGhlIERTQ1AgbXVzdCBiZSBz ZXQ/IFRoaXMgaXNuJ3Qgc3RhdGVkIGhlcmUuDQpbTHVjeV0gaG93IGFib3V0ICJpdCBNVVNUIHNl dCB0aGUgc2FtZSBEU0NQIHZhbHVlIGFzIGluIHRoZSBEUyBmaWVsZCBvZiB0aGUgcGF5bG9hZCBw YWNrZXQgdG8gYWxsIGZyYWdtZW50cy5bUkZDMjQ3NF0gIj8NCg0KLSBTZWN0aW9uIDQuMSwgZmly c3Qgc2VudGVuY2U6DQoiICAgUmVnYXJkaW5nIHBhY2tldCBmcmFnbWVudGF0aW9uLCBhbiBlbmNh cHN1bGF0b3IvZGVjYXBzdWxhdG9yIFNIT1VMRA0KICAgIGJlIGNvbXBsaWFudCB3aXRoIFtSRkM3 NTg4XSBhbmQgcGVyZm9ybSBmcmFnbWVudGF0aW9uIGJlZm9yZSB0aGUNCiAgICBlbmNhcHN1bGF0 aW9uLiINClJGQyA3NTg4IGlzIG1lbnRpb25lZCBoZXJlIGFuZCB0aGUgU0hPVUxEIGltcGxpZXMg dGhhdCBhIHJlYWRlci9pbXBsZW1lbnRlciBoYXMgdG8gcmVhZCBSRkMgNzU4OC4gSG93ZXZlciwg UkZDIDc1ODggaXMgbm90IGxpc3RlZCB1bmRlciBub3JtYXRpdmUgcmVmZXJlbmNlcyBhbmQgaXQg aXMgYW55aG93IGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQsIHdoaWNoIHdvdWxkIHJlcXVpcmUg YSBkb3duLXJlZiBpbiB0aGUgbGFzdCBjYWxsLg0KW0x1Y3ldIFNpbmNlIFJGQzc1ODggZG9jdW1l bnRzIGN1cnJlbnQgdmVuZG9yIGltcGxlbWVudGF0aW9ucywgaG93IGFib3V0IG5vdCByZWZlcmVu Y2UgW1JGQzc1ODhdIGluIHRoaXMgZHJhZnQ/ICANCg0KDQpFZGl0b3JpYWxzOg0KLSBUaGVyZSBh cmUgbXVsdGlwbGUgb2NjdXJlbmNlcyBpbiB0aGUgdGV4dCAiSUFOQSBOb3RlOiBSZXBsYWNlIFRC RDEgYW5kDQpUQkQyIHdpdGggdGhlIElBTkEtYXNzaWduZWQgbnVtYmVycyIuIEkgc3VnZ2VzdCB0 byByZW1vdmUgdGhlc2Ugbm90ZXMgYW5kIGp1c3QgdG8gc2F5IGluIHRoZSBJQU5BIGNvbnNpZGVy YXRpb25zIHNlY3Rpb24gdGhhdCBJQU5BIGlzIHJlcXVlc3RlZCB0byByZXBsYWNlIHRoZXNlIGxh YmVscyB3aXRoIHRoZSBhcHByb3ByaWF0ZSBwb3J0IG51bWJlcnMuIEFuZCB0ZWxsIGluIHRoZSBJ QU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2hlcmUgdG8gZmluZCB0aGVzZSBsYWJlbHMuDQoN Ci0gVEJEMS9UQkQyIGluIGZpZ3VyZXM6IHJlcGxhY2Ugd2l0aCBhIGRpZmZlcmVudCBsYWJlbHMg YW5kIHNheSB0aGF0IHRoZXNlIGxhYmVscyBkbyBjb3JyZXNwb25kZW50IHRvIHRoZSBJQU5BIGFz c2lnbmVkIHBvcnQgbnVtYmVycy4gVGhlIGZpZ3VyZXMgZG8gbm90IG5lZWQgdG8gc3RhdGUgdGhl IGFjdHVhbCBwb3J0IG51bWJlcnMsIGFzIHRoZXkgd2lsbCBkbywgaWYgdGhlIHRleHQgYW5kIHRo ZSBJQU5BIHRleHQgc3RheXMgYXMgaXQgaXMgcmlnaHQgbm93Lg0KW0x1Y3ldIGFjay4NCg0KLSBT ZWN0aW9uIDEuMTogTW92ZSBUTUNFIHVwIGluIHRoZSBsaXN0LCBhcyBpdCB1c2VkIGluIHRoZSB0 ZXJtaW5vbG9neSBldmVuIGJlZm9yZSBpdCBpcyBkZWZpbmVkLg0KW0x1Y3ldIGFjay4NCg0KVGhh bmtzLA0KTHVjeQ0KDQpUaGFua3MsDQoNCiAgIE1hcnRpbg0KDQo= From nobody Tue Jun 7 22:59:23 2016 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 74FEB12D77E for ; Tue, 7 Jun 2016 22:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPhRmnk4qbnT for ; Tue, 7 Jun 2016 22:59:20 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 A7F4212D77F for ; Tue, 7 Jun 2016 22:59:20 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id x189so190981484ywe.3 for ; Tue, 07 Jun 2016 22:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q+NksMW/poUNneLg4oWmK7/CiygAlnN+R1bukcy5P0A=; b=LnkUkE0fTmbove/3t7Wmnb82wpkG4A2ZP/KI1OlR0JwMetjyv2qEIPi1i4xW7ZUhHi 0rEeLG19MLWsgCqVhRtIrOkW8meSeNofSoy5PK9QXvsD9omvh38Ha/aNd33ydts43bZi J+AOBcYzvtDsrF/tHMFeNJ9mhVtbjNp7OfJ6fiSt6gcj+9Hv93ZR8y75HZXQi6mFSPK1 fYrDqBW1P1/bsmg8diftP5FC/J9p82ZsFYFkHdR1tlyhuVG3YuTx+JgG4a702xIF2cnM EBhW7akPG99sWbzvXhJj+nKZwjRNx4De1Of5s4Bjat1tOG6iwVCNH2A093WnCeZAcY1E yZOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q+NksMW/poUNneLg4oWmK7/CiygAlnN+R1bukcy5P0A=; b=enmxSug5NkjiXU2Qo36BYcU9gWOkAJS5zRQ9SaESXjGadl/P7aKtdpisekeWDnldc3 3XB78M+PtJAQC8OXfWAfYsM/NCkT2GxD2TKGOksh1cgL8vhfOSky7wNHMNL2HESDhYlb nkiZVJuHU4XUe8aDfcGXL2bGZ3RFazJfLc1ozGHp3BFiOFAOlw8qWWZBWfGYwVg4FCno PIOGHGGJfb2qE2e0rAiRTwTp3C/u/Mq8zS1rfi3IhYCm46nACqtwo9IZwBiVPfAgOTwV 7IAsPjjrlT/I7tzLKbo9GnzqACnQY0m7QvsqYbbeNJU3OQpuV9+WsVZfUJunFwsEwWc0 0nIg== X-Gm-Message-State: ALyK8tJ+rqXO6CLC/iirqgScSYdlBPvRREphMXXkPhJOxuHoYsO30+7+CcKQ0CZTmDzKMRyXUk5KTZmbdkQJGCT+ X-Received: by 10.37.34.84 with SMTP id i81mr1640990ybi.156.1465365559701; Tue, 07 Jun 2016 22:59:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Tue, 7 Jun 2016 22:59:19 -0700 (PDT) In-Reply-To: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> From: Jana Iyengar Date: Tue, 7 Jun 2016 22:59:19 -0700 Message-ID: To: Tom Herbert Content-Type: multipart/alternative; boundary=001a11c113a0a771ee0534be01e4 Archived-At: Cc: tsvwg WG , draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud , quic@ietf.org, ietf@ietf.org Subject: Re: [tsvwg] [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 05:59:22 -0000 --001a11c113a0a771ee0534be01e4 Content-Type: text/plain; charset=UTF-8 Just adding my 2c if this still isn't too late: I agree with Brian that the wording in the draft seems limiting. His suggested wording does make things better, but there still is the contradiction that Tom pointed out: I would agree, this paragraph also seems a little self > contradictory.There is an acknowledgment that "middleboxes that only > support TCP and UDP are not rare", but then the next sentence > recommends the use of several other protocols besides UDP and TCP. If > I put these two together, the only congested controlled protocol that > is recommended and expected to work on the Internet is TCP. This caught my attention as well. As it stands, the recommendation in this paragraph is very unclear. What exactly is the goal here? If it is to ensure that the recommendations allow for deployable protocols, then UDP-based ones must be allowed. Otherwise, the recommendation seems to be to only use TCP. I don't think that was the intent... but then what is the intent in this paragraph? - jana --001a11c113a0a771ee0534be01e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just adding my 2c if this still isn't too late: I agre= e with Brian that the wording in the draft seems limiting. His suggested wo= rding does make things better, but there still is the contradiction that To= m pointed out:

I would agree, this paragraph also seems a= little self
contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence
recommends the use of several other protocols besides UDP and TCP. If
I put these two together, the only congested controlled protocol that
is recommended and expected to work on the Internet is TCP.

This caught my attention as well. As it stands, the recomm= endation in this paragraph is very unclear.=C2=A0

= What exactly is the goal here? If it is to ensure that the recommendations = allow for deployable protocols, then UDP-based ones must be allowed. Otherw= ise, the recommendation seems to be to only use TCP. I don't think that= was the intent... but then what is the intent in this paragraph?

- jana
--001a11c113a0a771ee0534be01e4-- From nobody Wed Jun 8 00:49:00 2016 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 A7FB012D188 for ; Wed, 8 Jun 2016 00:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 YN3hePSUnGxn for ; Wed, 8 Jun 2016 00:48:56 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 B833D12B049 for ; Wed, 8 Jun 2016 00:48:55 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bAYEP-0006Fd-AV; Wed, 08 Jun 2016 09:48:53 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bAYEO-0007vD-G2; Wed, 08 Jun 2016 09:48:53 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <20160601015145.GA1754@verdi> Date: Wed, 8 Jun 2016 09:48:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160531124239.18741.45638.idtracker@ietfa.amsl.com> <6DD38B35-4E61-4AAF-A06F-36CA05F28126@ifi.uio.no> <20160531203436.GB95392@verdi> <03FC4BCE-5951-4F40-A7D9-84CCBB3C586D@ifi.uio.no> <20160601015145.GA1754@verdi> To: John Leslie X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 17 sum msgs/h 6 total rcpts 42791 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3646D67E08A82AB1A754FB1D08E27AD2536D427E X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 10302 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] [tcpm] New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:48:59 -0000 Dear John, Thank you very much for taking the time to read and comment on this, and = very sorry for my long delay in getting back to you. Busy days... More below; in my answers, I try to focus on comments that concern the = current draft: > On 01 Jun 2016, at 03:51, John Leslie wrote: >=20 > Michael Welzl wrote: >> On 31. mai 2016, at 22.34, John Leslie wrote: >>> Michael Welzl wrote: >>>=20 >>>> 1) a document that only makes the necessary update to RFC3168 to = allow a >>>> reaction to ECN that differs from the reaction to loss: >>>> This is draft-khademi-tsvwg-ecn-response, which I just posted. >>>=20 >>> Three cheers!!! >>>=20 >>>> 2) a document that only contains the concrete change to TCP that we >>>> suggest (the new multiplication factor): >>>> This is draft-khademi-tcpm-alternativebackoff-ecn, with details = below. >>>>=20 >>>> Please read and discuss item 2 here in TCPM - thanks!! :) >>>=20 >>> You don't specify where to discuss item 1). >>=20 >> Sorry - I did, but only in the corresponding email that went to TSVWG = only. >> =3D> TSVWG is the place for that. >=20 > So, this email is going to TSVWG... >>=20 >>> Thus, I would prefer that alternativebackoff-ecn not limit us to the >>> scheme in ecn-response. >>=20 >> You mean the other way round, right? >=20 > I'll take your word for it. (The interconnection of documents = between > two WGs is enough to confuse me when I'm trying to get out the door to = a > dinner meeting!) >=20 >> If so, then that???s how it is - draft-khademi-tsvwg-ecn-response = just >> mentions draft-khademi-tcpm-alternativebackoff-ecn as one example. >=20 > I was pretty thoroghly confused when reading ecn-response too = quickly. >=20 > There's an inherent problem talking about ECN: it involves router > action on the internetworking layer (IP) and sender action on the > transport layer (e.g. TCP). Reading Section 1, it's hard to separate > what RFCs 3168 and 5681 say from what we will propose. >=20 > In particular, I question whether the "congestion window" is an > appropriate concept for the internetworking layer. Routers (or other > "forwarders") simply mark congestion experienced within the two bits > allocated to ECN in the IP header. It can only confuse folks to > couple this with what the sender will do when it receives notice of > the congestion marking. >=20 > I understand this pretty well (IMHO); but _I_ was confused. "cwnd" > and "ssthresh" are internal details of the TCP treatment of congestion > marking, and we _do_ have to specify _that_ we are changing these; but > mentioning them in Section 1, but not explaining the changes until > Section 3, is unnecessarily confusing. > When I got to Section 3, I was running out of time. :^( >=20 > The actual 3168 text in Section 3.2 has _always_ been problemmatic. > The concept of "ECN-Capable transport" is poorly defined; bordering > on PFM "pure f-ing magic" of how the sender is supposed to "receive > a CE-marked packet". RFC3168 has some text that isn't specific to TCP and just talks about = "congestion control algorithms followed at the end systems". This text doesn't specify how the information about a CE-mark is = reflected from the receiver to the sender, because it can't - e.g. the = text probably applies to QUIC just as well as TCP. Then, it has a TCP-specific section, in which it describes how TCP = reflects the CE-mark, and how a TCP sender responds to it. We change both these text pieces in this draft. You say you were confused by the early mention of "cwnd" and "ssthresh". = I suggest to address this in the introduction by being explicit there = about what I just wrote here - that there is a generic statement about = the behavior of congestion controls, and a TCP-specific section in = RFC3168, and we're changing both. Then, we can continue to talk about = TCP as an example. > I don't think it's a good idea to try to minimize the text changes > to RFC 3168. So, IMHO, the fourth paragraph of Section 3.2 is not > helpful. This seems to be related to your confusion about how the ECE-mark = "magically" gets back to the sender. I hope that I was able to clarify = this enough here - this text necessarily leaves this open because it's = not about TCP alone. > I must note that the eighth paragraph is much better -- except for > having to guess where the end-quote is. Okay, thanks for pointing this out: the last sentence (after the end = quote) should be a paragraph on its own. > However "the semantics defined > in [RFC3168]" seems less than helpful. It's hard to find exactly what > 3168 text is being referenced here: most, at least, require exact > duplication of the reaction to loss. Ok, we can probably remove this bit about the semantics. The point was = to say the same as section 2.2 does. > BTW, "should be treated just as a congestion loss" isn't even > possible IMHO; and we really-should simply excise every occurance > of this text from 3168-as-modified. My short answer is that this surely isn't the point of the current = draft. > As I read Section 3.2 quickly, I assumed it intended to specify > that "the TCP source halves the congestion window 'cwnd' and reduces > the slow start threshhold 'ssthresh' " -- subject only to substituting > some other fraction for "halves". >=20 > (I'm not sure the more-careful reading I'm doing now actually > changes this!) IIUC this is about RFC3168, not our draft. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I could continue this, but most readers would die of boredom... >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > What I actually wanted to see was a clear statement that = ecn-response > was revising 3168 by removing the "MUST" requirement for these = algorithms > when the congestion is marked by the ECN CE instead of packet loss; = and > that _an_ experiment is being separately proposed by = alternativebackoff-ecn > to experiment with a different reaction by the sender. I thought our draft does exactly that - with the difference that it = still says MUST react / reduce the rate, but without the "as if a packet = was lost" thing. > There's still a lot of hand-waving (however we phrase ecn-response) > about how to tell whether an experiment is working and is safe to = deploy > on the big-I Internet. I'm happy to work on that; but it doesn't = belong > in this email. Section 3.3 pretty much says that; but the description > of what limits there may be to experiments is missing. IMHO, it's a > bad idea to let each experiment change anything it pleases -- there > should be limits in ecn-response to what is permissible to change. This is not written in section 3.3 but in our RFC3168 text update = (section 3.2), where we require a rate reduction by at least 15%. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There's yet another issue: how observers of these experiments can > know what they're observing. I _really_don't_ want to discuss that in > this email... >=20 > -- > John Leslie Cheers, Michael From nobody Wed Jun 8 05:20:46 2016 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 18D9F12D53D; Wed, 8 Jun 2016 05:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 HnbyGG9bpAcW; Wed, 8 Jun 2016 05:20:40 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 4042512D1EA; Wed, 8 Jun 2016 05:20:40 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n184so179016203wmn.1; Wed, 08 Jun 2016 05:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oGG8Vy1xecl2gchf3lAjRbHRbPZhJAaQ46e/iQXpI1U=; b=BAOXoR4C6tdHNAcYYVia75xsrQktD3J7v/zB6U9u07c8kTaF4zU65J7VSTGp6Baqrf Vqx3ipRU1LTE7PsZNCqWltx1lTjN6W91TVAxoWNduAVCuqMaTaYt5JwdC2zcjnHIxJjp /MrK31QYRsaByA2IjtqmqIBWsFA471lv3ORJqGl3Bjn4ikv/yAePMhfAnNmX3SLPYOcF OuOZt6OJGY+8qBT9Tomke0oYQOx5uNle10n6qUYuajgJQvzl76A6jPgYCZJaaMX+zhVB 4EnucmTtoA8W0BBW3EU1PFm7PSbME0sX8PgnbuuPnn0lW/i/5rvRuTVdpNMbPBfHmKjx zK5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oGG8Vy1xecl2gchf3lAjRbHRbPZhJAaQ46e/iQXpI1U=; b=C1zThgmRWvQlfVHetOxzqFe1nmMT8r2Tkmcpodz/w1Al1zpbJCcITvwqdp9hxcjN9a 4tfHVc6jzSrFQhM7lvbFWLrNnzpT4xfXTXICbfFHLnEtA2wJkQT6FdLjooVYA35kles0 wQH38Nmyp9vbBPdop71Cb1obSzmIHEioJbe0EhQMY6S6PkBj46TSOPILfKiUhMA3bJ4e YPuCw9+hJ193PDM1FQOBAmucfMFu3oDgtI2l5x+N9z+nKXVF1KA01DZZQzCZeYxbIpDv UXGN7RY7C4HE5SGEAZRAjwcp7bNv912xTRr6OKPEgpMt3S8yCuAWRPyCpLlHrrxMMaj0 GdOg== X-Gm-Message-State: ALyK8tIylU9gDeh0vL6IWHDTotNK8WbHnLnS3oLpCVJLeo6UDgQdNC+ZN2vj1a6tNJ+fyrLuraLL6xNQhjioNg== MIME-Version: 1.0 X-Received: by 10.28.211.142 with SMTP id k136mr7777814wmg.29.1465388438767; Wed, 08 Jun 2016 05:20:38 -0700 (PDT) Received: by 10.28.234.13 with HTTP; Wed, 8 Jun 2016 05:20:38 -0700 (PDT) In-Reply-To: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> Date: Wed, 8 Jun 2016 05:20:38 -0700 Message-ID: From: Ca By To: Jim Roskind Content-Type: multipart/alternative; boundary=001a1147136a59d17a0534c355b4 Archived-At: Cc: tsvwg WG , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , "quic@ietf.org" , "ietf@ietf.org" Subject: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:20:44 -0000 --001a1147136a59d17a0534c355b4 Content-Type: text/plain; charset=UTF-8 On Sunday, June 5, 2016, Jim Roskind > wrote: > > > On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert wrote: > >> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell wrote: >> > Greetings, all, >> > >> > Apologies for the late last call comment; I have only one, relatively >> minor. I hope it's still useful. >> > >> > I understand that Section 3 was written to encourage application >> developers not to roll their own transports ("trust us when we say this is >> hard, this document is a list of reasons why") but as written it would seem >> to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data >> channel, anything-over-PLUS), which I very much hope was not the intent. >> The problematic recommendation is in the second paragraph: >> > >> > These mechanisms are difficult to implement correctly. For most >> > applications, the use of one of the existing IETF transport protocols >> > is the simplest method of acquiring the required mechanisms. Doing >> > so also avoids issues that protocols using a new IP protocol number >> > face when being deployed over the Internet, where middleboxes that >> > only support TCP and UDP are not rare. Consequently, the RECOMMENDED >> > alternative to the UDP usage described in the remainder of this >> > section is the use of an IETF transport protocol such as TCP >> > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram >> > Congestion Control Protocol (DCCP) [RFC4340] with its different >> > congestion control types [RFC4341][RFC4342][RFC5622]. >> > >> > First, this paragraph ignores potential deployment issues with any of >> these other than TCP, which risks seeming out of touch, but this is a minor >> point and probably not worth a late edit. Second, I'm concerned this >> recommendation could be taken as broader than intended, against the >> definition of any new transport protocol encapsulated within UDP that >> performs substantially the same function as the listed protocols. >> > >> I would agree, this paragraph also seems a little self >> contradictory.There is an acknowledgment that "middleboxes that only >> support TCP and UDP are not rare", but then the next sentence >> recommends the use of several other protocols besides UDP and TCP. If >> I put these two together, the only congested controlled protocol that >> is recommended and expected to work on the Internet is TCP. >> > > +1 TCP (implemented in kernel space) can't possibly evolve congestion > avoidance as fast as the Internet has changed, or will change (example: > good handling of middle boxes that use "policers" rather than some flavor > of buffer-size based packet-drop). > The rationale for using UDP for QUIC was indeed that a new IP number would > never make it through the Internet (other protocol deployment attempts have > commonly verified this). It turns out that even UDP is partially blocked > (as recently as 2011) by paths to 5-7% of all chrome clients, which lead to > the "automated fallback" elements of QUIC, > > I think this changes with ipv6, no? Google sees over 26% ipv6 in the usa and growing quickly http://www.google.com/intl/en/ipv6/statistics.html And there is evidence that middle boxes go away in ipv6. .... So perhaps the world is changing and your assuptions do not hold > > Hopefully the benefits that QUIC is bringing to the Internet will not be > outlawed (precluded by such commentary). > > Jim > > >> >> Tom >> >> > I think this can be made clearer by simply adding to the list of >> examples: >> > >> > NEW: >> > >> > These mechanisms are difficult to implement correctly. For most >> > applications, the use of one of the existing IETF transport protocols >> > is the simplest method of acquiring the required mechanisms. Doing >> > so also avoids issues that protocols using a new IP protocol number >> > face when being deployed over the Internet, where middleboxes that >> > only support TCP and UDP are not rare. Consequently, the RECOMMENDED >> > alternative to the UDP usage described in the remainder of this >> > section is the use of an IETF transport protocol such as TCP >> > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram >> > Congestion Control Protocol (DCCP) [RFC4340] with its different >> > congestion control types [RFC4341][RFC4342][RFC5622], or transport >> > protocols specified by the IETF in the future. >> > >> > and removing the examples from the summary in section 7: >> > >> > OLD: >> > >> > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | >> > >> > NEW: >> > >> > | SHOULD use a full-featured transport | | >> > >> > Thanks, cheers, >> > >> > Brian >> > >> > >> >> On 18 May 2016, at 02:17, The IESG wrote: >> >> >> >> >> >> The IESG has received a request from the Transport Area Working Group >> WG >> >> (tsvwg) to consider the following document: >> >> - 'UDP Usage Guidelines' >> >> as Best Current Practice >> >> >> >> The IESG plans to make a decision in the next few weeks, and solicits >> >> final comments on this action. Please send substantive comments to the >> >> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments >> may be >> >> sent to iesg@ietf.org instead. In either case, please retain the >> >> beginning of the Subject line to allow automated sorting. >> >> >> >> Abstract >> >> >> >> >> >> The User Datagram Protocol (UDP) provides a minimal message-passing >> >> transport that has no inherent congestion control mechanisms. This >> >> document provides guidelines on the use of UDP for the designers of >> >> applications, tunnels and other protocols that use UDP. Congestion >> >> control guidelines are a primary focus, but the document also >> >> provides guidance on other topics, including message sizes, >> >> reliability, checksums, middlebox traversal, the use of ECN, DSCPs, >> >> and ports. >> >> >> >> Because congestion control is critical to the stable operation of the >> >> Internet, applications and other protocols that choose to use UDP as >> >> an Internet transport must employ mechanisms to prevent congestion >> >> collapse and to establish some degree of fairness with concurrent >> >> traffic. They may also need to implement additional mechanisms, >> >> depending on how they use UDP. >> >> >> >> Some guidance is also applicable to the design of other protocols >> >> (e.g., protocols layered directly on IP or via IP-based tunnels), >> >> especially when these protocols do not themselves provide congestion >> >> control. >> >> >> >> This document obsoletes RFC5405 and adds guidelines for multicast UDP >> >> usage. >> >> >> >> >> >> >> >> >> >> The file can be obtained via >> >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >> >> >> >> IESG discussion can be tracked via >> >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ >> >> >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> > >> > >> > _______________________________________________ >> > Spud mailing list >> > Spud@ietf.org >> > https://www.ietf.org/mailman/listinfo/spud >> > >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >> > > --001a1147136a59d17a0534c355b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, June 5, 2016, Jim Roskind <Ji= mRoskind@gmail.com> wrote:


On = Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <tom@herbe= rtland.com> wrote:
On Thu, Jun 2, 2= 016 at 3:11 AM, Brian Trammell <ietf@trammell.ch> wrote:
> Greetings, all,
>
> Apologies for the late last call comment; I have only one, relatively = minor. I hope it's still useful.
>
> I understand that Section 3 was written to encourage application devel= opers not to roll their own transports ("trust us when we say this is = hard, this document is a list of reasons why") but as written it would= seem to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB da= ta channel, anything-over-PLUS), which I very much hope was not the intent.= The problematic recommendation is in the second paragraph:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622].
>
> First, this paragraph ignores potential deployment issues with any of = these other than TCP, which risks seeming out of touch, but this is a minor= point and probably not worth a late edit. Second, I'm concerned this r= ecommendation could be taken as broader than intended, against the definiti= on of any new transport protocol encapsulated within UDP that performs subs= tantially the same function as the listed protocols.
>
I would agree, this paragraph also seems a little self
contradictory.There is an acknowledgment that "middleboxes that only support TCP and UDP are not rare", but then the next sentence
recommends the use of several other protocols besides UDP and TCP. If
I put these two together, the only congested controlled protocol that
is recommended and expected to work on the Internet is TCP.

+1 =C2=A0 TCP (implemented in kernel space) can't = possibly evolve congestion avoidance as fast as the Internet has changed, o= r will change (example: good handling of middle boxes that use "police= rs" rather than some flavor of buffer-size based packet-drop).=C2=A0
The rationale for using UDP for QUIC was indeed that a new IP numb= er would never make it through the Internet (other protocol deployment atte= mpts have commonly verified this).=C2=A0 It turns out that even UDP is part= ially blocked (as recently as 2011) by paths to 5-7% of all chrome clients,= which lead to the "automated fallback" elements of QUIC, =C2=A0= =C2=A0


I think this changes with ipv6, no?=C2=A0=C2=A0Google sees = over 26% ipv6 in the usa and growing quickly


And ther= e is evidence that middle boxes go away in ipv6. .... So perhaps the world = is changing and your assuptions do not hold



=C2=A0
<= /blockquote>
Hopefully the benefits that QUI= C is bringing to the Internet will not be outlawed (precluded by such comme= ntary).

Jim
=C2=A0

Tom

> I think this can be made clearer by simply adding to the list of examp= les:
>
> NEW:
>
>=C2=A0 =C2=A0 These mechanisms are difficult to implement correctly.=C2= =A0 For most
>=C2=A0 =C2=A0 applications, the use of one of the existing IETF transpo= rt protocols
>=C2=A0 =C2=A0 is the simplest method of acquiring the required mechanis= ms.=C2=A0 Doing
>=C2=A0 =C2=A0 so also avoids issues that protocols using a new IP proto= col number
>=C2=A0 =C2=A0 face when being deployed over the Internet, where middleb= oxes that
>=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequently= , the RECOMMENDED
>=C2=A0 =C2=A0 alternative to the UDP usage described in the remainder o= f this
>=C2=A0 =C2=A0 section is the use of an IETF transport protocol such as = TCP
>=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol (SCTP) [R= FC4960], and
>=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], o= r Datagram
>=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with its dif= ferent
>=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5622], or = transport
>=C2=A0 =C2=A0 protocols specified by the IETF in the future.
>
> and removing the examples from the summary in section 7:
>
> OLD:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport (TCP, SCTP, DCCP)= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>
> NEW:
>
>=C2=A0 =C2=A0 | SHOULD use a full-featured transport=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>
> Thanks, cheers,
>
> Brian
>
>
>> On 18 May 2016, at 02:17, The IESG <iesg-secretary@ietf.org<= /a>> wrote:
>>
>>
>> The IESG has received a request from the Transport Area Working Gr= oup WG
>> (tsvwg) to consider the following document:
>> - 'UDP Usage Guidelines'
>>=C2=A0 <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current P= ractice
>>
>> The IESG plans to make a decision in the next few weeks, and solic= its
>> final comments on this action. Please send substantive comments to= the
>> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, c= omments may be
>> sent to iesg@ietf.org instead. In either case, please retai= n the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>=C2=A0 =C2=A0The User Datagram Protocol (UDP) provides a minimal me= ssage-passing
>>=C2=A0 =C2=A0transport that has no inherent congestion control mech= anisms.=C2=A0 This
>>=C2=A0 =C2=A0document provides guidelines on the use of UDP for the= designers of
>>=C2=A0 =C2=A0applications, tunnels and other protocols that use UDP= .=C2=A0 Congestion
>>=C2=A0 =C2=A0control guidelines are a primary focus, but the docume= nt also
>>=C2=A0 =C2=A0provides guidance on other topics, including message s= izes,
>>=C2=A0 =C2=A0reliability, checksums, middlebox traversal, the use o= f ECN, DSCPs,
>>=C2=A0 =C2=A0and ports.
>>
>>=C2=A0 =C2=A0Because congestion control is critical to the stable o= peration of the
>>=C2=A0 =C2=A0Internet, applications and other protocols that choose= to use UDP as
>>=C2=A0 =C2=A0an Internet transport must employ mechanisms to preven= t congestion
>>=C2=A0 =C2=A0collapse and to establish some degree of fairness with= concurrent
>>=C2=A0 =C2=A0traffic.=C2=A0 They may also need to implement additio= nal mechanisms,
>>=C2=A0 =C2=A0depending on how they use UDP.
>>
>>=C2=A0 =C2=A0Some guidance is also applicable to the design of othe= r protocols
>>=C2=A0 =C2=A0(e.g., protocols layered directly on IP or via IP-base= d tunnels),
>>=C2=A0 =C2=A0especially when these protocols do not themselves prov= ide congestion
>>=C2=A0 =C2=A0control.
>>
>>=C2=A0 =C2=A0This document obsoletes RFC5405 and adds guidelines fo= r multicast UDP
>>=C2=A0 =C2=A0usage.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/d= oc/draft-ietf-tsvwg-rfc5405bis/
>>
>> IESG discussion can be tracked via
>> https://datatracker.iet= f.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

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

--001a1147136a59d17a0534c355b4-- From nobody Wed Jun 8 09:41:02 2016 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 8073712DA2E; Wed, 8 Jun 2016 09:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, 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 Ea3kiNXWmHGV; Wed, 8 Jun 2016 09:40:58 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id ECADD12DA1F; Wed, 8 Jun 2016 09:40:57 -0700 (PDT) Received: from [10.44.157.122] (212-88-240-96.access.telenet.be [212.88.240.96]) by trammell.ch (Postfix) with ESMTPSA id AFC611A0302; Wed, 8 Jun 2016 18:40:25 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Wed, 8 Jun 2016 18:40:24 +0200 Message-Id: <6B252567-A532-42FF-B035-E457400EECF5@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: Ca By X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsvwg WG , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Jim Roskind , "quic@ietf.org" Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 16:41:00 -0000 --Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 >> On 08 Jun 2016, at 14:20, Ca By wrote: >>=20 >>=20 >>=20 >> On Sunday, June 5, 2016, Jim Roskind wrote: >>=20 >>=20 >> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert = wrote: >> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell = wrote: >> > Greetings, all, >> > >> > Apologies for the late last call comment; I have only one, = relatively minor. I hope it's still useful. >> > >> > I understand that Section 3 was written to encourage application = developers not to roll their own transports ("trust us when we say this = is hard, this document is a list of reasons why") but as written it = would seem to discourage transport innovation atop UDP (e.g. QUIC, the = RTCWEB data channel, anything-over-PLUS), which I very much hope was not = the intent. The problematic recommendation is in the second paragraph: >> > >> > These mechanisms are difficult to implement correctly. For most >> > applications, the use of one of the existing IETF transport = protocols >> > is the simplest method of acquiring the required mechanisms. = Doing >> > so also avoids issues that protocols using a new IP protocol = number >> > face when being deployed over the Internet, where middleboxes = that >> > only support TCP and UDP are not rare. Consequently, the = RECOMMENDED >> > alternative to the UDP usage described in the remainder of this >> > section is the use of an IETF transport protocol such as TCP >> > [RFC0793], Stream Control Transmission Protocol (SCTP) = [RFC4960], and >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or = Datagram >> > Congestion Control Protocol (DCCP) [RFC4340] with its different >> > congestion control types [RFC4341][RFC4342][RFC5622]. >> > >> > First, this paragraph ignores potential deployment issues with any = of these other than TCP, which risks seeming out of touch, but this is a = minor point and probably not worth a late edit. Second, I'm concerned = this recommendation could be taken as broader than intended, against the = definition of any new transport protocol encapsulated within UDP that = performs substantially the same function as the listed protocols. >> > >> I would agree, this paragraph also seems a little self >> contradictory.There is an acknowledgment that "middleboxes that only >> support TCP and UDP are not rare", but then the next sentence >> recommends the use of several other protocols besides UDP and TCP. If >> I put these two together, the only congested controlled protocol that >> is recommended and expected to work on the Internet is TCP. >>=20 >> +1 TCP (implemented in kernel space) can't possibly evolve = congestion avoidance as fast as the Internet has changed, or will change = (example: good handling of middle boxes that use "policers" rather than = some flavor of buffer-size based packet-drop). >> The rationale for using UDP for QUIC was indeed that a new IP number = would never make it through the Internet (other protocol deployment = attempts have commonly verified this). It turns out that even UDP is = partially blocked (as recently as 2011) by paths to 5-7% of all chrome = clients, which lead to the "automated fallback" elements of QUIC, >>=20 >=20 > I think this changes with ipv6, no? Google sees over 26% ipv6 in the = usa and growing quickly >=20 > http://www.google.com/intl/en/ipv6/statistics.html >=20 > And there is evidence that middle boxes go away in ipv6. .... So = perhaps the world is changing and your assuptions do not hold (dropping ietf@, saving my Narten points since we're a bit off topic on = the draft last call) I'd like to see evidence, if you can share it. We've done a few measurements with Atlas that suggest the brokenness on = v6 is different, but not necessarily better, but don't have enough data = points to make an informed statement on the fact. Any time you touch a = NAPT (which lives at the core of any transition technology for v6-only = access to the v4 Internet), you run into the "only TCP and UDP have = ports" fallacy. But yes, we need to compare and contrast v4 and v6 = access network impairments for non-(6,17) protocol numbers. Cheers, Brian --Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXWEp5AAoJEIoSt78L6kajnYgP/3N/uJHh8+g4Qo/gscnWlYu2 tSC0qa5rzJ9j9VDBI8f9dya+mcI2N+PALwlL2ltznIANbRTYccWlisd+EC0ySxtc ln49ibyBH6YIX4jZXBclGAZRT6VidhXMkPTBTV3J1rYIF99FRosHbytkQtwzXxlF OOq9OIGc+Cb/krSld8j6jX7PoUSZk1dICL+7uHd5qtcrMzpZrwtQ73MHshlOROQE SgkE/36eI7m2k2WraYCKCJYAsvTol8czlGhd7/uOjFa+djyk82JHcyBqWz/hXCRU gW7jOSm83VYFDo7ijfIx50Eeu0zvyiifOaBASsFAWtIXd3zSwdj/BhDeEZELoqv9 W6PN8M6SurFs1ZjOjrbHsUFD/QgKyhBNq/lJmW5M+2eijXQzYwvDXB24ZRCeXFk6 9STH8u+sYMVxtKfQVyPUrRbqeUO2ITtbSNPDvp4DOCKD2xrnbRB0C+dxb4D0440M aNeXqrN6TctplkmY9A6cepY3fFLcPt7NDbWX2KZYsH2tfQkpPeE9NPSXfVO5YpGu rxaso2e+Fh2AKUjmEnwavwfgPsF12xndSboiDRFzJs/eXA0Y3kSWMQf5yz1DOy3F yNBrBNEKLHe8lAYVUGxF+6SnI4sivrhnEn41lzP1+lMTic+PyO1fni/zaKD3ksp4 yeR/bhTDYgujISd7/rpN =9pgK -----END PGP SIGNATURE----- --Apple-Mail=_178C65FE-32D5-4259-A227-F4D8168B3E70-- From nobody Wed Jun 8 22:14:38 2016 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 A7A8012B01C for ; Wed, 8 Jun 2016 22:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 ZGeNtL7Qfng8 for ; Wed, 8 Jun 2016 22:14:35 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EF812B015 for ; Wed, 8 Jun 2016 22:14:35 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u595EYK1010003 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 9 Jun 2016 01:14:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u595EYK1010003 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1465449274; bh=c9oVAszoox+Vzuk2rJ0UpTmetHU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=U6MWIfr1m+20Z9F9ERw+oe3T8NxNv9hW/NJRmTFXocuEDMrgCL0x1+SU+t6xhgk+Z BhtkNt38B+kgF3AvRK4S8eHGpFbj6cUMRcVnV90e+OF+lxYPZHXHUYfDTVCsnJANaj Nsuq6vXSYyacsqk1UrjFpm8c5ZPL0FcP21PH9OG8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u595EYK1010003 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Thu, 9 Jun 2016 01:14:04 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u595EOVL022252 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Thu, 9 Jun 2016 01:14:25 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Thu, 9 Jun 2016 01:14:24 -0400 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 Thread-Index: AdHCDchogAyx4sMnQ9q77258V6wqAg== Date: Thu, 9 Jun 2016 05:14:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.63.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 05:14:36 -0000 This is a TSVWG call for interest in WG adoption of draft-szigeti-tsvwg-iee= e-802-11. If you have read the draft and support WG adoption of it as a work item and WG draft, please send an email to the list (tsvwg@ietf.org) saying so. NB: It is important to say that you've read the draft. If you're willing to review/comment on future versions of this draft and/or implement this draft, please say so on the list or in email directly to the chairs (tsvwg-chairs@ietf.org). Authors: We (chairs) assume that you support WG adoption of your draft, so there's no need to say so on the list. However, we do need each author to= =20 publicly state on the list that their direct, personal knowledge (if any) o= f any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. This adoption call will run for about 2 weeks, ending at midnight, prevaili= ng US Eastern Time on Saturday June 25. To get things started, I hereby state as an individual that I have read the draft and support WG adoption of it. Guidelines for DiffServ to IEEE 802.11 Mapping draft-szigeti-tsvwg-ieee-802-11-01 Abstract As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This is due to the fact that two independent standards bodies provide QoS guidance on wired and wireless networks: specifically, the IETF specifies standards and design recommendations for wired IP networks, while a separate and autonomous standards- body, the IEEE, administers the standards for wireless 802.11 networks. The purpose of this document is to propose a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by these two standards bodies, and, as such, to optimize wired-and-wireless interconnect QoS. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0=20 ---------------------------------------------------- From nobody Thu Jun 9 07:28:54 2016 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 0083012D5C3 for ; Thu, 9 Jun 2016 07:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uoIW3WDkxNeG for ; Thu, 9 Jun 2016 07:28:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02AA12D11F for ; Thu, 9 Jun 2016 07:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1787; q=dns/txt; s=iport; t=1465482531; x=1466692131; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XB8ElQJR276ng2Sk2FZDCpYPE/XNBOglE1DfGMdiq0E=; b=b89ShZvv9GSAq3wkoIYiZFlcIh+CRlwhNbze/oeQO/Tu1SHQw6NDAw9V lAYes5Xx5sBICxMTtRG88oFDWUKoYqpyAQVPBIlqccAieGinm1qAOHhoa s45xfN0m5HBxyp1PNwWuNqRtJaFWjdTCGE/I9CaP7K2m/riCGibXJR/HU 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDDfFlX/4YNJK1egz6BUwa7EYF6h?= =?us-ascii?q?hMCgTU4FAEBAQEBAQFlJ4RFAQEBAwF5BQsCAQgYLjIlAgQOBQ6IGQi+LwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQ4OiB6CVoE5hjOCLgWTPIUZAYMsgWmJEYFTjU2PZ?= =?us-ascii?q?AEeNoIUgVpuiQl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="asc'?scan'208";a="113310220" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2016 14:28:50 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u59ESoSL016323 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 14:28:50 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 09:28:50 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 09:28:50 -0500 From: "Fred Baker (fred)" To: "Black, David" Thread-Topic: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 Thread-Index: AQHRwls9ykbxn+nBdUa2El966qhLBw== Date: Thu, 9 Jun 2016 14:28:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.70.133] Content-Type: multipart/signed; boundary="Apple-Mail=_5016FD43-F5D7-4C6C-B41C-37F50FB5C0B1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:28:53 -0000 --Apple-Mail=_5016FD43-F5D7-4C6C-B41C-37F50FB5C0B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On Jun 8, 2016, at 11:14 PM, Black, David wrote: >=20 > Authors: We (chairs) assume that you support WG adoption of your = draft, so > there's no need to say so on the list. However, we do need each = author to > publicly state on the list that their direct, personal knowledge (if = any) of any > IPR related to this document has already been disclosed, in = conformance > with BCPs 78 and 79. I know of no such IPR. --Apple-Mail=_5016FD43-F5D7-4C6C-B41C-37F50FB5C0B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV1l9I0ayAOS/EQ8MAQKtVxAAifNQbVcJfJykovv3bpk9p0MVdS+rBGtP BjAes/asaXRE3JSXHiY+THWMZNOcw48oa+YQAQocWkPz13AAPImPiBuA366liq2H xv37zhbG1qGUG9GpwKuKRHSQsDnsLBi1xdsU/KvYZAj4U7YVcMLlQs4UqaJBQxBC wJIGTZjLyli6pS1A8KT/Q1yxBFrUrVKaBCFHP20Yy2hQnliFJNLBmH6+fM+bSviH E18xyuNBR7OU21So9XQXFq4Ww2yR08naeDyskHiQCKLrzEDL6E9tVZ1yFhf+RCOw BpI8J6WNFhUnv5CumdEL5wWAnqWnQyYfv3FHCLpYrhssIHzb9Z8r90UCTfwPUdFn lvK47wWvOXHdfA581aia7QKRFFsbOP76YZwWkOtIL9FgKY8+TgXbw03OCRWF0juH aEfoq9ZmV4iBZmWtSEFD9zixlwvQFOIG/w42F/X4IZ4cwyDdP8wpOGt5wszjcQll YkCSX/f1WwKk+jaOeWMrKpKHcGTmcv/LqNAYnEjfqt1Yndnf3E4iLBZPBYS8g9da 7eE8nou3MqcrSyFMwN43LLWDVs2ygaKhmOmJPJbxS22nT2n+2VMOXjYvFaTKpYpr piimORe9RYX+BE+1MVakHnWuGPLWVmk1hsbl5m+KaXKcLVJJ2pK8hQs7VTgMQbSN oiOoMdHLpfg= =J9yU -----END PGP SIGNATURE----- --Apple-Mail=_5016FD43-F5D7-4C6C-B41C-37F50FB5C0B1-- From nobody Sat Jun 11 16:24:20 2016 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 25EFB12D113; Sat, 11 Jun 2016 16:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 x_flt3sI3d7G; Sat, 11 Jun 2016 16:24:11 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 2062712D0AD; Sat, 11 Jun 2016 16:24:11 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n184so33708797wmn.1; Sat, 11 Jun 2016 16:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=uB5VYr7NJj6zQWnx53KqNj1uz7hosxjAX+ATvnTdzGY=; b=kIt6f5zsK4WiECTBSLL9eVrpuLd/dGUFgo/ZMPyaxa2lxeRA5u3JudVLUdrWquRSWw kUYcET3Qk/h9ebe1wl6QNX7jwzW/eMgKO2qZuODkSj+HjG3V6K0W/bDDii8yDCiRr7HZ GI8gtyxPstyDMUdPv0g7dhzFuObNdJEDMjNWPp4vVVKYWG0uA5BCx/CuZx2lEmFJcobi xA3KRzNFBLL0LLhCQBWl7V5HjHiZutC5YiEEHxLlo2h0WXB2LDI3WDwvces5bDjNyzVA 4tciOdcCU3AqD9MYc4++QccgDDmWFdw4kWxTJr7lgEbS/AE+n6API4K0M9W9vthXecIm WUKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=uB5VYr7NJj6zQWnx53KqNj1uz7hosxjAX+ATvnTdzGY=; b=AGwcI2ophcRUQR90Ke++5iqW2Y4Z/+PoeAjhFxVKBqiJ92cDiCpPwMOzvuD1gX6REm szEkhf3GkESlMnzV6SpMBuQDJ6JgbTbKFgINNsfTqQl8O27CinjgNkjlK13YQnIVXDj9 ac1SMXP6/VjdYtnsxBhcmB3hqiFUg65N5m6rTk9qOz1U9enPdJ10cC1w2JtxPes+SIKU u3ZIHNKTk/lAEp+gm/S3jMiE3fYQyD8f7mGdYhAaA1H7jzbQPLByPxOFthW4O2cqAsq+ dn2vnWbXkLeqkcTjsAaaqmKsNxybFRIZ1W2z39NL1n+MtxGTgtXsNdwAzaUeWbqObizm cC8A== X-Gm-Message-State: ALyK8tIhmN8r0kPH2Uw/qpgwrMnt8uRdo6TaCh+7q+LvsyczwHVbXvJx0WwXij9s2O/D2Btg+NC9r4CfM+N0dA== MIME-Version: 1.0 X-Received: by 10.28.148.203 with SMTP id w194mr5033791wmd.10.1465687449538; Sat, 11 Jun 2016 16:24:09 -0700 (PDT) Received: by 10.28.234.13 with HTTP; Sat, 11 Jun 2016 16:24:09 -0700 (PDT) In-Reply-To: <6B252567-A532-42FF-B035-E457400EECF5@trammell.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> <6B252567-A532-42FF-B035-E457400EECF5@trammell.ch> Date: Sat, 11 Jun 2016 16:24:09 -0700 Message-ID: From: Ca By To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114b322ac81c71053508f333 Archived-At: Cc: tsvwg WG , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Jim Roskind , "quic@ietf.org" Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 23:24:13 -0000 --001a114b322ac81c71053508f333 Content-Type: text/plain; charset=UTF-8 On Wednesday, June 8, 2016, Brian Trammell wrote: > > > >> On 08 Jun 2016, at 14:20, Ca By > > wrote: > >> > >> > >> > >> On Sunday, June 5, 2016, Jim Roskind > wrote: > >> > >> > >> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert > wrote: > >> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell > wrote: > >> > Greetings, all, > >> > > >> > Apologies for the late last call comment; I have only one, relatively > minor. I hope it's still useful. > >> > > >> > I understand that Section 3 was written to encourage application > developers not to roll their own transports ("trust us when we say this is > hard, this document is a list of reasons why") but as written it would seem > to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data > channel, anything-over-PLUS), which I very much hope was not the intent. > The problematic recommendation is in the second paragraph: > >> > > >> > These mechanisms are difficult to implement correctly. For most > >> > applications, the use of one of the existing IETF transport > protocols > >> > is the simplest method of acquiring the required mechanisms. Doing > >> > so also avoids issues that protocols using a new IP protocol number > >> > face when being deployed over the Internet, where middleboxes that > >> > only support TCP and UDP are not rare. Consequently, the > RECOMMENDED > >> > alternative to the UDP usage described in the remainder of this > >> > section is the use of an IETF transport protocol such as TCP > >> > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], > and > >> > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > >> > Congestion Control Protocol (DCCP) [RFC4340] with its different > >> > congestion control types [RFC4341][RFC4342][RFC5622]. > >> > > >> > First, this paragraph ignores potential deployment issues with any of > these other than TCP, which risks seeming out of touch, but this is a minor > point and probably not worth a late edit. Second, I'm concerned this > recommendation could be taken as broader than intended, against the > definition of any new transport protocol encapsulated within UDP that > performs substantially the same function as the listed protocols. > >> > > >> I would agree, this paragraph also seems a little self > >> contradictory.There is an acknowledgment that "middleboxes that only > >> support TCP and UDP are not rare", but then the next sentence > >> recommends the use of several other protocols besides UDP and TCP. If > >> I put these two together, the only congested controlled protocol that > >> is recommended and expected to work on the Internet is TCP. > >> > >> +1 TCP (implemented in kernel space) can't possibly evolve congestion > avoidance as fast as the Internet has changed, or will change (example: > good handling of middle boxes that use "policers" rather than some flavor > of buffer-size based packet-drop). > >> The rationale for using UDP for QUIC was indeed that a new IP number > would never make it through the Internet (other protocol deployment > attempts have commonly verified this). It turns out that even UDP is > partially blocked (as recently as 2011) by paths to 5-7% of all chrome > clients, which lead to the "automated fallback" elements of QUIC, > >> > > > > I think this changes with ipv6, no? Google sees over 26% ipv6 in the > usa and growing quickly > > > > http://www.google.com/intl/en/ipv6/statistics.html > > > > And there is evidence that middle boxes go away in ipv6. .... So perhaps > the world is changing and your assuptions do not hold > > (dropping ietf@, saving my Narten points since we're a bit off topic on > the draft last call) > > I'd like to see evidence, if you can share it. > > " Verizon uses transparent proxy servers on IPv4 but not on IPv6" https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html We've done a few measurements with Atlas that suggest the brokenness on v6 > is different, but not necessarily better, but don't have enough data points > to make an informed statement on the fact. Any time you touch a NAPT (which > lives at the core of any transition technology for v6-only access to the v4 > Internet), you run into the "only TCP and UDP have ports" fallacy. But yes, > we need to compare and contrast v4 and v6 access network impairments for > non-(6,17) protocol numbers. > > NAPT is an edge case for v6 users, less than 30% and shrinking by bit volume as the whales have moved to v6 already https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html > Cheers, > > Brian > --001a114b322ac81c71053508f333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 8, 2016, Brian Trammell <ietf@trammell.ch> wrote:
>
>> On 08 Jun 2016, at 14:20, Ca By <cb.list6@gma= il.com> wrote:
>>
>>
>>
>> On Sunday, June 5, 2016, Jim Roskind <JimRo= skind@gmail.com> wrote:
>>
>>
>> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell <ietf@trammell.ch> wrote:
>> > Greetings, all,
>> >
>> > Apologies for the late last call comment; I have only one, re= latively minor. I hope it's still useful.
>> >
>> > I understand that Section 3 was written to encourage applicat= ion developers not to roll their own transports ("trust us when we say= this is hard, this document is a list of reasons why") but as written= it would seem to discourage transport innovation atop UDP (e.g. QUIC, the = RTCWEB data channel, anything-over-PLUS), which I very much hope was not th= e intent. The problematic recommendation is in the second paragraph:
>> >
>> >=C2=A0 =C2=A0 These mechanisms are difficult to implement corr= ectly.=C2=A0 For most
>> >=C2=A0 =C2=A0 applications, the use of one of the existing IET= F transport protocols
>> >=C2=A0 =C2=A0 is the simplest method of acquiring the required= mechanisms.=C2=A0 Doing
>> >=C2=A0 =C2=A0 so also avoids issues that protocols using a new= IP protocol number
>> >=C2=A0 =C2=A0 face when being deployed over the Internet, wher= e middleboxes that
>> >=C2=A0 =C2=A0 only support TCP and UDP are not rare.=C2=A0 Con= sequently, the RECOMMENDED
>> >=C2=A0 =C2=A0 alternative to the UDP usage described in the re= mainder of this
>> >=C2=A0 =C2=A0 section is the use of an IETF transport protocol= such as TCP
>> >=C2=A0 =C2=A0 [RFC0793], Stream Control Transmission Protocol = (SCTP) [RFC4960], and
>> >=C2=A0 =C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RF= C3758], or Datagram
>> >=C2=A0 =C2=A0 Congestion Control Protocol (DCCP) [RFC4340] wit= h its different
>> >=C2=A0 =C2=A0 congestion control types [RFC4341][RFC4342][RFC5= 622].
>> >
>> > First, this paragraph ignores potential deployment issues wit= h any of these other than TCP, which risks seeming out of touch, but this i= s a minor point and probably not worth a late edit. Second, I'm concern= ed this recommendation could be taken as broader than intended, against the= definition of any new transport protocol encapsulated within UDP that perf= orms substantially the same function as the listed protocols.
>> >
>> I would agree, this paragraph also seems a little self
>> contradictory.There is an acknowledgment that "middleboxes th= at only
>> support TCP and UDP are not rare", but then the next sentence=
>> recommends the use of several other protocols besides UDP and TCP.= If
>> I put these two together, the only congested controlled protocol t= hat
>> is recommended and expected to work on the Internet is TCP.
>>
>> +1=C2=A0 =C2=A0TCP (implemented in kernel space) can't possibl= y evolve congestion avoidance as fast as the Internet has changed, or will = change (example: good handling of middle boxes that use "policers"= ; rather than some flavor of buffer-size based packet-drop).
>> The rationale for using UDP for QUIC was indeed that a new IP numb= er would never make it through the Internet (other protocol deployment atte= mpts have commonly verified this).=C2=A0 It turns out that even UDP is part= ially blocked (as recently as 2011) by paths to 5-7% of all chrome clients,= which lead to the "automated fallback" elements of QUIC,
>>
>
> I think this changes with ipv6, no?=C2=A0 Google sees over 26% ipv6 in= the usa and growing quickly
>
> http://www.google.com/intl/en/ipv6/statistics.html
>
> And there is evidence that middle boxes go away in ipv6. .... So perha= ps the world is changing and your assuptions do not hold

(dropping ietf@, saving my Narten points since we're a bit off topic on= the draft last call)

I'd like to see evidence, if you can share it.


"=C2=A0Verizon uses transparent proxy = servers on IPv4 but not on IPv6"

=
=
=

We've done a few measurements with Atlas that suggest the brokenness on= v6 is different, but not necessarily better, but don't have enough dat= a points to make an informed statement on the fact. Any time you touch a NA= PT (which lives at the core of any transition technology for v6-only access= to the v4 Internet), you run into the "only TCP and UDP have ports&qu= ot; fallacy. But yes, we need to compare and contrast v4 and v6 access netw= ork impairments for non-(6,17) protocol numbers.


NAPT is an edge case for v6 users, les= s than 30% and shrinking by bit volume as the whales have moved to v6 alrea= dy


=C2=A0
Cheers,

Brian
--001a114b322ac81c71053508f333-- From nobody Sat Jun 11 22:12:08 2016 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 5D3C712D10F for ; Sat, 11 Jun 2016 22:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 Y07d3p5DNY2m for ; Sat, 11 Jun 2016 22:12:03 -0700 (PDT) Received: from nm37-vm9.bullet.mail.ir2.yahoo.com (nm37-vm9.bullet.mail.ir2.yahoo.com [212.82.97.150]) (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 11D0912B009 for ; Sat, 11 Jun 2016 22:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1465708321; bh=7Se32ZYrkdGNcXAih3GRNcv6HBs9n7Jmp92OGL8H46c=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=TYIoXWagL6xDy3Dk9kwxVG4YylXaIowdbAb21ZpWyuXwQPj9abMMZWvAIz+AOn6x/TdPRquxHalJ/+Lgg4ciow+7jAKroYKCnXmf3cX7IrFaW8Jo4Q+NsQ7fmE9yr6h6XOEuN8JWzJDeDTc8PwfRU7Ig6o0xetUtGQudcYW010UBFRtmfTsBpNHBYhR+BZnBp3wl0FaFjIZDiuhHvs3qAaXjtprZpox4wn8BmGzkS2ndOHWqgEWbmYDetYQd64SPppW0omwr4SFh103mp/n03PiDQ+pmFQ6o+MKTgQ5DRdwVfyVdTaZoJE9b5G5oaI/D20lTiu6ec8nKbfzOAjianQ== Received: from [212.82.98.60] by nm37.bullet.mail.ir2.yahoo.com with NNFMP; 12 Jun 2016 05:12:01 -0000 Received: from [212.82.98.74] by tm13.bullet.mail.ir2.yahoo.com with NNFMP; 12 Jun 2016 05:12:01 -0000 Received: from [127.0.0.1] by omp1011.mail.ir2.yahoo.com with NNFMP; 12 Jun 2016 05:12:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 386946.51620.bm@omp1011.mail.ir2.yahoo.com X-YMail-OSG: Mr0y7sAVM1nNjVny5KH7JBLwqtJyjHkK9jJ7I2ykKiZRSnGHz_uneCAabFPpgvT a8pqlD5KR3faKXGnd2RJu.A9.ubxxkR_4NTkEjPowc7X44s3nQLtPl6kSwVIeItkvKUv.lOPa3wf FH5AKoAgOnbAI_ScLr1WmnIykD2sJ8OcY3fDHuO5h7BCzuGzN6T.ndTTcPB97K3VQiZCqoCzqheD _o_obru7Pa53Gojoa_6goZhJnWrynhHH2jzyqFuOnDyHhepneFa4IixhF_b_jDm_PEqR_DEyMEBs 8hrzm3i9Pu0QQhSGJxnIviQdxTVrhqKo9ilaFuBk7QnFNmmDWiqJYAPZyzAGsM6HgcpRDQjiNQYf owO2dvt9oH.zGCRvi0eJAgFe26xA6CWLwLmQWak63UDhjqueCuteqt19Otm47xVHBR7wmtFGMMcJ 68bT1TNVagFb1PXtlj7HUKGGQeQ1xK9flLX1bFP08b_d9N1mHeNYMbHB8vpNW5r8Bf0oRLBHAlWg .vRp0cYY6htUpMukwmg0Ok30avsh6v06EC.4VmyXxdw-- Received: from jws11172.mail.ir2.yahoo.com by sendmailws161.mail.ir2.yahoo.com; Sun, 12 Jun 2016 05:12:00 +0000; 1465708320.697 Date: Sun, 12 Jun 2016 05:11:48 +0000 (UTC) From: Lloyd Wood To: Softwires WG , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" , Xuxiaohu , "nvo3@ietf.org" Message-ID: <974977917.2492241.1465708308527.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2492240_1136524516.1465708308517" Archived-At: Subject: Re: [tsvwg] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 05:12:07 -0000 ------=_Part_2492240_1136524516.1465708308517 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px = #715FFA solid !important; padding-left:1ex !important; background-color:whi= te !important; } Fragmentation should be strongly discouraged. if you've designed a tunnelling solution and you have fragmentation happeni= ng as a matter of course, you've designed it wrong.=C2=A0 Lloyd Woodlloyd.wood@yahoo.co.uk On Friday, May 27, 2016, 8:10 PM, Xuxiaohu wrote: The possible side-effect of performing fragmentation on UDP encapsulated pa= ckets is to worsen the reassembly burden on tunnel egress since fragments o= f UDP encapsulated packets are more likely to be forwarded across different= paths towards the tunnel egress than those of IP or GRE encapsulated packe= ts. It seems that most X-over-UDP proposals choose to prohibit the tunnel ingre= ss from performing fragmentation on UDP encapsulated packets. See the follo= wing quoted text regarding fragmentation from those X-over-UDP drafts: LISP: When an ITR receives a packet from a site-facing interface and adds H =C2=A0 octets worth of encapsulation to yield a packet size greater than L =C2=A0 octets, it resolves the MTU issue by first splitting the original =C2=A0 packet into 2 equal-sized fragments.=C2=A0 A LISP header is then pre= pended =C2=A0 to each fragment. VXLAN: VTEPs MUST NOT fragment VXLAN packets.=C2=A0 Intermediate routers may =C2=A0 fragment encapsulated VXLAN packets due to the larger frame size. =C2=A0 The destination VTEP MAY silently discard such VXLAN fragments. VXLAN-GPE: VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when =C2=A0 the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer =C2=A0 IPv4 header. GEVENE: =C2=A0 To prevent fragmentation and maximize performance, the best practice =C2=A0 when using Geneve is to ensure that the MTU of the physical network =C2=A0 is greater than or equal to the MTU of the encapsulated network plus =C2=A0 tunnel headers. GUE: =C2=A0 =C2=A0 If a packet is fragmented before encapsulation in GUE, all th= e =C2=A0 =C2=A0 related fragments must be encapsulated using the same source = port =C2=A0 =C2=A0 (inner flow identifier). An operator may set MTU to account f= or =C2=A0 =C2=A0 encapsulation overhead and reduce the likelihood of fragmenta= tion. GRE/UDP Regarding packet fragmentation, an encapsulator/decapsulator SHOULD =C2=A0 be compliant with [RFC7588] and perform fragmentation before the =C2=A0 encapsulation. However, the above choice seems conflict with the requirements as described= in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02 I wonder whether the IETF should reach a consensus on whether or not the fr= agmentation on UDP encapsulated packets should be allowed. =C2=A0=20 Best regards, Xiaohu > -----Original Message----- > From: Xuxiaohu > Sent: Thursday, May 26, 2016 4:35 PM > To: 'Joe Touch'; Fred Baker (fred); Wassim Haddad > Cc: int-area@ietf.org > Subject: RE: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-0= 3 >=20 >=20 >=20 > > -----Original Message----- > > From: Joe Touch [mailto:touch@isi.edu] > > Sent: Thursday, May 26, 2016 2:11 AM > > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad > > Cc: int-area@ietf.org > > Subject: Re: [Int-area] Call for adoption of > > draft-xu-intarea-ip-in-udp-03 > > > > > > > > On 5/24/2016 7:24 PM, Xuxiaohu wrote: > > > Hi Joe, > > > > > > I wonder whether you want to tell me the following truth by the > > > example that you gave: no matter whatever improvements we had done > > > with this draft, those persons who dislike it by the light of nature > > > would dislike it in the end. > > > > The only improvements that would make this doc useful would be to add > > capabilities already in GRE/UDP or GUE/UDP, which we already have. >=20 > Let's go over the four things you mentioned earlier in GRE/UDP and GUE/UD= P: >=20 > =C2=A0=C2=A0=C2=A0 - stronger checksums >=20 > In GRE/UDP, in order to use UDP-zero-checksum, it gave the following > restrictions: > " 6. UDP Checksum Handling >=20 >=C2=A0 =C2=A0 6.1. UDP Checksum with IPv4 >=20 >=C2=A0 =C2=A0 For UDP in IPv4, the UDP checksum MUST be processed as speci= fied in >=C2=A0 =C2=A0 [RFC768] and [RFC1122] for both transmit and receive. The IP= v4 >=20 >=20 >=20 > Yong, Crabber, Xu, Herbert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [Page 12] > -------------------------------------------------------------------------= ------- >=20 > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GRE-in-UDP Encapsulation= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2016 >=20 >=C2=A0 =C2=A0 header includes a checksum which protects against mis-delive= ry of >=C2=A0 =C2=A0 the packet due to corruption of IP addresses. The UDP checks= um >=C2=A0 =C2=A0 potentially provides protection against corruption of the UD= P header, >=C2=A0 =C2=A0 GRE header, and GRE payload. Disabling the use of checksums = is a >=C2=A0 =C2=A0 deployment consideration that should take into account the r= isk and >=C2=A0 =C2=A0 effects of packet corruption. >=20 >=C2=A0 =C2=A0 When a decapsulator receives a packet, the UDP checksum fiel= d MUST >=C2=A0 =C2=A0 be processed. If the UDP checksum is non-zero, the decapsula= tor MUST >=C2=A0 =C2=A0 verify the checksum before accepting the packet. By default = a >=C2=A0 =C2=A0 decapsulator SHOULD accept UDP packets with a zero checksum.= A node >=C2=A0 =C2=A0 MAY be configured to disallow zero checksums per [RFC1122]; = this may >=C2=A0 =C2=A0 be done selectively, for instance disallowing zero checksums= from >=C2=A0 =C2=A0 certain hosts that are known to be sending over paths subjec= t to >=C2=A0 =C2=A0 packet corruption. If verification of a non-zero checksum fa= ils, a >=C2=A0 =C2=A0 decapsulator lacks the capability to verify a non-zero check= sum, or >=C2=A0 =C2=A0 a packet with a zero-checksum was received and the decapsula= tor is >=C2=A0 =C2=A0 configured to disallow, the packet MUST be dropped and an ev= ent MAY >=C2=A0 =C2=A0 be logged. >=20 >=C2=A0 =C2=A0 6.2. UDP Checksum with IPv6 >=20 >=C2=A0 =C2=A0 For UDP in IPv6, the UDP checksum MUST be processed as speci= fied in >=C2=A0 =C2=A0 [RFC768] and [RFC2460] for both transmit and receive. >=20 >=C2=A0 =C2=A0 When UDP is used over IPv6, the UDP checksum is relied upon = to >=C2=A0 =C2=A0 protect both the IPv6 and UDP headers from corruption. As su= ch, A >=C2=A0 =C2=A0 default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE = GRE-in- >=C2=A0 =C2=A0 UDP Tunnel MAY be configured with the UDP zero-checksum mode= if the >=C2=A0 =C2=A0 traffic-managed controlled environment or a set of closely >=C2=A0 =C2=A0 cooperating traffic-managed controlled environments (such as= by >=C2=A0 =C2=A0 network operators who have agreed to work together in order = to >=C2=A0 =C2=A0 jointly provide specific services) meet at least one of foll= owing >=C2=A0 =C2=A0 conditions: >=20 >=C2=A0 =C2=A0 a. It is known (perhaps through knowledge of equipment types= and >=C2=A0 =C2=A0 =C2=A0 lower layer checks) that packet corruption is excepti= onally >=C2=A0 =C2=A0 =C2=A0 unlikely and where the operator is willing to take th= e risk of >=C2=A0 =C2=A0 =C2=A0 undetected packet corruption. >=20 >=C2=A0 =C2=A0 b. It is judged through observational measurements (perhaps = of >=C2=A0 =C2=A0 =C2=A0 historic or current traffic flows that use a non-zero= checksum) >=C2=A0 =C2=A0 =C2=A0 that the level of packet corruption is tolerably low = and where >=C2=A0 =C2=A0 =C2=A0 the operator is willing to take the risk of undetecte= d packet >=C2=A0 =C2=A0 =C2=A0 corruption. >=20 >=20 >=20 >=20 >=20 > Yong, Crabber, Xu, Herbert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [Page 13] > -------------------------------------------------------------------------= ------- >=20 > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GRE-in-UDP Encapsulation= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2016 >=20 >=C2=A0 =C2=A0 c. Carrying applications that are tolerant of mis-delivered = or >=C2=A0 =C2=A0 =C2=A0 corrupted packets (perhaps through higher layer check= sum, >=C2=A0 =C2=A0 =C2=A0 validation, and retransmission or transmission redund= ancy) where >=C2=A0 =C2=A0 =C2=A0 the operator is willing to rely on the applications u= sing the >=C2=A0 =C2=A0 =C2=A0 tunnel to survive any corrupt packets. >=20 >=C2=A0 =C2=A0 The following requirements apply to a TMCE GRE-in-UDP tunnel= that >=C2=A0 =C2=A0 use UDP zero-checksum mode: >=20 >=C2=A0 =C2=A0 =C2=A0 a. Use of the UDP checksum with IPv6 MUST be the defa= ult >=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration of all GRE-in-UDP tunnels. >=20 >=C2=A0 =C2=A0 =C2=A0 b. The GRE-in-UDP tunnel implementation MUST comply w= ith all >=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirements specified in Section 4 of [RFC693= 6] and with >=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirement 1 specified in Section 5 of [RFC69= 36]. >=20 >=C2=A0 =C2=A0 =C2=A0 c. The tunnel decapsulator SHOULD only allow the use = of UDP zero- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 checksum mode for IPv6 on a single received UD= P Destination >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Port regardless of the encapsulator. The motiv= ation for this >=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirement is possible corruption of the UDP = Destination Port, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 which may cause packet delivery to the wrong U= DP port. If that >=C2=A0 =C2=A0 =C2=A0 =C2=A0 other UDP port requires the UDP checksum, the = mis-delivered >=C2=A0 =C2=A0 =C2=A0 =C2=A0 packet will be discarded. >=20 >=C2=A0 =C2=A0 =C2=A0 d. It is RECOMMENDED that the UDP zero-checksum mode = for IPv6 is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 only enabled for certain selected source addre= sses. The tunnel >=C2=A0 =C2=A0 =C2=A0 =C2=A0 decapsulator MUST check that the source and de= stination IPv6 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 addresses are valid for the GRE-in-UDP tunnel = on which the >=C2=A0 =C2=A0 =C2=A0 =C2=A0 packet was received if that tunnel uses UDP ze= ro-checksum mode >=C2=A0 =C2=A0 =C2=A0 =C2=A0 and discard any packet for which this check fa= ils. >=20 >=C2=A0 =C2=A0 =C2=A0 e. The tunnel encapsulator SHOULD use different IPv6 = addresses for >=C2=A0 =C2=A0 =C2=A0 =C2=A0 each GRE-in-UDP tunnel that uses UDP zero-chec= ksum mode >=C2=A0 =C2=A0 =C2=A0 =C2=A0 regardless of the decapsulator in order to str= engthen the >=C2=A0 =C2=A0 =C2=A0 =C2=A0 decapsulator's check of the IPv6 source addres= s (i.e., the same >=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 source address SHOULD NOT be used with mo= re than one IPv6 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 destination address, independent of whether th= at destination >=C2=A0 =C2=A0 =C2=A0 =C2=A0 address is a unicast or multicast address). Wh= en this is not >=C2=A0 =C2=A0 =C2=A0 =C2=A0 possible, it is RECOMMENDED to use each source= IPv6 address for >=C2=A0 =C2=A0 =C2=A0 =C2=A0 as few UDP zero-checksum mode GRE-in-UDP tunne= ls as is feasible. >=20 >=C2=A0 =C2=A0 =C2=A0 f. When any middlebox exists on the path of a GRE-in-= UDP tunnel, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 it is RECOMMENDED to use the default mode, i.e= . use UDP >=C2=A0 =C2=A0 =C2=A0 =C2=A0 checksum, to reduce the chance that the encaps= ulated packets to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 be dropped. >=20 >=20 >=20 >=20 >=20 > Yong, Crabber, Xu, Herbert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [Page 14] > -------------------------------------------------------------------------= ------- >=20 > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GRE-in-UDP Encapsulation= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2016 >=20 >=C2=A0 =C2=A0 =C2=A0 g. Any middlebox that allows the UDP zero-checksum mo= de for IPv6 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST comply with requirement 1 and 8-10 in Sec= tion 5 of >=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC6936]. >=20 >=C2=A0 =C2=A0 =C2=A0 h. Measures SHOULD be taken to prevent IPv6 traffic w= ith zero UDP >=C2=A0 =C2=A0 =C2=A0 =C2=A0 checksums from "escaping" to the general Inter= net; see Section >=C2=A0 =C2=A0 =C2=A0 =C2=A0 8 for examples of such measures. >=20 >=C2=A0 =C2=A0 =C2=A0 i. IPv6 traffic with zero UDP checksums MUST be activ= ely monitored >=C2=A0 =C2=A0 =C2=A0 =C2=A0 for errors by the network operator. For exampl= e, the operator >=C2=A0 =C2=A0 =C2=A0 =C2=A0 may monitor Ethernet layer packet error rates. >=20 >=C2=A0 =C2=A0 =C2=A0 j. If a packet with a non-zero checksum is received, = the checksum >=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST be verified before accepting the packet. = This is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 regardless of whether the tunnel encapsulator = and decapsulator >=C2=A0 =C2=A0 =C2=A0 =C2=A0 have been configured with UDP zero-checksum mo= de. >=20 >=C2=A0 =C2=A0 The above requirements do not change either the requirements >=C2=A0 =C2=A0 specified in [RFC2460] as modified by [RFC6935] or the requi= rements >=C2=A0 =C2=A0 specified in [RFC6936]. >=20 >=C2=A0 =C2=A0 The requirement to check the source IPv6 address in addition= to the >=C2=A0 =C2=A0 destination IPv6 address, plus the strong recommendation aga= inst >=C2=A0 =C2=A0 reuse of source IPv6 addresses among GRE-in-UDP tunnels coll= ectively >=C2=A0 =C2=A0 provide some mitigation for the absence of UDP checksum cove= rage of >=C2=A0 =C2=A0 the IPv6 header. A traffic-managed controlled environment th= at >=C2=A0 =C2=A0 satisfies at least one of three conditions listed above in t= his >=C2=A0 =C2=A0 section provides additional assurance. >=20 >=C2=A0 =C2=A0 A GRE-in-UDP tunnel is suitable for transmission over lower = layers >=C2=A0 =C2=A0 in the traffic-managed controlled environments that are allo= wed by >=C2=A0 =C2=A0 the exceptions stated above and the rate of corruption of th= e inner >=C2=A0 =C2=A0 IP packet on such networks is not expected to increase by co= mparison >=C2=A0 =C2=A0 to GRE traffic that is not encapsulated in UDP.=C2=A0 For th= ese reasons, >=C2=A0 =C2=A0 GRE-in-UDP does not provide an additional integrity check ex= cept >=C2=A0 =C2=A0 when GRE checksum is used when UDP zero-checksum mode is use= d with >=C2=A0 =C2=A0 IPv6, and this design is in accordance with requirements 2, = 3 and 5 >=C2=A0 =C2=A0 specified in Section 5 of [RFC6936]. >=20 >=C2=A0 =C2=A0 Generic Router Encapsulation (GRE) does not accumulate incor= rect >=C2=A0 =C2=A0 state as a consequence of GRE header corruption. A corrupt G= RE >=C2=A0 =C2=A0 packet may result in either packet discard or forwarding of = the >=C2=A0 =C2=A0 packet without accumulation of GRE state. Active monitoring = of GRE- >=C2=A0 =C2=A0 in-UDP traffic for errors is REQUIRED as occurrence of error= s will >=C2=A0 =C2=A0 result in some accumulation of error information outside the >=C2=A0 =C2=A0 protocol for operational and management purposes. This desig= n is in >=C2=A0 =C2=A0 accordance with requirement 4 specified in Section 5 of [RFC= 6936]. >=20 >=20 >=20 > Yong, Crabber, Xu, Herbert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [Page 15] > -------------------------------------------------------------------------= ------- >=20 > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GRE-in-UDP Encapsulation= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 2016 >=20 >=C2=A0 =C2=A0 The remaining requirements specified in Section 5 of [RFC693= 6] are >=C2=A0 =C2=A0 not applicable to GRE-in-UDP.=C2=A0 Requirements 6 and 7 do = not apply >=C2=A0 =C2=A0 because GRE does not include a control feedback mechanism. >=C2=A0 =C2=A0 Requirements 8-10 are middlebox requirements that do not app= ly to >=C2=A0 =C2=A0 GRE-in-UDP tunnel endpoints (see Section 7.1 for further mid= dlebox >=C2=A0 =C2=A0 discussion). >=20 >=C2=A0 =C2=A0 It is worth mentioning that the use of a zero UDP checksum s= hould >=C2=A0 =C2=A0 present the equivalent risk of undetected packet corruption = when >=C2=A0 =C2=A0 sending similar packet using GRE-in-IPv6 without UDP [RFC767= 6] and >=C2=A0 =C2=A0 without GRE checksums. >=20 >=C2=A0 =C2=A0 In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-z= ero- >=C2=A0 =C2=A0 checksum mode for IPv6 when the conditions and requirements = stated >=C2=A0 =C2=A0 above are met. Otherwise the UDP checksum need to be used fo= r IPv6 >=C2=A0 =C2=A0 as specified in [RFC768] and [RFC2460]. Use of GRE checksum = is >=C2=A0 =C2=A0 RECOMMENED when the UDP checksum is not used. > " >=20 > In GUE, to support UDP-checksum-zero, it said >=20 > " Therefore, when GUE is used over >=C2=A0 =C2=A0 IPv6, either the UDP checksum must be enabled or the GUE hea= der >=C2=A0 =C2=A0 checksum must be used.=C2=A0 An encapsulator MAY set a zero = UDP checksum >=C2=A0 =C2=A0 for performance or implementation reasons, in which case the= GUE >=C2=A0 =C2=A0 header checksum MUST be used or applicable requirements for = using >=C2=A0 =C2=A0 zero UDP checksums in [GREUDP] MUST be met. If the UDP check= sum is >=C2=A0 =C2=A0 enabled, then the GUE header checksum should not be used sin= ce it is >=C2=A0 =C2=A0 mostly redundant." >=20 > It's easy for me to add the similar words to the IP-in-UDP draft like "th= e > applicable requirements for using zero UDP checksum in [GREUDP] MUST be > met when zero UDP checksum is used by the tunnel ingress". However, the > major goal for disabling the UDP checksum is to improve the performance. > When GUE header checksum is used and/or the bunch of applicable > requirements as described in GRE/UDP are verified, is the goal of improvi= ng > performance still achievable? If not, why not directly enable the UDP-che= cksum > instead? >=20 > =C2=A0=C2=A0=C2=A0 - fragmentation support >=20 > In GRE/UDP, it said >=20 > " 4.1. MTU and Fragmentation >=20 >=C2=A0 =C2=A0 Regarding packet fragmentation, an encapsulator/decapsulator= SHOULD >=C2=A0 =C2=A0 be compliant with [RFC7588] and perform fragmentation before= the >=C2=A0 =C2=A0 encapsulation. The size of fragments SHOULD be less or equal= to the >=C2=A0 =C2=A0 PMTU associated with the path between the GRE ingress and th= e GRE >=C2=A0 =C2=A0 egress tunnel endpoints minus the GRE and UDP overhead ..." >=20 > in GUE, it said >=20 > " 4.9. MTU and fragmentation >=20 >=C2=A0 =C2=A0 Standard conventions for handling of MTU (Maximum Transmissi= on Unit) >=C2=A0 =C2=A0 and fragmentation in conjunction with networking tunnels >=C2=A0 =C2=A0 (encapsulation of layer 2 or layer 3 packets) should be foll= owed. >=C2=A0 =C2=A0 Details are described in MTU and Fragmentation Issues with I= n-the- >=C2=A0 =C2=A0 Network Tunneling [RFC4459]... " >=20 > It seems that the only missing thing in the IP-in-UDP draft is to allow t= he outer > fragmentation. However, as it said in > (https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02#page-13), " ..= .IPsec > performs only Outer Fragmentation; this distinguishes it from IP-in-IP, w= hich > performs only Inner Fragmentation. " Note that IP-in-IP is the dominant > encapsulation choice within Softwires networks. In other words, performin= g > only inner fragmentation works very well in practice. Furthermore, the ou= ter > fragmentation issue (e.g., reassembly cost for the egress) would become e= ven > worse since the fragments of X-in-UDP packets are more likely to be forwa= rded > across different paths than those of X-in-IP and X-in-GRE packets. Hence,= I'm > wondering whether it's worthwhile to support the outer fragmentation on U= DP > encapsulated packets which seems useless in practice. >=20 > =C2=A0=C2=A0=C2=A0 - signalling support (e.g., to test whether a tunnel i= s up or > =C2=A0=C2=A0=C2=A0 to measure MTUs) >=20 > I haven't found any description of this in both GRE/UDP and GUE. Did you? >=20 > =C2=A0=C2=A0=C2=A0 - support for robust ID fields (related to fragmentati= on, > =C2=A0=C2=A0=C2=A0 e.g., to overcome the limits of IPv4 ID as per RFC 686= 4) >=20 > I haven't found any description of this in both GRE/UDP and GUE. Did you? >=20 > Xiaohu >=20 > > It is not our obligation to find a way for your document to proceed - > > that onus is on you. > > > > Joe =20 ------=_Part_2492240_1136524516.1465708308517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fragmentation should be strongly discouraged.

if you've designed a tunnelling solution and you have fragmentation h= appening as a matter of course, you've designed it wrong. 

Lloy= d Wood
lloyd.wood@yahoo.co.uk

On Friday, May 27, 2016, 8:10 PM, Xuxiaohu <xuxiaohu@huawei.com> wro= te:

<Note that I have changed the subject = of the email hence it has nothing to do with the WG adoption call now. It's= just a discussion on a particular issue which is related to those WGs whic= h are working on UDP tunnels. The reason for containing the old email is to= use it as a background which may be useful for better understanding of thi= s particular issue>

The possible side-effect of performing fragme= ntation on UDP encapsulated packets is to worsen the reassembly burden on t= unnel egress since fragments of UDP encapsulated packets are more likely to= be forwarded across different paths towards the tunnel egress than those o= f IP or GRE encapsulated packets.

It seems that most X-over-UDP prop= osals choose to prohibit the tunnel ingress from performing fragmentation o= n UDP encapsulated packets. See the following quoted text regarding fragmen= tation from those X-over-UDP drafts:

LISP:

When an ITR receiv= es a packet from a site-facing interface and adds H
  octets worth= of encapsulation to yield a packet size greater than L
  octets, = it resolves the MTU issue by first splitting the original
  packet= into 2 equal-sized fragments.  A LISP header is then prepended
&nb= sp; to each fragment.

VXLAN:

VTEPs MUST NOT fragment VXLAN p= ackets.  Intermediate routers may
  fragment encapsulated VXL= AN packets due to the larger frame size.
  The destination VTEP MA= Y silently discard such VXLAN fragments.

VXLAN-GPE:

VTEPs MUS= T never fragment an encapsulated VXLAN GPE packet, and when
  the = outer IP header is IPv4, VTEPs MUST set the DF bit in the outer
  = IPv4 header.

GEVENE:

  To prevent fragmentation and max= imize performance, the best practice
  when using Geneve is to ens= ure that the MTU of the physical network
  is greater than or equa= l to the MTU of the encapsulated network plus
  tunnel headers.
GUE:

    If a packet is fragmented before encapsulati= on in GUE, all the
    related fragments must be encapsulated = using the same source port
    (inner flow identifier). An ope= rator may set MTU to account for
    encapsulation overhead an= d reduce the likelihood of fragmentation.

GRE/UDP

Regarding p= acket fragmentation, an encapsulator/decapsulator SHOULD
  be comp= liant with [RFC7588] and perform fragmentation before the
  encaps= ulation.

However, the above choice seems conflict with the requireme= nts as described in https://tools.ietf.org/html/draft-ietf-int= area-tunnels-02


I wonder whether the IETF should reach a con= sensus on whether or not the fragmentation on UDP encapsulated packets shou= ld be allowed.
 
Best regards,
Xiaohu

> -----Origi= nal Message-----
> From: Xuxiaohu
> Sent: Thursday, May 26, 201= 6 4:35 PM
> To: 'Joe Touch'; Fred Baker (fred); Wassim Haddad
>= Cc: int= -area@ietf.org
> Subject: RE: [Int-area] Call for adoption of dra= ft-xu-intarea-ip-in-udp-03
>
>
>
> > -----Ori= ginal Message-----
> > From: Joe Touch [mailto:touch@isi.edu]
> >= Sent: Thursday, May 26, 2016 2:11 AM
> > To: Xuxiaohu; Fred Baker= (fred); Wassim Haddad
> > Cc: int-area@ietf.org
> > Subject:= Re: [Int-area] Call for adoption of
> > draft-xu-intarea-ip-in-ud= p-03
> >
> >
> >
> > On 5/24/2016 7:24 = PM, Xuxiaohu wrote:
> > > Hi Joe,
> > >
> >= ; > I wonder whether you want to tell me the following truth by the
&= gt; > > example that you gave: no matter whatever improvements we had= done
> > > with this draft, those persons who dislike it by th= e light of nature
> > > would dislike it in the end.
> &g= t;
> > The only improvements that would make this doc useful would= be to add
> > capabilities already in GRE/UDP or GUE/UDP, which w= e already have.
>
> Let's go over the four things you mentione= d earlier in GRE/UDP and GUE/UDP:
>
>     - str= onger checksums
>
> In GRE/UDP, in order to use UDP-zero-check= sum, it gave the following
> restrictions:
> " 6. UDP Checksum = Handling
>
>    6.1. UDP Checksum with IPv4
> =
>    For UDP in IPv4, the UDP checksum MUST be processed a= s specified in
>    [RFC768] and [RFC1122] for both transmi= t and receive. The IPv4
>
>
>
> Yong, Crabber, X= u, Herbert                  &n= bsp;                 [Page 12]
&= gt; -----------------------------------------------------------------------= ---------
>
> Internet-Draft         = GRE-in-UDP Encapsulation            March 2= 016
>
>    header includes a checksum which protects= against mis-delivery of
>    the packet due to corruption = of IP addresses. The UDP checksum
>    potentially provides= protection against corruption of the UDP header,
>    GRE = header, and GRE payload. Disabling the use of checksums is a
>  =   deployment consideration that should take into account the risk and<= br>>    effects of packet corruption.
>
>  &= nbsp; When a decapsulator receives a packet, the UDP checksum field MUST>    be processed. If the UDP checksum is non-zero, the decap= sulator MUST
>    verify the checksum before accepting the = packet. By default a
>    decapsulator SHOULD accept UDP pa= ckets with a zero checksum. A node
>    MAY be configured t= o disallow zero checksums per [RFC1122]; this may
>    be d= one selectively, for instance disallowing zero checksums from
> =   certain hosts that are known to be sending over paths subject to>    packet corruption. If verification of a non-zero checksu= m fails, a
>    decapsulator lacks the capability to verify= a non-zero checksum, or
>    a packet with a zero-checksum= was received and the decapsulator is
>    configured to di= sallow, the packet MUST be dropped and an event MAY
>    be= logged.
>
>    6.2. UDP Checksum with IPv6
> =
>    For UDP in IPv6, the UDP checksum MUST be processed a= s specified in
>    [RFC768] and [RFC2460] for both transmi= t and receive.
>
>    When UDP is used over IPv6, th= e UDP checksum is relied upon to
>    protect both the IPv6= and UDP headers from corruption. As such, A
>    default G= RE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in-
>  &n= bsp; UDP Tunnel MAY be configured with the UDP zero-checksum mode if the>    traffic-managed controlled environment or a set of close= ly
>    cooperating traffic-managed controlled environments= (such as by
>    network operators who have agreed to work= together in order to
>    jointly provide specific service= s) meet at least one of following
>    conditions:
> =
>    a. It is known (perhaps through knowledge of equipmen= t types and
>      lower layer checks) that packet co= rruption is exceptionally
>      unlikely and where t= he operator is willing to take the risk of
>      und= etected packet corruption.
>
>    b. It is judged th= rough observational measurements (perhaps of
>      h= istoric or current traffic flows that use a non-zero checksum)
> = ;     that the level of packet corruption is tolerably low and w= here
>      the operator is willing to take the risk = of undetected packet
>      corruption.
>
&= gt;
>
>
>
> Yong, Crabber, Xu, Herbert  &n= bsp;                     =             [Page 13]
> ---------------= -----------------------------------------------------------------
> <= br>> Internet-Draft          GRE-in-UDP Encapsu= lation            March 2016
>
>= ;    c. Carrying applications that are tolerant of mis-delivered = or
>      corrupted packets (perhaps through higher l= ayer checksum,
>      validation, and retransmission = or transmission redundancy) where
>      the operator= is willing to rely on the applications using the
>    &nbs= p; tunnel to survive any corrupt packets.
>
>    Th= e following requirements apply to a TMCE GRE-in-UDP tunnel that
>&nbs= p;   use UDP zero-checksum mode:
>
>      = a. Use of the UDP checksum with IPv6 MUST be the default
>  &nbs= p;     configuration of all GRE-in-UDP tunnels.
>
>=       b. The GRE-in-UDP tunnel implementation MUST comply wi= th all
>        requirements specified in Sectio= n 4 of [RFC6936] and with
>        requirement 1= specified in Section 5 of [RFC6936].
>
>      = c. The tunnel decapsulator SHOULD only allow the use of UDP zero-
>&n= bsp;       checksum mode for IPv6 on a single received UDP = Destination
>        Port regardless of the enca= psulator. The motivation for this
>        requi= rement is possible corruption of the UDP Destination Port,
>  &n= bsp;     which may cause packet delivery to the wrong UDP port. = If that
>        other UDP port requires the UDP= checksum, the mis-delivered
>        packet wil= l be discarded.
>
>      d. It is RECOMMENDED t= hat the UDP zero-checksum mode for IPv6 is
>      &nbs= p; only enabled for certain selected source addresses. The tunnel
>&= nbsp;       decapsulator MUST check that the source and des= tination IPv6
>        addresses are valid for t= he GRE-in-UDP tunnel on which the
>        packe= t was received if that tunnel uses UDP zero-checksum mode
>  &nb= sp;     and discard any packet for which this check fails.
&g= t;
>      e. The tunnel encapsulator SHOULD use diffe= rent IPv6 addresses for
>        each GRE-in-UDP= tunnel that uses UDP zero-checksum mode
>       = regardless of the decapsulator in order to strengthen the
>  &= nbsp;     decapsulator's check of the IPv6 source address (i.e.,= the same
>        IPv6 source address SHOULD NO= T be used with more than one IPv6
>        desti= nation address, independent of whether that destination
>   = ;     address is a unicast or multicast address). When this is n= ot
>        possible, it is RECOMMENDED to use e= ach source IPv6 address for
>        as few UDP = zero-checksum mode GRE-in-UDP tunnels as is feasible.
>
> = ;     f. When any middlebox exists on the path of a GRE-in-UDP tu= nnel,
>        it is RECOMMENDED to use the defa= ult mode, i.e. use UDP
>        checksum, to red= uce the chance that the encapsulated packets to
>     =   be dropped.
>
>
>
>
>
> Y= ong, Crabber, Xu, Herbert              &= nbsp;                    = [Page 14]
> --------------------------------------------------------= ------------------------
>
> Internet-Draft     = ;     GRE-in-UDP Encapsulation          =   March 2016
>
>      g. Any middlebox th= at allows the UDP zero-checksum mode for IPv6
>      &= nbsp; MUST comply with requirement 1 and 8-10 in Section 5 of
> = ;       [RFC6936].
>
>      h. = Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
> = ;       checksums from "escaping" to the general Internet; = see Section
>        8 for examples of such meas= ures.
>
>      i. IPv6 traffic with zero UDP ch= ecksums MUST be actively monitored
>        for = errors by the network operator. For example, the operator
>  &nb= sp;     may monitor Ethernet layer packet error rates.
> <= br>>      j. If a packet with a non-zero checksum is rece= ived, the checksum
>        MUST be verified bef= ore accepting the packet. This is
>        regar= dless of whether the tunnel encapsulator and decapsulator
>  &nb= sp;     have been configured with UDP zero-checksum mode.
>= ;
>    The above requirements do not change either the req= uirements
>    specified in [RFC2460] as modified by [RFC69= 35] or the requirements
>    specified in [RFC6936].
>= ;
>    The requirement to check the source IPv6 address in= addition to the
>    destination IPv6 address, plus the st= rong recommendation against
>    reuse of source IPv6 addre= sses among GRE-in-UDP tunnels collectively
>    provide som= e mitigation for the absence of UDP checksum coverage of
>  &nbs= p; the IPv6 header. A traffic-managed controlled environment that
>&n= bsp;   satisfies at least one of three conditions listed above in this=
>    section provides additional assurance.
>
&g= t;    A GRE-in-UDP tunnel is suitable for transmission over lower= layers
>    in the traffic-managed controlled environments= that are allowed by
>    the exceptions stated above and t= he rate of corruption of the inner
>    IP packet on such n= etworks is not expected to increase by comparison
>    to G= RE traffic that is not encapsulated in UDP.  For these reasons,
>= ;    GRE-in-UDP does not provide an additional integrity check ex= cept
>    when GRE checksum is used when UDP zero-checksum = mode is used with
>    IPv6, and this design is in accordan= ce with requirements 2, 3 and 5
>    specified in Section 5= of [RFC6936].
>
>    Generic Router Encapsulation (= GRE) does not accumulate incorrect
>    state as a conseque= nce of GRE header corruption. A corrupt GRE
>    packet may= result in either packet discard or forwarding of the
>    = packet without accumulation of GRE state. Active monitoring of GRE-
>=     in-UDP traffic for errors is REQUIRED as occurrence of errors= will
>    result in some accumulation of error information= outside the
>    protocol for operational and management p= urposes. This design is in
>    accordance with requirement= 4 specified in Section 5 of [RFC6936].
>
>
>
> = Yong, Crabber, Xu, Herbert              =                      = ; [Page 15]
> -------------------------------------------------------= -------------------------
>
> Internet-Draft    &nbs= p;     GRE-in-UDP Encapsulation         =   March 2016
>
>    The remaining requirement= s specified in Section 5 of [RFC6936] are
>    not applicab= le to GRE-in-UDP.  Requirements 6 and 7 do not apply
>  &nb= sp; because GRE does not include a control feedback mechanism.
> = ;   Requirements 8-10 are middlebox requirements that do not apply to<= br>>    GRE-in-UDP tunnel endpoints (see Section 7.1 for furth= er middlebox
>    discussion).
>
>   = ; It is worth mentioning that the use of a zero UDP checksum should
>=     present the equivalent risk of undetected packet corruption w= hen
>    sending similar packet using GRE-in-IPv6 without U= DP [RFC7676] and
>    without GRE checksums.
>
&g= t;    In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-= zero-
>    checksum mode for IPv6 when the conditions and r= equirements stated
>    above are met. Otherwise the UDP ch= ecksum need to be used for IPv6
>    as specified in [RFC76= 8] and [RFC2460]. Use of GRE checksum is
>    RECOMMENED wh= en the UDP checksum is not used.
> "
>
> In GUE, to supp= ort UDP-checksum-zero, it said
>
> " Therefore, when GUE is us= ed over
>    IPv6, either the UDP checksum must be enabled= or the GUE header
>    checksum must be used.  An en= capsulator MAY set a zero UDP checksum
>    for performanc= e or implementation reasons, in which case the GUE
>    he= ader checksum MUST be used or applicable requirements for using
>&nbs= p;   zero UDP checksums in [GREUDP] MUST be met. If the UDP checksum = is
>    enabled, then the GUE header checksum should not b= e used since it is
>    mostly redundant."
>
>= ; It's easy for me to add the similar words to the IP-in-UDP draft like "th= e
> applicable requirements for using zero UDP checksum in [GREUDP] M= UST be
> met when zero UDP checksum is used by the tunnel ingress". H= owever, the
> major goal for disabling the UDP checksum is to improve= the performance.
> When GUE header checksum is used and/or the bunch= of applicable
> requirements as described in GRE/UDP are verified, i= s the goal of improving
> performance still achievable? If not, why n= ot directly enable the UDP-checksum
> instead?
>
>  = ;   - fragmentation support
>
> In GRE/UDP, it said<= br>>
> " 4.1. MTU and Fragmentation
>
>   = Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
>= ;    be compliant with [RFC7588] and perform fragmentation before= the
>    encapsulation. The size of fragments SHOULD be le= ss or equal to the
>    PMTU associated with the path betwe= en the GRE ingress and the GRE
>    egress tunnel endpoints= minus the GRE and UDP overhead ..."
>
> in GUE, it said
&g= t;
> " 4.9. MTU and fragmentation
>
>    Sta= ndard conventions for handling of MTU (Maximum Transmission Unit)
>&n= bsp;   and fragmentation in conjunction with networking tunnels
&g= t;    (encapsulation of layer 2 or layer 3 packets) should be fo= llowed.
>    Details are described in MTU and Fragmentatio= n Issues with In-the-
>    Network Tunneling [RFC4459]... = "
>
> It seems that the only missing thing in the IP-in-UDP dr= aft is to allow the outer
> fragmentation. However, as it said in
= > (https://tools.ietf.org/html/draft-ietf-intarea-t= unnels-02#page-13), " ...IPsec
> performs only Outer Fragmentatio= n; this distinguishes it from IP-in-IP, which
> performs only Inner F= ragmentation. " Note that IP-in-IP is the dominant
> encapsulation ch= oice within Softwires networks. In other words, performing
> only inn= er fragmentation works very well in practice. Furthermore, the outer
>= ; fragmentation issue (e.g., reassembly cost for the egress) would become e= ven
> worse since the fragments of X-in-UDP packets are more likely t= o be forwarded
> across different paths than those of X-in-IP and X-i= n-GRE packets. Hence, I'm
> wondering whether it's worthwhile to supp= ort the outer fragmentation on UDP
> encapsulated packets which seems= useless in practice.
>
>     - signalling supp= ort (e.g., to test whether a tunnel is up or
>     to = measure MTUs)
>
> I haven't found any description of this in b= oth GRE/UDP and GUE. Did you?
>
>     - support= for robust ID fields (related to fragmentation,
>    = e.g., to overcome the limits of IPv4 ID as per RFC 6864)
>
> = I haven't found any description of this in both GRE/UDP and GUE. Did you?>
> Xiaohu
>
> > It is not our obligation to fi= nd a way for your document to proceed -
> > that onus is on you.> >
> > Joe
------=_Part_2492240_1136524516.1465708308517-- From nobody Sat Jun 11 23:26:03 2016 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 A822A128E19; Sat, 11 Jun 2016 23:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ymAnrPgA0aM5; Sat, 11 Jun 2016 23:25:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CF812B032; Sat, 11 Jun 2016 23:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45990; q=dns/txt; s=iport; t=1465712751; x=1466922351; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=di5l6+f5gqYQnykPUrLFrCOeeS4V5drp4Rpky/CeWbE=; b=Nt032ABlguuXJ+iCqgw6OZcGxbbfgfaViDfqDPki4h7zo99tBKjFhlmV lM8aKpQZj1JTZEH4mV2kirgwPhlAt+smLbvSv2RbhDWYuEf802zUNBKdr 8GsPeEmWujQVRK0dYiWzHvVTqZfGvqSRjZMI7v0noknJeGwJmI+Of20j2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgDh/lxX/4QNJK1dgnBOVn0Grx2MA?= =?us-ascii?q?IF5IoV1AoEhOBQBAQEBAQEBZSeESgEBAQMBGgECEFEHBAIBCBEDAQEBARULAQY?= =?us-ascii?q?HMhQJCAIEARIbh3sDDwgOvSgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXAQQLhhyDS?= =?us-ascii?q?oEDgkOBTxEBIwcSGAeFHAWGRQyBO5AhNAGGA4J4gziBdI8giAGHbAEeNoIHHBa?= =?us-ascii?q?BNW6IRg0XBxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,460,1459814400"; d="scan'208,217";a="283770831" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jun 2016 06:25:48 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5C6PmSk000872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2016 06:25:48 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 12 Jun 2016 01:25:47 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Sun, 12 Jun 2016 01:25:47 -0500 From: "Saumya Dikshit (sadikshi)" To: Lloyd Wood , Softwires WG , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" , Xuxiaohu , "nvo3@ietf.org" Thread-Topic: [nvo3] [tsvwg] Is it feasible to perform fragmentation on UDP encapsulated packets. Thread-Index: AQHRxHNBx0FCT/ugokeOCF2M3CVw6A== Date: Sun, 12 Jun 2016 06:25:47 +0000 Message-ID: References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <974977917.2492241.1465708308527.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <974977917.2492241.1465708308527.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.85.139] Content-Type: multipart/alternative; boundary="_000_D382FCD56783Csadikshiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] [nvo3] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 06:25:55 -0000 --_000_D382FCD56783Csadikshiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In case of typical datacenter brownfield deployments, the underlay and overlay may be completely disconnected operationally, hence there can be cases where the mtu mismatch in underlay network may not be notified to overlay endpoints and subsequently to end hosts. From: Lloyd Wood > Date: Sunday, June 12, 2016 at 10:41 AM To: Softwires WG >, "int-area= @ietf.org" >, "lisp@ietf.org" >, "tsvwg@ietf.org" >, Xuxiaohu >= , "nvo3@ietf.org" > Subject: Re: [nvo3] [tsvwg] Is it feasible to perform fragmentation on UDP = encapsulated packets. Fragmentation should be strongly discouraged. if you've designed a tunnelling solution and you have fragmentation happeni= ng as a matter of course, you've designed it wrong. Lloyd Wood lloyd.wood@yahoo.co.uk On Friday, May 27, 2016, 8:10 PM, Xuxiaohu > wrote: The possible side-effect of performing fragmentation on UDP encapsulated pa= ckets is to worsen the reassembly burden on tunnel egress since fragments o= f UDP encapsulated packets are more likely to be forwarded across different= paths towards the tunnel egress than those of IP or GRE encapsulated packe= ts. It seems that most X-over-UDP proposals choose to prohibit the tunnel ingre= ss from performing fragmentation on UDP encapsulated packets. See the follo= wing quoted text regarding fragmentation from those X-over-UDP drafts: LISP: When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. VXLAN: VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may fragment encapsulated VXLAN packets due to the larger frame size. The destination VTEP MAY silently discard such VXLAN fragments. VXLAN-GPE: VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer IPv4 header. GEVENE: To prevent fragmentation and maximize performance, the best practice when using Geneve is to ensure that the MTU of the physical network is greater than or equal to the MTU of the encapsulated network plus tunnel headers. GUE: If a packet is fragmented before encapsulation in GUE, all the related fragments must be encapsulated using the same source port (inner flow identifier). An operator may set MTU to account for encapsulation overhead and reduce the likelihood of fragmentation. GRE/UDP Regarding packet fragmentation, an encapsulator/decapsulator SHOULD be compliant with [RFC7588] and perform fragmentation before the encapsulation. However, the above choice seems conflict with the requirements as described= in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02 I wonder whether the IETF should reach a consensus on whether or not the fr= agmentation on UDP encapsulated packets should be allowed. Best regards, Xiaohu > -----Original Message----- > From: Xuxiaohu > Sent: Thursday, May 26, 2016 4:35 PM > To: 'Joe Touch'; Fred Baker (fred); Wassim Haddad > Cc: int-area@ietf.org > Subject: RE: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-0= 3 > > > > > -----Original Message----- > > From: Joe Touch [mailto:touch@isi.edu] > > Sent: Thursday, May 26, 2016 2:11 AM > > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad > > Cc: int-area@ietf.org > > Subject: Re: [Int-area] Call for adoption of > > draft-xu-intarea-ip-in-udp-03 > > > > > > > > On 5/24/2016 7:24 PM, Xuxiaohu wrote: > > > Hi Joe, > > > > > > I wonder whether you want to tell me the following truth by the > > > example that you gave: no matter whatever improvements we had done > > > with this draft, those persons who dislike it by the light of nature > > > would dislike it in the end. > > > > The only improvements that would make this doc useful would be to add > > capabilities already in GRE/UDP or GUE/UDP, which we already have. > > Let's go over the four things you mentioned earlier in GRE/UDP and GUE/UD= P: > > - stronger checksums > > In GRE/UDP, in order to use UDP-zero-checksum, it gave the following > restrictions: > " 6. UDP Checksum Handling > > 6.1. UDP Checksum with IPv4 > > For UDP in IPv4, the UDP checksum MUST be processed as specified in > [RFC768] and [RFC1122] for both transmit and receive. The IPv4 > > > > Yong, Crabber, Xu, Herbert [Page 12] > -------------------------------------------------------------------------= ------- > > Internet-Draft GRE-in-UDP Encapsulation March 2016 > > header includes a checksum which protects against mis-delivery of > the packet due to corruption of IP addresses. The UDP checksum > potentially provides protection against corruption of the UDP header, > GRE header, and GRE payload. Disabling the use of checksums is a > deployment consideration that should take into account the risk and > effects of packet corruption. > > When a decapsulator receives a packet, the UDP checksum field MUST > be processed. If the UDP checksum is non-zero, the decapsulator MUST > verify the checksum before accepting the packet. By default a > decapsulator SHOULD accept UDP packets with a zero checksum. A node > MAY be configured to disallow zero checksums per [RFC1122]; this may > be done selectively, for instance disallowing zero checksums from > certain hosts that are known to be sending over paths subject to > packet corruption. If verification of a non-zero checksum fails, a > decapsulator lacks the capability to verify a non-zero checksum, or > a packet with a zero-checksum was received and the decapsulator is > configured to disallow, the packet MUST be dropped and an event MAY > be logged. > > 6.2. UDP Checksum with IPv6 > > For UDP in IPv6, the UDP checksum MUST be processed as specified in > [RFC768] and [RFC2460] for both transmit and receive. > > When UDP is used over IPv6, the UDP checksum is relied upon to > protect both the IPv6 and UDP headers from corruption. As such, A > default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in- > UDP Tunnel MAY be configured with the UDP zero-checksum mode if the > traffic-managed controlled environment or a set of closely > cooperating traffic-managed controlled environments (such as by > network operators who have agreed to work together in order to > jointly provide specific services) meet at least one of following > conditions: > > a. It is known (perhaps through knowledge of equipment types and > lower layer checks) that packet corruption is exceptionally > unlikely and where the operator is willing to take the risk of > undetected packet corruption. > > b. It is judged through observational measurements (perhaps of > historic or current traffic flows that use a non-zero checksum) > that the level of packet corruption is tolerably low and where > the operator is willing to take the risk of undetected packet > corruption. > > > > > > Yong, Crabber, Xu, Herbert [Page 13] > -------------------------------------------------------------------------= ------- > > Internet-Draft GRE-in-UDP Encapsulation March 2016 > > c. Carrying applications that are tolerant of mis-delivered or > corrupted packets (perhaps through higher layer checksum, > validation, and retransmission or transmission redundancy) where > the operator is willing to rely on the applications using the > tunnel to survive any corrupt packets. > > The following requirements apply to a TMCE GRE-in-UDP tunnel that > use UDP zero-checksum mode: > > a. Use of the UDP checksum with IPv6 MUST be the default > configuration of all GRE-in-UDP tunnels. > > b. The GRE-in-UDP tunnel implementation MUST comply with all > requirements specified in Section 4 of [RFC6936] and with > requirement 1 specified in Section 5 of [RFC6936]. > > c. The tunnel decapsulator SHOULD only allow the use of UDP zero- > checksum mode for IPv6 on a single received UDP Destination > Port regardless of the encapsulator. The motivation for this > requirement is possible corruption of the UDP Destination Port, > which may cause packet delivery to the wrong UDP port. If that > other UDP port requires the UDP checksum, the mis-delivered > packet will be discarded. > > d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is > only enabled for certain selected source addresses. The tunnel > decapsulator MUST check that the source and destination IPv6 > addresses are valid for the GRE-in-UDP tunnel on which the > packet was received if that tunnel uses UDP zero-checksum mode > and discard any packet for which this check fails. > > e. The tunnel encapsulator SHOULD use different IPv6 addresses for > each GRE-in-UDP tunnel that uses UDP zero-checksum mode > regardless of the decapsulator in order to strengthen the > decapsulator's check of the IPv6 source address (i.e., the same > IPv6 source address SHOULD NOT be used with more than one IPv6 > destination address, independent of whether that destination > address is a unicast or multicast address). When this is not > possible, it is RECOMMENDED to use each source IPv6 address for > as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. > > f. When any middlebox exists on the path of a GRE-in-UDP tunnel, > it is RECOMMENDED to use the default mode, i.e. use UDP > checksum, to reduce the chance that the encapsulated packets to > be dropped. > > > > > > Yong, Crabber, Xu, Herbert [Page 14] > -------------------------------------------------------------------------= ------- > > Internet-Draft GRE-in-UDP Encapsulation March 2016 > > g. Any middlebox that allows the UDP zero-checksum mode for IPv6 > MUST comply with requirement 1 and 8-10 in Section 5 of > [RFC6936]. > > h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP > checksums from "escaping" to the general Internet; see Section > 8 for examples of such measures. > > i. IPv6 traffic with zero UDP checksums MUST be actively monitored > for errors by the network operator. For example, the operator > may monitor Ethernet layer packet error rates. > > j. If a packet with a non-zero checksum is received, the checksum > MUST be verified before accepting the packet. This is > regardless of whether the tunnel encapsulator and decapsulator > have been configured with UDP zero-checksum mode. > > The above requirements do not change either the requirements > specified in [RFC2460] as modified by [RFC6935] or the requirements > specified in [RFC6936]. > > The requirement to check the source IPv6 address in addition to the > destination IPv6 address, plus the strong recommendation against > reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively > provide some mitigation for the absence of UDP checksum coverage of > the IPv6 header. A traffic-managed controlled environment that > satisfies at least one of three conditions listed above in this > section provides additional assurance. > > A GRE-in-UDP tunnel is suitable for transmission over lower layers > in the traffic-managed controlled environments that are allowed by > the exceptions stated above and the rate of corruption of the inner > IP packet on such networks is not expected to increase by comparison > to GRE traffic that is not encapsulated in UDP. For these reasons, > GRE-in-UDP does not provide an additional integrity check except > when GRE checksum is used when UDP zero-checksum mode is used with > IPv6, and this design is in accordance with requirements 2, 3 and 5 > specified in Section 5 of [RFC6936]. > > Generic Router Encapsulation (GRE) does not accumulate incorrect > state as a consequence of GRE header corruption. A corrupt GRE > packet may result in either packet discard or forwarding of the > packet without accumulation of GRE state. Active monitoring of GRE- > in-UDP traffic for errors is REQUIRED as occurrence of errors will > result in some accumulation of error information outside the > protocol for operational and management purposes. This design is in > accordance with requirement 4 specified in Section 5 of [RFC6936]. > > > > Yong, Crabber, Xu, Herbert [Page 15] > -------------------------------------------------------------------------= ------- > > Internet-Draft GRE-in-UDP Encapsulation March 2016 > > The remaining requirements specified in Section 5 of [RFC6936] are > not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply > because GRE does not include a control feedback mechanism. > Requirements 8-10 are middlebox requirements that do not apply to > GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox > discussion). > > It is worth mentioning that the use of a zero UDP checksum should > present the equivalent risk of undetected packet corruption when > sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and > without GRE checksums. > > In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero- > checksum mode for IPv6 when the conditions and requirements stated > above are met. Otherwise the UDP checksum need to be used for IPv6 > as specified in [RFC768] and [RFC2460]. Use of GRE checksum is > RECOMMENED when the UDP checksum is not used. > " > > In GUE, to support UDP-checksum-zero, it said > > " Therefore, when GUE is used over > IPv6, either the UDP checksum must be enabled or the GUE header > checksum must be used. An encapsulator MAY set a zero UDP checksum > for performance or implementation reasons, in which case the GUE > header checksum MUST be used or applicable requirements for using > zero UDP checksums in [GREUDP] MUST be met. If the UDP checksum is > enabled, then the GUE header checksum should not be used since it is > mostly redundant." > > It's easy for me to add the similar words to the IP-in-UDP draft like "th= e > applicable requirements for using zero UDP checksum in [GREUDP] MUST be > met when zero UDP checksum is used by the tunnel ingress". However, the > major goal for disabling the UDP checksum is to improve the performance. > When GUE header checksum is used and/or the bunch of applicable > requirements as described in GRE/UDP are verified, is the goal of improvi= ng > performance still achievable? If not, why not directly enable the UDP-che= cksum > instead? > > - fragmentation support > > In GRE/UDP, it said > > " 4.1. MTU and Fragmentation > > Regarding packet fragmentation, an encapsulator/decapsulator SHOULD > be compliant with [RFC7588] and perform fragmentation before the > encapsulation. The size of fragments SHOULD be less or equal to the > PMTU associated with the path between the GRE ingress and the GRE > egress tunnel endpoints minus the GRE and UDP overhead ..." > > in GUE, it said > > " 4.9. MTU and fragmentation > > Standard conventions for handling of MTU (Maximum Transmission Unit) > and fragmentation in conjunction with networking tunnels > (encapsulation of layer 2 or layer 3 packets) should be followed. > Details are described in MTU and Fragmentation Issues with In-the- > Network Tunneling [RFC4459]... " > > It seems that the only missing thing in the IP-in-UDP draft is to allow t= he outer > fragmentation. However, as it said in > (https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02#page-13), " ..= .IPsec > performs only Outer Fragmentation; this distinguishes it from IP-in-IP, w= hich > performs only Inner Fragmentation. " Note that IP-in-IP is the dominant > encapsulation choice within Softwires networks. In other words, performin= g > only inner fragmentation works very well in practice. Furthermore, the ou= ter > fragmentation issue (e.g., reassembly cost for the egress) would become e= ven > worse since the fragments of X-in-UDP packets are more likely to be forwa= rded > across different paths than those of X-in-IP and X-in-GRE packets. Hence,= I'm > wondering whether it's worthwhile to support the outer fragmentation on U= DP > encapsulated packets which seems useless in practice. > > - signalling support (e.g., to test whether a tunnel is up or > to measure MTUs) > > I haven't found any description of this in both GRE/UDP and GUE. Did you? > > - support for robust ID fields (related to fragmentation, > e.g., to overcome the limits of IPv4 ID as per RFC 6864) > > I haven't found any description of this in both GRE/UDP and GUE. Did you? > > Xiaohu > > > It is not our obligation to find a way for your document to proceed - > > that onus is on you. > > > > Joe --_000_D382FCD56783Csadikshiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <04F0D63D812CC047A453F2C38A078610@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
In case of typical datacenter brownfield deployments, 
the underlay and overlay may be completely disconnected operationally,=  
hence there can be cases where the mtu mismatch in underlay network ma= y not
be notified to overlay endpoints and subsequently to end hosts.

From: Lloyd Wood <lloyd.wood@yahoo.co.uk>
Date: Sunday, June 12, 2016 at 10:4= 1 AM
To: Softwires WG <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Xuxiaohu <xuxiaohu@huawei.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] [tsvwg] Is it f= easible to perform fragmentation on UDP encapsulated packets.

Fragment= ation should be strongly discouraged.

if you've designed a tunnelling solution and you have fragmentation ha= ppening as a matter of course, you've designed it wrong. 

Lloyd Wood
lloyd.wood@yahoo.co.uk

On Friday, May 27, 2016, 8:10 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

<Note that I have changed the subject of the email hence it has nothing = to do with the WG adoption call now. It's just a discussion on a particular= issue which is related to those WGs which are working on UDP tunnels. The = reason for containing the old email is to use it as a background which may be useful for better understanding = of this particular issue>

The possible side-effect of performing fragmentation on UDP encapsulated pa= ckets is to worsen the reassembly burden on tunnel egress since fragments o= f UDP encapsulated packets are more likely to be forwarded across different= paths towards the tunnel egress than those of IP or GRE encapsulated packets.

It seems that most X-over-UDP proposals choose to prohibit the tunnel ingre= ss from performing fragmentation on UDP encapsulated packets. See the follo= wing quoted text regarding fragmentation from those X-over-UDP drafts:

LISP:

When an ITR receives a packet from a site-facing interface and adds H
  octets worth of encapsulation to yield a packet size greater than L<= br>   octets, it resolves the MTU issue by first splitting the original   packet into 2 equal-sized fragments.  A LISP header is then pre= pended
  to each fragment.

VXLAN:

VTEPs MUST NOT fragment VXLAN packets.  Intermediate routers may
  fragment encapsulated VXLAN packets due to the larger frame size.   The destination VTEP MAY silently discard such VXLAN fragments.

VXLAN-GPE:

VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when
  the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer<= br>   IPv4 header.

GEVENE:

  To prevent fragmentation and maximize performance, the best practice=
  when using Geneve is to ensure that the MTU of the physical network<= br>   is greater than or equal to the MTU of the encapsulated network plus=
  tunnel headers.

GUE:

    If a packet is fragmented before encapsulation in GUE, all th= e
    related fragments must be encapsulated using the same source = port
    (inner flow identifier). An operator may set MTU to account f= or
    encapsulation overhead and reduce the likelihood of fragmenta= tion.

GRE/UDP

Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
  be compliant with [RFC7588] and perform fragmentation before the
  encapsulation.

However, the above choice seems conflict with the requirements as described= in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02


I wonder whether the IETF should reach a consensus on whether or not the fr= agmentation on UDP encapsulated packets should be allowed.
 
Best regards,
Xiaohu

> -----Original Message-----
> From: Xuxiaohu
> Sent: Thursday, May 26, 2016 4:35 PM
> To: 'Joe Touch'; Fred Baker (fred); Wassim Haddad
> Cc: int-area@ietf.org
> Subject: RE: [Int-area] Call for adoption of draft-xu-intarea-ip-in-ud= p-03
>
>
>
> > -----Original Message-----
> > From: Joe Touch [mailto:touch@isi.edu]
> > Sent: Thursday, May 26, 2016 2:11 AM
> > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad
> > Cc: int-area@ietf.org
> > Subject: Re: [Int-area] Call for adoption of
> > draft-xu-intarea-ip-in-udp-03
> >
> >
> >
> > On 5/24/2016 7:24 PM, Xuxiaohu wrote:
> > > Hi Joe,
> > >
> > > I wonder whether you want to tell me the following truth by = the
> > > example that you gave: no matter whatever improvements we ha= d done
> > > with this draft, those persons who dislike it by the light o= f nature
> > > would dislike it in the end.
> >
> > The only improvements that would make this doc useful would be to= add
> > capabilities already in GRE/UDP or GUE/UDP, which we already have= .
>
> Let's go over the four things you mentioned earlier in GRE/UDP and GUE= /UDP:
>
>     - stronger checksums
>
> In GRE/UDP, in order to use UDP-zero-checksum, it gave the following > restrictions:
> " 6. UDP Checksum Handling
>
>    6.1. UDP Checksum with IPv4
>
>    For UDP in IPv4, the UDP checksum MUST be processed as sp= ecified in
>    [RFC768] and [RFC1122] for both transmit and receive. The= IPv4
>
>
>
> Yong, Crabber, Xu, Herbert            &n= bsp;                     =   [Page 12]
> ----------------------------------------------------------------------= ----------
>
> Internet-Draft          GRE-in-UDP Encapsulat= ion            March 2016
>
>    header includes a checksum which protects against mis-del= ivery of
>    the packet due to corruption of IP addresses. The UDP che= cksum
>    potentially provides protection against corruption of the= UDP header,
>    GRE header, and GRE payload. Disabling the use of checksu= ms is a
>    deployment consideration that should take into account th= e risk and
>    effects of packet corruption.
>
>    When a decapsulator receives a packet, the UDP checksum f= ield MUST
>    be processed. If the UDP checksum is non-zero, the decaps= ulator MUST
>    verify the checksum before accepting the packet. By defau= lt a
>    decapsulator SHOULD accept UDP packets with a zero checks= um. A node
>    MAY be configured to disallow zero checksums per [RFC1122= ]; this may
>    be done selectively, for instance disallowing zero checks= ums from
>    certain hosts that are known to be sending over paths sub= ject to
>    packet corruption. If verification of a non-zero checksum= fails, a
>    decapsulator lacks the capability to verify a non-zero ch= ecksum, or
>    a packet with a zero-checksum was received and the decaps= ulator is
>    configured to disallow, the packet MUST be dropped and an= event MAY
>    be logged.
>
>    6.2. UDP Checksum with IPv6
>
>    For UDP in IPv6, the UDP checksum MUST be processed as sp= ecified in
>    [RFC768] and [RFC2460] for both transmit and receive.
>
>    When UDP is used over IPv6, the UDP checksum is relied up= on to
>    protect both the IPv6 and UDP headers from corruption. As= such, A
>    default GRE-in-UDP Tunnel MUST perform UDP checksum; A TM= CE GRE-in-
>    UDP Tunnel MAY be configured with the UDP zero-checksum m= ode if the
>    traffic-managed controlled environment or a set of closel= y
>    cooperating traffic-managed controlled environments (such= as by
>    network operators who have agreed to work together in ord= er to
>    jointly provide specific services) meet at least one of f= ollowing
>    conditions:
>
>    a. It is known (perhaps through knowledge of equipment ty= pes and
>      lower layer checks) that packet corruption is exce= ptionally
>      unlikely and where the operator is willing to take= the risk of
>      undetected packet corruption.
>
>    b. It is judged through observational measurements (perha= ps of
>      historic or current traffic flows that use a non-z= ero checksum)
>      that the level of packet corruption is tolerably l= ow and where
>      the operator is willing to take the risk of undete= cted packet
>      corruption.
>
>
>
>
>
> Yong, Crabber, Xu, Herbert            &n= bsp;                     =   [Page 13]
> ----------------------------------------------------------------------= ----------
>
> Internet-Draft          GRE-in-UDP Encapsulat= ion            March 2016
>
>    c. Carrying applications that are tolerant of mis-deliver= ed or
>      corrupted packets (perhaps through higher layer ch= ecksum,
>      validation, and retransmission or transmission red= undancy) where
>      the operator is willing to rely on the application= s using the
>      tunnel to survive any corrupt packets.
>
>    The following requirements apply to a TMCE GRE-in-UDP tun= nel that
>    use UDP zero-checksum mode:
>
>      a. Use of the UDP checksum with IPv6 MUST be the d= efault
>        configuration of all GRE-in-UDP tunnels. >
>      b. The GRE-in-UDP tunnel implementation MUST compl= y with all
>        requirements specified in Section 4 of [RFC= 6936] and with
>        requirement 1 specified in Section 5 of [RF= C6936].
>
>      c. The tunnel decapsulator SHOULD only allow the u= se of UDP zero-
>        checksum mode for IPv6 on a single received= UDP Destination
>        Port regardless of the encapsulator. The mo= tivation for this
>        requirement is possible corruption of the U= DP Destination Port,
>        which may cause packet delivery to the wron= g UDP port. If that
>        other UDP port requires the UDP checksum, t= he mis-delivered
>        packet will be discarded.
>
>      d. It is RECOMMENDED that the UDP zero-checksum mo= de for IPv6 is
>        only enabled for certain selected source ad= dresses. The tunnel
>        decapsulator MUST check that the source and= destination IPv6
>        addresses are valid for the GRE-in-UDP tunn= el on which the
>        packet was received if that tunnel uses UDP= zero-checksum mode
>        and discard any packet for which this check= fails.
>
>      e. The tunnel encapsulator SHOULD use different IP= v6 addresses for
>        each GRE-in-UDP tunnel that uses UDP zero-c= hecksum mode
>        regardless of the decapsulator in order to = strengthen the
>        decapsulator's check of the IPv6 source add= ress (i.e., the same
>        IPv6 source address SHOULD NOT be used with= more than one IPv6
>        destination address, independent of whether= that destination
>        address is a unicast or multicast address).= When this is not
>        possible, it is RECOMMENDED to use each sou= rce IPv6 address for
>        as few UDP zero-checksum mode GRE-in-UDP tu= nnels as is feasible.
>
>      f. When any middlebox exists on the path of a GRE-= in-UDP tunnel,
>        it is RECOMMENDED to use the default mode, = i.e. use UDP
>        checksum, to reduce the chance that the enc= apsulated packets to
>        be dropped.
>
>
>
>
>
> Yong, Crabber, Xu, Herbert            &n= bsp;                     =   [Page 14]
> ----------------------------------------------------------------------= ----------
>
> Internet-Draft          GRE-in-UDP Encapsulat= ion            March 2016
>
>      g. Any middlebox that allows the UDP zero-checksum= mode for IPv6
>        MUST comply with requirement 1 and 8-10 in = Section 5 of
>        [RFC6936].
>
>      h. Measures SHOULD be taken to prevent IPv6 traffi= c with zero UDP
>        checksums from "escaping" to the = general Internet; see Section
>        8 for examples of such measures.
>
>      i. IPv6 traffic with zero UDP checksums MUST be ac= tively monitored
>        for errors by the network operator. For exa= mple, the operator
>        may monitor Ethernet layer packet error rat= es.
>
>      j. If a packet with a non-zero checksum is receive= d, the checksum
>        MUST be verified before accepting the packe= t. This is
>        regardless of whether the tunnel encapsulat= or and decapsulator
>        have been configured with UDP zero-checksum= mode.
>
>    The above requirements do not change either the requireme= nts
>    specified in [RFC2460] as modified by [RFC6935] or the re= quirements
>    specified in [RFC6936].
>
>    The requirement to check the source IPv6 address in addit= ion to the
>    destination IPv6 address, plus the strong recommendation = against
>    reuse of source IPv6 addresses among GRE-in-UDP tunnels c= ollectively
>    provide some mitigation for the absence of UDP checksum c= overage of
>    the IPv6 header. A traffic-managed controlled environment= that
>    satisfies at least one of three conditions listed above i= n this
>    section provides additional assurance.
>
>    A GRE-in-UDP tunnel is suitable for transmission over low= er layers
>    in the traffic-managed controlled environments that are a= llowed by
>    the exceptions stated above and the rate of corruption of= the inner
>    IP packet on such networks is not expected to increase by= comparison
>    to GRE traffic that is not encapsulated in UDP.  For= these reasons,
>    GRE-in-UDP does not provide an additional integrity check= except
>    when GRE checksum is used when UDP zero-checksum mode is = used with
>    IPv6, and this design is in accordance with requirements = 2, 3 and 5
>    specified in Section 5 of [RFC6936].
>
>    Generic Router Encapsulation (GRE) does not accumulate in= correct
>    state as a consequence of GRE header corruption. A corrup= t GRE
>    packet may result in either packet discard or forwarding = of the
>    packet without accumulation of GRE state. Active monitori= ng of GRE-
>    in-UDP traffic for errors is REQUIRED as occurrence of er= rors will
>    result in some accumulation of error information outside = the
>    protocol for operational and management purposes. This de= sign is in
>    accordance with requirement 4 specified in Section 5 of [= RFC6936].
>
>
>
> Yong, Crabber, Xu, Herbert            &n= bsp;                     =   [Page 15]
> ----------------------------------------------------------------------= ----------
>
> Internet-Draft          GRE-in-UDP Encapsulat= ion            March 2016
>
>    The remaining requirements specified in Section 5 of [RFC= 6936] are
>    not applicable to GRE-in-UDP.  Requirements 6 and 7 = do not apply
>    because GRE does not include a control feedback mechanism= .
>    Requirements 8-10 are middlebox requirements that do not = apply to
>    GRE-in-UDP tunnel endpoints (see Section 7.1 for further = middlebox
>    discussion).
>
>    It is worth mentioning that the use of a zero UDP checksu= m should
>    present the equivalent risk of undetected packet corrupti= on when
>    sending similar packet using GRE-in-IPv6 without UDP [RFC= 7676] and
>    without GRE checksums.
>
>    In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UD= P-zero-
>    checksum mode for IPv6 when the conditions and requiremen= ts stated
>    above are met. Otherwise the UDP checksum need to be used= for IPv6
>    as specified in [RFC768] and [RFC2460]. Use of GRE checks= um is
>    RECOMMENED when the UDP checksum is not used.
> "
>
> In GUE, to support UDP-checksum-zero, it said
>
> " Therefore, when GUE is used over
>    IPv6, either the UDP checksum must be enabled or the GUE = header
>    checksum must be used.  An encapsulator MAY set a ze= ro UDP checksum
>    for performance or implementation reasons, in which case = the GUE
>    header checksum MUST be used or applicable requirements f= or using
>    zero UDP checksums in [GREUDP] MUST be met. If the UDP ch= ecksum is
>    enabled, then the GUE header checksum should not be used = since it is
>    mostly redundant."
>
> It's easy for me to add the similar words to the IP-in-UDP draft like = "the
> applicable requirements for using zero UDP checksum in [GREUDP] MUST b= e
> met when zero UDP checksum is used by the tunnel ingress". Howeve= r, the
> major goal for disabling the UDP checksum is to improve the performanc= e.
> When GUE header checksum is used and/or the bunch of applicable
> requirements as described in GRE/UDP are verified, is the goal of impr= oving
> performance still achievable? If not, why not directly enable the UDP-= checksum
> instead?
>
>     - fragmentation support
>
> In GRE/UDP, it said
>
> " 4.1. MTU and Fragmentation
>
>    Regarding packet fragmentation, an encapsulator/decapsula= tor SHOULD
>    be compliant with [RFC7588] and perform fragmentation bef= ore the
>    encapsulation. The size of fragments SHOULD be less or eq= ual to the
>    PMTU associated with the path between the GRE ingress and= the GRE
>    egress tunnel endpoints minus the GRE and UDP overhead ..= ."
>
> in GUE, it said
>
> " 4.9. MTU and fragmentation
>
>    Standard conventions for handling of MTU (Maximum Transmi= ssion Unit)
>    and fragmentation in conjunction with networking tunnels<= br> >    (encapsulation of layer 2 or layer 3 packets) should be f= ollowed.
>    Details are described in MTU and Fragmentation Issues wit= h In-the-
>    Network Tunneling [RFC4459]... "
>
> It seems that the only missing thing in the IP-in-UDP draft is to allo= w the outer
> fragmentation. However, as it said in
> (https://tools.ietf.org/html/draft-ietf-intarea-t= unnels-02#page-13), " ...IPsec
> performs only Outer Fragmentation; this distinguishes it from IP-in-IP= , which
> performs only Inner Fragmentation. " Note that IP-in-IP is the do= minant
> encapsulation choice within Softwires networks. In other words, perfor= ming
> only inner fragmentation works very well in practice. Furthermore, the= outer
> fragmentation issue (e.g., reassembly cost for the egress) would becom= e even
> worse since the fragments of X-in-UDP packets are more likely to be fo= rwarded
> across different paths than those of X-in-IP and X-in-GRE packets. Hen= ce, I'm
> wondering whether it's worthwhile to support the outer fragmentation o= n UDP
> encapsulated packets which seems useless in practice.
>
>     - signalling support (e.g., to test whether a tunne= l is up or
>     to measure MTUs)
>
> I haven't found any description of this in both GRE/UDP and GUE. Did y= ou?
>
>     - support for robust ID fields (related to fragment= ation,
>     e.g., to overcome the limits of IPv4 ID as per RFC = 6864)
>
> I haven't found any description of this in both GRE/UDP and GUE. Did y= ou?
>
> Xiaohu
>
> > It is not our obligation to find a way for your document to proce= ed -
> > that onus is on you.
> >
> > Joe
--_000_D382FCD56783Csadikshiciscocom_-- From nobody Mon Jun 13 03:43:25 2016 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 DB81912D0FC for ; Mon, 13 Jun 2016 03:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 2jx2xaOUzDPL for ; Mon, 13 Jun 2016 03:43:21 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5850D12D18B for ; Mon, 13 Jun 2016 03:43:20 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id u5DAhDsB001922 for ; Mon, 13 Jun 2016 12:43:14 +0200 From: "Jose Saldana" To: References: <20160613072152.12367.38313.idtracker@ietfa.amsl.com> In-Reply-To: <20160613072152.12367.38313.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 12:43:19 +0200 Message-ID: <00fa01d1c560$66d20ff0$34762fd0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIV1MAB+U6ijLF/iSLecPI2GPtwXJ9fFObg Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: Subject: [tsvwg] RV: New Version Notification for draft-suznjevic-tsvwg-delay-limits-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 10:43:24 -0000 Hi all, We have just submitted this draft about Delay Limits for Real-Time = Services. See = https://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-delay-limits/=20 It surveys a set of recommendations about the maximum latency tolerated = by the users of delay-constrained services. Some recommendations = already exist for VoIP, but emerging services as e.g. online gaming, = have different requirements. Different papers in the literature = reporting these constraints are surveyed, and a summary of the latency = limits for each service is finally provided. It replaces draft-suznjevic-dispatch-delay-limits and = draft-suznjevic-tsvwg-mtd-tcmtf Best regards, Jose and Mirko > -----Mensaje original----- > De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Enviado el: lunes, 13 de junio de 2016 9:22 > Para: Mirko Suznjevic ; Jose Saldana > > Asunto: New Version Notification for = draft-suznjevic-tsvwg-delay-limits-00.txt >=20 >=20 > A new version of I-D, draft-suznjevic-tsvwg-delay-limits-00.txt > has been successfully submitted by Jose Saldana and posted to the IETF > repository. >=20 > Name: draft-suznjevic-tsvwg-delay-limits > Revision: 00 > Title: Delay Limits for Real-Time Services > Document date: 2016-06-13 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-suznjevic-tsvwg-delay-limits- > 00.txt > Status: = https://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-delay-limits/ > Htmlized: = https://tools.ietf.org/html/draft-suznjevic-tsvwg-delay-limits-00 >=20 >=20 > Abstract: > Network delay is one of the main factors which can degrade the > Quality of Experience (QoE) of the users of network services. This > document surveys a set of recommendations about the maximum latency > tolerated by the users of delay-constrained services. Some > recommendations already exist for VoIP, but emerging services as = e.g. > online gaming, have different requirements. Different papers in = the > literature reporting these constraints are surveyed, and a summary = of > the latency limits for each service is finally provided. >=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 Mon Jun 13 09:29:12 2016 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 6DCC612D5B5 for ; Mon, 13 Jun 2016 09:29:10 -0700 (PDT) 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=unavailable 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 IAN0n_i2Y3YG for ; Mon, 13 Jun 2016 09:29:07 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 F14A912D0F5 for ; Mon, 13 Jun 2016 09:29:06 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h190so46856104ith.1 for ; Mon, 13 Jun 2016 09:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=du4m1CiAht/rWn4Pu541Szj3Q9nuu59Dq4Mqrbk8uQE=; b=bJbvuLN8iv02D9MyVIThRticmNUVLQpNOCfGrMOvmgUzjeD5sK5T2eRSUE8K1rl1Uu RWC1v3P8Jj5DUAN4PuDTHx4eNiwO0NT8A/OmyBAH+6nMdAgn1GagGhJrmN5z1XN+68he 6fQHMHth/W0He/YSnWWF7Z0kPhIqMlGfZIP/fBW8ebsn1qZ0S5ELgvc6bTx1aV6UTbnp 1YTmVryS1b0ut8XkYeY1SRAJ/I/npqNZlBJ7kcmvSkBOW0/FrkzsJDIiNETVEXpv9tX6 klra8rK7AaiyKcjYH5r0ASt1woSosj1t7vgSIlTDK5FyhfsoFB1BUrUsm7ojLJAhKozl Btww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=du4m1CiAht/rWn4Pu541Szj3Q9nuu59Dq4Mqrbk8uQE=; b=TV1N7bM86joE4Icc0hR8n+RlUxqES4JKEKBJNcO0iu32zY3FcJ52+nKKNmkAn1uV3O FwfTwduNBYiKO+hT8ySmbmAee5S1e3rBV60Jch4RDbCVzuko6K32g72ngh9UHm7zc3Ng lp4JMBE88rRgADLAPDTWqC/Y4o1oqTg3ut5j2FuebdhUMQ5u/ssgHcuLBbCktx0hC/SN XLAwCjpXN+l+Eof+Q1pWOEYeYY4+Ae1JHNjOwT+Sy1wc+/3OIMij2yaj+oqzH4/IdOCS wyra7D+N1v7l6axYBCVkvsKAzcoNHLGSKESRM0cLmml3K8eeqOSa+O233KsUmzSYYK6+ IDaw== X-Gm-Message-State: ALyK8tKpXx9ONBz3JiPxxu9ewCdnEtI45MIY+GS2F9uRYL++WTN+d3md3Bj57vYdFYq/Z17fGvlldxkuyxpQ/w== MIME-Version: 1.0 X-Received: by 10.36.73.219 with SMTP id e88mr841383itd.88.1465835346137; Mon, 13 Jun 2016 09:29:06 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Mon, 13 Jun 2016 09:29:05 -0700 (PDT) In-Reply-To: <974977917.2492241.1465708308527.JavaMail.yahoo@mail.yahoo.com> References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <974977917.2492241.1465708308527.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 13 Jun 2016 09:29:05 -0700 Message-ID: From: Tom Herbert To: Lloyd Wood Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" , "lisp@ietf.org" , "nvo3@ietf.org" , Softwires WG , Xuxiaohu , "tsvwg@ietf.org" Subject: Re: [tsvwg] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 16:29:10 -0000 On Sat, Jun 11, 2016 at 10:11 PM, Lloyd Wood wrote: > Fragmentation should be strongly discouraged. > > if you've designed a tunnelling solution and you have fragmentation > happening as a matter of course, you've designed it wrong. > As mentioned before we do not always have control of the underlay MTUs to be able to set Jumbo Frames to make MTU larger than 1500 to account for tunnel fragmentation. At Facebook for instance, we run IP tunnels between L4 load balancers and backend servers. In certain POPs we cannot get more than 1500 MTU in the path. The ingress MTU into the load balancer is 1500 so it is possible to receive packets from the Internet that are greater than the tunnel MTU. In this case we will fragment. Since the tunnel is behind a firewall and our devices and the path from load balancers to backends is low loss there is little concern of being DOSed. Tom > Lloyd Wood > lloyd.wood@yahoo.co.uk > > On Friday, May 27, 2016, 8:10 PM, Xuxiaohu wrote: > > do with the WG adoption call now. It's just a discussion on a particular > issue which is related to those WGs which are working on UDP tunnels. The > reason for containing the old email is to use it as a background which may > be useful for better understanding of this particular issue> > > The possible side-effect of performing fragmentation on UDP encapsulated > packets is to worsen the reassembly burden on tunnel egress since fragments > of UDP encapsulated packets are more likely to be forwarded across different > paths towards the tunnel egress than those of IP or GRE encapsulated > packets. > > It seems that most X-over-UDP proposals choose to prohibit the tunnel > ingress from performing fragmentation on UDP encapsulated packets. See the > following quoted text regarding fragmentation from those X-over-UDP drafts: > > LISP: > > When an ITR receives a packet from a site-facing interface and adds H > octets worth of encapsulation to yield a packet size greater than L > octets, it resolves the MTU issue by first splitting the original > packet into 2 equal-sized fragments. A LISP header is then prepended > to each fragment. > > VXLAN: > > VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may > fragment encapsulated VXLAN packets due to the larger frame size. > The destination VTEP MAY silently discard such VXLAN fragments. > > VXLAN-GPE: > > VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when > the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer > IPv4 header. > > GEVENE: > > To prevent fragmentation and maximize performance, the best practice > when using Geneve is to ensure that the MTU of the physical network > is greater than or equal to the MTU of the encapsulated network plus > tunnel headers. > > GUE: > > If a packet is fragmented before encapsulation in GUE, all the > related fragments must be encapsulated using the same source port > (inner flow identifier). An operator may set MTU to account for > encapsulation overhead and reduce the likelihood of fragmentation. > > GRE/UDP > > Regarding packet fragmentation, an encapsulator/decapsulator SHOULD > be compliant with [RFC7588] and perform fragmentation before the > encapsulation. > > However, the above choice seems conflict with the requirements as described > in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02 > > > I wonder whether the IETF should reach a consensus on whether or not the > fragmentation on UDP encapsulated packets should be allowed. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: Xuxiaohu >> Sent: Thursday, May 26, 2016 4:35 PM >> To: 'Joe Touch'; Fred Baker (fred); Wassim Haddad >> Cc: int-area@ietf.org >> Subject: RE: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 >> >> >> >> > -----Original Message----- >> > From: Joe Touch [mailto:touch@isi.edu] >> > Sent: Thursday, May 26, 2016 2:11 AM >> > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad >> > Cc: int-area@ietf.org >> > Subject: Re: [Int-area] Call for adoption of >> > draft-xu-intarea-ip-in-udp-03 >> > >> > >> > >> > On 5/24/2016 7:24 PM, Xuxiaohu wrote: >> > > Hi Joe, >> > > >> > > I wonder whether you want to tell me the following truth by the >> > > example that you gave: no matter whatever improvements we had done >> > > with this draft, those persons who dislike it by the light of nature >> > > would dislike it in the end. >> > >> > The only improvements that would make this doc useful would be to add >> > capabilities already in GRE/UDP or GUE/UDP, which we already have. >> >> Let's go over the four things you mentioned earlier in GRE/UDP and >> GUE/UDP: >> >> - stronger checksums >> >> In GRE/UDP, in order to use UDP-zero-checksum, it gave the following >> restrictions: >> " 6. UDP Checksum Handling >> >> 6.1. UDP Checksum with IPv4 >> >> For UDP in IPv4, the UDP checksum MUST be processed as specified in >> [RFC768] and [RFC1122] for both transmit and receive. The IPv4 >> >> >> >> Yong, Crabber, Xu, Herbert [Page 12] >> >> -------------------------------------------------------------------------------- >> >> Internet-Draft GRE-in-UDP Encapsulation March 2016 >> >> header includes a checksum which protects against mis-delivery of >> the packet due to corruption of IP addresses. The UDP checksum >> potentially provides protection against corruption of the UDP header, >> GRE header, and GRE payload. Disabling the use of checksums is a >> deployment consideration that should take into account the risk and >> effects of packet corruption. >> >> When a decapsulator receives a packet, the UDP checksum field MUST >> be processed. If the UDP checksum is non-zero, the decapsulator MUST >> verify the checksum before accepting the packet. By default a >> decapsulator SHOULD accept UDP packets with a zero checksum. A node >> MAY be configured to disallow zero checksums per [RFC1122]; this may >> be done selectively, for instance disallowing zero checksums from >> certain hosts that are known to be sending over paths subject to >> packet corruption. If verification of a non-zero checksum fails, a >> decapsulator lacks the capability to verify a non-zero checksum, or >> a packet with a zero-checksum was received and the decapsulator is >> configured to disallow, the packet MUST be dropped and an event MAY >> be logged. >> >> 6.2. UDP Checksum with IPv6 >> >> For UDP in IPv6, the UDP checksum MUST be processed as specified in >> [RFC768] and [RFC2460] for both transmit and receive. >> >> When UDP is used over IPv6, the UDP checksum is relied upon to >> protect both the IPv6 and UDP headers from corruption. As such, A >> default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in- >> UDP Tunnel MAY be configured with the UDP zero-checksum mode if the >> traffic-managed controlled environment or a set of closely >> cooperating traffic-managed controlled environments (such as by >> network operators who have agreed to work together in order to >> jointly provide specific services) meet at least one of following >> conditions: >> >> a. It is known (perhaps through knowledge of equipment types and >> lower layer checks) that packet corruption is exceptionally >> unlikely and where the operator is willing to take the risk of >> undetected packet corruption. >> >> b. It is judged through observational measurements (perhaps of >> historic or current traffic flows that use a non-zero checksum) >> that the level of packet corruption is tolerably low and where >> the operator is willing to take the risk of undetected packet >> corruption. >> >> >> >> >> >> Yong, Crabber, Xu, Herbert [Page 13] >> >> -------------------------------------------------------------------------------- >> >> Internet-Draft GRE-in-UDP Encapsulation March 2016 >> >> c. Carrying applications that are tolerant of mis-delivered or >> corrupted packets (perhaps through higher layer checksum, >> validation, and retransmission or transmission redundancy) where >> the operator is willing to rely on the applications using the >> tunnel to survive any corrupt packets. >> >> The following requirements apply to a TMCE GRE-in-UDP tunnel that >> use UDP zero-checksum mode: >> >> a. Use of the UDP checksum with IPv6 MUST be the default >> configuration of all GRE-in-UDP tunnels. >> >> b. The GRE-in-UDP tunnel implementation MUST comply with all >> requirements specified in Section 4 of [RFC6936] and with >> requirement 1 specified in Section 5 of [RFC6936]. >> >> c. The tunnel decapsulator SHOULD only allow the use of UDP zero- >> checksum mode for IPv6 on a single received UDP Destination >> Port regardless of the encapsulator. The motivation for this >> requirement is possible corruption of the UDP Destination Port, >> which may cause packet delivery to the wrong UDP port. If that >> other UDP port requires the UDP checksum, the mis-delivered >> packet will be discarded. >> >> d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is >> only enabled for certain selected source addresses. The tunnel >> decapsulator MUST check that the source and destination IPv6 >> addresses are valid for the GRE-in-UDP tunnel on which the >> packet was received if that tunnel uses UDP zero-checksum mode >> and discard any packet for which this check fails. >> >> e. The tunnel encapsulator SHOULD use different IPv6 addresses for >> each GRE-in-UDP tunnel that uses UDP zero-checksum mode >> regardless of the decapsulator in order to strengthen the >> decapsulator's check of the IPv6 source address (i.e., the same >> IPv6 source address SHOULD NOT be used with more than one IPv6 >> destination address, independent of whether that destination >> address is a unicast or multicast address). When this is not >> possible, it is RECOMMENDED to use each source IPv6 address for >> as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. >> >> f. When any middlebox exists on the path of a GRE-in-UDP tunnel, >> it is RECOMMENDED to use the default mode, i.e. use UDP >> checksum, to reduce the chance that the encapsulated packets to >> be dropped. >> >> >> >> >> >> Yong, Crabber, Xu, Herbert [Page 14] >> >> -------------------------------------------------------------------------------- >> >> Internet-Draft GRE-in-UDP Encapsulation March 2016 >> >> g. Any middlebox that allows the UDP zero-checksum mode for IPv6 >> MUST comply with requirement 1 and 8-10 in Section 5 of >> [RFC6936]. >> >> h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP >> checksums from "escaping" to the general Internet; see Section >> 8 for examples of such measures. >> >> i. IPv6 traffic with zero UDP checksums MUST be actively monitored >> for errors by the network operator. For example, the operator >> may monitor Ethernet layer packet error rates. >> >> j. If a packet with a non-zero checksum is received, the checksum >> MUST be verified before accepting the packet. This is >> regardless of whether the tunnel encapsulator and decapsulator >> have been configured with UDP zero-checksum mode. >> >> The above requirements do not change either the requirements >> specified in [RFC2460] as modified by [RFC6935] or the requirements >> specified in [RFC6936]. >> >> The requirement to check the source IPv6 address in addition to the >> destination IPv6 address, plus the strong recommendation against >> reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively >> provide some mitigation for the absence of UDP checksum coverage of >> the IPv6 header. A traffic-managed controlled environment that >> satisfies at least one of three conditions listed above in this >> section provides additional assurance. >> >> A GRE-in-UDP tunnel is suitable for transmission over lower layers >> in the traffic-managed controlled environments that are allowed by >> the exceptions stated above and the rate of corruption of the inner >> IP packet on such networks is not expected to increase by comparison >> to GRE traffic that is not encapsulated in UDP. For these reasons, >> GRE-in-UDP does not provide an additional integrity check except >> when GRE checksum is used when UDP zero-checksum mode is used with >> IPv6, and this design is in accordance with requirements 2, 3 and 5 >> specified in Section 5 of [RFC6936]. >> >> Generic Router Encapsulation (GRE) does not accumulate incorrect >> state as a consequence of GRE header corruption. A corrupt GRE >> packet may result in either packet discard or forwarding of the >> packet without accumulation of GRE state. Active monitoring of GRE- >> in-UDP traffic for errors is REQUIRED as occurrence of errors will >> result in some accumulation of error information outside the >> protocol for operational and management purposes. This design is in >> accordance with requirement 4 specified in Section 5 of [RFC6936]. >> >> >> >> Yong, Crabber, Xu, Herbert [Page 15] >> >> -------------------------------------------------------------------------------- >> >> Internet-Draft GRE-in-UDP Encapsulation March 2016 >> >> The remaining requirements specified in Section 5 of [RFC6936] are >> not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply >> because GRE does not include a control feedback mechanism. >> Requirements 8-10 are middlebox requirements that do not apply to >> GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox >> discussion). >> >> It is worth mentioning that the use of a zero UDP checksum should >> present the equivalent risk of undetected packet corruption when >> sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and >> without GRE checksums. >> >> In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero- >> checksum mode for IPv6 when the conditions and requirements stated >> above are met. Otherwise the UDP checksum need to be used for IPv6 >> as specified in [RFC768] and [RFC2460]. Use of GRE checksum is >> RECOMMENED when the UDP checksum is not used. >> " >> >> In GUE, to support UDP-checksum-zero, it said >> >> " Therefore, when GUE is used over >> IPv6, either the UDP checksum must be enabled or the GUE header >> checksum must be used. An encapsulator MAY set a zero UDP checksum >> for performance or implementation reasons, in which case the GUE >> header checksum MUST be used or applicable requirements for using >> zero UDP checksums in [GREUDP] MUST be met. If the UDP checksum is >> enabled, then the GUE header checksum should not be used since it is >> mostly redundant." >> >> It's easy for me to add the similar words to the IP-in-UDP draft like "the >> applicable requirements for using zero UDP checksum in [GREUDP] MUST be >> met when zero UDP checksum is used by the tunnel ingress". However, the >> major goal for disabling the UDP checksum is to improve the performance. >> When GUE header checksum is used and/or the bunch of applicable >> requirements as described in GRE/UDP are verified, is the goal of >> improving >> performance still achievable? If not, why not directly enable the >> UDP-checksum >> instead? >> >> - fragmentation support >> >> In GRE/UDP, it said >> >> " 4.1. MTU and Fragmentation >> >> Regarding packet fragmentation, an encapsulator/decapsulator SHOULD >> be compliant with [RFC7588] and perform fragmentation before the >> encapsulation. The size of fragments SHOULD be less or equal to the >> PMTU associated with the path between the GRE ingress and the GRE >> egress tunnel endpoints minus the GRE and UDP overhead ..." >> >> in GUE, it said >> >> " 4.9. MTU and fragmentation >> >> Standard conventions for handling of MTU (Maximum Transmission Unit) >> and fragmentation in conjunction with networking tunnels >> (encapsulation of layer 2 or layer 3 packets) should be followed. >> Details are described in MTU and Fragmentation Issues with In-the- >> Network Tunneling [RFC4459]... " >> >> It seems that the only missing thing in the IP-in-UDP draft is to allow >> the outer >> fragmentation. However, as it said in >> (https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02#page-13), " >> ...IPsec >> performs only Outer Fragmentation; this distinguishes it from IP-in-IP, >> which >> performs only Inner Fragmentation. " Note that IP-in-IP is the dominant >> encapsulation choice within Softwires networks. In other words, performing >> only inner fragmentation works very well in practice. Furthermore, the >> outer >> fragmentation issue (e.g., reassembly cost for the egress) would become >> even >> worse since the fragments of X-in-UDP packets are more likely to be >> forwarded >> across different paths than those of X-in-IP and X-in-GRE packets. Hence, >> I'm >> wondering whether it's worthwhile to support the outer fragmentation on >> UDP >> encapsulated packets which seems useless in practice. >> >> - signalling support (e.g., to test whether a tunnel is up or >> to measure MTUs) >> >> I haven't found any description of this in both GRE/UDP and GUE. Did you? >> >> - support for robust ID fields (related to fragmentation, >> e.g., to overcome the limits of IPv4 ID as per RFC 6864) >> >> I haven't found any description of this in both GRE/UDP and GUE. Did you? >> >> Xiaohu >> >> > It is not our obligation to find a way for your document to proceed - >> > that onus is on you. >> > >> > Joe From nobody Tue Jun 14 01:14:52 2016 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 B1F0212B032; Tue, 14 Jun 2016 01:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 8b9ZZ3WToUGD; Tue, 14 Jun 2016 01:14:46 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F829127078; Tue, 14 Jun 2016 01:14:45 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-2e-575fbcf355e1 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.CA.12926.3FCBF575; Tue, 14 Jun 2016 10:14:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.294.0; Tue, 14 Jun 2016 10:14:43 +0200 To: IETF AVTCore WG From: Magnus Westerlund Message-ID: Date: Tue, 14 Jun 2016 10:14:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM2K7ve7nPfHhBi9O21i87FnJbjG/8zS7 xdp/7ewWx97cZXNg8Viy5CeTx6ydT1gCmKK4bFJSczLLUov07RK4Mh4/2sdWcJW7Yu7DJ6wN jDc5uxg5OSQETCRO7F7CCGGLSVy4t56ti5GLQ0jgCKPEq0VvmCCc5YwSZz82sYNUiQgoSeyY tI0ZxGYWSJQ4uP8SG4jNJmAhcfNHI5gtLOAj8fXLXBYQm1fAXuJk/2WwOIuAqsSpQ01gtqhA jETj7cPsEDWCEidnPgGq5wCaaS/xYGsZxHh5ieats8FWCQloSzQ0dbBOYOSfhaRjFkLHLCQd CxiZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEBuTBLb9VdzBefuN4iFGAg1GJh/eBTny4 EGtiWXFl7iFGCQ5mJRHepJ1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NT C1KLYLJMHJxSDYyG8mkr72zPXXVooxrPzU+3tDaHeyR/rK8Rlmw8ck8rfIqi3gzGvoeK/Dw9 MXPKrz19su/yii+pf6VD53IXm5Q1fTk2ve/1F8lp/jdrExacqdVez/GVYd2ZJaxV9vwMK/Yr 1KUdEWWcs/LwdysTzqoDPs/+sF1btuD8ttIc2euXLu2fzdsT5vFViaU4I9FQi7moOBEAbjui kkQCAAA= Archived-At: Cc: "rtcweb@ietf.org" , tsvwg Subject: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 08:14:48 -0000 AVT, RTCWEB and TSVWG This announces an additional one week WG last call (in AVT) on the changes done to "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions" that is intended for Proposed Standard. The last call concludes on the 21st of June. So this last call is deemed necessary due to normative changes in the behaviour as result of the conclusions of how to resolve the Discuss regarding reaction to ECN markings. If there are no issues in this additional WG last call, the draft will be approved for publication as it has already passed IESG review. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-16 Cheers Magnus Westerlund AVTCORE WG chair ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 14 06:21:03 2016 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 B07CA12D662; Tue, 14 Jun 2016 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 uEpuZ837quLs; Tue, 14 Jun 2016 06:20:57 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDCE12D149; Tue, 14 Jun 2016 06:20:57 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EDKrkG030742 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jun 2016 09:20:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5EDKrkG030742 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1465910454; bh=DuhFDGqjhQ/8VD5WyBYNAgylz7w=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=g9qea73KSBhwHDxUlFzQ2yVnnJk4bno4rfc66HNlR3VlZPT6ZvmHTgNNFgM83E7MI i32lfa4BiAbgNLKT1oLLb10DLS/saYtl2nPyJ1qHJy7D3kBwPvM7P/xJCxtH4b1Orn AnEjqjwKsJA5K470EueUlsQeZiuYi0SA9F6FLUtU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5EDKrkG030742 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 14 Jun 2016 09:20:02 -0400 Received: from MXHUB314.corp.emc.com (MXHUB314.corp.emc.com [10.146.3.92]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EDKdJE021165 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 14 Jun 2016 09:20:40 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB314.corp.emc.com ([10.146.3.92]) with mapi id 14.03.0266.001; Tue, 14 Jun 2016 09:20:39 -0400 From: "Black, David" To: Magnus Westerlund , IETF AVTCore WG Thread-Topic: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRxhTZlEGL7AwWFU+285hNj7xak5/o7+uw Date: Tue, 14 Jun 2016 13:20:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg Subject: Re: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 13:21:00 -0000 In the new ECN text in Section 7, I see: Given the above issues, implementations MAY ignore ECN-CE marks when=09 determining if the congestion circuit breaker triggers, since=09 excessive persistent congestion will eventually lead to packet loss=09 that will trigger the circuit breaker. Doing this will protect the=09 network from congestion collapse, but might result in sub-optimal=09 user experience for competing flows that share the bottleneck queue,=09 since that queue will be driven to overflow, inducing high latency. If this is a concern, the only current guidance is for=09 implementations to treat ECN-CE marked packets as equivalent to lost=09 packets, whilst being aware that this might trigger the circuit=09 breaker prematurely in future, depending on how AQM and ECN=09 deployment evolves. Developers that implement a circuit breaker=09 based on ECN-CE marks will need to track future developments in AQM=09 standards and deployed ECN marking behaviour, and ensure their=09 implementations are updated to match. I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT" requirement with an explanation of what happens when something else is done. Proposed rewrite: Given the above issues, implementations SHOULD NOT ignore ECN-CE marks when determining whether to trigger the congestion circuit breaker, even= =09 though excessive persistent congestion will eventually lead to packet lo= ss=09 that triggers the circuit breaker. Relying on packet loss protects the= =09 network from congestion collapse, but might result in sub-optimal=09 user experience for competing flows that share the bottleneck queue,=09 since that queue will be driven to overflow, inducing higher latency. Current implementation guidance is for implementations to treat ECN-CE marked packets as equivalent to lost=09 packets, whilst being aware that this might trigger the circuit=09 breaker prematurely in the future, depending on how AQM and ECN=09 deployment evolves. Developers that implement a circuit breaker=09 based on ECN-CE marks will need to track future developments in AQM=09 standards and deployed ECN marking behaviour, and ensure their=09 implementations are updated to match. The original "MAY" language invites implementers to completely ignore ECN-CE marks, which I think is very bad advice. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Magnus Westerlun= d > Sent: Tuesday, June 14, 2016 4:15 AM > To: IETF AVTCore WG > Cc: rtcweb@ietf.org; tsvwg > Subject: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-= breakers- > 16 >=20 > AVT, RTCWEB and TSVWG >=20 > This announces an additional one week WG last call (in AVT) on the > changes done to "Multimedia Congestion Control: Circuit Breakers for > Unicast RTP Sessions" that is intended for Proposed Standard. The last > call concludes on the 21st of June. >=20 > So this last call is deemed necessary due to normative changes in the > behaviour as result of the conclusions of how to resolve the Discuss > regarding reaction to ECN markings. >=20 > If there are no issues in this additional WG last call, the draft will > be approved for publication as it has already passed IESG review. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-circuit-breake= rs-16 >=20 > Cheers >=20 > Magnus Westerlund > AVTCORE WG chair >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Tue Jun 14 06:44:14 2016 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 D4AED128E18; Tue, 14 Jun 2016 06:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 BH0nhxd6spt6; Tue, 14 Jun 2016 06:44:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5776A12D5C2; Tue, 14 Jun 2016 06:44:06 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-bd-57600a247218 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.B5.12926.42A00675; Tue, 14 Jun 2016 15:44:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.294.0; Tue, 14 Jun 2016 15:43:48 +0200 To: "Black, David" , IETF AVTCore WG References: From: Magnus Westerlund Message-ID: Date: Tue, 14 Jun 2016 15:43:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7ja4KV0K4wfVv2hYve1ayW2w9vJbd Yu2/dnaLY2/usjmweBw5MpvFY8mSn0wBTFFcNimpOZllqUX6dglcGf29H5kKnqhV/O45wtrA eE+ui5GTQ0LARKJx8xdGCFtM4sK99WxdjFwcQgJHGCVufNvPBpIQEljOKLG4vQTEFhaIkli9 8wFYXETAQ6JpywNGiIZmRolZ8ycwgSSYBewlrvxaww5iswlYSNz80QjWwAsUv3n7O5jNIqAq 0TRvAliNqECMROPtw+wQNYISJ2c+YQGxOQX8JPb+O87axcgBNvPB1jKI8fISzVtnM0Pcpi3R 0NTBOoFRcBaS7lkIHbOQdCxgZF7FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERjAB7f8Vt3B ePmN4yFGAQ5GJR7eBzrx4UKsiWXFlbmHGCU4mJVEeNvYE8KFeFMSK6tSi/Lji0pzUosPMUpz sCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MIo/FjxuYtZ/ZMkX06tFwp2JjjFMu22zwr5u Yv21d32BwZPF+o/M/u/ap6T2q+zQx4NsnVM8AqfxVZZ3hzC8P992O2vu8RwztyNSjNeTnFf/ /nxHIuaN84/e0lvL17FtEWnb8vPufpbbbv5zRG2f9Wry9LQ0NGk9mPO9jDlN4uXKqHl3dF4G uCixFGckGmoxFxUnAgBjR6ISXAIAAA== Archived-At: Cc: "rtcweb@ietf.org" , tsvwg Subject: Re: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 13:44:10 -0000 Hi, Please see below. Den 2016-06-14 kl. 15:20, skrev Black, David: > In the new ECN text in Section 7, I see: > > Given the above issues, implementations MAY ignore ECN-CE marks when > determining if the congestion circuit breaker triggers, since > excessive persistent congestion will eventually lead to packet loss > that will trigger the circuit breaker. Doing this will protect the > network from congestion collapse, but might result in sub-optimal > user experience for competing flows that share the bottleneck queue, > since that queue will be driven to overflow, inducing high latency. > If this is a concern, the only current guidance is for > implementations to treat ECN-CE marked packets as equivalent to lost > packets, whilst being aware that this might trigger the circuit > breaker prematurely in future, depending on how AQM and ECN > deployment evolves. Developers that implement a circuit breaker > based on ECN-CE marks will need to track future developments in AQM > standards and deployed ECN marking behaviour, and ensure their > implementations are updated to match. > > I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT" > requirement with an explanation of what happens when something else > is done. Proposed rewrite: > > Given the above issues, implementations SHOULD NOT ignore ECN-CE marks > when determining whether to trigger the congestion circuit breaker, even > though excessive persistent congestion will eventually lead to packet loss > that triggers the circuit breaker. Relying on packet loss protects the > network from congestion collapse, but might result in sub-optimal > user experience for competing flows that share the bottleneck queue, > since that queue will be driven to overflow, inducing higher latency. > > Current implementation guidance is for > implementations to treat ECN-CE marked packets as equivalent to lost > packets, whilst being aware that this might trigger the circuit > breaker prematurely in the future, depending on how AQM and ECN > deployment evolves. Developers that implement a circuit breaker > based on ECN-CE marks will need to track future developments in AQM > standards and deployed ECN marking behaviour, and ensure their > implementations are updated to match. > > The original "MAY" language invites implementers to completely ignore > ECN-CE marks, which I think is very bad advice. So in the discussion between Mirja, the authors and me in attempting to resolve the discuss we ended up in MAY for a reason. We on the call agreed after a lengthy discussion that treating a ECN-CE mark the same way as a loss, is not appropriate. This despite that current in force specification indicate that would be the answer. However, as indicated in the updated text, there are a number of ongoing work that indicates that is not the expected actual marking behavior. This resulted in another issue, there are no specified marking behavior that we define an appropriate response based on. When such a behavior is defined one can update circuit breaker with a well defined response to ECN-CE marks. So due to the lack of defined behavior we didn't see a possibility for using SHOULD NOT, as we can't point to what should be implemented. Thus we chose to propose MAY as it then is open to the implementation if they can find a well working response or completely ignore this. So far I lack evidence for any significant deployment of ECN for RTP, unfortunately. This lessens the impact of this choice. Secondly, ignoring the ECN-CE marks for a circuit breaker we believe will have a limited impact. If the implementation only have circuit breaker, i.e. no full fledged congestion controller and uses ECN, they can in worst case drive the buffer into the overload regime where it starts dropping packets. So if the flow does cause persistent congestion it will drive the AQM into packet drops and thus triggering of the circuit breaker. Yes, it will be unfair and push away responsive flows. But, that will happen also without ECN, is not something that the circuit breaker can protect against. I hope this makes it clearer why we arrived at MAY and don't see the possibility to use SHOULD strength wording regarding ECN-CE marks. Cheers Magnus Westerlund AVTCORE Chair. ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 14 06:59:36 2016 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 B883D12D759; Tue, 14 Jun 2016 06:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 aEEbiEgX6_FW; Tue, 14 Jun 2016 06:59:33 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0E44712D74D; Tue, 14 Jun 2016 06:59:33 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9BA06C9418; Tue, 14 Jun 2016 09:59:27 -0400 (EDT) Date: Tue, 14 Jun 2016 09:59:27 -0400 From: John Leslie To: "Black, David" Message-ID: <20160614135927.GE39331@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: Cc: Magnus Westerlund , "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 13:59:35 -0000 Black, David wrote: > > In the new ECN text in Section 7, I see: > > Given the above issues, implementations MAY ignore ECN-CE marks when > determining if the congestion circuit breaker triggers, since > excessive persistent congestion will eventually lead to packet loss >... > I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT" > requirement with an explanation of what happens when something else > is done. I'm very sympathetic to your issue: there are implementations of ECN out there which _will_not_ drop an ECN-capable packet before the sending queue has overflowed. But at the same time, we're headed into changes where ECN-CE marking will become more frequent than packet-drop. We must find a way to avoid ECN-CE triggering the congestion circuit breaker when the forwarding node has not reached a level of congestion which could trigger packet loss. I'd prefer language (perhaps in an RFC-3168-bis) stating that packet drop MUST me used, at least occasionally, on packets which would be ECN-CE marked, when the overall congestion at that node reaches the drop level for non-ECN-capable packets. (The forwarding node is the only node with sufficient information to see the issue.) (I recommend folks interested in circuit-breaker pay attention to the L4S BoF being scheduled for Berlin.) -- John Leslie From nobody Tue Jun 14 07:21:01 2016 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 CB34212D7AA; Tue, 14 Jun 2016 07:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 PxabOGro3I76; Tue, 14 Jun 2016 07:20:50 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29A412D79B; Tue, 14 Jun 2016 07:20:49 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EEKhhX017803 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jun 2016 10:20:46 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5EEKhhX017803 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1465914047; bh=2SjV7jVI0zuMzxIA0xsaInXWGgU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=pJINkQkeIn1Exy+Bruh1n5uWbp7YA/NXNHj4kRkxF2PuzdaKEAo/3j1kGA+Qe2pdB f9Yg70GYJvrfgxEFjBQzTqgIVcCk2F4O2ryEjO36iyt8MFMymESTNNdXlpwIgE71fg oqYjz9W16gFiQ9V3GfFuB1dBFAqw9nPM5NxnMrT8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5EEKhhX017803 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 14 Jun 2016 10:19:42 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EEKK00015973 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 14 Jun 2016 10:20:20 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0266.001; Tue, 14 Jun 2016 10:20:20 -0400 From: "Black, David" To: Magnus Westerlund , IETF AVTCore WG Thread-Topic: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRxkLUYr+6QxUe90uOYiuDzdk+1J/pASmA Date: Tue, 14 Jun 2016 14:20:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg Subject: Re: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 14:20:53 -0000 > This resulted in another issue, there are no specified marking behavior > that we define an appropriate response based on. When such a behavior is > defined one can update circuit breaker with a well defined response to > ECN-CE marks. So due to the lack of defined behavior we didn't see a > possibility for using SHOULD NOT, as we can't point to what should be > implemented. Thus we chose to propose MAY as it then is open to the > implementation if they can find a well working response or completely > ignore this. My problem is that the new "MAY" sentence is unqualified: > > Given the above issues, implementations MAY ignore ECN-CE marks when > > determining if the congestion circuit breaker triggers, That invites implementers to ignore ECN-CE marks without giving this topic = the level of consideration anticipated in this discussion and elsewhere in Sect= ion 7. If "SHOULD NOT" language is unworkable, please propose alternate text that qualifies applicability of the "MAY" - e.g., only after careful considerati= on of everything that we're now discussing and the rest of the text in Section 7. I proposed "SHOULD NOT" because it appear that the original RFC 2119 defini= tion of that term is a good fit to this situation: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Thanks, --David > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, June 14, 2016 9:44 AM > To: Black, David; IETF AVTCore WG > Cc: rtcweb@ietf.org; tsvwg > Subject: Re: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circ= uit- > breakers-16 >=20 > Hi, >=20 > Please see below. >=20 > Den 2016-06-14 kl. 15:20, skrev Black, David: > > In the new ECN text in Section 7, I see: > > > > Given the above issues, implementations MAY ignore ECN-CE marks when > > determining if the congestion circuit breaker triggers, since > > excessive persistent congestion will eventually lead to packet loss > > that will trigger the circuit breaker. Doing this will protect the > > network from congestion collapse, but might result in sub-optimal > > user experience for competing flows that share the bottleneck queue, > > since that queue will be driven to overflow, inducing high latency. > > If this is a concern, the only current guidance is for > > implementations to treat ECN-CE marked packets as equivalent to lost > > packets, whilst being aware that this might trigger the circuit > > breaker prematurely in future, depending on how AQM and ECN > > deployment evolves. Developers that implement a circuit breaker > > based on ECN-CE marks will need to track future developments in AQM > > standards and deployed ECN marking behaviour, and ensure their > > implementations are updated to match. > > > > I think "MAY" is inappropriate here - this text reads like a "SHOULD NO= T" > > requirement with an explanation of what happens when something else > > is done. Proposed rewrite: > > > > Given the above issues, implementations SHOULD NOT ignore ECN-CE mar= ks > > when determining whether to trigger the congestion circuit breaker, > even > > though excessive persistent congestion will eventually lead to packe= t loss > > that triggers the circuit breaker. Relying on packet loss protects= the > > network from congestion collapse, but might result in sub-optimal > > user experience for competing flows that share the bottleneck queue, > > since that queue will be driven to overflow, inducing higher latency= . > > > > Current implementation guidance is for > > implementations to treat ECN-CE marked packets as equivalent to lost > > packets, whilst being aware that this might trigger the circuit > > breaker prematurely in the future, depending on how AQM and ECN > > deployment evolves. Developers that implement a circuit breaker > > based on ECN-CE marks will need to track future developments in AQM > > standards and deployed ECN marking behaviour, and ensure their > > implementations are updated to match. > > > > The original "MAY" language invites implementers to completely ignore > > ECN-CE marks, which I think is very bad advice. >=20 > So in the discussion between Mirja, the authors and me in attempting to > resolve the discuss we ended up in MAY for a reason. We on the call > agreed after a lengthy discussion that treating a ECN-CE mark the same > way as a loss, is not appropriate. This despite that current in force > specification indicate that would be the answer. However, as indicated > in the updated text, there are a number of ongoing work that indicates > that is not the expected actual marking behavior. >=20 > This resulted in another issue, there are no specified marking behavior > that we define an appropriate response based on. When such a behavior is > defined one can update circuit breaker with a well defined response to > ECN-CE marks. So due to the lack of defined behavior we didn't see a > possibility for using SHOULD NOT, as we can't point to what should be > implemented. Thus we chose to propose MAY as it then is open to the > implementation if they can find a well working response or completely > ignore this. >=20 > So far I lack evidence for any significant deployment of ECN for RTP, > unfortunately. This lessens the impact of this choice. >=20 > Secondly, ignoring the ECN-CE marks for a circuit breaker we believe > will have a limited impact. If the implementation only have circuit > breaker, i.e. no full fledged congestion controller and uses ECN, they > can in worst case drive the buffer into the overload regime where it > starts dropping packets. So if the flow does cause persistent congestion > it will drive the AQM into packet drops and thus triggering of the > circuit breaker. Yes, it will be unfair and push away responsive flows. > But, that will happen also without ECN, is not something that the > circuit breaker can protect against. >=20 > I hope this makes it clearer why we arrived at MAY and don't see the > possibility to use SHOULD strength wording regarding ECN-CE marks. >=20 > Cheers >=20 > Magnus Westerlund > AVTCORE Chair. >=20 >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Wed Jun 15 04:11:44 2016 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 9722F12D1A6 for ; Wed, 15 Jun 2016 04:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.92 X-Spam-Level: X-Spam-Status: No, score=0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-tsvwg@employees.org header.d=employees.org 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 YNM5ZAE-yksM for ; Wed, 15 Jun 2016 04:11:41 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EE512D18E for ; Wed, 15 Jun 2016 04:11:40 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 11:11:39 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B81D09CC7C; Wed, 15 Jun 2016 04:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:mime-version:content-type; s= selector1; bh=9Nd8tey7CrAbndz0mv7mt+XgUco=; b=Ghvv72TmFQBg/Vclr2 qFZvKhVcxV80DVCcgRcFLZKjp7TnjlJL7bhZhoZiGo4Z4glTkyWT2QePZlW77mDA 38TXD8b1BQ7fr9L1EGhN26+jNkwlWLUegEdHsJl9IWLHijqri+w/DjW2JUSqlh51 Vfqk1e464R9QBkEbAv1pLDEEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:mime-version:content-type; q=dns; s= selector1; b=EMXyPizyilPgx8RybToj2/tzkW2i5+j8rlzo6w1i4XZ+gB+g78L 354G1U/WebPVigGbAG3eNQQK7KiHSsXRnnN+vlEpQph7PEO5J0T2taij3KdjDLTe R754mdxRkO35uedI8kMdpxy6Fect9qYm8AYDXgH/XwdnKFQ6HYigRCmY= Received: by cowbell.employees.org (Postfix, from userid 1736) id A1A5A9CC51; Wed, 15 Jun 2016 04:11:38 -0700 (PDT) Date: Wed, 15 Jun 2016 12:11:38 +0100 From: Derek Fawcus To: tsvwg@ietf.org Message-ID: <20160615111138.GA65681@cowbell.employees.org> Mail-Followup-To: tsvwg@ietf.org, randall@lakerest.net, tuexen@fh-muenster.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: tuexen@fh-muenster.de, randall@lakerest.net Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 11:11:42 -0000 On Wed, May 18, 2016 at 01:13:46pm -0700, 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 of the IETF. > > Title : Stream Control Transmission Protocol (SCTP) Network Address Translation Support > Authors : Randall R. Stewart > Michael Tuexen > Irene Ruengeler > Filename : draft-ietf-tsvwg-natsupp-09.txt > Pages : 44 > Date : 2016-05-18 So does anyone know if there are any host stacks which support the above extensions yet? (Even if only process space implementations). i.e. processing the extended ABORT chunk (with M bit set), and will use the Port Number Collision Error Cause to trigger a re-attempt with a new port number? Basically the situation in section 6.4 plus the handling in section 6.3. I note that 6.3 mentioned re-attemting with a new V-Tag, but 6.4 does not mention the client re-attemping with a new port number (assuming it was an ephemeral port). As to why: Assume a CGN where the map of private addr+port <=> public add+port assignments is being shared for TCP/UDP/UDP-Lite/DCCP, it would be useful to be able to use the same map for SCTP. DF From nobody Wed Jun 15 08:04:48 2016 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 E5D2212D836; Wed, 15 Jun 2016 08:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 LE5F-AD8UTlS; Wed, 15 Jun 2016 08:04:39 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BD112D849; Wed, 15 Jun 2016 08:04:39 -0700 (PDT) Received: from [130.209.247.112] (port=50083 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bDCMs-0001RF-Mx; Wed, 15 Jun 2016 16:04:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Wed, 15 Jun 2016 16:04:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Black, David" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Magnus Westerlund , "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:04:41 -0000 > On 14 Jun 2016, at 15:20, Black, David wrote: >=20 >> This resulted in another issue, there are no specified marking = behavior >> that we define an appropriate response based on. When such a behavior = is >> defined one can update circuit breaker with a well defined response = to >> ECN-CE marks. So due to the lack of defined behavior we didn't see a >> possibility for using SHOULD NOT, as we can't point to what should be >> implemented. Thus we chose to propose MAY as it then is open to the >> implementation if they can find a well working response or completely >> ignore this. >=20 > My problem is that the new "MAY" sentence is unqualified: >=20 >>> Given the above issues, implementations MAY ignore ECN-CE marks = when >>> determining if the congestion circuit breaker triggers, >=20 > That invites implementers to ignore ECN-CE marks without giving this = topic the > level of consideration anticipated in this discussion and elsewhere in = Section 7. > If "SHOULD NOT" language is unworkable, please propose alternate text = that > qualifies applicability of the "MAY" - e.g., only after careful = consideration of > everything that we're now discussing and the rest of the text in = Section 7. >=20 > I proposed "SHOULD NOT" because it appear that the original RFC 2119 = definition > of that term is a good fit to this situation: >=20 > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. The issue with saying =E2=80=9Cimplementations SHOULD NOT ignore ECN-CE = marks=E2=80=9D, is that it implies that they should respond to those = marks. However, the outcome of the long discussion we had with Mirja was = that there=E2=80=99s no consensus on what=E2=80=99s the correct = response, and concern that implementations picking the wrong choice will = hinder the deployment of ECN.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 15 09:07:02 2016 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 7F26612D920; Wed, 15 Jun 2016 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 SRG71oQhs4JM; Wed, 15 Jun 2016 09:06:51 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE10212D8FB; Wed, 15 Jun 2016 09:06:51 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FG6bUo024433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jun 2016 12:06:41 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FG6bUo024433 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466006802; bh=fBUUGjcyrMM7KuZukJy/BBJlINk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SFkE0GjYhxGm2dPoHUuw74LqajFwiNlASgGHEiY+rKdQ2ROFzrNLx4tH7geCDRJXC rSvFTpd3/hZkskkyrZFLUBG+t0obcZ68gfefy0hX0UWCULYnL6ESeontST0vCPbp6R j6CL2s+GhcqENTXUUOeww+fDrvfu5TdVXOLhMSy4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FG6bUo024433 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 15 Jun 2016 12:05:43 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FG6KY7024501 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 15 Jun 2016 12:06:21 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Wed, 15 Jun 2016 12:06:20 -0400 From: "Black, David" To: Colin Perkins Thread-Topic: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRxkLUYr+6QxUe90uOYiuDzdk+1J/pASmAgAHjzYD//80dQA== Date: Wed, 15 Jun 2016 16:06:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Magnus Westerlund , "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 16:06:53 -0000 PiBUaGUgaXNzdWUgd2l0aCBzYXlpbmcg4oCcaW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1QgaWdu b3JlIEVDTi1DRSBtYXJrc+KAnSwgaXMNCj4gdGhhdCBpdCBpbXBsaWVzIHRoYXQgdGhleSBzaG91 bGQgcmVzcG9uZCB0byB0aG9zZSBtYXJrcy4gSG93ZXZlciwgdGhlIG91dGNvbWUNCj4gb2YgdGhl IGxvbmcgZGlzY3Vzc2lvbiB3ZSBoYWQgd2l0aCBNaXJqYSB3YXMgdGhhdCB0aGVyZeKAmXMgbm8g Y29uc2Vuc3VzIG9uIHdoYXTigJlzDQo+IHRoZSBjb3JyZWN0IHJlc3BvbnNlLCBhbmQgY29uY2Vy biB0aGF0IGltcGxlbWVudGF0aW9ucyBwaWNraW5nIHRoZSB3cm9uZw0KPiBjaG9pY2Ugd2lsbCBo aW5kZXIgdGhlIGRlcGxveW1lbnQgb2YgRUNOLg0KDQpVbmRlcnN0b29kLCBhbmQgSSdtIG5vdCBh c2tpbmcgZm9yIHRoYXQuICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcgaW1w bGVtZW50ZXJzDQp3aXRoIHRvbyBtdWNoIGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3Mg KGUuZy4sIGJlY2F1c2UgYW4gaW1wbGVtZW50ZXIgZG9lc24ndA0Kd2FudCB0byB0aGluayBhYm91 dCB0aGlzIHByb2JsZW0gc3BhY2UgaW4gdGhlIGZpcnN0IHBsYWNlKS4NCg0KQ291bGQgc29tZW9u ZSBwcm9wb3NlIGluaXRpYWwgdGV4dCB0byBxdWFsaWZpZXMgdGhlIGN1cnJlbnQgIk1BWSBpZ25v cmUiIHN0YXRlbWVudD8NCg0KSSdtIGxvb2tpbmcgZm9yIHNvbWUgc29ydCBvZiBhcHBsaWNhYmls aXR5IGFuZCBwcmVyZXF1aXNpdGUgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUNCnNpdHVhdGlvbnMg YW5kIGRlc2lnbiBhc3BlY3RzIHRoYXQgb3VnaHQgdG8gYmUgY29uc2lkZXJlZCBiZWZvcmUgYW4g aW1wbGVtZW50YXRpb24NCmRlY2lkZXMgdG8gaWdub3JlIEVDTi1DRSBtYXJrcy4gIA0KDQpUaGFu a3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDb2xp biBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwg SnVuZSAxNSwgMjAxNiAxMTowNCBBTQ0KPiBUbzogQmxhY2ssIERhdmlkDQo+IENjOiBNYWdudXMg V2VzdGVybHVuZDsgSUVURiBBVlRDb3JlIFdHOyBydGN3ZWJAaWV0Zi5vcmc7IHRzdndnDQo+IFN1 YmplY3Q6IFJlOiBbQVZUQ09SRV0gW3RzdndnXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJh ZnQtaWV0Zi1hdnRjb3JlLXJ0cC0NCj4gY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gPiBPbiAx NCBKdW4gMjAxNiwgYXQgMTU6MjAsIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4g d3JvdGU6DQo+ID4NCj4gPj4gVGhpcyByZXN1bHRlZCBpbiBhbm90aGVyIGlzc3VlLCB0aGVyZSBh cmUgbm8gc3BlY2lmaWVkIG1hcmtpbmcgYmVoYXZpb3INCj4gPj4gdGhhdCB3ZSBkZWZpbmUgYW4g YXBwcm9wcmlhdGUgcmVzcG9uc2UgYmFzZWQgb24uIFdoZW4gc3VjaCBhIGJlaGF2aW9yIGlzDQo+ ID4+IGRlZmluZWQgb25lIGNhbiB1cGRhdGUgY2lyY3VpdCBicmVha2VyIHdpdGggYSB3ZWxsIGRl ZmluZWQgcmVzcG9uc2UgdG8NCj4gPj4gRUNOLUNFIG1hcmtzLiBTbyBkdWUgdG8gdGhlIGxhY2sg b2YgZGVmaW5lZCBiZWhhdmlvciB3ZSBkaWRuJ3Qgc2VlIGENCj4gPj4gcG9zc2liaWxpdHkgZm9y IHVzaW5nIFNIT1VMRCBOT1QsIGFzIHdlIGNhbid0IHBvaW50IHRvIHdoYXQgc2hvdWxkIGJlDQo+ ID4+IGltcGxlbWVudGVkLiBUaHVzIHdlIGNob3NlIHRvIHByb3Bvc2UgTUFZIGFzIGl0IHRoZW4g aXMgb3BlbiB0byB0aGUNCj4gPj4gaW1wbGVtZW50YXRpb24gaWYgdGhleSBjYW4gZmluZCBhIHdl bGwgd29ya2luZyByZXNwb25zZSBvciBjb21wbGV0ZWx5DQo+ID4+IGlnbm9yZSB0aGlzLg0KPiA+ DQo+ID4gTXkgcHJvYmxlbSBpcyB0aGF0IHRoZSBuZXcgIk1BWSIgc2VudGVuY2UgaXMgdW5xdWFs aWZpZWQ6DQo+ID4NCj4gPj4+ICAgR2l2ZW4gdGhlIGFib3ZlIGlzc3VlcywgaW1wbGVtZW50YXRp b25zIE1BWSBpZ25vcmUgRUNOLUNFIG1hcmtzIHdoZW4NCj4gPj4+ICAgZGV0ZXJtaW5pbmcgaWYg dGhlIGNvbmdlc3Rpb24gY2lyY3VpdCBicmVha2VyIHRyaWdnZXJzLA0KPiA+DQo+ID4gVGhhdCBp bnZpdGVzIGltcGxlbWVudGVycyB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIHdpdGhvdXQgZ2l2aW5n IHRoaXMgdG9waWMgdGhlDQo+ID4gbGV2ZWwgb2YgY29uc2lkZXJhdGlvbiBhbnRpY2lwYXRlZCBp biB0aGlzIGRpc2N1c3Npb24gYW5kIGVsc2V3aGVyZSBpbiBTZWN0aW9uIDcuDQo+ID4gSWYgIlNI T1VMRCBOT1QiIGxhbmd1YWdlIGlzIHVud29ya2FibGUsIHBsZWFzZSBwcm9wb3NlIGFsdGVybmF0 ZSB0ZXh0IHRoYXQNCj4gPiBxdWFsaWZpZXMgYXBwbGljYWJpbGl0eSBvZiB0aGUgIk1BWSIgLSBl LmcuLCBvbmx5IGFmdGVyIGNhcmVmdWwgY29uc2lkZXJhdGlvbiBvZg0KPiA+IGV2ZXJ5dGhpbmcg dGhhdCB3ZSdyZSBub3cgZGlzY3Vzc2luZyBhbmQgdGhlIHJlc3Qgb2YgdGhlIHRleHQgaW4gU2Vj dGlvbiA3Lg0KPiA+DQo+ID4gSSBwcm9wb3NlZCAiU0hPVUxEIE5PVCIgYmVjYXVzZSBpdCBhcHBl YXIgdGhhdCB0aGUgb3JpZ2luYWwgUkZDIDIxMTkNCj4gZGVmaW5pdGlvbg0KPiA+IG9mIHRoYXQg dGVybSBpcyBhIGdvb2QgZml0IHRvIHRoaXMgc2l0dWF0aW9uOg0KPiA+DQo+ID4gNC4gU0hPVUxE IE5PVCAgIFRoaXMgcGhyYXNlLCBvciB0aGUgcGhyYXNlICJOT1QgUkVDT01NRU5ERUQiIG1lYW4g dGhhdA0KPiA+ICAgdGhlcmUgbWF5IGV4aXN0IHZhbGlkIHJlYXNvbnMgaW4gcGFydGljdWxhciBj aXJjdW1zdGFuY2VzIHdoZW4gdGhlDQo+ID4gICBwYXJ0aWN1bGFyIGJlaGF2aW9yIGlzIGFjY2Vw dGFibGUgb3IgZXZlbiB1c2VmdWwsIGJ1dCB0aGUgZnVsbA0KPiA+ICAgaW1wbGljYXRpb25zIHNo b3VsZCBiZSB1bmRlcnN0b29kIGFuZCB0aGUgY2FzZSBjYXJlZnVsbHkgd2VpZ2hlZA0KPiA+ICAg YmVmb3JlIGltcGxlbWVudGluZyBhbnkgYmVoYXZpb3IgZGVzY3JpYmVkIHdpdGggdGhpcyBsYWJl bC4NCj4gDQo+IFRoZSBpc3N1ZSB3aXRoIHNheWluZyDigJxpbXBsZW1lbnRhdGlvbnMgU0hPVUxE IE5PVCBpZ25vcmUgRUNOLUNFIG1hcmtz4oCdLCBpcw0KPiB0aGF0IGl0IGltcGxpZXMgdGhhdCB0 aGV5IHNob3VsZCByZXNwb25kIHRvIHRob3NlIG1hcmtzLiBIb3dldmVyLCB0aGUgb3V0Y29tZQ0K PiBvZiB0aGUgbG9uZyBkaXNjdXNzaW9uIHdlIGhhZCB3aXRoIE1pcmphIHdhcyB0aGF0IHRoZXJl 4oCZcyBubyBjb25zZW5zdXMgb24gd2hhdOKAmXMNCj4gdGhlIGNvcnJlY3QgcmVzcG9uc2UsIGFu ZCBjb25jZXJuIHRoYXQgaW1wbGVtZW50YXRpb25zIHBpY2tpbmcgdGhlIHdyb25nDQo+IGNob2lj ZSB3aWxsIGhpbmRlciB0aGUgZGVwbG95bWVudCBvZiBFQ04uDQo+IA0KPiANCj4gDQo+IC0tDQo+ IENvbGluIFBlcmtpbnMNCj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiANCj4gDQo+IA0KDQo= From nobody Wed Jun 15 11:20:45 2016 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 3683512DAE6; Wed, 15 Jun 2016 11:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mZ_o7baesiGR; Wed, 15 Jun 2016 11:20:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3E812DADD; Wed, 15 Jun 2016 11:20:34 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5FIKS2G012768; Wed, 15 Jun 2016 11:20:29 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5C4144C3A4BF; Wed, 15 Jun 2016 14:21:06 -0400 (EDT) To: gorry@erg.abdn.ac.uk From: Mark Allman In-Reply-To: <575BBC10.3080905@abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Honky Tonk Woman X-URL-0: http://www.icir.org/mallman-files/Document93975.doc X-URL-1: http://www.icir.org/mallman-files/Document23723.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 Jun 2016 14:21:06 -0400 Message-ID: <52397.1466014866@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] Some comments on draft-ietf-tcpm-rto-consider-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 18:20:42 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Gorry! Responses to Gorry's lengthy feedback (thanks!) inline. Also, I have issued an -04 that takes into account this feedback and offline conversations with Gorry, David and others. It is available now: The whole draft has undergone some editing, but sections 1 & 2 could use some review. (Although the entire document is short, so if you can, please look it over.) https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ http://www.icir.org/mallman/pubs/All16a/ Comments, please! allman > * Introduction/Scope. Re-worked substantially. > * Comments on the recommendations >=20 > - Some of these comments relate I think to assumptions about TCP > specifics, that could be generalised, or may be handed in the > introduction. >=20 > (1) > "the > RTO MUST be conservatively set to no less than 1 second." > - If this is TCP or SCTP, then RTO is defined. If more is intended > RTO needs to have been defined. New intro defines it. > " For instance, consider a DNS request from a client to a > resolver. When the request can be served from the resolver's > cache the FT likely well approximates the network RTT between > the client and resolver. However, on a cache miss the resolver > will have to request the needed information from authoritative > DNS servers, which will non-trivially increase the FT and > therefore the FT between the client and resolver does not well > match the network-based RTT between the two hosts." >=20 > - If the transport is assumed as DNS/UDP, this needs to be said in > the example, up until this point the ID only discusses TCP and > clearly DNS/TCP does not have this concern. Yes, implicit assumption of UDP. Now explicit. Good catch. Thanks.=20 > " (b) FT observations MUST be taken regularly." I have re-factored the text a bit in -04. You might like it better. I think it reads better. Although the intent did not change. > - The language below seems inappropriate in a MUST clause, I think > this implies it is a SHOULD, and the exception conditions do need to > be discussed, since the period isn't stated, how is this normative > requirement to be interpreted? I guess I don't follow. I read this as "you MUST take FT samples regularly" and "regularly SHOULD be once / RTT (or as often as you exchange data if less frequently than once / RTT". I.e., the MUST and the SHOULD are about different things. I tried to make the words more clearly delineate this in -04. > - Maybe this text needs clarification: The current wording > requirement could be read to contradict RFC5405, that avoids against > sending UDP probes and traffic when an application is idle. This > needs more careful explanation. Even for TCP/SCTP, I would not > advocate requiring keep-alive or heartbeat packets as suggested by > "the requirement that the FT be sampled continuously throughout the > lifetime of a connection." See below (where you return to this issue). > "For the purpose of this > requirement, we state that FT samples SHOULD be taken at > least once per RTT or as frequently as data is exchanged and > ACKed if that happens less frequently than every RTT." > and later: > " Hence, this once-per-RTT sampling requirement is explicitly > a "SHOULD" and not a "MUST". >=20 > " However, we also recognize that it may not always be > practical to take a FT sample this often in all cases." >=20 > -I agree with the =E2=80=9CSHOULD=E2=80=9D from the perspective of TCP, s= ome methods > respond more slowly to congestion that TCP, and sample less > often. How does this relate to the various repair mechanisms in RTP? > (they also can have timers and retransmit) - are these counter > examples where the SHOULD does not apply? This isn't about how often we respond to congestion. That is orthogonal to this document. We are trying to schedule retransmissions. So, what we really want to know---and I think this is now better defined in the intro text you have seen---is how long we should await delivery confirmation before tripping a retransmit. That confirmation could be dictated by the network RTT. Or, be longer than that depending on protocol operation. That is why the document uses "FT" and not "RTT". So, I am not sure where you're going here with the congestion responses. > =E2=80=9C(c) FT samples used in the computation of the RTO MUST NOT be > ambiguous.=E2=80=9D >=20 > - I read this requirement is on the samples. That's not > correct. Maybe it should be > more like: > "An RTO algorithm MUST NOT use FT samples that are ambiguous when > calculating the RTO." I changed it to this in -04: (d) An RTO mechanism MUST NOT use ambiguous FT samples. ( (c) is now something else---see below---and so this changed to (d) ) > - I wonder if section 3 could also talk about other ways to measure > RTTs when not sending data, such as keepalive and SCTP heartbeat > messages. We don't always care about measuring RTTs. So, we have to be careful here, but I have added a 2(c) in section 3 on this topic. It says: (c) FT observations MAY be taken from non-data exchanges. Some protocols use keepalives, heartbeats or other messages to exchange control information. To the extent that the latency of these transactions mirrors data exchange, they can be leveraged to take FT samples within the RTO mechanism. Such samples can help protocols keep their RTO accurate during lulls in data transmission. However, given that these messages may not be subject to the same delays as data transmission, we do not take a general view on whether this is useful or not. > "The backoff may be removed > after the successful transmission of non-retransmitted data." >=20 > - The "may" appears to be protocol permission, can it be "MAY=E2=80=9D? I think this comes from 6298 wording---which I just checked and is not in protocol permission language. I think you're correct here. I have changed it in -04 to be more precise all the way around: The backoff SHOULD be removed after the successful repair of the lost data and subsequent transmission of non-retransmitted data. > " A maximum value MAY be placed on the RTO provided it is at least > 60 seconds (a la [RFC6298])." >=20 > - To me, there seem to be two requirements here: >=20 > " A maximum value MAY be placed on the RTO. The maximum MUST NOT exceed > 60 seconds (as in [RFC6298])." Sounds reasonable. And, especially so since you mis-understood it and translated it wrong! :) The version in -04 is ... A maximum value MAY be placed on the RTO. The maximum RTO MUST NOT be less than 60 seconds (a la [RFC6298]). > (4) "An exception is made to this rule if an IETF standardized > mechanism is used to determine that a particular loss is due to > a non-congestion event (e.g., packet corruption)." >=20 > - NiT: I wonder if this can be mis-cited? There are as yet no specs > in the space published in the RFC series. Could we be more careful > on endorsing this work, and say perhaps that "exceptions could be > made to this rule if an IETF standardized ... . Good call. I made this change. > "Additionally, > RTO-triggered congestion control actions may be reversed when a > standard mechanism determines that the cause of the loss was not > congestion after all." >=20 > - Examples from the RFC series exist, and would be good. E.g. Eifel > or something else? I added an "(e.g., [RFC5682])". Good call. > - Is this the place to define "spurious", since this is used later. Hm. I was trying to figure out how to cleanly wedge that in, but I couldn't find something I liked. Instead I tweaked the intro at the first use of "spurious". > " We note that research has shown the tension between the > responsiveness and correctness of retransmission timeouts seems to > be a fundamental tradeoff [AP99]." > - I think this paper is about TCP, and I think the tension is clear > for protocols like TCP. I added a note. > "While the implication of these deviations > from the standard may be more spurious retransmits (per [AP99]), we > are aware of no large scale problems caused by this change to the > minimum RTO." >=20 > - I'd like to argue that a lower RTO can reduce performance for > paths where this RTO can be set below the RTT. Such paths do exist, > and middleboxes sometimes split TCP connections to overcome this > issue. I think at least the ID should note the issue, even if it > claims that these paths are somehow accommodated within the > guidance. I do not quite understand this. I am not conjuring a case where the timeout could ever be less than the RTT.=20=20 A middlebox can split the TCP connection so we end up with two connections A<->M and M<->B. Are you considering the "RTT" to be A<->B and are then saying A can actually retransmit based on the A<->M delay? Sure. But, in this case I am not sure how A's TCP will ever know the A<->B "RTT". For non-TCP protocols that have a higher layer delivery confirmation mechanism that comes from B I could see this. However, in this case, I am not sure how we'd know to retransmit on A<->M timescales. Basically I am confused here. I am happy to address this if you can explain to me what you mean. > * Standards status and RFC 2119 recommendations. >=20 > "nor limit future standardization of specific RTO mechanisms." > - I'd need advice, but I thought BCPs did exactly this. Paraphrasing > slightly, the purpose of the RFC5405 was to impose default > constraints that future RFCs have to justify their choices > against. That's limiting. The MUSTs are real requirements and the > SHOULD strong desirables. The feedback we have to the RFC5405.bis is > to stengthen more SHOULDs to MUSTs - I'm going to speak to my ADs > before I agree to any of these. But if the IESG agree, then I think > that is what BCP status is about. >=20 > Scope (a) I don=E2=80=99t disagree, unless the community explicity update= s a > spec a new BCP doesn't change old RFCs. >=20 > Scope (v) - To me seems weird. Because it seems to set a "SHOULD" > over the entire document, and that document contains MUSTs. I can't > see how an RFC can have a "SHOULD-MUST", but likely the ADs can > advise during WGLC. (This has all been removed / changed in a big way. So, I am not commenting on it.) > I worry the following can be cited elsewhere as compliance of a > protocol or mechanism by the IETF, when really I think this is > intended to define an acceptable RTO response. Some tightening of > the language would seem appropriate: >=20 > "RTO mechanisms that are not standardized but adhere to the > requirements in the following section are deemed consistent with > the standards. " > - sounds dangerously wide when cited as text - I was presuming the > document intended "are deemed consistent with > the standards in the RTO behaviour" - or something, I presume you > don't want people to cite this RFC saying their new protocol foo-bar > is "consistent with IETF standards" because it does this. >=20 > "an implementation is considered standards compliant" > - I quibble again here on language, because I don't think this is > true generally of the protocol, only true of their RTO response. (This has all been removed / changed in a big way. So, I am not commenting on it.) > "In other words, the requirements in this document can be viewed as > specifying the default properties of an RTO mechanism." > - This seems like an informational statement that could be cited as > a contradiction to the RFC2119 text unless worded carefully? This > sort of text needs AD advice if kept. >=20 > "Specifications can more concretely nail down specifics within these > defaults or work outside the defaults as necessary." > - The same comment on the second half of this sentence. I removed the word "default" from the document. I think the last paragraph of the intro better addresses things now. > "That is, this document's > stance is to not limit the community's ability to make exceptions > to the requirements herein for particular cases." > - If this is BCP, I think this needs to be tighter, I don't think > any ID can expect to automatically make exceptions to a BCP, by > simply saying "the WG decided differently" if you want that, then I > think this document needs to be INFO (I'm not the Chair or AD for > the document). If it's BCP, I'd expect the consensus to set the best > current practice and the ADs to block new RFCs with at least a > DISCUSS to work out why WG XXX was going against what has been IETF > consensus. I don't think you can go info and make the same sort of requirements. I don't really disagree with what you say. I.e., I would expect that if this were a BCP that it would be taken into account when designing RTOs. And, if something wanted to be more aggressive or do something outside the requirements that this be done explicitly with the BCP text as context. I.e., I would expect that the WG would consider this and have an answer for why the deviation is OK far before it hits the IESG. > "However, > implementations that fall within the defaults do not require > explicit specifications to be considered consistent with the > standards." > - I could not parse this sentence, it sounds like it could be > normative language without a keyword. Text is gone in -04. > Section 3: >=20 > "We now list the requirements that SHOULD apply when designing > retransmission timeout (RTO) mechanisms." > - this seems to scope a "MUST" with a preceding "SHOULD". I question > if this is allowed in a BCP. I understand what is meant. But, it is not important enough in this instance to argue about, IMO, and so I nuked the SHOULD normative language from the beginning of section 3. --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldhnI8ACgkQWyrrWs4yIs5BvACggU2U8DRtvGil7m1+NQgL6nHA P2sAnRuE63zaJTFZE7hHmmjqaqKjSU36 =rVR8 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jun 15 13:13:49 2016 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 5808912DB4D; Wed, 15 Jun 2016 13:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 242GUliZqxNX; Wed, 15 Jun 2016 13:13:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACA612DB3F; Wed, 15 Jun 2016 13:13:43 -0700 (PDT) Received: from [128.9.184.95] ([128.9.184.95]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5FKCVX2010402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jun 2016 13:12:32 -0700 (PDT) To: Lloyd Wood , Softwires WG , "int-area@ietf.org" , "lisp@ietf.org" , "tsvwg@ietf.org" , Xuxiaohu , "nvo3@ietf.org" References: <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <974977917.2492241.1465708308527.JavaMail.yahoo@mail.yahoo.com> From: Joe Touch Message-ID: <5761B6AF.8030107@isi.edu> Date: Wed, 15 Jun 2016 13:12:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <974977917.2492241.1465708308527.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------030502040200010703010909" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Is it feasible to perform fragmentation on UDP encapsulated packets. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:13:47 -0000 This is a multi-part message in MIME format. --------------030502040200010703010909 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 6/11/2016 10:11 PM, Lloyd Wood wrote: > Fragmentation should be strongly discouraged. Avoided where possible for sure. > > if you've designed a tunnelling solution and you have fragmentation > happening as a matter of course, you've designed it wrong. If you have a solution that recurses (X over X, with some intervening layers or not), and X has a required minimum message size, then you either have a solution that - in at least some non-trivial situations - will fragment as a matter of course or a fantasy that cannot exist. The only reason we avoid this in typical operation is by avoiding X over X. Once you have a tunnel, that might not be avoidable (or even detectable, depending on encryption). Joe > > Lloyd Wood > lloyd.wood@yahoo.co.uk > > On Friday, May 27, 2016, 8:10 PM, Xuxiaohu wrote: > > nothing to do with the WG adoption call now. It's just a > discussion on a particular issue which is related to those WGs > which are working on UDP tunnels. The reason for containing the > old email is to use it as a background which may be useful for > better understanding of this particular issue> > > The possible side-effect of performing fragmentation on UDP > encapsulated packets is to worsen the reassembly burden on tunnel > egress since fragments of UDP encapsulated packets are more likely > to be forwarded across different paths towards the tunnel egress > than those of IP or GRE encapsulated packets. > > It seems that most X-over-UDP proposals choose to prohibit the > tunnel ingress from performing fragmentation on UDP encapsulated > packets. See the following quoted text regarding fragmentation > from those X-over-UDP drafts: > > LISP: > > When an ITR receives a packet from a site-facing interface and adds H > octets worth of encapsulation to yield a packet size greater than L > octets, it resolves the MTU issue by first splitting the original > packet into 2 equal-sized fragments. A LISP header is then > prepended > to each fragment. > > VXLAN: > > VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may > fragment encapsulated VXLAN packets due to the larger frame size. > The destination VTEP MAY silently discard such VXLAN fragments. > > VXLAN-GPE: > > VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when > the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer > IPv4 header. > > GEVENE: > > To prevent fragmentation and maximize performance, the best practice > when using Geneve is to ensure that the MTU of the physical network > is greater than or equal to the MTU of the encapsulated network plus > tunnel headers. > > GUE: > > If a packet is fragmented before encapsulation in GUE, all the > related fragments must be encapsulated using the same source port > (inner flow identifier). An operator may set MTU to account for > encapsulation overhead and reduce the likelihood of fragmentation. > > GRE/UDP > > Regarding packet fragmentation, an encapsulator/decapsulator SHOULD > be compliant with [RFC7588] and perform fragmentation before the > encapsulation. > > However, the above choice seems conflict with the requirements as > described in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02 > > > I wonder whether the IETF should reach a consensus on whether or > not the fragmentation on UDP encapsulated packets should be allowed. > > Best regards, > Xiaohu > > > -----Original Message----- > > From: Xuxiaohu > > Sent: Thursday, May 26, 2016 4:35 PM > > To: 'Joe Touch'; Fred Baker (fred); Wassim Haddad > > Cc: int-area@ietf.org > > Subject: RE: [Int-area] Call for adoption of > draft-xu-intarea-ip-in-udp-03 > > > > > > > > > -----Original Message----- > > > From: Joe Touch [mailto:touch@isi.edu ] > > > Sent: Thursday, May 26, 2016 2:11 AM > > > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad > > > Cc: int-area@ietf.org > > > Subject: Re: [Int-area] Call for adoption of > > > draft-xu-intarea-ip-in-udp-03 > > > > > > > > > > > > On 5/24/2016 7:24 PM, Xuxiaohu wrote: > > > > Hi Joe, > > > > > > > > I wonder whether you want to tell me the following truth by the > > > > example that you gave: no matter whatever improvements we > had done > > > > with this draft, those persons who dislike it by the light > of nature > > > > would dislike it in the end. > > > > > > The only improvements that would make this doc useful would be > to add > > > capabilities already in GRE/UDP or GUE/UDP, which we already have. > > > > Let's go over the four things you mentioned earlier in GRE/UDP > and GUE/UDP: > > > > - stronger checksums > > > > In GRE/UDP, in order to use UDP-zero-checksum, it gave the following > > restrictions: > > " 6. UDP Checksum Handling > > > > 6.1. UDP Checksum with IPv4 > > > > For UDP in IPv4, the UDP checksum MUST be processed as > specified in > > [RFC768] and [RFC1122] for both transmit and receive. The IPv4 > > > > > > > > Yong, Crabber, Xu, Herbert > [Page 12] > > > -------------------------------------------------------------------------------- > > > > Internet-Draft GRE-in-UDP Encapsulation > March 2016 > > > > header includes a checksum which protects against mis-delivery of > > the packet due to corruption of IP addresses. The UDP checksum > > potentially provides protection against corruption of the UDP > header, > > GRE header, and GRE payload. Disabling the use of checksums is a > > deployment consideration that should take into account the > risk and > > effects of packet corruption. > > > > When a decapsulator receives a packet, the UDP checksum field > MUST > > be processed. If the UDP checksum is non-zero, the > decapsulator MUST > > verify the checksum before accepting the packet. By default a > > decapsulator SHOULD accept UDP packets with a zero checksum. > A node > > MAY be configured to disallow zero checksums per [RFC1122]; > this may > > be done selectively, for instance disallowing zero checksums from > > certain hosts that are known to be sending over paths subject to > > packet corruption. If verification of a non-zero checksum > fails, a > > decapsulator lacks the capability to verify a non-zero > checksum, or > > a packet with a zero-checksum was received and the > decapsulator is > > configured to disallow, the packet MUST be dropped and an > event MAY > > be logged. > > > > 6.2. UDP Checksum with IPv6 > > > > For UDP in IPv6, the UDP checksum MUST be processed as > specified in > > [RFC768] and [RFC2460] for both transmit and receive. > > > > When UDP is used over IPv6, the UDP checksum is relied upon to > > protect both the IPv6 and UDP headers from corruption. As such, A > > default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE > GRE-in- > > UDP Tunnel MAY be configured with the UDP zero-checksum mode > if the > > traffic-managed controlled environment or a set of closely > > cooperating traffic-managed controlled environments (such as by > > network operators who have agreed to work together in order to > > jointly provide specific services) meet at least one of following > > conditions: > > > > a. It is known (perhaps through knowledge of equipment types and > > lower layer checks) that packet corruption is exceptionally > > unlikely and where the operator is willing to take the risk of > > undetected packet corruption. > > > > b. It is judged through observational measurements (perhaps of > > historic or current traffic flows that use a non-zero checksum) > > that the level of packet corruption is tolerably low and where > > the operator is willing to take the risk of undetected packet > > corruption. > > > > > > > > > > > > Yong, Crabber, Xu, Herbert > [Page 13] > > > -------------------------------------------------------------------------------- > > > > Internet-Draft GRE-in-UDP Encapsulation > March 2016 > > > > c. Carrying applications that are tolerant of mis-delivered or > > corrupted packets (perhaps through higher layer checksum, > > validation, and retransmission or transmission redundancy) > where > > the operator is willing to rely on the applications using the > > tunnel to survive any corrupt packets. > > > > The following requirements apply to a TMCE GRE-in-UDP tunnel that > > use UDP zero-checksum mode: > > > > a. Use of the UDP checksum with IPv6 MUST be the default > > configuration of all GRE-in-UDP tunnels. > > > > b. The GRE-in-UDP tunnel implementation MUST comply with all > > requirements specified in Section 4 of [RFC6936] and with > > requirement 1 specified in Section 5 of [RFC6936]. > > > > c. The tunnel decapsulator SHOULD only allow the use of UDP > zero- > > checksum mode for IPv6 on a single received UDP Destination > > Port regardless of the encapsulator. The motivation for this > > requirement is possible corruption of the UDP Destination > Port, > > which may cause packet delivery to the wrong UDP port. If > that > > other UDP port requires the UDP checksum, the mis-delivered > > packet will be discarded. > > > > d. It is RECOMMENDED that the UDP zero-checksum mode for > IPv6 is > > only enabled for certain selected source addresses. The > tunnel > > decapsulator MUST check that the source and destination IPv6 > > addresses are valid for the GRE-in-UDP tunnel on which the > > packet was received if that tunnel uses UDP zero-checksum > mode > > and discard any packet for which this check fails. > > > > e. The tunnel encapsulator SHOULD use different IPv6 > addresses for > > each GRE-in-UDP tunnel that uses UDP zero-checksum mode > > regardless of the decapsulator in order to strengthen the > > decapsulator's check of the IPv6 source address (i.e., > the same > > IPv6 source address SHOULD NOT be used with more than one > IPv6 > > destination address, independent of whether that destination > > address is a unicast or multicast address). When this is not > > possible, it is RECOMMENDED to use each source IPv6 > address for > > as few UDP zero-checksum mode GRE-in-UDP tunnels as is > feasible. > > > > f. When any middlebox exists on the path of a GRE-in-UDP > tunnel, > > it is RECOMMENDED to use the default mode, i.e. use UDP > > checksum, to reduce the chance that the encapsulated > packets to > > be dropped. > > > > > > > > > > > > Yong, Crabber, Xu, Herbert > [Page 14] > > > -------------------------------------------------------------------------------- > > > > Internet-Draft GRE-in-UDP Encapsulation > March 2016 > > > > g. Any middlebox that allows the UDP zero-checksum mode for > IPv6 > > MUST comply with requirement 1 and 8-10 in Section 5 of > > [RFC6936]. > > > > h. Measures SHOULD be taken to prevent IPv6 traffic with > zero UDP > > checksums from "escaping" to the general Internet; see > Section > > 8 for examples of such measures. > > > > i. IPv6 traffic with zero UDP checksums MUST be actively > monitored > > for errors by the network operator. For example, the operator > > may monitor Ethernet layer packet error rates. > > > > j. If a packet with a non-zero checksum is received, the > checksum > > MUST be verified before accepting the packet. This is > > regardless of whether the tunnel encapsulator and > decapsulator > > have been configured with UDP zero-checksum mode. > > > > The above requirements do not change either the requirements > > specified in [RFC2460] as modified by [RFC6935] or the > requirements > > specified in [RFC6936]. > > > > The requirement to check the source IPv6 address in addition > to the > > destination IPv6 address, plus the strong recommendation against > > reuse of source IPv6 addresses among GRE-in-UDP tunnels > collectively > > provide some mitigation for the absence of UDP checksum > coverage of > > the IPv6 header. A traffic-managed controlled environment that > > satisfies at least one of three conditions listed above in this > > section provides additional assurance. > > > > A GRE-in-UDP tunnel is suitable for transmission over lower > layers > > in the traffic-managed controlled environments that are > allowed by > > the exceptions stated above and the rate of corruption of the > inner > > IP packet on such networks is not expected to increase by > comparison > > to GRE traffic that is not encapsulated in UDP. For these > reasons, > > GRE-in-UDP does not provide an additional integrity check except > > when GRE checksum is used when UDP zero-checksum mode is used > with > > IPv6, and this design is in accordance with requirements 2, 3 > and 5 > > specified in Section 5 of [RFC6936]. > > > > Generic Router Encapsulation (GRE) does not accumulate incorrect > > state as a consequence of GRE header corruption. A corrupt GRE > > packet may result in either packet discard or forwarding of the > > packet without accumulation of GRE state. Active monitoring > of GRE- > > in-UDP traffic for errors is REQUIRED as occurrence of errors > will > > result in some accumulation of error information outside the > > protocol for operational and management purposes. This design > is in > > accordance with requirement 4 specified in Section 5 of > [RFC6936]. > > > > > > > > Yong, Crabber, Xu, Herbert > [Page 15] > > > -------------------------------------------------------------------------------- > > > > Internet-Draft GRE-in-UDP Encapsulation > March 2016 > > > > The remaining requirements specified in Section 5 of > [RFC6936] are > > not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply > > because GRE does not include a control feedback mechanism. > > Requirements 8-10 are middlebox requirements that do not apply to > > GRE-in-UDP tunnel endpoints (see Section 7.1 for further > middlebox > > discussion). > > > > It is worth mentioning that the use of a zero UDP checksum should > > present the equivalent risk of undetected packet corruption when > > sending similar packet using GRE-in-IPv6 without UDP > [RFC7676] and > > without GRE checksums. > > > > In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero- > > checksum mode for IPv6 when the conditions and requirements > stated > > above are met. Otherwise the UDP checksum need to be used for > IPv6 > > as specified in [RFC768] and [RFC2460]. Use of GRE checksum is > > RECOMMENED when the UDP checksum is not used. > > " > > > > In GUE, to support UDP-checksum-zero, it said > > > > " Therefore, when GUE is used over > > IPv6, either the UDP checksum must be enabled or the GUE header > > checksum must be used. An encapsulator MAY set a zero UDP > checksum > > for performance or implementation reasons, in which case the GUE > > header checksum MUST be used or applicable requirements for using > > zero UDP checksums in [GREUDP] MUST be met. If the UDP > checksum is > > enabled, then the GUE header checksum should not be used > since it is > > mostly redundant." > > > > It's easy for me to add the similar words to the IP-in-UDP draft > like "the > > applicable requirements for using zero UDP checksum in [GREUDP] > MUST be > > met when zero UDP checksum is used by the tunnel ingress". > However, the > > major goal for disabling the UDP checksum is to improve the > performance. > > When GUE header checksum is used and/or the bunch of applicable > > requirements as described in GRE/UDP are verified, is the goal > of improving > > performance still achievable? If not, why not directly enable > the UDP-checksum > > instead? > > > > - fragmentation support > > > > In GRE/UDP, it said > > > > " 4.1. MTU and Fragmentation > > > > Regarding packet fragmentation, an encapsulator/decapsulator > SHOULD > > be compliant with [RFC7588] and perform fragmentation before the > > encapsulation. The size of fragments SHOULD be less or equal > to the > > PMTU associated with the path between the GRE ingress and the GRE > > egress tunnel endpoints minus the GRE and UDP overhead ..." > > > > in GUE, it said > > > > " 4.9. MTU and fragmentation > > > > Standard conventions for handling of MTU (Maximum > Transmission Unit) > > and fragmentation in conjunction with networking tunnels > > (encapsulation of layer 2 or layer 3 packets) should be followed. > > Details are described in MTU and Fragmentation Issues with > In-the- > > Network Tunneling [RFC4459]... " > > > > It seems that the only missing thing in the IP-in-UDP draft is > to allow the outer > > fragmentation. However, as it said in > > > (https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02#page-13), > " ...IPsec > > performs only Outer Fragmentation; this distinguishes it from > IP-in-IP, which > > performs only Inner Fragmentation. " Note that IP-in-IP is the > dominant > > encapsulation choice within Softwires networks. In other words, > performing > > only inner fragmentation works very well in practice. > Furthermore, the outer > > fragmentation issue (e.g., reassembly cost for the egress) would > become even > > worse since the fragments of X-in-UDP packets are more likely to > be forwarded > > across different paths than those of X-in-IP and X-in-GRE > packets. Hence, I'm > > wondering whether it's worthwhile to support the outer > fragmentation on UDP > > encapsulated packets which seems useless in practice. > > > > - signalling support (e.g., to test whether a tunnel is up or > > to measure MTUs) > > > > I haven't found any description of this in both GRE/UDP and GUE. > Did you? > > > > - support for robust ID fields (related to fragmentation, > > e.g., to overcome the limits of IPv4 ID as per RFC 6864) > > > > I haven't found any description of this in both GRE/UDP and GUE. > Did you? > > > > Xiaohu > > > > > It is not our obligation to find a way for your document to > proceed - > > > that onus is on you. > > > > > > Joe > --------------030502040200010703010909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 6/11/2016 10:11 PM, Lloyd Wood wrote:
Fragmentation should be strongly discouraged.

Avoided where possible for sure.

if you've designed a tunnelling solution and you have fragmentation happening as a matter of course, you've designed it wrong.

If you have a solution that recurses (X over X, with some intervening layers or not), and X has a required minimum message size, then you either have a solution that - in at least some non-trivial situations - will fragment as a matter of course or a fantasy that cannot exist.

The only reason we avoid this in typical operation is by avoiding X over X. Once you have a tunnel, that might not be avoidable (or even detectable, depending on encryption).

Joe


Lloyd Wood

On Friday, May 27, 2016, 8:10 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

<Note that I have changed the subject of the email hence it has nothing to do with the WG adoption call now. It's just a discussion on a particular issue which is related to those WGs which are working on UDP tunnels. The reason for containing the old email is to use it as a background which may be useful for better understanding of this particular issue>

The possible side-effect of performing fragmentation on UDP encapsulated packets is to worsen the reassembly burden on tunnel egress since fragments of UDP encapsulated packets are more likely to be forwarded across different paths towards the tunnel egress than those of IP or GRE encapsulated packets.

It seems that most X-over-UDP proposals choose to prohibit the tunnel ingress from performing fragmentation on UDP encapsulated packets. See the following quoted text regarding fragmentation from those X-over-UDP drafts:

LISP:

When an ITR receives a packet from a site-facing interface and adds H
  octets worth of encapsulation to yield a packet size greater than L
  octets, it resolves the MTU issue by first splitting the original
  packet into 2 equal-sized fragments.  A LISP header is then prepended
  to each fragment.

VXLAN:

VTEPs MUST NOT fragment VXLAN packets.  Intermediate routers may
  fragment encapsulated VXLAN packets due to the larger frame size.
  The destination VTEP MAY silently discard such VXLAN fragments.

VXLAN-GPE:

VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when
  the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer
  IPv4 header.

GEVENE:

  To prevent fragmentation and maximize performance, the best practice
  when using Geneve is to ensure that the MTU of the physical network
  is greater than or equal to the MTU of the encapsulated network plus
  tunnel headers.

GUE:

    If a packet is fragmented before encapsulation in GUE, all the
    related fragments must be encapsulated using the same source port
    (inner flow identifier). An operator may set MTU to account for
    encapsulation overhead and reduce the likelihood of fragmentation.

GRE/UDP

Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
  be compliant with [RFC7588] and perform fragmentation before the
  encapsulation.

However, the above choice seems conflict with the requirements as described in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02


I wonder whether the IETF should reach a consensus on whether or not the fragmentation on UDP encapsulated packets should be allowed.
 
Best regards,
Xiaohu

> -----Original Message-----
> From: Xuxiaohu
> Sent: Thursday, May 26, 2016 4:35 PM
> To: 'Joe Touch'; Fred Baker (fred); Wassim Haddad
> Cc: int-area@ietf.org
> Subject: RE: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03
>
>
>
> > -----Original Message-----
> > From: Joe Touch [mailto:touch@isi.edu]
> > Sent: Thursday, May 26, 2016 2:11 AM
> > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad
> > Cc: int-area@ietf.org
> > Subject: Re: [Int-area] Call for adoption of
> > draft-xu-intarea-ip-in-udp-03
> >
> >
> >
> > On 5/24/2016 7:24 PM, Xuxiaohu wrote:
> > > Hi Joe,
> > >
> > > I wonder whether you want to tell me the following truth by the
> > > example that you gave: no matter whatever improvements we had done
> > > with this draft, those persons who dislike it by the light of nature
> > > would dislike it in the end.
> >
> > The only improvements that would make this doc useful would be to add
> > capabilities already in GRE/UDP or GUE/UDP, which we already have.
>
> Let's go over the four things you mentioned earlier in GRE/UDP and GUE/UDP:
>
>     - stronger checksums
>
> In GRE/UDP, in order to use UDP-zero-checksum, it gave the following
> restrictions:
> " 6. UDP Checksum Handling
>
>    6.1. UDP Checksum with IPv4
>
>    For UDP in IPv4, the UDP checksum MUST be processed as specified in
>    [RFC768] and [RFC1122] for both transmit and receive. The IPv4
>
>
>
> Yong, Crabber, Xu, Herbert                                    [Page 12]
> --------------------------------------------------------------------------------
>
> Internet-Draft          GRE-in-UDP Encapsulation            March 2016
>
>    header includes a checksum which protects against mis-delivery of
>    the packet due to corruption of IP addresses. The UDP checksum
>    potentially provides protection against corruption of the UDP header,
>    GRE header, and GRE payload. Disabling the use of checksums is a
>    deployment consideration that should take into account the risk and
>    effects of packet corruption.
>
>    When a decapsulator receives a packet, the UDP checksum field MUST
>    be processed. If the UDP checksum is non-zero, the decapsulator MUST
>    verify the checksum before accepting the packet. By default a
>    decapsulator SHOULD accept UDP packets with a zero checksum. A node
>    MAY be configured to disallow zero checksums per [RFC1122]; this may
>    be done selectively, for instance disallowing zero checksums from
>    certain hosts that are known to be sending over paths subject to
>    packet corruption. If verification of a non-zero checksum fails, a
>    decapsulator lacks the capability to verify a non-zero checksum, or
>    a packet with a zero-checksum was received and the decapsulator is
>    configured to disallow, the packet MUST be dropped and an event MAY
>    be logged.
>
>    6.2. UDP Checksum with IPv6
>
>    For UDP in IPv6, the UDP checksum MUST be processed as specified in
>    [RFC768] and [RFC2460] for both transmit and receive.
>
>    When UDP is used over IPv6, the UDP checksum is relied upon to
>    protect both the IPv6 and UDP headers from corruption. As such, A
>    default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in-
>    UDP Tunnel MAY be configured with the UDP zero-checksum mode if the
>    traffic-managed controlled environment or a set of closely
>    cooperating traffic-managed controlled environments (such as by
>    network operators who have agreed to work together in order to
>    jointly provide specific services) meet at least one of following
>    conditions:
>
>    a. It is known (perhaps through knowledge of equipment types and
>      lower layer checks) that packet corruption is exceptionally
>      unlikely and where the operator is willing to take the risk of
>      undetected packet corruption.
>
>    b. It is judged through observational measurements (perhaps of
>      historic or current traffic flows that use a non-zero checksum)
>      that the level of packet corruption is tolerably low and where
>      the operator is willing to take the risk of undetected packet
>      corruption.
>
>
>
>
>
> Yong, Crabber, Xu, Herbert                                    [Page 13]
> --------------------------------------------------------------------------------
>
> Internet-Draft          GRE-in-UDP Encapsulation            March 2016
>
>    c. Carrying applications that are tolerant of mis-delivered or
>      corrupted packets (perhaps through higher layer checksum,
>      validation, and retransmission or transmission redundancy) where
>      the operator is willing to rely on the applications using the
>      tunnel to survive any corrupt packets.
>
>    The following requirements apply to a TMCE GRE-in-UDP tunnel that
>    use UDP zero-checksum mode:
>
>      a. Use of the UDP checksum with IPv6 MUST be the default
>        configuration of all GRE-in-UDP tunnels.
>
>      b. The GRE-in-UDP tunnel implementation MUST comply with all
>        requirements specified in Section 4 of [RFC6936] and with
>        requirement 1 specified in Section 5 of [RFC6936].
>
>      c. The tunnel decapsulator SHOULD only allow the use of UDP zero-
>        checksum mode for IPv6 on a single received UDP Destination
>        Port regardless of the encapsulator. The motivation for this
>        requirement is possible corruption of the UDP Destination Port,
>        which may cause packet delivery to the wrong UDP port. If that
>        other UDP port requires the UDP checksum, the mis-delivered
>        packet will be discarded.
>
>      d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is
>        only enabled for certain selected source addresses. The tunnel
>        decapsulator MUST check that the source and destination IPv6
>        addresses are valid for the GRE-in-UDP tunnel on which the
>        packet was received if that tunnel uses UDP zero-checksum mode
>        and discard any packet for which this check fails.
>
>      e. The tunnel encapsulator SHOULD use different IPv6 addresses for
>        each GRE-in-UDP tunnel that uses UDP zero-checksum mode
>        regardless of the decapsulator in order to strengthen the
>        decapsulator's check of the IPv6 source address (i.e., the same
>        IPv6 source address SHOULD NOT be used with more than one IPv6
>        destination address, independent of whether that destination
>        address is a unicast or multicast address). When this is not
>        possible, it is RECOMMENDED to use each source IPv6 address for
>        as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible.
>
>      f. When any middlebox exists on the path of a GRE-in-UDP tunnel,
>        it is RECOMMENDED to use the default mode, i.e. use UDP
>        checksum, to reduce the chance that the encapsulated packets to
>        be dropped.
>
>
>
>
>
> Yong, Crabber, Xu, Herbert                                    [Page 14]
> --------------------------------------------------------------------------------
>
> Internet-Draft          GRE-in-UDP Encapsulation            March 2016
>
>      g. Any middlebox that allows the UDP zero-checksum mode for IPv6
>        MUST comply with requirement 1 and 8-10 in Section 5 of
>        [RFC6936].
>
>      h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
>        checksums from "escaping" to the general Internet; see Section
>        8 for examples of such measures.
>
>      i. IPv6 traffic with zero UDP checksums MUST be actively monitored
>        for errors by the network operator. For example, the operator
>        may monitor Ethernet layer packet error rates.
>
>      j. If a packet with a non-zero checksum is received, the checksum
>        MUST be verified before accepting the packet. This is
>        regardless of whether the tunnel encapsulator and decapsulator
>        have been configured with UDP zero-checksum mode.
>
>    The above requirements do not change either the requirements
>    specified in [RFC2460] as modified by [RFC6935] or the requirements
>    specified in [RFC6936].
>
>    The requirement to check the source IPv6 address in addition to the
>    destination IPv6 address, plus the strong recommendation against
>    reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively
>    provide some mitigation for the absence of UDP checksum coverage of
>    the IPv6 header. A traffic-managed controlled environment that
>    satisfies at least one of three conditions listed above in this
>    section provides additional assurance.
>
>    A GRE-in-UDP tunnel is suitable for transmission over lower layers
>    in the traffic-managed controlled environments that are allowed by
>    the exceptions stated above and the rate of corruption of the inner
>    IP packet on such networks is not expected to increase by comparison
>    to GRE traffic that is not encapsulated in UDP.  For these reasons,
>    GRE-in-UDP does not provide an additional integrity check except
>    when GRE checksum is used when UDP zero-checksum mode is used with
>    IPv6, and this design is in accordance with requirements 2, 3 and 5
>    specified in Section 5 of [RFC6936].
>
>    Generic Router Encapsulation (GRE) does not accumulate incorrect
>    state as a consequence of GRE header corruption. A corrupt GRE
>    packet may result in either packet discard or forwarding of the
>    packet without accumulation of GRE state. Active monitoring of GRE-
>    in-UDP traffic for errors is REQUIRED as occurrence of errors will
>    result in some accumulation of error information outside the
>    protocol for operational and management purposes. This design is in
>    accordance with requirement 4 specified in Section 5 of [RFC6936].
>
>
>
> Yong, Crabber, Xu, Herbert                                    [Page 15]
> --------------------------------------------------------------------------------
>
> Internet-Draft          GRE-in-UDP Encapsulation            March 2016
>
>    The remaining requirements specified in Section 5 of [RFC6936] are
>    not applicable to GRE-in-UDP.  Requirements 6 and 7 do not apply
>    because GRE does not include a control feedback mechanism.
>    Requirements 8-10 are middlebox requirements that do not apply to
>    GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox
>    discussion).
>
>    It is worth mentioning that the use of a zero UDP checksum should
>    present the equivalent risk of undetected packet corruption when
>    sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and
>    without GRE checksums.
>
>    In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero-
>    checksum mode for IPv6 when the conditions and requirements stated
>    above are met. Otherwise the UDP checksum need to be used for IPv6
>    as specified in [RFC768] and [RFC2460]. Use of GRE checksum is
>    RECOMMENED when the UDP checksum is not used.
> "
>
> In GUE, to support UDP-checksum-zero, it said
>
> " Therefore, when GUE is used over
>    IPv6, either the UDP checksum must be enabled or the GUE header
>    checksum must be used.  An encapsulator MAY set a zero UDP checksum
>    for performance or implementation reasons, in which case the GUE
>    header checksum MUST be used or applicable requirements for using
>    zero UDP checksums in [GREUDP] MUST be met. If the UDP checksum is
>    enabled, then the GUE header checksum should not be used since it is
>    mostly redundant."
>
> It's easy for me to add the similar words to the IP-in-UDP draft like "the
> applicable requirements for using zero UDP checksum in [GREUDP] MUST be
> met when zero UDP checksum is used by the tunnel ingress". However, the
> major goal for disabling the UDP checksum is to improve the performance.
> When GUE header checksum is used and/or the bunch of applicable
> requirements as described in GRE/UDP are verified, is the goal of improving
> performance still achievable? If not, why not directly enable the UDP-checksum
> instead?
>
>     - fragmentation support
>
> In GRE/UDP, it said
>
> " 4.1. MTU and Fragmentation
>
>    Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
>    be compliant with [RFC7588] and perform fragmentation before the
>    encapsulation. The size of fragments SHOULD be less or equal to the
>    PMTU associated with the path between the GRE ingress and the GRE
>    egress tunnel endpoints minus the GRE and UDP overhead ..."
>
> in GUE, it said
>
> " 4.9. MTU and fragmentation
>
>    Standard conventions for handling of MTU (Maximum Transmission Unit)
>    and fragmentation in conjunction with networking tunnels
>    (encapsulation of layer 2 or layer 3 packets) should be followed.
>    Details are described in MTU and Fragmentation Issues with In-the-
>    Network Tunneling [RFC4459]... "
>
> It seems that the only missing thing in the IP-in-UDP draft is to allow the outer
> fragmentation. However, as it said in
> (https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02#page-13), " ...IPsec
> performs only Outer Fragmentation; this distinguishes it from IP-in-IP, which
> performs only Inner Fragmentation. " Note that IP-in-IP is the dominant
> encapsulation choice within Softwires networks. In other words, performing
> only inner fragmentation works very well in practice. Furthermore, the outer
> fragmentation issue (e.g., reassembly cost for the egress) would become even
> worse since the fragments of X-in-UDP packets are more likely to be forwarded
> across different paths than those of X-in-IP and X-in-GRE packets. Hence, I'm
> wondering whether it's worthwhile to support the outer fragmentation on UDP
> encapsulated packets which seems useless in practice.
>
>     - signalling support (e.g., to test whether a tunnel is up or
>     to measure MTUs)
>
> I haven't found any description of this in both GRE/UDP and GUE. Did you?
>
>     - support for robust ID fields (related to fragmentation,
>     e.g., to overcome the limits of IPv4 ID as per RFC 6864)
>
> I haven't found any description of this in both GRE/UDP and GUE. Did you?
>
> Xiaohu
>
> > It is not our obligation to find a way for your document to proceed -
> > that onus is on you.
> >
> > Joe

--------------030502040200010703010909-- From nobody Wed Jun 15 16:13:51 2016 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 6EC8212D0C8; Wed, 15 Jun 2016 16:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 AWXJqR-eKqwW; Wed, 15 Jun 2016 16:13:45 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F6E12D7F2; Wed, 15 Jun 2016 16:13:45 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FNDhBN010622 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jun 2016 19:13:44 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FNDhBN010622 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466032424; bh=jMRpurX7nmt4Gns5nx5+wvdtw00=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=L5FtVXPWjjapjZo7/SKgnZhq66GElxva+Kmx0mf9A/rsfaLowPy6VIdTbtWT3mfQW CbUUsm01mF5db8LAvqyNByxKgkDp9q3P6+REbl8w1uAd5oipUyBPWgNiY9RL8PuLIz 8LDMUXMYTQEPPrZ8ilR0IA6jKI0dvrM1HRSf5iHU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FNDhBN010622 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 15 Jun 2016 19:13:41 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FNDeN9010712 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 15 Jun 2016 19:13:41 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Wed, 15 Jun 2016 19:13:40 -0400 From: "Black, David" To: "tsvwg@ietf.org" , "tcpm@ietf.org" Thread-Topic: draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AdHHW4z/q0muU6tJRV2lEuM6JS3YNQ== Date: Wed, 15 Jun 2016 23:13:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:13:46 -0000 First off, I want to thank Mark for all the work invested in the -04 versio= n of this draft - in particular, the new scope statements (S.1 - S.6) in Section= 2 are important clarifications of what this draft does and what it does not d= o, so I'm pleased to see them, thank you. As Mark noted, there have been some extensive offline conversations. The purpose of this email is to surface one focal point of those conversati= ons so that we can get to and record some form of agreement on the public lists= . This concerns (R.3) in Section 2 of the -04: (R.3) Alternatively, future RTO mechanism implementations may be made directly against the requirements in Section 3 without another protocol-specific specification. The focal point was ensuring that (R.3) does not conflict with (R.1) earlie= r in Section 2: (R.1) RTO mechanisms that are currently standardized are not updated=20 or obsoleted by this document. Implementations are free to use these existing specifications as they do now. IMHO, all the participants in the offline discussion agree that the first s= entence of (R.1) is 100% correct as stated (e.g., as this draft does not propose to update any RFCs). In 20/20 hindsight, the offline discussion was mostly about word choice and order in (R.3). I think (R.3) is ok as is in -04, but it contains a small ambiguity (does "= future" modify "RTO mechanism" or "implementations"?) that would benefit from a small editorial clarification to make it clear that "future" modifies "RTO mechanisms": (R.3) Alternatively, implementations of future RTO mechanisms may be made directly against the requirements in Section 3 without another protocol-specific specification. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0=20 ---------------------------------------------------- From nobody Thu Jun 16 05:06:58 2016 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 F287912D532; Thu, 16 Jun 2016 05:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HFeVn9J9zCsT; Thu, 16 Jun 2016 05:06:53 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FB112D520; Thu, 16 Jun 2016 05:06:53 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5GC6pou008942; Thu, 16 Jun 2016 05:06:51 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 467194C7C3DB; Thu, 16 Jun 2016 08:07:33 -0400 (EDT) To: "Black\, David" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blue on Black X-URL-0: http://www.icir.org/mallman-files/Document81055.jpg X-URL-1: http://www.icir.org/mallman-files/Document50253.doc X-URL-2: http://www.icir.org/mallman-files/Document83738.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 16 Jun 2016 08:07:33 -0400 Message-ID: <28607.1466078853@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:06:54 -0000 --=-------459435943823349593450 Content-Type: text/plain > (R.3) Alternatively, implementations of future RTO mechanisms may be > made directly against the requirements in Section 3 without > another protocol-specific specification. I am fine with this wording and have made a note to use it in -05 (modulo any further comments that roll in, of course). Thanks, allman -- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldiloIACgkQWyrrWs4yIs6rTACfVrBYISpS9qhUr/gOg2xf2u/S gjgAnisSXVHrz2sM/GEhaREkrEcUDB8E =KYe8 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Jun 16 15:25:59 2016 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 07E5612DB45; Thu, 16 Jun 2016 15:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 1_vB2Jp_0XzS; Thu, 16 Jun 2016 15:25:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2012D11E; Thu, 16 Jun 2016 15:25:52 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 31E1BC9416; Thu, 16 Jun 2016 18:25:48 -0400 (EDT) Date: Thu, 16 Jun 2016 18:25:48 -0400 From: John Leslie To: "Black, David" Message-ID: <20160616222548.GB77166@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: Cc: tsvwg , "rtcweb@ietf.org" , Colin Perkins , IETF AVTCore WG Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 22:25:54 -0000 Black, David wrote: > > ... I view the current text as providing implementers with too much > latitude to ignore ECN-CE marks (e.g., because an implementer doesn't > want to think about this problem space in the first place). Understand, we have at least two proposals to make ECN-CE more frequent than packet drop would be for non-ECN packets: possibly substantially more frequent. Unless both are killed off, ECN-CE will show up frequently enough that closing the flow on ECN-CE would kill too many connections. If you want circuit-breaking on such connections, there are two ways: 1. convince the forwarding nodes to drop packets if their queue exceeds design capacity; or 2. require the sender to send enough not-ECN-capable packets so that our receiver will see enough packet-drops when a circuit-breaker should activate. (I prefer the first option; but I wouldn't object to the second.) There really isn't any way for our circuit-breaker to know _how_much_ more frequent the ECN-CE marks may be. :^( We _will_ be sorry if we allot the same frequency of CE packets as packet-drops to trigger the circuit-breaker. > Could someone propose initial text to qualifies the current "MAY ignore" > statement? Essentially, for the second option, you might propose text to the effect of: ] ] If too many ECN-CE packets are received, the sender SHOULD send some ] not-ECN-capable packets to determine whether enough packets along the ] path are being dropped to justify activating our circuit-breaker. I'm not enthusiastic about adding that; but it would resolve the issue. BTW, I'm 100% convinced that either of the proposals being considered in TSVWG could bring _substantial_ benefit to RTCWEB traffic. -- John Leslie From nobody Fri Jun 17 03:14:34 2016 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 8CB3912B037; Fri, 17 Jun 2016 03:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 0RZxOCMKxb0S; Fri, 17 Jun 2016 03:14:23 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4CD12B03F; Fri, 17 Jun 2016 03:14:23 -0700 (PDT) Received: from [130.209.247.112] (port=57386 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bDqn4-0003o3-Ox; Fri, 17 Jun 2016 11:14:20 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <20160616222548.GB77166@verdi> Date: Fri, 17 Jun 2016 11:14:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> References: <20160616222548.GB77166@verdi> To: John Leslie , "Black, David" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 10:14:25 -0000 > On 16 Jun 2016, at 23:25, John Leslie wrote: >=20 > Black, David wrote: >>=20 >> ... I view the current text as providing implementers with too much >> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't >> want to think about this problem space in the first place). I agree, but the argument is that doing so is less harmful than = deploying a circuit breaker that triggers too often when ECN is used.=20 I=E2=80=99m not sure I believe this argument, though, since it seems = that any new AQM that applies ECN marks much more often than at present = will have to consider backwards compatibility, to work with deployed TCP = (e.g., draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a = signal to use the new marking, while existing implementations set = ECT(0)). These compatibility mechanisms would seem to prevent the issues = with the circuit breaker too. > Understand, we have at least two proposals to make ECN-CE more = frequent > than packet drop would be for non-ECN packets: possibly substantially > more frequent. Unless both are killed off, ECN-CE will show up = frequently > enough that closing the flow on ECN-CE would kill too many = connections. >=20 > If you want circuit-breaking on such connections, there are two = ways: > 1. convince the forwarding nodes to drop packets if their queue = exceeds > design capacity; or > 2. require the sender to send enough not-ECN-capable packets so that = our > receiver will see enough packet-drops when a circuit-breaker should > activate. >=20 > (I prefer the first option; but I wouldn't object to the second.) >=20 > There really isn't any way for our circuit-breaker to know = _how_much_ > more frequent the ECN-CE marks may be. :^( This is a problem, both for the circuit breaker, and for the algorithms = being defined in RMCAT. We do need some understanding what the expected = marking rates are likely to be, so congestion control and circuit = breakers can be defined.=20 > We _will_ be sorry if we > allot the same frequency of CE packets as packet-drops to trigger the > circuit-breaker. >=20 >> Could someone propose initial text to qualifies the current "MAY = ignore" >> statement? >=20 > Essentially, for the second option, you might propose text to the > effect of: > ]=20 > ] If too many ECN-CE packets are received, the sender SHOULD send some > ] not-ECN-capable packets to determine whether enough packets along = the > ] path are being dropped to justify activating our circuit-breaker. >=20 > I=E2=80=99m not enthusiastic about adding that; but it would resolve = the issue. I=E2=80=99m not convinced this would work. The circuit breaker is = looking at long term trends, and in order to have enough not-ECT packets = to determine if it should trigger, you=E2=80=99d essentially have to run = without ECN for some seconds.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Fri Jun 17 04:41:40 2016 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 D6A4612D10C; Fri, 17 Jun 2016 04:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 qX-wQQVCmueP; Fri, 17 Jun 2016 04:41:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC88E12D104; Fri, 17 Jun 2016 04:41:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F0CFFD9305; Fri, 17 Jun 2016 13:41:27 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id latcIjV43XMC; Fri, 17 Jun 2016 13:41:27 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AA67ED9304; Fri, 17 Jun 2016 13:41:27 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <28607.1466078853@lawyers.icir.org> Date: Fri, 17 Jun 2016 13:41:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28607.1466078853@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:41:34 -0000 Hi Mark, witting as an individual contributor.=20 First of all, thanks for the update! I think it reads much better now. = There are 2-3 MUST and SHOULD which we could further discuss, but I = don=E2=80=99t think that is anything big and I=E2=80=99ll defer this to = later. I have a personal opinion on the point below (R-3). I think this point = is just not needed. I say this not because I don=E2=80=99t agree with = the statement but spelling this out in an RFC, to me, contradict the = point of the RFC. I know this point is important for you but let me = further explain.=20 To me I don=E2=80=99t have a problem if people do implement something = that is not standard conform. Especially in transport where there are a = lot of things that don=E2=80=99t have interoperability problem, to me = this is fully okay. Sometimes we in the IETF even pick up existing = implementation and document them as informational, because we believe = the implementation is good and having a stable reference will help = others to do the right thing.=20 However, when we make a recommend I think we should be clear. This is = especially helpful for implementators who do not really have a good = reason to do something different and just look for a general = recommendation.=20 Further I have to note that we do use the word SHOULD in cases where we = know that there are good reason to deviate from the proposed = recommendation. In such a case you could still claim to be standard = conform (for what it is worth) even when you don=E2=80=99t follow the = SHOULD. However basically saying whatever you do is confirm with this = specification, to me really contradicts the point of making a = recommendation. It=E2=80=99s simple if you follow all MUSTs and SHOULDs if case you = don=E2=80=99t have a good reason to do something else, you are conform = to the RFC, and otherwise you are simply not conform. That doesn=E2=80=99t= say that you always when you implement something have to follow RFCs. = That=E2=80=99s non-sense. Implementors are free to do what they want and = we can=E2=80=99t stop them; we can only give reasonable recommendations. My 2c... Mirja > Am 16.06.2016 um 14:07 schrieb Mark Allman : >=20 >=20 >> (R.3) Alternatively, implementations of future RTO mechanisms may = be >> made directly against the requirements in Section 3 without >> another protocol-specific specification. >=20 > I am fine with this wording and have made a note to use it in -05 > (modulo any further comments that roll in, of course). >=20 > Thanks, > allman >=20 >=20 > -- > http://www.icir.org/mallman/ >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jun 17 05:44:42 2016 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 A84F112D0CC; Fri, 17 Jun 2016 05:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 lYmuOpPp-Igl; Fri, 17 Jun 2016 05:44:36 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5E412D532; Fri, 17 Jun 2016 05:44:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,483,1459839600"; d="asc'?scan'208";a="121286875" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx143-out.netapp.com with ESMTP; 17 Jun 2016 05:39:24 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 17 Jun 2016 05:39:21 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 17 Jun 2016 05:39:21 -0700 From: "Eggert, Lars" To: Takeshi Takahashi Thread-Topic: Secdir review of draft-ietf-tsvwg-rfc5405bis-13 Thread-Index: AdG7IyLdVBROrcWPQpmXcgE5pcjURQNrNASA Date: Fri, 17 Jun 2016 12:39:21 +0000 Message-ID: <73CCA28B-9857-46E0-A338-A19F2EE4EEDB@netapp.com> References: <009201d1bb24$1563e4e0$402baea0$@nict.go.jp> In-Reply-To: <009201d1bb24$1563e4e0$402baea0$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_9606CB93-2407-4047-80A6-4F489318439C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tsvwg-rfc5405bis.all@ietf.org" , "tsvwg@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [tsvwg] Secdir review of draft-ietf-tsvwg-rfc5405bis-13 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 12:44:38 -0000 --Apple-Mail=_9606CB93-2407-4047-80A6-4F489318439C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, thanks for the review! I'll incorporate respective changes into -14. On 2016-05-31, at 12:06, Takeshi Takahashi = wrote: > In Table 1 "Summary of recommendations", I wonder if the corresponding > section numbers are correct. >=20 > [Now] > "SHOULD avoid using multiple ports" corresponds to Section 5.1 > and > "SHOULD use a randomized source port or equivalent technique" = corresponds to > Section 5.2 >=20 > [New] > "SHOULD avoid using multiple ports" corresponds to Section 5.1.1 > and > "SHOULD use a randomized source port or equivalent technique" = corresponds to > Section 5.1.2 >=20 > I might be wrong, so please check. You were right that what we had was wrong (copy/paste bug, I think), but = they pointers should be to Sections 5.1.2 and 6, respectively. > Also I have seen several typos (especially, missing parentheses around > referenced section numbers) on this document, so please revise the = texts > before the publication of this document. No typos come up when using "idnits --spellcheck". I also don't quite = understand what you mean by "missing parentheses around referenced = section numbers" - could you please clarify? Thanks, Lars --Apple-Mail=_9606CB93-2407-4047-80A6-4F489318439C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXY+98AAoJEFS1wwm/cMFXZC8QAK6SVMLO4dB5WFegxnzPD89L brl5Wf9G/xyMNbxWJOHa/BSYs+xwrmjP9htKTxxKCQH7LYKf7qW0q+SaVsv3TyrW hpgiYC0sbNau6Mt6hWTVHOQUjQEM4uBRc9c0S/9OpMbfEKZ/gnE0HoCuabHBlx6b 5G8ZD7i5B6Xil4yp4QCEtTOfKKSQsoKaG+ThLoZ3iaY8HvjTapjJOlYUhkWZt44f NLaXe2gbQGN88llbcVW1HdoXjAwFFrofd0iXrvB2J2eHjSl+XR2iM6+r7+emdTqu ENvTQ+hKBjYA0zDD3XmVYtjIVdNfM1xjkAz9Vy7euim0c0lSGyMI/X4x6D3mDRM7 9XdMsFMVUWk7XMaiBlwK2QnxxnWXEbxTh3K6NIHepagYiMwSc67+k/MOhP/3Nhv8 88g+vzrABGTelPQ63kOVaRAvhZliYOeYGJrCSUH4L2/N1lpPhId44Pz4khjydYgi MRcsZeYrEMD9TrqLowyK8AD8M7Wna9n9jH+E2/9/6zWrk5pHXFlyfPyomPrN/uZU AutROpTPYn8rbmcCD8S9HyIJzXZJMmdF4iRrkVauj9Pwk4wAzvsLkbPt8uqIwuNW O9ScGOTp/4ioDg+SRhC1peireDPazyGD1Wd9P1skLt/cdyk9b4s01ITY4WvJUnZU My7yw8+z7T0qZ+bOYZaH =iOIx -----END PGP SIGNATURE----- --Apple-Mail=_9606CB93-2407-4047-80A6-4F489318439C-- From nobody Fri Jun 17 06:12:18 2016 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 AC91312D56F; Fri, 17 Jun 2016 06:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 g5R1Hv6V-Vr4; Fri, 17 Jun 2016 06:12:12 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3887F12D1E7; Fri, 17 Jun 2016 06:12:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,483,1459839600"; d="asc'?scan'208";a="123287723" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx144-out.netapp.com with ESMTP; 17 Jun 2016 06:11:53 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 17 Jun 2016 06:11:49 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 17 Jun 2016 06:11:49 -0700 From: "Eggert, Lars" To: Tim Chown Thread-Topic: OPS-DIR review of draft-ietf-tsvwg-rfc5405bis-133 Thread-Index: AQHRxCyvFuNBDQVKW0+KRxmB2HFhQ5/uIJ0A Date: Fri, 17 Jun 2016 13:11:49 +0000 Message-ID: References: <5DDC4122-431A-450F-91DD-AAEF4BE9113E@jisc.ac.uk> In-Reply-To: <5DDC4122-431A-450F-91DD-AAEF4BE9113E@jisc.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_5D596C30-72A7-4BEE-8B0F-385C7F121C28"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tsvwg-rfc5405bis.all@ietf.org" , "ops-dir@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] OPS-DIR review of draft-ietf-tsvwg-rfc5405bis-133 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:12:13 -0000 --Apple-Mail=_5D596C30-72A7-4BEE-8B0F-385C7F121C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, thanks for the review! I'll incorporate respective changes into -14. On 2016-06-12, at 0:00, Tim Chown wrote: > It might be nice to include some level of discussion of new examples = of UDP-based protocols devised since RFC 5405 (i.e. since 2008), such as = QUIC, or applications such as mosh that enable ssh over UDP rather than = the traditional TCP. Do these follow the guidance here, for example? This would add quite a bit of digging - there is no spec for mosh, and = while there is one for QUIC now, I'd require more time than I currently = have to analyze if and how it follows the different guidelines we = describe here. (I will however argue that if the QUIC WG forms, the = eventual QUIC RFC should do so :-) > CGNs have appeared since RFC 5405; are there specific issues they pose = for UDP-based applications which require state to remain? Other than being generally worse than normal NATs due to even faster = timeouts? Not that I'm aware of. > p.16 final para of point 1 - is most UDP-based communication = congestion controlled? I'd argue that most sent at volume, yes. Maybe with the exception of = multicast, but that is limited in reach. > p.30 when you say =E2=80=9Ccompetes fairly within an order of = magnitude=E2=80=9D do you mean on a 10G link that UDP can take over 9G? Yes, actually, although that's obviously the extreme, non-ideal case. We = wanted to make it clear that there is significant leeway, because TCP = isn't "fair" to TCP either. > p.30 in the next paragraph, this suggestion would seem non-trivial to = implement well/accurately, and then the =E2=80=9Corder of magnitude=E2=80=9D= is thrown in too=E2=80=A6 Yes, there is a lot of wiggle room here (on purpose). > p.30 section 4.2 - perhaps reword as it implies explicit PMTUD to each = known destination (receiver)? I'm not sure it implies PMTUD - you'd normally have the MTU information = available through other means in a multicast scenario. > p.32 worth adding an example of why this is so valuable, e.g. DNS = cache poisoning? Which paragraph? > p.34 perhaps note that the IPv6 Flow Label is mutable on path (section = 6 of RFC 6437) Is this important here? Lars --Apple-Mail=_5D596C30-72A7-4BEE-8B0F-385C7F121C28 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXY/cXAAoJEFS1wwm/cMFXr/cQAIirN1STe75LmG6jrn4hGtRT Jixq2/1/5MTVpRFe4mmMneXgb3B1vyvp53b5CUyHBSe6FqYkfdsP84JmNEgyipsb tMW2EiQoqf3vjHdJKIxRF/9PlSK43I78JoaEj3fwC6sl3JyNb8UlT6nghIeHCcmd DW2ezhuUjzMKpWvIYovHcBOklInVAe0wPNZAtmi81jVvgQqMnA/EFH7yuqCBdhoV W/A/37JAn9ylGqM+jzsOQmBCLjOrLOwAS6CrWl0U9iIUHuEIuVOMeIaW6MGK6lFe RFU/4yhVvn7SxNuRmA2l+ZQk+z1hkzNKa+E+B+4CXoY9ycioi6CSwC63Yy6JJk4B 9pnaaceuOzeC0UNAfDMuN2O7NN+qG3YJHgDCkc/GZFj27vW4HCTifHg0jCCfaIEx jsvcok4nq0AG/7ikQiFQ7ArjR+Thw+FxoM7pb2g9t7eT8ikJxf3bI0TIjY80YmvJ 9o5XhnvRBhAtBcF7vvZU6Cx7QywiLGc+IL3+S1jfrKSD7XHAaoVkRrB6na5xGCuK IUf/eXqqBreFq4E+JfzpNz7qUsYa6F4Mfvm8nFeZohms2mg85dKf/ab/N+E3QcWf uaom5UtbBAyzg2cjRopRDIXyjYHtqXfrlnEQQAx54/bpqlwcx394UzkIm0lINfss OoUoJ4gscjD1Je9nwGOx =mISH -----END PGP SIGNATURE----- --Apple-Mail=_5D596C30-72A7-4BEE-8B0F-385C7F121C28-- From nobody Fri Jun 17 06:21:50 2016 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 D973C12D662; Fri, 17 Jun 2016 06:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 um_0JhTvoxTx; Fri, 17 Jun 2016 06:21:24 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED6212D5AF; Fri, 17 Jun 2016 06:21:23 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HDLKnl009791; Fri, 17 Jun 2016 06:21:20 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0874C4CDA854; Fri, 17 Jun 2016 09:22:07 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 09:22:07 -0400 Message-ID: <98229.1466169727@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:21:42 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > I have a personal opinion on the point below (R-3). I think this > point is just not needed. I say this not because I don=E2=80=99t agree > with the statement but spelling this out in an RFC, to me, > contradict the point of the RFC. On the one hand, I can understand that opinion. Why would we write the RFC if we weren't going to allow these things and so why do we have to say this? And, if people think this is unnecessary I am happy to nuke it. However, let me sketch the lay of the land as I see it .... It seems the meat in this document can be used for different purposes. And, we have seen opinions on each of these I think. The document could be used: (a) as input to future RTO specifications, (b) as input to future RTO implementations, or (c) as both (a) and (b) My take is (c). And, so (R.2) is meant to cover case (a), while (R.3) is meant to cover case (b). So, while I can see your point about not needing to say something obvious, I am worried that eliding (R.3) will leave us in one of two places: - In case (a) above. I.e., because (R.2) discusses only specifications and not implementations and so a natural reading may well be that this document is meant to only help future standardization efforts. - Or, in some ambiguous state where clearly (a) holds (via (R.2)), but it is not explicit that this covers implementations, too, even if we think that it does since the text does not explicitly say that. And, so we end up with confusion. Does that make sense? Am I worrying too much about explicitly including implementations? allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldj+X4ACgkQWyrrWs4yIs4vOQCeMFXg99BZIHiPVV9eHhHnRmAk HdAAnRyqQosnxBOss48aSyQRLyMa9sHE =2yd7 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 06:50:20 2016 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 AB57C12D5E7; Fri, 17 Jun 2016 06:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 hlRA2S4i_qQ3; Fri, 17 Jun 2016 06:50:13 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8646B12D52B; Fri, 17 Jun 2016 06:50:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,483,1459839600"; d="asc'?scan'208";a="121299228" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx143-out.netapp.com with ESMTP; 17 Jun 2016 06:48:37 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 17 Jun 2016 06:48:34 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 17 Jun 2016 06:48:34 -0700 From: "Eggert, Lars" To: Brian Trammell Thread-Topic: Last Call: (UDP Usage Guidelines) to Best Current Practice Thread-Index: AQHRsJqdds6gCdh0lUGI5N5yDaTPkp/WgnIAgBfPlIA= Date: Fri, 17 Jun 2016 13:48:33 +0000 Message-ID: <0E763363-CFB4-40B9-AD6F-F85E3686DBF3@netapp.com> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> In-Reply-To: <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_8D76EDC2-7AD8-463F-99C7-CBC2F972CF81"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tsvwg-rfc5405bis@ietf.org" , tsvwg WG Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:50:19 -0000 --Apple-Mail=_8D76EDC2-7AD8-463F-99C7-CBC2F972CF81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Addressed in my working copy - thanks > On 2016-06-02, at 12:11, Brian Trammell wrote: >=20 > Greetings, all, >=20 > Apologies for the late last call comment; I have only one, relatively = minor. I hope it's still useful. >=20 > I understand that Section 3 was written to encourage application = developers not to roll their own transports ("trust us when we say this = is hard, this document is a list of reasons why") but as written it = would seem to discourage transport innovation atop UDP (e.g. QUIC, the = RTCWEB data channel, anything-over-PLUS), which I very much hope was not = the intent. The problematic recommendation is in the second paragraph: >=20 > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport = protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the = RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], = and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622]. >=20 > First, this paragraph ignores potential deployment issues with any of = these other than TCP, which risks seeming out of touch, but this is a = minor point and probably not worth a late edit. Second, I'm concerned = this recommendation could be taken as broader than intended, against the = definition of any new transport protocol encapsulated within UDP that = performs substantially the same function as the listed protocols. >=20 > I think this can be made clearer by simply adding to the list of = examples: >=20 > NEW: >=20 > These mechanisms are difficult to implement correctly. For most > applications, the use of one of the existing IETF transport = protocols > is the simplest method of acquiring the required mechanisms. Doing > so also avoids issues that protocols using a new IP protocol number > face when being deployed over the Internet, where middleboxes that > only support TCP and UDP are not rare. Consequently, the = RECOMMENDED > alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP > [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], = and > SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram > Congestion Control Protocol (DCCP) [RFC4340] with its different > congestion control types [RFC4341][RFC4342][RFC5622], or transport > protocols specified by the IETF in the future. >=20 > and removing the examples from the summary in section 7: >=20 > OLD: >=20 > | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | = | >=20 > NEW: >=20 > | SHOULD use a full-featured transport | = | >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 >> On 18 May 2016, at 02:17, The IESG wrote: >>=20 >>=20 >> The IESG has received a request from the Transport Area Working Group = WG >> (tsvwg) to consider the following document: >> - 'UDP Usage Guidelines' >> as Best Current Practice >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> The User Datagram Protocol (UDP) provides a minimal message-passing >> transport that has no inherent congestion control mechanisms. This >> document provides guidelines on the use of UDP for the designers of >> applications, tunnels and other protocols that use UDP. Congestion >> control guidelines are a primary focus, but the document also >> provides guidance on other topics, including message sizes, >> reliability, checksums, middlebox traversal, the use of ECN, DSCPs, >> and ports. >>=20 >> Because congestion control is critical to the stable operation of = the >> Internet, applications and other protocols that choose to use UDP as >> an Internet transport must employ mechanisms to prevent congestion >> collapse and to establish some degree of fairness with concurrent >> traffic. They may also need to implement additional mechanisms, >> depending on how they use UDP. >>=20 >> Some guidance is also applicable to the design of other protocols >> (e.g., protocols layered directly on IP or via IP-based tunnels), >> especially when these protocols do not themselves provide congestion >> control. >>=20 >> This document obsoletes RFC5405 and adds guidelines for multicast = UDP >> usage. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >>=20 >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >=20 --Apple-Mail=_8D76EDC2-7AD8-463F-99C7-CBC2F972CF81 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXY/+0AAoJEFS1wwm/cMFXyngP/1jLgmZVojFu0fT1rtGBl9W+ vz+SiZa/CEQdTodUiZqjD1NWZSvTKsIpcWI7NoiiYbg2JG3F06UjxuOOgB0dPG+O Ck+exATleBpXPB3CpivE0wVeAawFrPpr8DPI8xxgGHL+SGQBJyJ/zk9NzTUqajrA Lxe+0qrV6E4eyKfwL7KUWZyhu51Jpo7dWHFv/OGR6ygoZJTdV1y68SkB5/TFtrVz q47Xjb9fRf0MUniGzrQ5DyWnbBTOdg4Ia5O4s/LLVkvoxwyLYAPEgZ69UIar/GNd mZ8n6aes/bWiBT3v4IUqrNsG9ulAFrjrD0FCqNEDaM5LmrBuhpqKCRQIaME8gl68 edOAI2bT+PUxKRy0MOd9XES04fWkkhf8MpgDqSbcqgcWhcaj0aqgfNnDn7TlmgWJ hkUNulNCJd9qnfX45xp8rZCcjKu56ryzDKVgLC82vbmVRxwKdpteX6EH6gU40P/H 59r8HXcjXs6lNC3UPjgib3YahQ3NU/D16l6Yq1NlSKUeJkdHC1BPXPfYfgNHzx/v ZKPuM0ioR0Eyz7wS1AjBKx4oziWBOWtPn/semz+YU888+6mapURVABvJL7monivy e00AJhP3OsRvONcQ3ZFyjsP7JuvLSNRHmlVtivy/Jnjw/xjH5RVKKzFRayCal9AJ Fi+qxk3ROz1zeayDh89W =oHFv -----END PGP SIGNATURE----- --Apple-Mail=_8D76EDC2-7AD8-463F-99C7-CBC2F972CF81-- From nobody Fri Jun 17 06:50:27 2016 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 1444912D660; Fri, 17 Jun 2016 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 GKtkgpbiKLdq; Fri, 17 Jun 2016 06:50:13 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A15B12B01E; Fri, 17 Jun 2016 06:50:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,483,1459839600"; d="asc'?scan'208";a="121298492" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx143-out.netapp.com with ESMTP; 17 Jun 2016 06:45:11 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 17 Jun 2016 06:45:08 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 17 Jun 2016 06:45:08 -0700 From: "Eggert, Lars" To: "mallman@icir.org" , "draft-ietf-tsvwg-rfc5405bis.all@ietf.org" Thread-Topic: Last Call: (UDP Usage Guidelines) to Best Current Practice Thread-Index: AQHRu25jbN+dquhoh0aBzfOcEJMgbp/uO2mA Date: Fri, 17 Jun 2016 13:45:08 +0000 Message-ID: References: <34060.1464721077@lawyers.icir.org> In-Reply-To: <34060.1464721077@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4C215168-7450-4EEA-B4E1-9001A34CAFCA"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:50:20 -0000 --Apple-Mail=_4C215168-7450-4EEA-B4E1-9001A34CAFCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2016-05-31, at 20:57, Mark Allman wrote: > - I'd be interested to hear why it is RECOMMENDED to adhere to the > RTO algorithm in RFC6298. In my view, in 2016 this is just > unnecessary and wrong (see my broader opinion below). (That > said, if someone wants to use that algorithm, I think it is > fine... but, prescribing it is not needed, IMO.) because it's a reasonable example for which we have a spec. I'm happy to = recommend something else that is reasonable. > - I'd also like to see the normative text better underscore the > importance of backoff. More than we currently do? It is important to note that the initial timeout value is not the maximum possible timeout -- the RECOMMENDED algorithm in [RFC6298] doubles the measured RTT value after each timeout (e.g., [RFC3261]). After a series of timeouts, this exponential back-off therefore results in values that are much longer than the initial value. Would you suggest text? > - "TCP requires the initial RTT to be set to no less than 1 > second" ... TCP requires the initial ***RTO*** be no less than 1 > second. There is a difference between the RTT and the RTO and > this draft is pretty liberal with using them interchangeably > (which is both confusing and wrong). Oops. Will check. > A broader opinion is that we should just elide these words in favor > of a set of general RTO guidelines that span protocols (see > draft-ietf-tcpm-rto-consider ; which goes beyond TCP, but is in TCPM > for now because TCP is where it started, but comments would be > appreciated from all corners). We could do that. At this point, I'm in favor of doing whatever get this = off my plate faster :-) Lars --Apple-Mail=_4C215168-7450-4EEA-B4E1-9001A34CAFCA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXY/7mAAoJEFS1wwm/cMFXykkQALiv4zNKlr3AH5Ig4j3diLm2 a3CE52b59jPHAtDZ26H8mlNgaim446qMSrweHjdEkRIXUoWe+RAHH/9XXIzYWMzO wujsMMAFQRvQXxB22t0m7qgHj6cbFP1d8iiFxMHfhCWxrEPSEFIY4sC7zZP8Ih1G amU2gzaixWsRCTVdZ9JnH7qN0kStBhncsYzXnYasvgD2y95Ai5R9DKfIflz9vAsU UohC1xtW4VNrCUWdykaDcLl6kygttgz3lVCJosGF6tV+Hf3A76xgFpi2lhQb74KE SBbvLhd6NWzN+u4cNEQdX8FoHfUPwdSP1tTdcCRL6vg8Rl7YbWmXzrol6GuNYnnd IoGBSPmFmMX9gBrGriVpdVt7UlkOc/K9q57fXM1DO/3Tp6ZyndNFA/f7AfvIVW5U fgfkyTpDKaOXTxk8L2bDtPH1xM9cYPvw0wbBR6uAPLQpBf6eu8/D0MJ3C+VmTjWz E7Jc6ARyPb8LNObXKKHYom/EFL/y318Rn4GiAzFvBQmEdhmdRm95fs3bZ6RceqOc +jBy7BNtDjW9OYA3tCKU1TlniRjK8DLjXUIOKebJKyZhSX8D5XNHXvK7Ps+rktKQ gZj9Kc+F0v61VNQ7K/hK9OMlTR//WE/JZWIy3pOEe4ZjY9C0PGaoGeMSENlH32lp v7DUFO0o4pM26o5izXg4 =j+Yd -----END PGP SIGNATURE----- --Apple-Mail=_4C215168-7450-4EEA-B4E1-9001A34CAFCA-- From nobody Fri Jun 17 06:58:32 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF60212D689; Fri, 17 Jun 2016 06:58:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160617135824.19100.1482.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 06:58:24 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-14.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:58:25 -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 of the IETF. Title : UDP Usage Guidelines Authors : Lars Eggert Godred Fairhurst Greg Shepherd Filename : draft-ietf-tsvwg-rfc5405bis-14.txt Pages : 57 Date : 2016-06-17 Abstract: The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ECN, DSCPs, and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC5405 and adds guidelines for multicast UDP usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc5405bis-14 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 Fri Jun 17 07:01:36 2016 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 1F26012D626 for ; Fri, 17 Jun 2016 07:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 3XksAnZdOSjD for ; Fri, 17 Jun 2016 07:01:28 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD0D12D5C0 for ; Fri, 17 Jun 2016 07:01:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,484,1459839600"; d="asc'?scan'208";a="117697027" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx142-out.netapp.com with ESMTP; 17 Jun 2016 07:01:05 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 17 Jun 2016 07:01:01 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 17 Jun 2016 07:01:01 -0700 From: "Eggert, Lars" To: tsvwg WG Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-14.txt Thread-Index: AQHRyKBg0geAjTcGs0idv6lPmilNQ5/uJXUA Date: Fri, 17 Jun 2016 14:01:00 +0000 Message-ID: <019AEFC5-E344-4374-8F3C-9A31A9751C0C@netapp.com> References: <20160617135824.19100.1482.idtracker@ietfa.amsl.com> In-Reply-To: <20160617135824.19100.1482.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_DC4AEA4E-6507-45E5-94CA-7CF5E5EB2380"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Mark Allman Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-14.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:01:35 -0000 --Apple-Mail=_DC4AEA4E-6507-45E5-94CA-7CF5E5EB2380 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This revision attempts to address the various directorate and other = review we have gotten. The main open issue in my book is what to do about Mark Allman's comment = regarding scrapping the RTT/RTO text in favor of simply to (normatively, = I guess) referring to draft-ietf-tcpm-rto-consider. Lars > On 2016-06-17, at 15:58, internet-drafts@ietf.org wrote: >=20 >=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 of the = IETF. >=20 > Title : UDP Usage Guidelines > Authors : Lars Eggert > Godred Fairhurst > Greg Shepherd > Filename : draft-ietf-tsvwg-rfc5405bis-14.txt > Pages : 57 > Date : 2016-06-17 >=20 > Abstract: > The User Datagram Protocol (UDP) provides a minimal message-passing > transport that has no inherent congestion control mechanisms. This > document provides guidelines on the use of UDP for the designers of > applications, tunnels and other protocols that use UDP. Congestion > control guidelines are a primary focus, but the document also > provides guidance on other topics, including message sizes, > reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > and ports. >=20 > Because congestion control is critical to the stable operation of = the > Internet, applications and other protocols that choose to use UDP as > an Internet transport must employ mechanisms to prevent congestion > collapse and to establish some degree of fairness with concurrent > traffic. They may also need to implement additional mechanisms, > depending on how they use UDP. >=20 > Some guidance is also applicable to the design of other protocols > (e.g., protocols layered directly on IP or via IP-based tunnels), > especially when these protocols do not themselves provide congestion > control. >=20 > This document obsoletes RFC5405 and adds guidelines for multicast = UDP > usage. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rfc5405bis-14 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_DC4AEA4E-6507-45E5-94CA-7CF5E5EB2380 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXZAKeAAoJEFS1wwm/cMFXrWUQAM1QiVQNPvAqCK53hIIiWVv4 2Gkx5L+DBXbth7T0WdOLGAgHaZEtik96R6PtTmmjxGBk69TMDaSsKi8PTD/vdYSt 1d0IRkNieIF5fHXX/o2hhaSZ0j9jKv+IWLk8XvG588HHi6DkUXBQe3+dpKx+TBW/ fhSOx/J1IK+03eE3tyEFqJGtIdUReqN+TJdJkedQscn58s9Zq1kl25TH+ZdXee5j c6ulDKNBNSpxG0v18yVNbIlWlL8gJ8Xvu/tgh5ndl9gatrdzNGqoRPCrg78toZi9 gUYnyc7eGbKS3mimLAShyxpeFOMR1C8mPieCQWVnQdpiuN5X6E4TaAjUa3YbBK69 Eum511PjZDsFzB6EgMq0rU3u0f7JXtguTqXV7bjDel276aQ2B+BUT88Jv2SrLQUf nVSBwnCFds0ghS4WWObk1m7Kc7QqLHm5ZyONyXt36uYO5DiYItXhn8Ri/9tuDxTf b7abiMEmsFBsnhiU6pyEYiCZDKqbKpVRaeI1xKJ2Ak3apWWoQYiJtMSjJvgVeSYn 40LtcbLSiibK2GE1zZCzgNXfwYIkJJ61zNxxamP1TBll5KbGe4OX8ssBhZFJB4qs A6EqpmoJTkJ6g4vbujE9HDleSsnunExinnGjMre2rgih8ayrdXHmUpvk/FRopyiC Mnr/YOGuyoV8ob4/yH/c =xiEi -----END PGP SIGNATURE----- --Apple-Mail=_DC4AEA4E-6507-45E5-94CA-7CF5E5EB2380-- From nobody Fri Jun 17 07:03:37 2016 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 E307712D610; Fri, 17 Jun 2016 07:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 6aTVvyc6MaJ1; Fri, 17 Jun 2016 07:03:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FC412D14F; Fri, 17 Jun 2016 07:03:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5371FD930E; Fri, 17 Jun 2016 16:03:28 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z5cvWFpLrpzC; Fri, 17 Jun 2016 16:03:28 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E2AB0D9305; Fri, 17 Jun 2016 16:03:27 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <98229.1466169727@lawyers.icir.org> Date: Fri, 17 Jun 2016 16:03:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> References: <98229.1466169727@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:03:32 -0000 Again, my personal view is that the statement is not needed, and I find = it rather confusing that helpful. Based my (limited) experience in = (Linux) implementors community I would like to add that even though they = are often not very active on ietf mailing lists and might not follow the = RFC in their implementation, they still read the draft. So simply = focusing on the actual recommendation in the doc (and the needed = statements how this doc related to other docs in the RFC series) is = sufficient for me and more clear. Mirja > Am 17.06.2016 um 15:22 schrieb Mark Allman : >=20 >=20 >> I have a personal opinion on the point below (R-3). I think this >> point is just not needed. I say this not because I don=E2=80=99t = agree >> with the statement but spelling this out in an RFC, to me, >> contradict the point of the RFC. >=20 > On the one hand, I can understand that opinion. Why would we write > the RFC if we weren't going to allow these things and so why do we > have to say this? And, if people think this is unnecessary I am > happy to nuke it. >=20 > However, let me sketch the lay of the land as I see it .... It > seems the meat in this document can be used for different purposes. > And, we have seen opinions on each of these I think. The document > could be used: >=20 > (a) as input to future RTO specifications, >=20 > (b) as input to future RTO implementations, or >=20 > (c) as both (a) and (b) >=20 > My take is (c). And, so (R.2) is meant to cover case (a), while > (R.3) is meant to cover case (b). >=20 > So, while I can see your point about not needing to say something > obvious, I am worried that eliding (R.3) will leave us in one of two > places: >=20 > - In case (a) above. I.e., because (R.2) discusses only > specifications and not implementations and so a natural reading > may well be that this document is meant to only help future > standardization efforts. >=20 > - Or, in some ambiguous state where clearly (a) holds (via (R.2)), > but it is not explicit that this covers implementations, too, > even if we think that it does since the text does not explicitly > say that. And, so we end up with confusion. >=20 > Does that make sense? Am I worrying too much about explicitly > including implementations? >=20 > allman >=20 >=20 >=20 From nobody Fri Jun 17 07:04:18 2016 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 67A9212D5CE; Fri, 17 Jun 2016 07:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 UFHsbW5608CS; Fri, 17 Jun 2016 07:04:10 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B82A12D660; Fri, 17 Jun 2016 07:04:09 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5HE3wXt025920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jun 2016 10:04:01 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5HE3wXt025920 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466172241; bh=1MdxT5kVQ5qEdUCAEs7ZwD4cBRI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hA7wI5bFZq/YTELrEnIlkKgAt7v3xLCpCE/hVRLFTDWJonXKGB1n5859Hxlbln8uT r2jRBzS5UTrL5HzEOjk+DQECJATSxWtnNmQVztpQKXtw9wQVElPQfmLdu1PDndKL60 EUyVdw8nwzIMo37PtYOZHR3t/TAb0NZV1nFN3tBg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5HE3wXt025920 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 17 Jun 2016 10:03:29 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5HE3nPx006854 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 17 Jun 2016 10:03:49 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0266.001; Fri, 17 Jun 2016 10:03:48 -0400 From: "Black, David" To: Colin Perkins , John Leslie Thread-Topic: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4QG1826TWG60eO2TVJ3aRsKp/ttMoA///yYCA= Date: Fri, 17 Jun 2016 14:03:48 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> In-Reply-To: <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:04:12 -0000 Q29saW4sDQoNCj4gPj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcg aW1wbGVtZW50ZXJzIHdpdGggdG9vIG11Y2gNCj4gPj4gbGF0aXR1ZGUgdG8gaWdub3JlIEVDTi1D RSBtYXJrcyAoZS5nLiwgYmVjYXVzZSBhbiBpbXBsZW1lbnRlciBkb2Vzbid0DQo+ID4+IHdhbnQg dG8gdGhpbmsgYWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJzdCBwbGFjZSkuDQo+ IA0KPiBJIGFncmVlLCBidXQgdGhlIGFyZ3VtZW50IGlzIHRoYXQgZG9pbmcgc28gaXMgbGVzcyBo YXJtZnVsIHRoYW4gZGVwbG95aW5nIGEgY2lyY3VpdA0KPiBicmVha2VyIHRoYXQgdHJpZ2dlcnMg dG9vIG9mdGVuIHdoZW4gRUNOIGlzIHVzZWQuDQo+IA0KPiBJ4oCZbSBub3Qgc3VyZSBJIGJlbGll dmUgdGhpcyBhcmd1bWVudCwgdGhvdWdoLCBzaW5jZSBpdCBzZWVtcyB0aGF0IGFueSBuZXcgQVFN DQo+IHRoYXQgYXBwbGllcyBFQ04gbWFya3MgbXVjaCBtb3JlIG9mdGVuIHRoYW4gYXQgcHJlc2Vu dCB3aWxsIGhhdmUgdG8gY29uc2lkZXINCj4gYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdv cmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sIGRyYWZ0LWJyaXNjb2UtdHN2d2ctDQo+IGFxbS10 Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEgc2lnbmFsIHRvIHVzZSB0aGUg bmV3IG1hcmtpbmcsDQo+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDAp KS4gVGhlc2UgY29tcGF0aWJpbGl0eSBtZWNoYW5pc21zDQo+IHdvdWxkIHNlZW0gdG8gcHJldmVu dCB0aGUgaXNzdWVzIHdpdGggdGhlIGNpcmN1aXQgYnJlYWtlciB0b28uDQoNClRoYXQgcm91Z2hs eSBtYXRjaGVzIG15IGxpbmUgb2YgdGhpbmtpbmcsIGFuZCBJJ2xsIG9ic2VydmUgdGhhdCB0aGUg b3JpZ2luYWwgRENUQ1ANCnByb3RvY29sIGRlc2lnbiB0aGF0IHVzZWQgbW9yZSBhZ2dyZXNzaXZl IEVDTi1DRSBtYXJraW5nIHdhcyBvbmx5IHNhZmUgZm9yDQpDb250cm9sbGVkIEVudmlyb25tZW50 IGRlcGxveW1lbnRzLiAgIFNlZSB0aGUgVFNWV0cgcmZjNTQwNWJpcyBkcmFmdCBmb3IgdGhlDQpk ZWZpbml0aW9uIG9mIENvbnRyb2xsZWQgRW52aXJvbm1lbnQsIGFuZCBpZ25vcmUgdGhlIGZhY3Qg dGhhdCB0aGUgcmZjNTQwNWJpcw0KZHJhZnQgaXMgYSBVRFAgZHJhZnQgLSB0aGlzIGRlZmluaXRp b24gaXMgbW9yZSBicm9hZGx5IGFwcGxpY2FibGUuDQoNCkdvaW5nIGJhY2sgb3ZlciBTZWN0aW9u IDcgaW4gdGhpcyBhdnRjb3JlIGRyYWZ0LCBteSB2aWV3cyBhcmU6DQoNCltBXSBOb25lIG9mIHRo ZXNlIGRyYWZ0cyBqdXN0aWZ5IGEgIk1BWSBpZ25vcmUiIHJlc3BvbnNlIHRvIEVDTi1DRSBtYXJr czoNCgktIGRyYWZ0LWtoYWRlbWktdGNwbS1hbHRlcm5hdGl2ZWJhY2tvZmYtZWNuDQoJLSBkcmFm dC1pZXRmLXJtY2F0LW5hZGENCgktIGRyYWZ0LWlldGYtcm1jYXQtc2NyZWFtLWNjDQoNCltCXSBJ biBsaW5lIHdpdGggQ29saW4ncyBjb21tZW50IG9uIHRoZSBMNFMgZHJhZnQsIEkgdGhpbmsgaXQn cyBpbmN1bWJlbnQgb24NCnRoZSBhdXRob3JzIG9mIGRyYWZ0LWJyaXNjb2UtYXFtLWR1YWxxLWNv dXBsZWQgdG8gZmlndXJlIG91dCBob3cgdGhhdCB3aWxsDQpjb2V4aXN0IChvciBhdm9pZCkgZGVw bG95ZWQgVENQLCBhbmQgdGhpcyBhdnRjb3JlIGRyYWZ0IG91Z2h0IG5vdCB0byBiZQ0KdHJ5aW5n IHRvIHByZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KDQpTbywgSSBkb24ndCB0aGlu ayB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gNyBoYXMganVzdGlmaWVkIHRoZSB1bmZldHRl cmVkDQoiaW1wbGVtZW50YXRpb25zIE1BWSBpZ25vcmUgRUNOLUNFIG1hcmtzIiB0ZXh0LCBhcyBp Z25vcmluZyB0aG9zZSBtYXJrcw0KaXMgbm90IGNvbnNpc3RlbnQgd2l0aCBhbnkgb2YgdGhlIGZv dXIgY2l0ZWQgZHJhZnRzLg0KDQpJbiBtb3JlIGRldGFpbCwgSSB0aGluayBtYWtpbmcgY2hhbmdl cyB0byBub3JtYXRpdmUgcmVxdWlyZW1lbnRzIGhlcmUgYmFzZWQNCm9uIFtCXSBpcyBwcmVtYXR1 cmUsIGFuZCBJIHdvdWxkIGhvcGUgdGhhdCB0aGUgcm1jYXQgV0cgY291bGQgYmUgZW5jb3VyYWdl ZA0KdG8gY29uc2lkZXIgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaW4gaXRzIGNvbmdlc3Rpb24g Y29udHJvbCBkcmFmdHMsIGFzIHRob3NlIENDDQptZWNoYW5pc21zIGFyZSByZWxhdGVkIHRvIHRo ZSBjaXJjdWl0IGJyZWFrZXIgbWVjaGFuaXNtLCBoZW5jZSBsaWtlbHkNCnRvIGJlIGluIHJlbGF0 ZWQgYXJlYXMgb2YgYW4gUlRQIGltcGxlbWVudGF0aW9uLg0KDQpUaGF0IGxlYXZlcyBkcmFmdC1r aGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbiwgd2hpY2ggVFNWV0cNCndpbGwgYmUg bG9va2luZyBhdCBpbiBCZXJsaW4uICBJZiBhIG5vcm1hdGl2ZSBzdGF0ZW1lbnQgYWJvdXQgRUNO LUNFIHJlYWN0aW9uDQppcyBnb2luZyB0byByZXN0IG9uIHRoYXQgZHJhZnQsIHRoZW4gdGhlIHJl ZmVyZW5jZSB0byB0aGF0IGRyYWZ0IHNob3VsZCBiZQ0Kbm9ybWF0aXZlLiAgU29tZXRoaW5nIGFi b3V0IGRvaW5nIHRoYXQgc3RyaWtlcyBtZSBhcyBwcmVtYXR1cmUgLi4uDQoNCkkgcmVhbGl6ZSB0 aGF0IHdlJ3JlIHRyeWluZyB0byBwcmVkaWN0IGFuZCBhY2NvbW1vZGF0ZSB0aGUgZnV0dXJlLCB3 aGljaA0KaXMgYW4gaW1wcmVjaXNlIHVuZGVydGFraW5nIGF0IGJlc3QuICAgQXMgYW4gYWx0ZXJu YXRpdmUgdG8gdGhlIGN1cnJlbnQgdGV4dCwNCndvdWxkIGl0IGJlIHJlYXNvbmFibGUgdG8gc2F5 ICh3aXRob3V0IGFueSBSRkMgMjExOSBrZXl3b3JkcykgdGhhdCB0aGUNCmJlc3QgY3VycmVudCBn dWlkYW5jZSBpcyBzdGlsbCB0byB0cmVhdCBFQ04tQ0UgbWFya3MgYXMgaW5kaWNhdGluZyBkcm9w cywNCndpdGggYSB3YXJuaW5nIHRoYXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5IG9mIHRo aXMgY2hhbmdpbmcgaW4gdGhlDQpuZWFyIGZ1dHVyZSBkdWUgdG8gYWxsIG9mIHRoZSB3b3JrIGlu IHByb2dyZXNzIGNpdGVkIGluIFNlY3Rpb24gNz8NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNz cEBjc3BlcmtpbnMub3JnXQ0KPiBTZW50OiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgNjoxNCBBTQ0K PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiBDYzogcnRjd2ViQGlldGYub3JnOyBJ RVRGIEFWVENvcmUgV0c7IHRzdndnDQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBbQVZUQ09SRV0g W3RzdndnXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJhZnQtaWV0Zi0NCj4gYXZ0Y29yZS1y dHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gDQo+ID4gT24gMTYgSnVuIDIwMTYsIGF0IDIz OjI1LCBKb2huIExlc2xpZSA8am9obkBqbGMubmV0PiB3cm90ZToNCj4gPg0KPiA+IEJsYWNrLCBE YXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+IC4uLiAgSSB2aWV3 IHRoZSBjdXJyZW50IHRleHQgYXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoIHRvbyBtdWNo DQo+ID4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4g aW1wbGVtZW50ZXIgZG9lc24ndA0KPiA+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxl bSBzcGFjZSBpbiB0aGUgZmlyc3QgcGxhY2UpLg0KPiANCj4gSSBhZ3JlZSwgYnV0IHRoZSBhcmd1 bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bCB0aGFuIGRlcGxveWluZyBhIGNp cmN1aXQNCj4gYnJlYWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2Vk Lg0KPiANCj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQsIHRob3VnaCwg c2luY2UgaXQgc2VlbXMgdGhhdCBhbnkgbmV3IEFRTQ0KPiB0aGF0IGFwcGxpZXMgRUNOIG1hcmtz IG11Y2ggbW9yZSBvZnRlbiB0aGFuIGF0IHByZXNlbnQgd2lsbCBoYXZlIHRvIGNvbnNpZGVyDQo+ IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3b3JrIHdpdGggZGVwbG95ZWQgVENQIChlLmcu LCBkcmFmdC1icmlzY29lLXRzdndnLQ0KPiBhcW0tdGNwbS1ybWNhdC1sNHMtcHJvYmxlbSB1c2Vz IEVDVCgxKSBhcyBhIHNpZ25hbCB0byB1c2UgdGhlIG5ldyBtYXJraW5nLA0KPiB3aGlsZSBleGlz dGluZyBpbXBsZW1lbnRhdGlvbnMgc2V0IEVDVCgwKSkuIFRoZXNlIGNvbXBhdGliaWxpdHkgbWVj aGFuaXNtcw0KPiB3b3VsZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJj dWl0IGJyZWFrZXIgdG9vLg0KPiANCj4gPiAgIFVuZGVyc3RhbmQsIHdlIGhhdmUgYXQgbGVhc3Qg dHdvIHByb3Bvc2FscyB0byBtYWtlIEVDTi1DRSBtb3JlIGZyZXF1ZW50DQo+ID4gdGhhbiBwYWNr ZXQgZHJvcCB3b3VsZCBiZSBmb3Igbm9uLUVDTiBwYWNrZXRzOiBwb3NzaWJseSBzdWJzdGFudGlh bGx5DQo+ID4gbW9yZSBmcmVxdWVudC4gVW5sZXNzIGJvdGggYXJlIGtpbGxlZCBvZmYsIEVDTi1D RSB3aWxsIHNob3cgdXAgZnJlcXVlbnRseQ0KPiA+IGVub3VnaCB0aGF0IGNsb3NpbmcgdGhlIGZs b3cgb24gRUNOLUNFIHdvdWxkIGtpbGwgdG9vIG1hbnkgY29ubmVjdGlvbnMuDQo+ID4NCj4gPiAg IElmIHlvdSB3YW50IGNpcmN1aXQtYnJlYWtpbmcgb24gc3VjaCBjb25uZWN0aW9ucywgdGhlcmUg YXJlIHR3byB3YXlzOg0KPiA+IDEuIGNvbnZpbmNlIHRoZSBmb3J3YXJkaW5nIG5vZGVzIHRvIGRy b3AgcGFja2V0cyBpZiB0aGVpciBxdWV1ZSBleGNlZWRzDQo+ID4gICBkZXNpZ24gY2FwYWNpdHk7 IG9yDQo+ID4gMi4gcmVxdWlyZSB0aGUgc2VuZGVyIHRvIHNlbmQgZW5vdWdoIG5vdC1FQ04tY2Fw YWJsZSBwYWNrZXRzIHNvIHRoYXQgb3VyDQo+ID4gICByZWNlaXZlciB3aWxsIHNlZSBlbm91Z2gg cGFja2V0LWRyb3BzIHdoZW4gYSBjaXJjdWl0LWJyZWFrZXIgc2hvdWxkDQo+ID4gICBhY3RpdmF0 ZS4NCj4gPg0KPiA+ICAgKEkgcHJlZmVyIHRoZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0 IG9iamVjdCB0byB0aGUgc2Vjb25kLikNCj4gPg0KPiA+ICAgVGhlcmUgcmVhbGx5IGlzbid0IGFu eSB3YXkgZm9yIG91ciBjaXJjdWl0LWJyZWFrZXIgdG8ga25vdyBfaG93X211Y2hfDQo+ID4gbW9y ZSBmcmVxdWVudCB0aGUgRUNOLUNFIG1hcmtzIG1heSBiZS4gOl4oDQo+IA0KPiBUaGlzIGlzIGEg cHJvYmxlbSwgYm90aCBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciwgYW5kIGZvciB0aGUgYWxnb3Jp dGhtcyBiZWluZw0KPiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNvbWUgdW5kZXJzdGFu ZGluZyB3aGF0IHRoZSBleHBlY3RlZCBtYXJraW5nDQo+IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUs IHNvIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgY2lyY3VpdCBicmVha2VycyBjYW4gYmUgZGVmaW5l ZC4NCj4gDQo+ID4gV2UgX3dpbGxfIGJlIHNvcnJ5IGlmIHdlDQo+ID4gYWxsb3QgdGhlIHNhbWUg ZnJlcXVlbmN5IG9mIENFIHBhY2tldHMgYXMgcGFja2V0LWRyb3BzIHRvIHRyaWdnZXIgdGhlDQo+ ID4gY2lyY3VpdC1icmVha2VyLg0KPiA+DQo+ID4+IENvdWxkIHNvbWVvbmUgcHJvcG9zZSBpbml0 aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZSBjdXJyZW50ICJNQVkgaWdub3JlIg0KPiA+PiBzdGF0 ZW1lbnQ/DQo+ID4NCj4gPiAgIEVzc2VudGlhbGx5LCBmb3IgdGhlIHNlY29uZCBvcHRpb24sIHlv dSBtaWdodCBwcm9wb3NlIHRleHQgdG8gdGhlDQo+ID4gZWZmZWN0IG9mOg0KPiA+IF0NCj4gPiBd IElmIHRvbyBtYW55IEVDTi1DRSBwYWNrZXRzIGFyZSByZWNlaXZlZCwgdGhlIHNlbmRlciBTSE9V TEQgc2VuZCBzb21lDQo+ID4gXSBub3QtRUNOLWNhcGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUg d2hldGhlciBlbm91Z2ggcGFja2V0cyBhbG9uZyB0aGUNCj4gPiBdIHBhdGggYXJlIGJlaW5nIGRy b3BwZWQgdG8ganVzdGlmeSBhY3RpdmF0aW5nIG91ciBjaXJjdWl0LWJyZWFrZXIuDQo+ID4NCj4g PiAgIEnigJltIG5vdCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3Vs ZCByZXNvbHZlIHRoZSBpc3N1ZS4NCj4gDQo+IEnigJltIG5vdCBjb252aW5jZWQgdGhpcyB3b3Vs ZCB3b3JrLiBUaGUgY2lyY3VpdCBicmVha2VyIGlzIGxvb2tpbmcgYXQgbG9uZyB0ZXJtDQo+IHRy ZW5kcywgYW5kIGluIG9yZGVyIHRvIGhhdmUgZW5vdWdoIG5vdC1FQ1QgcGFja2V0cyB0byBkZXRl cm1pbmUgaWYgaXQgc2hvdWxkDQo+IHRyaWdnZXIsIHlvdeKAmWQgZXNzZW50aWFsbHkgaGF2ZSB0 byBydW4gd2l0aG91dCBFQ04gZm9yIHNvbWUgc2Vjb25kcy4NCj4gDQo+IC0tDQo+IENvbGluIFBl cmtpbnMNCj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiANCj4gDQo+IA0KDQo= From nobody Fri Jun 17 07:13:10 2016 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 06FBD12D62F; Fri, 17 Jun 2016 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 L1lz3ahcFRMb; Fri, 17 Jun 2016 07:13:07 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C238512D0FF; Fri, 17 Jun 2016 07:13:07 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HED5wG015928; Fri, 17 Jun 2016 07:13:05 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 106154CE758A; Fri, 17 Jun 2016 10:13:52 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document33151.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 10:13:52 -0400 Message-ID: <6766.1466172832@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:13:09 -0000 --=-------459435943823349593450 Content-Type: text/plain I am mulling this. But, a question... > So simply focusing on the actual recommendation in the doc (and > the needed statements how this doc related to other docs in the > RFC series) is sufficient for me and more clear. I guess this is counter-intuitive to me as usually implicitness is a less direct path to clarity than explicitness. So, would you also then get rid of (R.2)? So, we use (R.1) to state how the doc relates to existing specs and then say nothing about the future (about either specs or implementations). To me that is at least a more consistent path than retaining (R.2) and removing (R.3). But, I am still mulling ... Thanks, allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkBZ0ACgkQWyrrWs4yIs5k3wCeIvJCrbIiKvo0PxG7CvZ+I02m lNsAn0cfLWZbDq3uDG00DrhCX6pspoPg =Y2/k -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 07:23:06 2016 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 84DF212D62F; Fri, 17 Jun 2016 07:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 gues2klBF0AH; Fri, 17 Jun 2016 07:22:59 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946C712D0FC; Fri, 17 Jun 2016 07:22:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E2515D9305; Fri, 17 Jun 2016 16:22:56 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yJZCo+LhDG6V; Fri, 17 Jun 2016 16:21:48 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A53F3D9304; Fri, 17 Jun 2016 16:21:48 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <6766.1466172832@lawyers.icir.org> Date: Fri, 17 Jun 2016 16:21:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CDD4A4D-085F-4621-8D49-2629A24808B3@tik.ee.ethz.ch> References: <6766.1466172832@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:23:01 -0000 I find R-2 less problematic/confusing but also probably not needed. = Especially seeing the SHOULD in there seems slightly weird to me. To me = the better approach would be to simply use SHOULDs instead of (most of = the) MUSTs in the latter text in the doc; and potentially add more text = there that the SHOULD is a really strong SHOULD and there must be a good = reason to deviate. Mirja =20 > Am 17.06.2016 um 16:13 schrieb Mark Allman : >=20 >=20 > I am mulling this. But, a question... >=20 >> So simply focusing on the actual recommendation in the doc (and >> the needed statements how this doc related to other docs in the >> RFC series) is sufficient for me and more clear. >=20 > I guess this is counter-intuitive to me as usually implicitness is a > less direct path to clarity than explicitness. >=20 > So, would you also then get rid of (R.2)? So, we use (R.1) to state > how the doc relates to existing specs and then say nothing about the > future (about either specs or implementations). To me that is at > least a more consistent path than retaining (R.2) and removing > (R.3). >=20 > But, I am still mulling ... >=20 > Thanks, > allman >=20 >=20 >=20 From nobody Fri Jun 17 08:02:43 2016 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 5AF8112D6A1; Fri, 17 Jun 2016 08:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 qOLuHtqOyGy4; Fri, 17 Jun 2016 08:02:39 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC4112D686; Fri, 17 Jun 2016 08:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E0759D9305; Fri, 17 Jun 2016 17:02:37 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FHFcyi7WHAnM; Fri, 17 Jun 2016 17:02:37 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8C04FD9304; Fri, 17 Jun 2016 17:02:37 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 17 Jun 2016 17:02:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> To: "Black, David" , Magnus Westerlund , Colin Perkins X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:02:42 -0000 +1 to not use normative language here. However, please note that having a high level of ECN-CE marks (without = any losses) means that all packets were received correctly. This = situation can even occurs without high delays (depending on the AQM = used), which would just mean the services works perfectly. Therefore for = me CE marks are a perfect input signal for a congestion control loop = (where the AQM tell the sender to take action - whatever that means). = But I=E2=80=99m less concerned than David about eventually ignoring it = for circuit breaker. In addition one point on something Magnus wrote earlier: "If the implementation only have circuit breaker, i.e. no full fledged = congestion controller and uses ECN, they can in worst case drive the = buffer into the overload regime where it starts dropping packets. =E2=80=9E= I=E2=80=99m not sure about this case. ECN is an input signal for = congestion control. If you don=E2=80=99t use congestion control but only = a circuit breaker, you should probably not enable ECN. At least it not = clear to me why you would enable it, and it's definitely not conform to = the ECN spec. Probably we should say something about this in the = draft...? Mirja > Am 17.06.2016 um 16:03 schrieb Black, David : >=20 > Colin, >=20 >>>> ... I view the current text as providing implementers with too = much >>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>> want to think about this problem space in the first place). >>=20 >> I agree, but the argument is that doing so is less harmful than = deploying a circuit >> breaker that triggers too often when ECN is used. >>=20 >> I=E2=80=99m not sure I believe this argument, though, since it seems = that any new AQM >> that applies ECN marks much more often than at present will have to = consider >> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe-tsvwg- >> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >> while existing implementations set ECT(0)). These compatibility = mechanisms >> would seem to prevent the issues with the circuit breaker too. >=20 > That roughly matches my line of thinking, and I'll observe that the = original DCTCP > protocol design that used more aggressive ECN-CE marking was only safe = for > Controlled Environment deployments. See the TSVWG rfc5405bis draft = for the > definition of Controlled Environment, and ignore the fact that the = rfc5405bis > draft is a UDP draft - this definition is more broadly applicable. >=20 > Going back over Section 7 in this avtcore draft, my views are: >=20 > [A] None of these drafts justify a "MAY ignore" response to ECN-CE = marks: > - draft-khademi-tcpm-alternativebackoff-ecn > - draft-ietf-rmcat-nada > - draft-ietf-rmcat-scream-cc >=20 > [B] In line with Colin's comment on the L4S draft, I think it's = incumbent on > the authors of draft-briscoe-aqm-dualq-coupled to figure out how that = will > coexist (or avoid) deployed TCP, and this avtcore draft ought not to = be > trying to prejudge what will be done there. >=20 > So, I don't think the current text in Section 7 has justified the = unfettered > "implementations MAY ignore ECN-CE marks" text, as ignoring those = marks > is not consistent with any of the four cited drafts. >=20 > In more detail, I think making changes to normative requirements here = based > on [B] is premature, and I would hope that the rmcat WG could be = encouraged > to consider the RTP circuit breaker in its congestion control drafts, = as those CC > mechanisms are related to the circuit breaker mechanism, hence likely > to be in related areas of an RTP implementation. >=20 > That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG > will be looking at in Berlin. If a normative statement about ECN-CE = reaction > is going to rest on that draft, then the reference to that draft = should be > normative. Something about doing that strikes me as premature ... >=20 > I realize that we're trying to predict and accommodate the future, = which > is an imprecise undertaking at best. As an alternative to the = current text, > would it be reasonable to say (without any RFC 2119 keywords) that the > best current guidance is still to treat ECN-CE marks as indicating = drops, > with a warning that there is a good possibility of this changing in = the > near future due to all of the work in progress cited in Section 7? >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Friday, June 17, 2016 6:14 AM >> To: John Leslie; Black, David >> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: = draft-ietf- >> avtcore-rtp-circuit-breakers-16 >>=20 >>=20 >>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>=20 >>> Black, David wrote: >>>>=20 >>>> ... I view the current text as providing implementers with too = much >>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>> want to think about this problem space in the first place). >>=20 >> I agree, but the argument is that doing so is less harmful than = deploying a circuit >> breaker that triggers too often when ECN is used. >>=20 >> I=E2=80=99m not sure I believe this argument, though, since it seems = that any new AQM >> that applies ECN marks much more often than at present will have to = consider >> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe-tsvwg- >> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >> while existing implementations set ECT(0)). These compatibility = mechanisms >> would seem to prevent the issues with the circuit breaker too. >>=20 >>> Understand, we have at least two proposals to make ECN-CE more = frequent >>> than packet drop would be for non-ECN packets: possibly = substantially >>> more frequent. Unless both are killed off, ECN-CE will show up = frequently >>> enough that closing the flow on ECN-CE would kill too many = connections. >>>=20 >>> If you want circuit-breaking on such connections, there are two = ways: >>> 1. convince the forwarding nodes to drop packets if their queue = exceeds >>> design capacity; or >>> 2. require the sender to send enough not-ECN-capable packets so that = our >>> receiver will see enough packet-drops when a circuit-breaker should >>> activate. >>>=20 >>> (I prefer the first option; but I wouldn't object to the second.) >>>=20 >>> There really isn't any way for our circuit-breaker to know = _how_much_ >>> more frequent the ECN-CE marks may be. :^( >>=20 >> This is a problem, both for the circuit breaker, and for the = algorithms being >> defined in RMCAT. We do need some understanding what the expected = marking >> rates are likely to be, so congestion control and circuit breakers = can be defined. >>=20 >>> We _will_ be sorry if we >>> allot the same frequency of CE packets as packet-drops to trigger = the >>> circuit-breaker. >>>=20 >>>> Could someone propose initial text to qualifies the current "MAY = ignore" >>>> statement? >>>=20 >>> Essentially, for the second option, you might propose text to the >>> effect of: >>> ] >>> ] If too many ECN-CE packets are received, the sender SHOULD send = some >>> ] not-ECN-capable packets to determine whether enough packets along = the >>> ] path are being dropped to justify activating our circuit-breaker. >>>=20 >>> I=E2=80=99m not enthusiastic about adding that; but it would = resolve the issue. >>=20 >> I=E2=80=99m not convinced this would work. The circuit breaker is = looking at long term >> trends, and in order to have enough not-ECT packets to determine if = it should >> trigger, you=E2=80=99d essentially have to run without ECN for some = seconds. >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jun 17 09:06:00 2016 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 8446612D69B; Fri, 17 Jun 2016 09:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 pQ5bOq_0zsDu; Fri, 17 Jun 2016 09:05:57 -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 8CF5412D665; Fri, 17 Jun 2016 09:05:57 -0700 (PDT) Received: from [10.3.79.239] (unknown [85.255.235.103]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9B6331B0034C; Fri, 17 Jun 2016 17:05:45 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Fri, 17 Jun 2016 17:05:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18E75E0E-06BD-4C72-9EBD-F54AF73141A0@erg.abdn.ac.uk> References: <34060.1464721077@lawyers.icir.org> To: "Eggert, Lars" Archived-At: Cc: "draft-ietf-tsvwg-rfc5405bis.all@ietf.org" , "tsvwg@ietf.org" , "mallman@icir.org" Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 16:05:59 -0000 > On 17 Jun 2016, at 14:45, Eggert, Lars wrote: >=20 > Hi, >=20 >> On 2016-05-31, at 20:57, Mark Allman wrote: >> - I'd be interested to hear why it is RECOMMENDED to adhere to the >> RTO algorithm in RFC6298. In my view, in 2016 this is just >> unnecessary and wrong (see my broader opinion below). (That >> said, if someone wants to use that algorithm, I think it is >> fine... but, prescribing it is not needed, IMO.) >=20 > because it's a reasonable example for which we have a spec. I'm happy to r= ecommend something else that is reasonable. >=20 >> - I'd also like to see the normative text better underscore the >> importance of backoff. >=20 > More than we currently do? >=20 > It is important to note that the initial timeout value is not the > maximum possible timeout -- the RECOMMENDED algorithm in [RFC6298] > doubles the measured RTT value /measured rtt/timeout period/ was what I suggested. > after each timeout (e.g., [RFC3261]). > After a series of timeouts, this exponential back-off therefore > results in values that are much longer than the initial value. >=20 > Would you suggest text? >=20 >> - "TCP requires the initial RTT to be set to no less than 1 >> second" ... TCP requires the initial ***RTO*** be no less than 1 >> second. There is a difference between the RTT and the RTO and >> this draft is pretty liberal with using them interchangeably >> (which is both confusing and wrong). >=20 > Oops. Will check. >=20 Basically there is not in general a concept of RTO in UDP protocols, althou= gh reliable protocols could follow TCP.=20 >> A broader opinion is that we should just elide these words in favor >> of a set of general RTO guidelines that span protocols (see >> draft-ietf-tcpm-rto-consider ; which goes beyond TCP, but is in TCPM >> for now because TCP is where it started, but comments would be >> appreciated from all corners). >=20 > We could do that. At this point, I'm in favor of doing whatever get this o= ff my plate faster :-) The publication status and scope of Marks draft currently in TCPM still need= s discussion... Including how and whether it will mention UDP... Let's hope= that is clear soon. This ref to that draft was intended to help progress bo= th. I fear Removing the mention of retransmission from the guidelines to onl= y an external reference stalls both drafts to a discussion in Berlin...=20 > Lars I think suggested text would be helpful. Gorry= From nobody Fri Jun 17 09:15:17 2016 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 AE23512D53A for ; Fri, 17 Jun 2016 09:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-WkFD0o_ikQ for ; Fri, 17 Jun 2016 09:15:13 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AEF12D825 for ; Fri, 17 Jun 2016 09:15:04 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g20so75839200ywb.0 for ; Fri, 17 Jun 2016 09:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KqQYq5ioavoZwVqIfj9gFmhby37618ZnFnHeYkfhQmI=; b=iowW1EUPdl5lobY8t+y4o8xwSJRaNnRmfMt+Ub9C/bbDmiTx/4gFhP8Obs8o3rlxlM RFm8wugu0MYS15ffp2MqYmWhmvUmxXpjT4BD0qEIW6MqpO69OD0C1jdIK3OPFlb25NAg Qy1iNTS9lF0TSrhZnCg342j6chloj9AvyjDPR1Lwc1GuERnb+dSsewHozwzn86sfJfiW RxE71HKTQHHsVrlj0NKje7i/t0Q1JMtt58uV3oyOogC05U8CPrJKfNL70nc2IM+MvRnN Jc0QgD20LwycUb1HNJJDItnN7NLfzdRFgvNHU6WVAesYqNV1qPeDhG3BBG2gosW6jhj2 bHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KqQYq5ioavoZwVqIfj9gFmhby37618ZnFnHeYkfhQmI=; b=hwMiU17+wrcVG7BZkdNWG9tFnRECfbsgd9P7PgT3RPXwMSQMT1PJGQxRFexfLFNf1i uT4HINNGC0up3j/xRw7rAdxEy/YiCnn2k6I1/jtMlKC+lDzhlAr0XxSViorcY2u4ZE/h oI6ubpHw2MPjpns96hTFGglPMHjA8BzsR5lPLERnIIZ4STXROds9QukTqbkteK9i7E0q DKgmfLgUzmxbqX6Rbxwbvhtzvz6K37iYPwqVqXwtQECMUFKFVO6FW4bHYmAx0DTSLr7T bmtsosdFth5ETSPiJrfQkC+zoxiTOynEucpvIYA98sFMJ6u6LKjz3ICbVc4/ez/h5hoz 6AEg== X-Gm-Message-State: ALyK8tJbMKaLqxOegJpcxZ/P6AQ8g8kBiLF86Lwdcj2+hqAqjwPKrYYa+6Rjzb7Qnt+Uy9iLy0h4w93hNJ312ijv X-Received: by 10.37.49.193 with SMTP id x184mr1604233ybx.57.1466180103693; Fri, 17 Jun 2016 09:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.219.83 with HTTP; Fri, 17 Jun 2016 09:15:00 -0700 (PDT) In-Reply-To: <18E75E0E-06BD-4C72-9EBD-F54AF73141A0@erg.abdn.ac.uk> References: <34060.1464721077@lawyers.icir.org> <18E75E0E-06BD-4C72-9EBD-F54AF73141A0@erg.abdn.ac.uk> From: Jana Iyengar Date: Fri, 17 Jun 2016 09:15:00 -0700 Message-ID: To: "Gorry (erg)" Content-Type: multipart/alternative; boundary=001a1148af184256e805357ba85e Archived-At: Cc: "draft-ietf-tsvwg-rfc5405bis.all@ietf.org" , "tsvwg@ietf.org" , "mallman@icir.org" Subject: Re: [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 16:15:16 -0000 --001a1148af184256e805357ba85e Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 9:05 AM, Gorry (erg) wrote: > > > > On 17 Jun 2016, at 14:45, Eggert, Lars wrote: > > > > Hi, > > > >> On 2016-05-31, at 20:57, Mark Allman wrote: > >> - I'd be interested to hear why it is RECOMMENDED to adhere to the > >> RTO algorithm in RFC6298. In my view, in 2016 this is just > >> unnecessary and wrong (see my broader opinion below). (That > >> said, if someone wants to use that algorithm, I think it is > >> fine... but, prescribing it is not needed, IMO.) > > > > because it's a reasonable example for which we have a spec. I'm happy to > recommend something else that is reasonable. > > > >> - I'd also like to see the normative text better underscore the > >> importance of backoff. > > > > More than we currently do? > > > > It is important to note that the initial timeout value is not the > > maximum possible timeout -- the RECOMMENDED algorithm in [RFC6298] > > doubles the measured RTT value > /measured rtt/timeout period/ was what I suggested. > > > after each timeout (e.g., [RFC3261]). > > After a series of timeouts, this exponential back-off therefore > > results in values that are much longer than the initial value. > > > > Would you suggest text? > > > >> - "TCP requires the initial RTT to be set to no less than 1 > >> second" ... TCP requires the initial ***RTO*** be no less than 1 > >> second. There is a difference between the RTT and the RTO and > >> this draft is pretty liberal with using them interchangeably > >> (which is both confusing and wrong). > > > > Oops. Will check. > > > Basically there is not in general a concept of RTO in UDP protocols, > although reliable protocols could follow TCP. While that's true, there can be an expectation of something like an RTO. We did this for LEDBAT, and we called it a Congestion Timeout (CTO). From RFC 6817: update_CTO() # implements an RTT estimation mechanism using data # transmission times and ACK reception times, # which is used to implement a congestion timeout (CTO). # If implementing LEDBAT in TCP, sender SHOULD use # mechanisms described in RFC 6298 [RFC6298 ], # and the CTO would be the same as the retransmission timeout (RTO). and this is used as follows: if no ACKs are received within a CTO: # extreme congestion, or significant RTT change. # set cwnd to 1MSS and backoff the congestion timer. cwnd = 1 * MSS CTO = 2 * CTO The UDP guidelines draft can a reflect similar concept and language. > > >> A broader opinion is that we should just elide these words in favor > >> of a set of general RTO guidelines that span protocols (see > >> draft-ietf-tcpm-rto-consider ; which goes beyond TCP, but is in TCPM > >> for now because TCP is where it started, but comments would be > >> appreciated from all corners). > > > > We could do that. At this point, I'm in favor of doing whatever get this > off my plate faster :-) > > The publication status and scope of Marks draft currently in TCPM still > needs discussion... Including how and whether it will mention UDP... Let's > hope that is clear soon. This ref to that draft was intended to help > progress both. I fear Removing the mention of retransmission from the > guidelines to only an external reference stalls both drafts to a discussion > in Berlin... > +1 to using rto-consider as the reference if at all possible. - jana > > Lars > > I think suggested text would be helpful. > > Gorry > --001a1148af184256e805357ba85e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 17, 2016 at 9:05 AM, Gorry (erg) <gorry@erg.abdn.ac.uk> wro= te:


> On 17 Jun 2016, at 14:45, Eggert, Lars <lars@netapp.com> wrote:
>
> Hi,
>
>> On 2016-05-31, at 20:57, Mark Allman <mallman@icir.org> wrote:
>> - I'd be interested to hear why it is RECOMMENDED to adhere to= the
>>=C2=A0 =C2=A0RTO algorithm in RFC6298.=C2=A0 In my view, in 2016 th= is is just
>>=C2=A0 =C2=A0unnecessary and wrong (see my broader opinion below).= =C2=A0 (That
>>=C2=A0 =C2=A0said, if someone wants to use that algorithm, I think = it is
>>=C2=A0 =C2=A0fine... but, prescribing it is not needed, IMO.)
>
> because it's a reasonable example for which we have a spec. I'= m happy to recommend something else that is reasonable.
>
>> - I'd also like to see the normative text better underscore th= e
>>=C2=A0 =C2=A0importance of backoff.
>
> More than we currently do?
>
>=C2=A0 =C2=A0It is important to note that the initial timeout value is = not the
>=C2=A0 =C2=A0maximum possible timeout -- the RECOMMENDED algorithm in [= RFC6298]
>=C2=A0 =C2=A0doubles the measured RTT value
/measured rtt/timeout period/ was what I suggested.

> after each timeout (e.g., [RFC3261]).
>=C2=A0 =C2=A0After a series of timeouts, this exponential back-off ther= efore
>=C2=A0 =C2=A0results in values that are much longer than the initial va= lue.
>
> Would you suggest text?
>
>> - "TCP requires the initial RTT to be set to no less than 1 >>=C2=A0 =C2=A0second" ... TCP requires the initial ***RTO*** be= no less than 1
>>=C2=A0 =C2=A0second.=C2=A0 There is a difference between the RTT an= d the RTO and
>>=C2=A0 =C2=A0this draft is pretty liberal with using them interchan= geably
>>=C2=A0 =C2=A0(which is both confusing and wrong).
>
> Oops. Will check.
>
=C2=A0Basically there is not in general a concept of RTO in UDP prot= ocols, although reliable protocols could follow TCP.

<= /div>
While that's true, there can be an expectation of something l= ike an RTO. We did this for LEDBAT, and we called it a Congestion Timeout (= CTO). From RFC 6817:
update_CTO=
()
    # implements an RTT estimation mechanism using data
    # transmission times and ACK reception times,
    # which is used to implement a congestion timeout (CTO).
    # If implementing LEDBAT in TCP, sender SHOULD use
    # mechanisms described in RFC 6298 [RFC6298],
    # and the CTO would be the same as the retransmission timeout (RTO).

and this is used as follows:
if no ACKs are received within a CTO: # extreme congestion, or significant RTT change. # set cwnd to 1MSS and backoff the congestion timer. cwnd =3D 1 * MSS CTO =3D 2 * CTO

The UDP guidelines draft can a reflect simi= lar concept and language.

>> A broader opinion is that we should just elide these words in favo= r
>> of a set of general RTO guidelines that span protocols (see
>> draft-ietf-tcpm-rto-consider ; which goes beyond TCP, but is in TC= PM
>> for now because TCP is where it started, but comments would be
>> appreciated from all corners).
>
> We could do that. At this point, I'm in favor of doing whatever ge= t this off my plate faster :-)

The publication status and scope of Marks draft currently in TCPM st= ill needs discussion... Including how and whether it will mention UDP...=C2= =A0 Let's hope that is clear soon. This ref to that draft was intended = to help progress both. I fear Removing the mention of retransmission from t= he guidelines to only an external reference stalls both drafts to a discuss= ion in Berlin...

+1 to using rto-consid= er as the reference if at all possible.

- jana
=C2=A0
> Lars

I think suggested text would be helpful.

Gorry

--001a1148af184256e805357ba85e-- From nobody Fri Jun 17 10:08:31 2016 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 594B312D7E5; Fri, 17 Jun 2016 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wVUfwLQzel9f; Fri, 17 Jun 2016 10:08:26 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69BF12D8CE; Fri, 17 Jun 2016 10:08:18 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HH8GOE009339; Fri, 17 Jun 2016 10:08:16 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 58DE84D0102A; Fri, 17 Jun 2016 13:09:04 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <1CDD4A4D-085F-4621-8D49-2629A24808B3@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document65411.doc X-URL-1: http://www.icir.org/mallman-files/Document5190.docx X-URL-2: http://www.icir.org/mallman-files/Document36104.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 13:09:04 -0400 Message-ID: <30640.1466183344@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 17:08:27 -0000 --=-------459435943823349593450 Content-Type: text/plain I like to re-state things to see if I understand what is being said. So, let me see if I understand what you're suggesting (in high level terms). (This is about the RTO document in specific, but more broadly would seem applicable to single-host algorithm specifications.) You are starting from the fact that implementers are not beholden to the RFCs in any tangible way. And, also the fact that we don't have any real recourse when the standards are not followed. So, since they don't feel constrained by the RFCs, we should approach RFCs in the same way and not worry about constraints as much as giving our best recommendations. We hope our strong recommendations are listened to and used. But, if they are not, they are not and there isn't anything we can do about them regardless of what we say people "MUST" do. I.e., the standards process should meet the implementers where they are. Is that roughly correct? (In the above I mean to have no opinion, just trying to understand your hit. I may subsequently have an opinion and if I can somehow get over my usual shyness I might then say it. :) ) allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkLq0ACgkQWyrrWs4yIs62jACfV/a/5+FNkTIW/OTz15/3GLXa MIwAnj0jVqftlOG3JogkqUb7zhpZz1+o =Ns0p -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 11:24:20 2016 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 4984712D97F for ; Fri, 17 Jun 2016 11:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Asepz2jC3Vnd for ; Fri, 17 Jun 2016 11:24:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B91C12D979 for ; Fri, 17 Jun 2016 11:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=794; q=dns/txt; s=iport; t=1466187857; x=1467397457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rOGPjqSXG7giMO1XwlmbqH2c7V9yx9RD8L9RSyhG/zQ=; b=AugtjdEJFQVPj8Pv4YL+0mpjq78ihVkpx9lPRUjz7jT5EfiQr7csfp/w ELI3LOVwQGMfWSLJ4MKV5u0MV9H8ycLfL8u6kUO2XtcpGhIWFJiT7lDCC 1YoWXKvmyy1AsfFCG358bi9HJi0dbWsEvptQvCS8roSx492JoFjPomU7W o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBEP2RX/4MNJK1dgz6BUwa6WYF6h?= =?us-ascii?q?hcCgSQ4FAEBAQEBAQFlJ4RLAQEBAwE6PwUHBAIBCBEEAQEBHgkHMhQJCAEBBA4?= =?us-ascii?q?FCIggCMEKAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIp0gTmIYgEEmHEBjiGPKY90A?= =?us-ascii?q?R42g3BuiHx/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,484,1459814400"; d="scan'208";a="119940965" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jun 2016 18:24:16 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5HIOGgJ002779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 18:24:16 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 17 Jun 2016 13:24:15 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1104.009; Fri, 17 Jun 2016 13:24:15 -0500 From: "Tim Szigeti (szigeti)" To: "Fred Baker (fred)" , "Black, David" Thread-Topic: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 Thread-Index: AdHCDchogAyx4sMnQ9q77258V6wqAgAd13sAAZAMs5A= Date: Fri, 17 Jun 2016 18:24:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.208.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:24:18 -0000 Same for me - I know of no such IPR. Thanks, -tim -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Thursday, June 09, 2016 7:29 AM To: Black, David Cc: tsvwg@ietf.org Subject: Re: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - th= rough June 25 > On Jun 8, 2016, at 11:14 PM, Black, David wrote: >=20 > Authors: We (chairs) assume that you support WG adoption of your=20 > draft, so there's no need to say so on the list. However, we do need=20 > each author to publicly state on the list that their direct, personal=20 > knowledge (if any) of any IPR related to this document has already=20 > been disclosed, in conformance with BCPs 78 and 79. I know of no such IPR. From nobody Fri Jun 17 11:27:42 2016 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 2914412D995; Fri, 17 Jun 2016 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 x_vnTTojdwhj; Fri, 17 Jun 2016 11:27:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B305812D98D; Fri, 17 Jun 2016 11:27:38 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 76CBF7BBBFA07; Fri, 17 Jun 2016 18:27:33 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HIRarN030652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 18:27:36 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HIRZDT026199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 20:27:36 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 20:27:35 +0200 From: "Scharf, Michael (Nokia - DE)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyJs+daDP2nXoIEy1xGblSmRRlJ/tj0yAgABTZTA= Date: Fri, 17 Jun 2016 18:27:35 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB3B5@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <98229.1466169727@lawyers.icir.org> <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> In-Reply-To: <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:27:41 -0000 V2l0aCBjaGFpciBoYXQgb2ZmLi4uDQoNCj4gQWdhaW4sIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhh dCB0aGUgc3RhdGVtZW50IGlzIG5vdCBuZWVkZWQsIGFuZCBJIGZpbmQgaXQgcmF0aGVyIGNvbmZ1 c2luZyB0aGF0IGhlbHBmdWwuIEJhc2VkIG15IChsaW1pdGVkKSBleHBlcmllbmNlIGluIChMaW51 eCkgaW1wbGVtZW50b3JzIGNvbW11bml0eSBJIHdvdWxkIGxpa2UgdG8gYWRkIHRoYXQgZXZlbiB0 aG91Z2ggdGhleSBhcmUgb2Z0ZW4gbm90IHZlcnkgYWN0aXZlIG9uIGlldGYgbWFpbGluZyBsaXN0 cyBhbmQgbWlnaHQgbm90IGZvbGxvdyB0aGUgUkZDIGluIHRoZWlyIGltcGxlbWVudGF0aW9uLCB0 aGV5IHN0aWxsIHJlYWQgdGhlIGRyYWZ0LiBTbyBzaW1wbHkgZm9jdXNpbmcgb24gdGhlIGFjdHVh bCByZWNvbW1lbmRhdGlvbiBpbiB0aGUgZG9jIChhbmQgdGhlIG5lZWRlZCBzdGF0ZW1lbnRzIGhv dyB0aGlzIGRvYyByZWxhdGVkIHRvIG90aGVyIGRvY3MgaW4gdGhlIFJGQyBzZXJpZXMpIGlzIHN1 ZmZpY2llbnQgZm9yIG1lIGFuZCBtb3JlIGNsZWFyLg0KDQorMSBvbiByZW1vdmluZyAoUi4zKQ0K DQpJIGRvIE5PVCBzdXBwb3J0IHRoZSBjdXJyZW50IGxhbmd1YWdlIGluIChSLjMpLCBhcyB3ZWxs IGFzIHJlbGF0ZWQgd29yZGluZyBvbiAiaW1wbGVtZW50YXRpb25zIiBlbHNld2hlcmUgaW4gdGhl IGRvY3VtZW50Lg0KIA0KRm9yIFRDUCwgSSBhbSBjb25mdXNlZCBieSBob3cgdGhpcyB3b3JkaW5n IHJlbGF0ZXMgdG8gUkZDIDYyOTguIEZvciBUQ1AsIEkgZnVsbHkgYWdyZWUgdGhhdCBhbGxvd2lu ZyBtb3JlIGZsZXhpYmlsaXR5IGNvbXBhcmVkIHRvIFJGQyA2Mjk4IHdvdWxkIGJlIHVzZWZ1bCwg YW5kIGEgbmV3IFJGQyA2Mjk4YmlzIGNvdWxkIHJlZmVyZW5jZSBhIEJDUCBkcmFmdC1pZXRmLXRj cG0tcnRvLWNvbnNpZGVyLiBIb3dldmVyLCBJIGJlbGlldmUgdGhhdCBndWlkYW5jZSBmb3IgVENQ IGltcGxlbWVudGVycyBiZWxvbmdzIGludG8gYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgUkZD IDYyOThiaXMuIFRoZSBkb2N1bWVudCBkcmFmdC1pZXRmLXRjcG0tcnRvLWNvbnNpZGVyIHNob3Vs ZCBmb2N1cyBvbiBhIHNldCBvZiByZXF1aXJlbWVudHMgb25seS4gDQoNClNvcnJ5LCBJIHNob3Vs ZCBoYXZlIGNvbW1lbnRlZCBvbiB0aGF0IHByaW9yIHRvIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24g YnV0IEkgaGF2ZSBmb2N1c2VzIHNvIGZhciBvbiB0aGUgYWN0dWFsIHdvcmRpbmcgb2YgdGhlIHJl cXVpcmVtZW50cywgd2hpY2ggYXJlIG5vdCByZWFsbHkgY29udHJvdmVyc2lhbCAoYnV0IHNlZSB0 aGUgbm90ZSBiZWxvdykuDQoNCkkgd291bGQgYWRkIHRoYXQgSSBoYXZlIHNvbWUgZG91YnRzIG9u IHRoZSBNVVNUIGZvciBleHBvbmVudGlhbCBiYWNrb2ZmIGJ1dCBJIGhhdmUgdG8gZnVydGhlciB0 aGluayBhYm91dCB0aGlzLiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGF0IGEgcmV0cmFuc21pc3Np b24gdGltZW91dCB0aGF0IG9ubHkgYmFja3Mgb2ZmIGFmdGVyIHNvbWUgYXR0ZW1wdHMgd291bGQg YWxzbyBiZSByZWFzb25hYmx5IHNhZmUuIEFsc28sIGEgdGltZXIgdGhhdCB3b3VsZCBleHBvbmVu dGlhbGx5IGJhY2sgb2ZmIGV2ZXJ5IHNlY29uZCBhdHRlbXB0IHdvdWxkIGFsc28gd29yayBJTUhP LiBJIHRoaW5rIHRoZSBjdXJyZW50IE1VU1QgdGhhdCBkaXNhbGxvd3MgdGhpcyBpcyBzbGlnaHRs eSB0b28gcmVzdHJpY3RpdmUgYnV0IEkgY291bGQgbm90IGNvbWUgdXAgd2l0aCBzb21ldGhpbmcg YmV0dGVyIHRvZGF5Lg0KDQpQbGVhc2UgZmluZCBiZWxvdyBteSByZXZpZXcgZm9yIC0wNCwgbXkg Y29tbWVudHMgYXJlIGxpc3RlZCB3aXRoIFttc10gYmVsb3cuIEkgaGF2ZSBwcm92aWRlZCBhbHRl cm5hdGl2ZSB3b3JkaW5nIGZvciBtb3N0IGNhc2VzIHRvIGF2b2lkIGFtYmlndWl0eS4NCg0KVGhh bmtzDQoNCk1pY2hhZWwNCg0KDQoNCioqKioqIHJldmlldyBvZiAtMDQgKioqKioNCg0KKiBUaXRs ZQ0KDQogIlJldHJhbnNtaXNzaW9uIFRpbWVvdXQgUmVxdWlyZW1lbnRzIg0KDQpbbXNdIEkgYW0g ZmluZSB3aXRoIHRoZSBuZXcgdGl0bGUuDQoNCiogQWJzdHJhY3QNCg0KW21zXSBPTEQNCg0KICAg IEVuc3VyaW5nIHJlbGlhYmxlIGNvbW11bmljYXRpb24gb2Z0ZW4gbWFuaWZlc3RzIGluIGEgdGlt ZW91dCBhbmQNCiAgICByZXRyeSBtZWNoYW5pc20uICBFYWNoIGltcGxlbWVudGF0aW9uIG9mIGEg cmV0cmFuc21pc3Npb24gdGltZW91dA0KICAgIG1lY2hhbmlzbSByZXByZXNlbnRzIGEgYmFsYW5j ZSBiZXR3ZWVuIGNvcnJlY3RuZXNzIGFuZCB0aW1lbGluZXNzDQogICAgYW5kIHRoZXJlZm9yZSBu byBpbXBsZW1lbnRhdGlvbiBzdWl0cyBhbGwgc2l0dWF0aW9ucy4gIFRoaXMgZG9jdW1lbnQNCiAg ICBwcm92aWRlcyBoaWdoLWxldmVsIHJlcXVpcmVtZW50cyBmb3IgcmV0cmFuc21pc3Npb24gdGlt ZW91dCBzY2hlbWVzDQogICAgYXBwcm9wcmlhdGUgZm9yIGdlbmVyYWwgdXNlIGluIHRoZSBJbnRl cm5ldC4gIFdpdGhpbiB0aGUNCiAgICByZXF1aXJlbWVudHMsIGltcGxlbWVudGF0aW9ucyBoYXZl IGxhdGl0dWRlIHRvIGRlZmluZSBwYXJ0aWN1bGFycw0KICAgIHRoYXQgYmVzdCBhZGRyZXNzIGVh Y2ggc2l0dWF0aW9uLg0KDQpbbXNdIE5FVw0KDQogICAgRW5zdXJpbmcgcmVsaWFibGUgY29tbXVu aWNhdGlvbiBvZnRlbiBtYW5pZmVzdHMgaW4gYSB0aW1lb3V0IGFuZA0KICAgIHJldHJ5IG1lY2hh bmlzbS4gIEVhY2ggcmV0cmFuc21pc3Npb24gdGltZW91dCBtZWNoYW5pc20gcmVwcmVzZW50cw0K ICAgIGEgYmFsYW5jZSBiZXR3ZWVuIGNvcnJlY3RuZXNzIGFuZCB0aW1lbGluZXNzLiBUaGlzIGRv Y3VtZW50DQogICAgcHJvdmlkZXMgaGlnaC1sZXZlbCByZXF1aXJlbWVudHMgZm9yIHJldHJhbnNt aXNzaW9uIHRpbWVvdXQgc2NoZW1lcw0KICAgIGFwcHJvcHJpYXRlIGZvciBnZW5lcmFsIHVzZSBp biB0aGUgSW50ZXJuZXQuDQoNCiogU2VjdGlvbiAxICAgSW50cm9kdWN0aW9uDQoNClttc10gT0xE DQoNCiAgICBUaGUgaW50ZW50IGlzIHRvIHByb3ZpZGUgYSBzYWZlDQogICAgZm91bmRhdGlvbiBv biB3aGljaCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSB0aGUgZmxleGliaWxpdHkgdG8NCiAgICBpbnN0 YW50aWF0ZSBtZWNoYW5pc21zIHRoYXQgYmVzdCByZWFsaXplIHRoZWlyIHNwZWNpZmljIGdvYWxz Lg0KDQpbbXNdIE5FVw0KDQogICAgVGhlIGludGVudCBpcyB0byBwcm92aWRlIGEgZm91bmRhdGlv biBvZiByZXF1aXJlbWVudHMgZm9yIHJldHJhbnNtaXNzaW9uDQogICAgdGltZW91dCBtZWNoYW5p c21zIHRoYXQgYXJlIGNvbnNpZGVyZWQgc2FmZSBmb3IgdGhlIGdsb2JhbCBJbnRlcm5ldC4NCg0K KiBTZWN0aW9uIDIgICBTY29wZSAgICANCiAgICANClttc10gV2hpbGUgc29tZWhvdyBpbXBsaWNp dGx5IGNsZWFyIGZyb20gdGhlIGVhcmxpZXIgdXNlIG9mIHRoZSB3b3JkaW5nICJnbG9iYWwgSW50 ZXJuZXQiLCBJIGJlbGlldmUgdGhhdCBzaG91bGQgYmUgbWFkZSBtb3JlIGV4cGxpY2l0IGluIFNl Y3Rpb24gMi4gTm90ZSB0aGF0IElFVEYgcHJvdG9jb2xzIGFyZSB1c2VkIG5vdCBvbmx5IGluIHRo ZSBnbG9iYWwgSW50ZXJuZXQuIFRoaXMgY2FuIGJlIChTLjApIG9yIChTLjcpLg0KDQogICAgKFMu NykgVGhlIHJlcXVpcmVtZW50cyBmb2N1cyBvbiBjb21tdW5pY2F0aW9uIG92ZXIgdGhlIGdsb2Jh bCBJbnRlcm5ldC4NCiAgICAgICAgICBSZXRyYW5zbWlzc2lvbiB0aW1lb3V0IG1lY2hhbmlzbXMg aW4gY29udHJvbGxlZCBlbnZpcm9ubWVudHMgc2VwYXJhdGVkDQoJICAgIGZyb20gdGhlIGdsb2Jh bCBJbnRlcm5ldCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAg ICAgICAgIEUuZy4sIHRoaXMgZG9jdW1lbnQgZG9lcyBhZGRyZXNzIHJldHJhbnNtaXNzaW9uIHRp bWVycyB1c2VkIGluIGNvbnRyb2xsZWQNCiAgICAgICAgICBlbnZpcm9ubWVudHMgc3VjaCBhcyBu dWNsZWFyIHBvd2VyIHBsYW50cywgYWlycGxhbmVzLCBmYWJyaWMgYXV0b21hdGlvbiwNCiAgICAg ICAgICBldGMuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgYWRkcmVzcyByZXRyYW5zbWlzc2lvbiB0 aW1lcnMgaW4gcmVhbC10aW1lDQogICAgICAgICAgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMgZm9y IHN1Y2ggZW52aXJvbm1lbnRzLg0KDQpbbXNdIE9MRA0KDQogICAgQWRkaXRpb25hbGx5LCB0aGUg Zm9sbG93aW5nIHN0YXRlbWVudHMgZGV0YWlsIHRoZSByZWxhdGlvbnNoaXAgb2YNCiAgICB0aGUg cmVxdWlyZW1lbnRzIGluIHRoaXMgZG9jdW1lbnQgdG8gb3RoZXIgc3BlY2lmaWNhdGlvbnMgYW5k DQogICAgaW1wbGVtZW50YXRpb25zOg0KDQogICAgKFIuMSkgUlRPIG1lY2hhbmlzbXMgdGhhdCBh cmUgY3VycmVudGx5IHN0YW5kYXJkaXplZCBhcmUgbm90IHVwZGF0ZWQgDQogICAgICAgICAgb3Ig b2Jzb2xldGVkIGJ5IHRoaXMgZG9jdW1lbnQuICBJbXBsZW1lbnRhdGlvbnMgYXJlIGZyZWUgdG8N CiAgICAgICAgICB1c2UgdGhlc2UgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgYXMgdGhleSBkbyBu b3cuDQoNCiAgICAgICAgICBUaGlzIGhvbGRzIGV2ZW4gaW4gY2FzZXMgd2hlcmUgdGhlIGV4aXN0 aW5nIHNwZWNpZmljYXRpb24NCiAgICAgICAgICBkaWZmZXJzIGZyb20gdGhlIHJlcXVpcmVtZW50 cyBpbiB0aGlzIGRvY3VtZW50IChlLmcuLA0KICAgICAgICAgIFtSRkMzMjYxXSB1c2VzIGEgc21h bGxlciBpbml0aWFsIHRpbWVvdXQgdGhhbiB0aGlzIGRvY3VtZW50DQogICAgICAgICAgc3BlY2lm aWVzKS4gIEV4aXN0aW5nIHN0YW5kYXJkIHNwZWNpZmljYXRpb25zIGVuam95IHRoZWlyIG93bg0K ICAgICAgICAgIGNvbnNlbnN1cyB3aGljaCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGNoYW5nZS4N CiAgICANCiAgICAoUi4yKSBGdXR1cmUgc3RhbmRhcmRpemF0aW9uIGVmZm9ydHMgdGhhdCBzcGVj aWZ5IFJUTyBtZWNoYW5pc21zIA0KICAgICAgICAgIFNIT1VMRCBmb2xsb3cgdGhlIHJlcXVpcmVt ZW50cyBpbiB0aGlzIGRvY3VtZW50Lg0KICAgICAgICAgIFRoZXJlIG1heSBiZSByZWFzb25zIGZv ciBmdXR1cmUgUlRPIG1lY2hhbmlzbXMgdG8gZGV2aWF0ZSBmcm9tDQogICAgICAgICAgdGhlIHJl cXVpcmVtZW50cyBpbiBTZWN0aW9uIDMuICBJbiB0aGVzZSBjYXNlcywgd2UgZXhwZWN0IG9ubHkN CiAgICAgICAgICB0aGF0IHRoZSBzdGFuZGFyZHMgcHJvY2VzcyBkb2VzIHNvIGFmdGVyIHJlYXNv bmFibGUNCiAgICAgICAgICBkZWxpYmVyYXRpb24gYW5kIHdpdGggZ29vZCByZWFzb24uDQoNCiAg ICAoUi4zKSBBbHRlcm5hdGl2ZWx5LCBmdXR1cmUgUlRPIG1lY2hhbmlzbSBpbXBsZW1lbnRhdGlv bnMgbWF5IGJlDQogICAgICAgICAgbWFkZSBkaXJlY3RseSBhZ2FpbnN0IHRoZSByZXF1aXJlbWVu dHMgaW4gU2VjdGlvbiAzIHdpdGhvdXQNCiAgICAgICAgICBhbm90aGVyIHByb3RvY29sLXNwZWNp ZmljIHNwZWNpZmljYXRpb24uIA0KDQogICAgKFIuNCkgVGhlcmUgd2lsbCBubyBkb3VidCBiZSBj YXNlcyB3aGVyZSBhcHBseWluZyB0aGUgcmVxdWlyZW1lbnRzDQogICAgICAgICAgaW4gdGhpcyBk b2N1bWVudCBkaXJlY3RseSBpcyBub3QgcG9zc2libGUgZHVlIHRvIHRoZSBzdHJ1Y3R1cmUNCiAg ICAgICAgICBvciBvcGVyYXRpb24gb2YgYSBwcm90b2NvbC4gIEZvciBpbnN0YW5jZSwgYSBjYXNl IHdoZXJlIGENCiAgICAgICAgICB0aW1lb3V0IGlzIHVzZWQgdG8gZGV0ZWN0IGxvc3MsIGJ1dCB0 aGUgbG9zcyBpcyBub3QgcmVwYWlyZWQNCiAgICAgICAgICB3aXRoIGEgZGlyZWN0IHJldHJhbnNt aXNzaW9uIG9mIHRoZSBvcmlnaW5hbCBkYXRhLiAgSW4gdGhlc2UNCiAgICAgICAgICBzaXR1YXRp b25zLCBhbiBhbHRlcm5hdGUgc3BlY2lmaWNhdGlvbiBpcyByZXF1aXJlZC4gIFdlDQogICAgICAg ICAgZW5jb3VyYWdlIHN1Y2ggZnV0dXJlIGVmZm9ydHMgdG8gbGV2ZXJhZ2UgdGhlIHNwaXJpdCBv ZiB0aGUgDQogICAgICAgICAgcmVxdWlyZW1lbnRzIGluIHRoaXMgZG9jdW1lbnQgdG8gaW5mb3Jt IGFsdGVybmF0ZQ0KICAgICAgICAgIHNwZWNpZmljYXRpb25zLiANCg0KW21zXSBORVcNCg0KICAg IEFkZGl0aW9uYWxseSwgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIGRldGFpbCB0aGUgcmVsYXRp b25zaGlwIG9mDQogICAgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50IHRvIG90aGVy IHNwZWNpZmljYXRpb25zOg0KDQogICAgKFIuMSkgUlRPIG1lY2hhbmlzbXMgdGhhdCBhcmUgY3Vy cmVudGx5IHN0YW5kYXJkaXplZCBhcmUgbm90IHVwZGF0ZWQgDQogICAgICAgICAgb3Igb2Jzb2xl dGVkIGJ5IHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgICBUaGlzIGhvbGRzIGV2ZW4gaW4gY2Fz ZXMgd2hlcmUgdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb24NCiAgICAgICAgICBkaWZmZXJzIGZy b20gdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50IChlLmcuLA0KICAgICAgICAgIFtS RkMzMjYxXSB1c2VzIGEgc21hbGxlciBpbml0aWFsIHRpbWVvdXQgdGhhbiB0aGlzIGRvY3VtZW50 DQogICAgICAgICAgc3BlY2lmaWVzKS4gIEV4aXN0aW5nIHN0YW5kYXJkIHNwZWNpZmljYXRpb25z IGVuam95IHRoZWlyIG93bg0KICAgICAgICAgIGNvbnNlbnN1cyB3aGljaCB0aGlzIGRvY3VtZW50 IGRvZXMgbm90IGNoYW5nZS4NCiAgICANCiAgICAoUi4yKSBGdXR1cmUgc3RhbmRhcmRpemF0aW9u IGVmZm9ydHMgdGhhdCBzcGVjaWZ5IFJUTyBtZWNoYW5pc21zIA0KICAgICAgICAgIFNIT1VMRCBm b2xsb3cgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50Lg0KICAgICAgICAgIFRoZXJl IG1heSBiZSByZWFzb25zIGZvciBmdXR1cmUgUlRPIG1lY2hhbmlzbXMgdG8gZGV2aWF0ZSBmcm9t DQogICAgICAgICAgdGhlIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDMuICBJbiB0aGVzZSBjYXNl cywgd2UgZXhwZWN0IG9ubHkNCiAgICAgICAgICB0aGF0IHRoZSBzdGFuZGFyZHMgcHJvY2VzcyBk b2VzIHNvIGFmdGVyIHJlYXNvbmFibGUNCiAgICAgICAgICBkZWxpYmVyYXRpb24gYW5kIHdpdGgg Z29vZCByZWFzb24uDQoNCiAgICAoUi4zKSBUaGVyZSB3aWxsIG5vIGRvdWJ0IGJlIGNhc2VzIHdo ZXJlIGFwcGx5aW5nIHRoZSByZXF1aXJlbWVudHMNCiAgICAgICAgICBpbiB0aGlzIGRvY3VtZW50 IGRpcmVjdGx5IGlzIG5vdCBwb3NzaWJsZSBkdWUgdG8gdGhlIHN0cnVjdHVyZQ0KICAgICAgICAg IG9yIG9wZXJhdGlvbiBvZiBhIHByb3RvY29sLiAgRm9yIGluc3RhbmNlLCBhIGNhc2Ugd2hlcmUg YQ0KICAgICAgICAgIHRpbWVvdXQgaXMgdXNlZCB0byBkZXRlY3QgbG9zcywgYnV0IHRoZSBsb3Nz IGlzIG5vdCByZXBhaXJlZA0KICAgICAgICAgIHdpdGggYSBkaXJlY3QgcmV0cmFuc21pc3Npb24g b2YgdGhlIG9yaWdpbmFsIGRhdGEuICBJbiB0aGVzZQ0KICAgICAgICAgIHNpdHVhdGlvbnMsIGFu IGFsdGVybmF0ZSBzcGVjaWZpY2F0aW9uIGlzIHJlcXVpcmVkLiAgV2UNCiAgICAgICAgICBlbmNv dXJhZ2Ugc3VjaCBmdXR1cmUgZWZmb3J0cyB0byBsZXZlcmFnZSB0aGUgc3Bpcml0IG9mIHRoZSAN CiAgICAgICAgICByZXF1aXJlbWVudHMgaW4gdGhpcyBkb2N1bWVudCB0byBpbmZvcm0gYWx0ZXJu YXRlDQogICAgICAgICAgc3BlY2lmaWNhdGlvbnMuDQoNClttc10gLi4uIGFsYmVpdCBJIHRoaW5r IGV2ZW4gbW9yZSBvZiB0aGlzIGNvdWxkIGJlIHJlbW92ZWQNCg0KKiBTZWN0aW9uIDQgICBEaXNj dXNzaW9uDQoNClttc10gT0xEDQoNCiAgICBGaW5hbGx5LCB3ZSBub3RlIHRoYXQgd2hpbGUgYWxs b3dpbmcgaW1wbGVtZW50YXRpb25zIHRvIGJlIG1vcmUNCiAgICBhZ2dyZXNzaXZlIG1heSBpbiBm YWN0IGluY3JlYXNlIHRoZSBudW1iZXIgb2YgbmVlZGxlc3MNCiAgICByZXRyYW5zbWlzc2lvbnMg dGhlIGFib3ZlIHJlcXVpcmVtZW50cyBmYWlsIHNhZmUgaW4gdGhhdCB0aGV5IGluc2lzdA0KICAg IG9uIGV4cG9uZW50aWFsIGJhY2tvZmYgb2YgdGhlIFJUTyBhbmQgYSB0cmFuc21pc3Npb24gcmF0 ZSByZWR1Y3Rpb24uDQogICAgVGhlcmVmb3JlLCBwcm92aWRpbmcgaW1wbGVtZW50ZXJzIG1vcmUg bGF0aXR1ZGUgdGhhbiB0aGV5IGhhdmUNCiAgICB0cmFkaXRpb25hbGx5IGJlZW4gZ2l2ZW4gaW4g SUVURiBzcGVjaWZpY2F0aW9ucyBvZiBSVE8gbWVjaGFuaXNtcw0KICAgIGRvZXMgbm90IHNvbWVo b3cgb3BlbiB0aGUgZmxvb2QgZ2F0ZXMgdG8gYWdncmVzc2l2ZSBiZWhhdmlvci4gIFNpbmNlDQog ICAgdGhlcmUgaXMgYSBkb3duc2lkZSB0byBiZWluZyBhZ2dyZXNzaXZlIHRoZSBpbmNlbnRpdmVz IGZvciBwcm9wZXINCiAgICBiZWhhdmlvciBhcmUgcmV0YWluZWQgaW4gdGhlIG1lY2hhbmlzbS4N Cg0KW21zXSBORVcgDQoNCiAgICBUaGUgYWJvdmUgcmVxdWlyZW1lbnRzIGFyZSBzYWZlIGZyb20g YSBuZXR3b3JrIHBlcnNwZWN0aXZlIGluIHRoYXQgdGhleSBpbnNpc3QNCiAgICBvbiBleHBvbmVu dGlhbCBiYWNrb2ZmIG9mIHRoZSBSVE8gYW5kIGEgdHJhbnNtaXNzaW9uIHJhdGUgcmVkdWN0aW9u Lg0KDQoqIFNlY3Rpb24gNSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpbbXNdIFRoaXMgc2Vj dGlvbiBpcyBJTUhPIHRvbyBzaG9ydCBhbmQgYSByZWZlcmVuY2UganVzdCB0byBUQ1AgaXMgbm90 IHN1ZmZpY2llbnQgZm9yIGEgcHJvdG9jb2wgdGhhdCBzaGFsbCBiZSBwcm90b2NvbC1hZ25vc3Rp Yy4gSSBjYW5ub3QgcHJvdmlkZSBiZXR0ZXIgd29yZGluZyBvdXQtb2YtbXktaGVhZCBidXQgaGVy ZSBhcmUgYSBjb3VwbGUgb2YgdG9waWNzIHRoYXQgaGF2ZSB0byBiZSBjb3ZlcmVkIGluIHRoaXMg c2VjdGlvbjoNCg0KKDEpIEEgZGlzY3Vzc2lvbiBvZiB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25z IGlmIHJldHJhbnNtaXNzaW9uIHRpbWVvdXQgbWVjaGFuaXNtcyBkZXZpYXRlIGZyb20gc3RhbmRh cmRpemVkIHJldHJhbnNtaXNzaW9uIG1lY2hhbmlzbXMuIEZvciBpbnN0YW5jZSwgbm90IGNvbXBs eWluZyB0byBwcm90b2NvbCBzdGFuZGFyZHMgY291bGQgdHJpZ2dlciBhbm9tYWx5IGRldGVjdGlv biBzeXN0ZW1zIG9yIHRoaXMgY291bGQgYmUgY2xhc3NpZmllZCBhcyBhbiBhdHRhY2suDQoNCigy KSBBIGRpc2N1c3Npb24gdGhhdCBvcGVyYXRpb25hbCAic2FmZXR5IiBpbiBjb250cm9sbGVkIGVu dmlyb25tZW50cyBzZXBhcmF0ZWQgZnJvbSB0aGUgZ2xvYmFsIEludGVybmV0LCBzdWNoIGFzIG51 Y2xlYXIgcG93ZXIgcGxhbnRzLCBhaXJwbGFuZXMsIGZhYnJpYyBhdXRvbWF0aW9uLCBpcyBub3Qg YWRkcmVzc2VkIGJ5IHRoaXMgZG9jdW1lbnQuDQoNCigzKSBBIGRpc2N1c3Npb24gd2hldGhlciBy ZXRyYW5zbWlzc2lvbiB0aW1lb3V0IG1lY2hhbmlzbXMsIG9yIGRldmlhdGlvbnMgb2YgdGhlbSwg Y2FuIGJlIHVzZWQgZm9yIGZpbmdlci1wcmludGluZy4gKFRoaXMgbWF5IGJlIHZlcnkgZXhvdGlj IGJ1dCBpZiBhbiBpbXBsZW1lbnRhdGlvbiB1c2VzIGEgdmVyeSB1bmlxdWUgaW5pdGlhbCBSVE8g dGhhdCBjb3VsZCBoYXZlIHByaWNhY3kgaW1wbGljYXRpb25zLikNCg0KKDQpIC4uLiBwb3NzaWJs eSBtb3JlLCB3ZSBtYXkgbmVlZCBpbnB1dCBmcm9tIHNlY3VyaXR5IGV4cGVydHMNCg0KKioqKiog cmV2aWV3IG9mIC0wNCAqKioqKg0KDQo= From nobody Fri Jun 17 11:59:15 2016 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 BD59B12D9D8; Fri, 17 Jun 2016 11:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 vRZxQZgdzqy7; Fri, 17 Jun 2016 11:59:13 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CF212D9C1; Fri, 17 Jun 2016 11:59:13 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HIxCVN021911; Fri, 17 Jun 2016 11:59:12 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D73644D156FE; Fri, 17 Jun 2016 14:59:59 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB3B5@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document58786.jpg X-URL-1: http://www.icir.org/mallman-files/Document2527.html X-URL-2: http://www.icir.org/mallman-files/Document141.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 14:59:59 -0400 Message-ID: <67283.1466189999@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:59:15 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just one quick one that is easy to answer ... > For TCP, I am confused by how this wording relates to RFC > 6298. This document does nothing to RFC6298. I.e., (R.1) RTO mechanisms that are currently standardized are not updated=20 or obsoleted by this document. Implementations are free to use these existing specifications as they do now. That is, RFC6298 remains as it is now. Implementers are free to use the algorithm as it sits in RFC6298. > For TCP, I fully agree that allowing more flexibility compared to > RFC 6298 would be useful, and a new RFC 6298bis could reference a > BCP draft-ietf-tcpm-rto-consider. However, I believe that guidance > for TCP implementers belongs into a standards track document RFC > 6298bis. The document draft-ietf-tcpm-rto-consider should focus on > a set of requirements only. I am not sure what you mean here. So, we'd use rto-consider as a set of requirements. And, then we'd generate a 6298bis that is less specific than 6298. So, e.g., instead of providing equations like this: RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| SRTT <- (1 - alpha) * SRTT + alpha * R' RTO <- SRTT + max (G, K*RTTVAR) and their corresponding parameter values, we'd just fall back to some generic language like "use RTT samples and the variance of RTT samples per [rto-consider] to compute an RTO"? So, the document is then a fuzzy re-statement of the [rto-consider] requirements instead of a specific algorithm. Something like that? Or, do you just want a 6298bis that includes a statement at the top that says "this algorithm follows the requirements in [rto-consider]"? Or, something else? I can't envision how you view this as working.=20 allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkSK8ACgkQWyrrWs4yIs7fBQCeJLdFCcTMxuvOdzlMpLF8HfG6 pHIAnRTo9K18UfEOLNhkX72rsvvcjDWl =9CmG -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 12:12:50 2016 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 88D3712D9D8; Fri, 17 Jun 2016 12:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 DhQhRPhW422T; Fri, 17 Jun 2016 12:12:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7FD12D82D; Fri, 17 Jun 2016 12:12:44 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 59D6982C523B9; Fri, 17 Jun 2016 19:12:39 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HJCg53019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 19:12:43 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HJCc4e032572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 21:12:40 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 21:11:57 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyMpxoDoEKDWkakuYZCmVs3o6/5/uBIuw Date: Fri, 17 Jun 2016 19:11:56 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB571@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488DB3B5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <67283.1466189999@lawyers.icir.org> In-Reply-To: <67283.1466189999@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:12:48 -0000 > > For TCP, I fully agree that allowing more flexibility compared to RFC=20 > > 6298 would be useful, and a new RFC 6298bis could reference a BCP=20 > > draft-ietf-tcpm-rto-consider. However, I believe that guidance for TCP= =20 > > implementers belongs into a standards track document RFC 6298bis. The=20 > > document draft-ietf-tcpm-rto-consider should focus on a set of=20 > > requirements only. > I am not sure what you mean here. 6298bis would have a new (first) section with a MUST that applies the guide= lines in [rto-consider] specifically to the TCP protocol, mandating that al= l TCP implementations MUST use retransmission timeout mechanisms matching t= his minimum set of requirements. This is relatively straightforward given t= hat [rto-consider] is rather TCP-ish already. But for a number of requireme= nts the actual TCP terminology and technology could be used. And then the document would recommend with a MAY (or SHOULD) the algorithm = in 6298 as default. And I believe that such a proposed standard for TCP would be closer to what= implementations actually do.=20 (And I believe for SCTP it would also be a no-brainer to come up with somet= hing in TSVWG, but the SCTP experts would have comment on that.) Michael From nobody Fri Jun 17 12:41:07 2016 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 EAAC012DA39; Fri, 17 Jun 2016 12:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Z5oJbsOiVpaE; Fri, 17 Jun 2016 12:41:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB7512DA32; Fri, 17 Jun 2016 12:41:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 571E3D930B; Fri, 17 Jun 2016 21:41:02 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id byeYKCTqtDZ7; Fri, 17 Jun 2016 21:41:02 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 089C7D9304; Fri, 17 Jun 2016 21:41:02 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <30640.1466183344@lawyers.icir.org> Date: Fri, 17 Jun 2016 21:41:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <409BB227-4760-49A9-A223-D1B30BDE08C3@tik.ee.ethz.ch> References: <30640.1466183344@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:41:06 -0000 Hi Mark, > Am 17.06.2016 um 19:09 schrieb Mark Allman : >=20 > You are starting from the fact that implementers are not beholden to > the RFCs in any tangible way. And, also the fact that we don't have > any real recourse when the standards are not followed. So, since > they don't feel constrained by the RFCs, we should approach RFCs in > the same way and not worry about constraints as much as giving our > best recommendations. We hope our strong recommendations are > listened to and used. But, if they are not, they are not and there > isn't anything we can do about them regardless of what we say people > "MUST" do. I.e., the standards process should meet the implementers > where they are. >=20 > Is that roughly correct? Roughly yes. I wouldn=E2=80=99t use the wording "implementers are not = beholden to the RFCs in any tangible way=E2=80=9C but anyway... Even though your statement was scoped to single-host algos, I don=E2=80=99= t want to let this stand in the room like this. Let me add a few things = (that are more general and probably not important for the discussion on = rto though).=20 First, this is slightly different if interoperability is required. But = even in this case, we can=E2=80=99t control what implementors are doing. = However, I would say there is a natural incentive in this case to follow = the spec because other it just won=E2=80=99t work.=20 Then I would also like to say that the consequence of this thinking is = not that RFCs are useless as anyway nobody will follow anyway. I know = that is not was you were saying or thinking I assume. I just want to = clearly state that there is an important role for RFCs to make = recommendation; as I said implementors read RFC (even if they don=E2=80=99= t follow). And finally, the other important aspect is that this liberal approach in = the Internet, where we of course depend to a certain extend on other = people doing things right/not too wrong, is that enables innovation in = the Internet and make the Internet to this great thing we have today. = E.g if someone invents a complete new service that uses the Internet = that might not fit our current recommendation. So this freedom is needed = and deliberate. With this more philosophical statement, I guess the only this that is = left to say is: Have a good weekend! Mirja From nobody Fri Jun 17 12:49:34 2016 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 6625912D0AE; Fri, 17 Jun 2016 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ElhpoBKp0xJ1; Fri, 17 Jun 2016 12:49:32 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B8512DA37; Fri, 17 Jun 2016 12:49:32 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HJnV9Z028713; Fri, 17 Jun 2016 12:49:31 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 951844D161D6; Fri, 17 Jun 2016 15:50:18 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB571@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document27509.jpg X-URL-1: http://www.icir.org/mallman-files/Document14512.html X-URL-2: http://www.icir.org/mallman-files/Document32703.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 15:50:18 -0400 Message-ID: <75094.1466193018@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:49:33 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > 6298bis would have a new (first) section with a MUST that applies > the guidelines in [rto-consider] specifically to the TCP protocol, > mandating that all TCP implementations MUST use retransmission > timeout mechanisms matching this minimum set of requirements. This > is relatively straightforward given that [rto-consider] is rather > TCP-ish already. But for a number of requirements the actual TCP > terminology and technology could be used.=20 >=20 > And then the document would recommend with a MAY (or SHOULD) the > algorithm in 6298 as default.=20 >=20 > And I believe that such a proposed standard for TCP would be > closer to what implementations actually do.=20=20 We have been around this before, but for the public record ... To me this is a bunch of work for, perhaps, epsilon gain. We state some high level requirements. But, then we have to re-state the high-level requirements after prepending a protocol name and only then can an implementation can actually leverage the requirements. Perhaps that forms a nice clean document progression. But, man, what a bunch of busy work that has no value add... Rather, I think this document can be directly applied to both future specifications and future implementations. I don't yet have a well-formed hit on whether we should directly state that in some fashion (as the doc---perhaps clumsily---tries to do now) or leave the requirements as our best thinking to be implicitly applied however folks see fit (my understanding of Mirja's hit). allman =2D- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkVHcACgkQWyrrWs4yIs56BgCfZgbbSPMDlepII8/Y6U8ZMfcG pjkAn3bl03uoCFxE1EfPewcIaFq5wukv =U/wk -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 13:00:40 2016 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 D9EEC12D8A3; Fri, 17 Jun 2016 13:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 z7GoZNznodCE; Fri, 17 Jun 2016 13:00:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7743012D8B1; Fri, 17 Jun 2016 13:00:33 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 73147F5AF9995; Fri, 17 Jun 2016 20:00:27 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HK0VUt014552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 20:00:31 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HK0Um5001559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 22:00:30 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 22:00:30 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyJs+daDP2nXoIEy1xGblSmRRlJ/uEZAQ Date: Fri, 17 Jun 2016 20:00:29 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB6E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <98229.1466169727@lawyers.icir.org> In-Reply-To: <98229.1466169727@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:00:35 -0000 PiBIb3dldmVyLCBsZXQgbWUgc2tldGNoIHRoZSBsYXkgb2YgdGhlIGxhbmQgYXMgSSBzZWUgaXQg Li4uLiAgIEl0DQo+IHNlZW1zIHRoZSBtZWF0IGluIHRoaXMgZG9jdW1lbnQgY2FuIGJlIHVzZWQg Zm9yIGRpZmZlcmVudCBwdXJwb3Nlcy4NCj4gQW5kLCB3ZSBoYXZlIHNlZW4gb3BpbmlvbnMgb24g ZWFjaCBvZiB0aGVzZSBJIHRoaW5rLiAgVGhlIGRvY3VtZW50IGNvdWxkIGJlIHVzZWQ6DQo+DQo+ ICAoYSkgYXMgaW5wdXQgdG8gZnV0dXJlIFJUTyBzcGVjaWZpY2F0aW9ucywNCj4NCj4gIChiKSBh cyBpbnB1dCB0byBmdXR1cmUgUlRPIGltcGxlbWVudGF0aW9ucywgb3INCj4NCj4gIChjKSBhcyBi b3RoIChhKSBhbmQgKGIpDQoNCkluIGNhc2UgdGhlcmUgd2FzIGFueSBhbWJpZ3VpdHk6IA0KDQpJ IGRvIE5PVCBzdXBwb3J0IChiKSBvciAoYykuDQoNClNwZWNpZmljYWxseSwgSSBkbyBub3QgdW5k ZXJzdGFuZCBob3cgW3J0by1jb25zaWRlcl0gY2FuIGZvcmVzZWUgdGhlIHJlcXVpcmVtZW50cyBv ZiBmdXR1cmUgcHJvdG9jb2xzIG5vdCBzdGFuZGFyZGl6ZWQgYnkgdGhlIElFVEYgcmlnaHQgbm93 LiBUaGUgSW50ZXJuZXQgaXMgc3ViamVjdCB0byBwZXJtYW5lbnQgY2hhbmdlLiBJIGNvbmNsdWRl IHRoYXQgdGhlIHJlcXVpcmVtZW50cyBvdXRsaW5lZCBpbiB0aGlzIGRvY3VtZW50IGNhbm5vdCBi ZSBjb25zaWRlcmVkICJzYWZlIiBmb3IgaW1wbGVtZW50YXRpb25zIG9mIHByb3RvY29scyBpbiBm dXR1cmUsIHVua25vd24gZW52aXJvbm1lbnRzLg0KDQpUaGUgYW5hbHlzaXMgd2hhdCBpcyAic2Fm ZSIgaGFzIHRvIGJlIGRvbmUgb24gYSBwZXIgcHJvdG9jb2wgYmFzaXMsIHdpdGhpbiB0aGUgc3Rh bmRhcmRpemF0aW9uIHByb2Nlc3Mgb2YgdGhhdCBwcm90b2NvbCwgdGFraW5nIFtydG8tY29uc2lk ZXJdIGFzIG9uZSBpbnB1dCByZWdhcmRpbmcgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGUgZ2xvYmFs IEludGVybmV0IGF0IHRoZSB0aW1lIHdoZW4gdGhlIGRvY3VtZW50IHdhcyBwdWJsaXNoZWQuDQoN Ck1pY2hhZWwgKHdpdGggY2hhaXIgaGF0IG9mZikNCg0K From nobody Fri Jun 17 13:15:26 2016 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 AF38912DAB1; Fri, 17 Jun 2016 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mQRz8kAuM6uS; Fri, 17 Jun 2016 13:15:20 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D46812DA61; Fri, 17 Jun 2016 13:15:20 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HKFJsS002100; Fri, 17 Jun 2016 13:15:19 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B5E734D16961; Fri, 17 Jun 2016 16:16:06 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <409BB227-4760-49A9-A223-D1B30BDE08C3@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 16:16:06 -0400 Message-ID: <78939.1466194566@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:15:22 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > > You are starting from the fact that implementers are not beholden to > > the RFCs in any tangible way. And, also the fact that we don't have > > any real recourse when the standards are not followed. So, since > > they don't feel constrained by the RFCs, we should approach RFCs in > > the same way and not worry about constraints as much as giving our > > best recommendations. We hope our strong recommendations are > > listened to and used. But, if they are not, they are not and there > > isn't anything we can do about them regardless of what we say people > > "MUST" do. I.e., the standards process should meet the implementers > > where they are. > >=20 > > Is that roughly correct? >=20 > Roughly yes. OK. Then, I am going to mull this approach. I view three things on the table: - Mirja's approach: State the recommendations, but not explicitly what they apply to and as SHOULDs rather than MUSTs and then let people use them as they find useful. - Michael's approach: The requirements exist only to guide future specs. And, implementations are explicitly not to leverage these directly. - Mark's approach: Somewhere in the middle, I guess. State the recommendations, but also explicitly that they are for both future specs and future implementations. (Clearly closer to Mirja and Michael.) I am still thinking. Others can chime in. But, only if your name starts with "M"... because naming conventions are important. > First, this is slightly different if interoperability is > required. But even in this case, we can=E2=80=99t control what > implementors are doing. However, I would say there is a natural > incentive in this case to follow the spec because other it just > won=E2=80=99t work.=20=20 (Yep. This is why I scoped!) > Then I would also like to say that the consequence of this > thinking is not that RFCs are useless as anyway nobody will follow > anyway. I know that is not was you were saying or thinking I > assume. I just want to clearly state that there is an important > role for RFCs to make recommendation; as I said implementors read > RFC (even if they don=E2=80=99t follow). Well, OK. I understand what you're saying. But, what I am struggling with here is that if we make some MUSTs then we get a little something in return. That sets an expectation. And, if the FooBar implementation doesn't follow that expectation and it causes problems then there is a lever to say "well, gee, we said you needed to do something and you didn't". FooBar does not have to listen. We cannot make them do something different. But, we get a little lever. So, the question in my mind is whether we get the same sort of leverage with your looser notion of "just state the requirements" and "use SHOULDs". And, I am thinking not. I.e., we didn't say "do this" we said "do this unless you have a good reason" and FooBar might think they have a good reason (e.g., "helps my customers, so sorry about your's!"). We can still try to say "well, we strongly recommended ...", but we're in a bit lesser position. The thing I am trying to form an opinion on is "how much lesser". I.e., I have sort of convinced myself stronger statements are better. But, it might be that they are only epsilon better and so ultimately it doesn't much matter. Thanks, allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkWoYACgkQWyrrWs4yIs69swCbB3X7C+P9WeSeoeWEjBbN3ira yWYAnjvcGsRJnzao8clsiLRKl6lBF0rm =pIyO -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 13:17:41 2016 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 5459512DAB1; Fri, 17 Jun 2016 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HfXBND5TMO7P; Fri, 17 Jun 2016 13:17:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E6512DAAE; Fri, 17 Jun 2016 13:17:35 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HKHYbQ002410; Fri, 17 Jun 2016 13:17:34 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1A6764D169C8; Fri, 17 Jun 2016 16:18:22 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB6E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document42183.doc X-URL-1: http://www.icir.org/mallman-files/Document76662.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 16:18:22 -0400 Message-ID: <79277.1466194702@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:17:36 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Applying "the future will be different" stops all work. Period. allman > > However, let me sketch the lay of the land as I see it .... It > > seems the meat in this document can be used for different purposes. > > And, we have seen opinions on each of these I think. The document coul= d be used: > > > > (a) as input to future RTO specifications, > > > > (b) as input to future RTO implementations, or > > > > (c) as both (a) and (b) >=20 > In case there was any ambiguity:=20 >=20 > I do NOT support (b) or (c). >=20 > Specifically, I do not understand how [rto-consider] can foresee > the requirements of future protocols not standardized by the IETF > right now. The Internet is subject to permanent change. I conclude > that the requirements outlined in this document cannot be > considered "safe" for implementations of protocols in future, > unknown environments.=20 >=20 > The analysis what is "safe" has to be done on a per protocol > basis, within the standardization process of that protocol, taking > [rto-consider] as one input regarding the requirements in the > global Internet at the time when the document was published.=20 >=20 > Michael (with chair hat off) --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkWw0ACgkQWyrrWs4yIs4p8gCfeUd0nOlz63OPHJXz8vWfbZod MHwAoJ9c0FdiFNieoFK8NtE1PUFViTnM =xzXq -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 16:08:39 2016 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 6706512DC44; Fri, 17 Jun 2016 16:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 j6_kYc4bgCWH; Fri, 17 Jun 2016 16:08:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A8B12DBE2; Fri, 17 Jun 2016 16:08:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id AF45A114C51F6; Fri, 17 Jun 2016 23:08:30 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HN8Y3h001195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 23:08:35 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HN7PUT013210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Jun 2016 01:08:31 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sat, 18 Jun 2016 01:07:56 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyNF5oDoEKDWkakuYZCmVs3o6/5/uODGg Date: Fri, 17 Jun 2016 23:07:56 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488DB571@FR712WXCHMBA15.zeu.alcatel-lucent.com> <75094.1466193018@lawyers.icir.org> In-Reply-To: <75094.1466193018@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 23:08:39 -0000 > > 6298bis would have a new (first) section with a MUST that applies > > the guidelines in [rto-consider] specifically to the TCP protocol, > > mandating that all TCP implementations MUST use retransmission > > timeout mechanisms matching this minimum set of requirements. This > > is relatively straightforward given that [rto-consider] is rather > > TCP-ish already. But for a number of requirements the actual TCP > > terminology and technology could be used. > > > > And then the document would recommend with a MAY (or SHOULD) the > > algorithm in 6298 as default. > > > > And I believe that such a proposed standard for TCP would be > > closer to what implementations actually do. >=20 > We have been around this before, but for the public record ... >=20 > To me this is a bunch of work for, perhaps, epsilon gain. We state > some high level requirements. But, then we have to re-state the > high-level requirements after prepending a protocol name and only > then can an implementation can actually leverage the requirements. Implementers can read the requirements in rto-consider right now. What implementers cannot leverage right now is a statement about IETF conse= nsus that for any protocol standardized in the IETF, any RTO algorithm, in = all circumstances is always "safe" when it meets the requirements under the= constraints stated in the document. And specifically implementers of proto= cols other than TCP cannot rely on that because a document first has to pas= s IETF last call and IESG approval before the IETF can state that the guida= nce it is indeed "best current practice". > Perhaps that forms a nice clean document progression. But, man, > what a bunch of busy work that has no value add... If [rto-consider] is IETF consensus, IMHO a 6298bis document would be a no-= brainer in TCPM. Maybe I miss something, but that would be a candidate for = a WGLC directly on the -00 version, given that we already review [rto-consi= der]. One added value of 6298bis is that it applies the generic wording in = [rto-consider] specifically to the TCP. I believe that this is simpler to r= ead for a TCP implementer than to reverse-engineer protocol-agnostic wordin= g in a draft that gets longer and longer to be protocol-agnostic (and likel= y will have to be further extended when it hits IETF last call)? And, as a = side note, my formal concerns would be addressed, since TCPM would have a d= ocument we can e.g. proceed on standards track. So is your concern that nobody would invest cycles to author a 6298bis in T= CPM? Or something equivalent e.g. for SCTP? In summary, can we agree that if somebody volunteers to submit 6298bis, whi= ch references [rto-consider], my proposed wording for [rto-consider] actual= ly has some gain ("epsilon" or more). Thus, in summary my proposal just sor= ts out everything in TCPM? Or what is then missing in TCPM? Michael From nobody Fri Jun 17 16:25:54 2016 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 451AC12DC4C; Fri, 17 Jun 2016 16:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 A6IraUF4jmRD; Fri, 17 Jun 2016 16:25:47 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9791F12D63C; Fri, 17 Jun 2016 16:25:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E5777D9305; Sat, 18 Jun 2016 01:25:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iOQFaYhAMZhr; Sat, 18 Jun 2016 01:25:42 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9DAA9D9304; Sat, 18 Jun 2016 01:25:42 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <78939.1466194566@lawyers.icir.org> Date: Sat, 18 Jun 2016 01:25:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78939.1466194566@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 23:25:49 -0000 Hi Mark, just on this one point and then I go to sleep=E2=80=A6 > Am 17.06.2016 um 22:16 schrieb Mark Allman : >=20 > But, what I am struggling with here is that if we make some MUSTs > then we get a little something in return. That sets an expectation. > And, if the FooBar implementation doesn't follow that expectation > and it causes problems then there is a lever to say "well, gee, we > said you needed to do something and you didn't". FooBar does not > have to listen. We cannot make them do something different. But, > we get a little lever. So, the question in my mind is whether we > get the same sort of leverage with your looser notion of "just state > the requirements" and "use SHOULDs". And, I am thinking not. I.e., > we didn't say "do this" we said "do this unless you have a good > reason" and FooBar might think they have a good reason (e.g., "helps > my customers, so sorry about your's!"). We can still try to say > "well, we strongly recommended ...", but we're in a bit lesser > position. So SHOULD is the right usage here, because what you actually want to say = is, do it expect you have a good reason. Yes, not everybody knows how to = understand SHOULD correctly and there are even different opinion in the = IETF. And what a good reason is, is even harder to define. So from my = point the only practical solution is not using MUST but providing as = much explanation as possible on when the SHOULD might not need to be = follow and when it clearly should be followed. That=E2=80=99s often also = not easy, I know. But that's the only way to make your point, also for = people who are maybe less familiar with the language used in RFCs. Btw. = there is no requirement to use this normative language. Actually this is = only meant to help people understanding a document and its requirements = more quickly. But effectively the message should still be clear even if = the normative, upper-letter notation is ignored. Mirja= From nobody Fri Jun 17 19:22:04 2016 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 8857B12DCE5 for ; Fri, 17 Jun 2016 19:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 rwwrNMw4yIG4 for ; Fri, 17 Jun 2016 19:22:02 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04B812DCE4 for ; Fri, 17 Jun 2016 19:22:01 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5I2Lu6L003254 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jun 2016 22:21:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5I2Lu6L003254 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466216518; bh=cjj08Xrc1momNVUBAH6r+sGoNRQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bll/PXXWH8FJtSBxQ5gkYX4yS2X+GD3HHMb4NlnBv/LguTnOL9W18ZetWrSwp/JG/ l7uPsCQSXNGSH4b1EC9LeAVEBcfTDgYDE3bui/COUD71osLegWGTtYKHVMb8CHXfUk gXZoss8hkp1Tfcp+WxuqkVzJVYIa4amUx5l8u8xw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5I2Lu6L003254 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor); Fri, 17 Jun 2016 22:21:21 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5I2LZJB022443 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 17 Jun 2016 22:21:36 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0266.001; Fri, 17 Jun 2016 22:21:35 -0400 From: "Black, David" To: "Eggert, Lars" , tsvwg WG Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-14.txt Thread-Index: AQHRyKBVusS6gHQm5Uy2wlJL3ZYobJ/t8ygAgACKusA= Date: Sat, 18 Jun 2016 02:21:34 +0000 Message-ID: References: <20160617135824.19100.1482.idtracker@ietfa.amsl.com> <019AEFC5-E344-4374-8F3C-9A31A9751C0C@netapp.com> In-Reply-To: <019AEFC5-E344-4374-8F3C-9A31A9751C0C@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Mark Allman Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-14.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 02:22:03 -0000 > The main open issue in my book is what to do about Mark Allman's comment > regarding scrapping the RTT/RTO text in favor of simply to (normatively, = I guess) > referring to draft-ietf-tcpm-rto-consider. As draft shepherd, my strong guidance is not to do that because that TCPM d= raft does not and will not provide specific UDP guidance; that's the rfc5405bis = draft's role. I believe that the rfc5405bis RTT/RTO text is aligned with the TCPM RTO dra= ft, but this should be double-checked against the stable version of that draft that= emerges from the ongoing discussion. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Eggert, Lars > Sent: Friday, June 17, 2016 10:01 AM > To: tsvwg WG > Cc: Mark Allman > Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-14.txt >=20 > This revision attempts to address the various directorate and other revie= w we > have gotten. >=20 > The main open issue in my book is what to do about Mark Allman's comment > regarding scrapping the RTT/RTO text in favor of simply to (normatively, = I guess) > referring to draft-ietf-tcpm-rto-consider. >=20 > Lars >=20 > > On 2016-06-17, at 15:58, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Transport Area Working Group of the IE= TF. > > > > Title : UDP Usage Guidelines > > Authors : Lars Eggert > > Godred Fairhurst > > Greg Shepherd > > Filename : draft-ietf-tsvwg-rfc5405bis-14.txt > > Pages : 57 > > Date : 2016-06-17 > > > > Abstract: > > The User Datagram Protocol (UDP) provides a minimal message-passing > > transport that has no inherent congestion control mechanisms. This > > document provides guidelines on the use of UDP for the designers of > > applications, tunnels and other protocols that use UDP. Congestion > > control guidelines are a primary focus, but the document also > > provides guidance on other topics, including message sizes, > > reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > > and ports. > > > > Because congestion control is critical to the stable operation of the > > Internet, applications and other protocols that choose to use UDP as > > an Internet transport must employ mechanisms to prevent congestion > > collapse and to establish some degree of fairness with concurrent > > traffic. They may also need to implement additional mechanisms, > > depending on how they use UDP. > > > > Some guidance is also applicable to the design of other protocols > > (e.g., protocols layered directly on IP or via IP-based tunnels), > > especially when these protocols do not themselves provide congestion > > control. > > > > This document obsoletes RFC5405 and adds guidelines for multicast UDP > > usage. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-14 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rfc5405bis-14 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > From nobody Fri Jun 17 23:22:52 2016 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 7735C12D177; Fri, 17 Jun 2016 23:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 vIkQy38WV_Lk; Fri, 17 Jun 2016 23:22:39 -0700 (PDT) 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 9B0CA12B049; Fri, 17 Jun 2016 23:22:39 -0700 (PDT) Received: from [192.168.2.19] (host-2-102-74-50.as13285.net [2.102.74.50]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 928291B001B5; Sat, 18 Jun 2016 07:22:36 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Sat, 18 Jun 2016 07:22:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= Archived-At: Cc: Magnus Westerlund , tsvwg , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 06:22:42 -0000 I think we SHOULD NOT recommend to use ECN marks as inputs to a CB. See belo= w: > On 17 Jun 2016, at 16:02, Mirja K=C3=BChlewind wrote: >=20 > +1 to not use normative language here. >=20 > However, please note that having a high level of ECN-CE marks (without any= losses) means that all packets were received correctly. This situation can e= ven occurs without high delays (depending on the AQM used), which would just= mean the services works perfectly. Therefore for me CE marks are a perfect i= nput signal for a congestion control loop (where the AQM tell the sender to t= ake action - whatever that means). We may in future figure out ways to do this to detect significant failure us= ing a rate adaptive transport and ECN e.g. Observing 100% CE marks or somet= hing, for an RTP flow that is trying to send well below its peak rate decide= d by CC -- but I think this is speculating at an algorithm and adding detail= s here is not a good idea. Especially as AQM continues to evolve. > But I=E2=80=99m less concerned than David about eventually ignoring it for= circuit breaker. >=20 Agree. Loss is the measurement that a CB MUST respond to. > In addition one point on something Magnus wrote earlier: > "If the implementation only have circuit breaker, i.e. no full fledged con= gestion controller and uses ECN, they can in worst case drive the buffer int= o the overload regime where it starts dropping packets. =E2=80=9E >=20 > I=E2=80=99m not sure about this case. ECN is an input signal for congestio= n control. If you don=E2=80=99t use congestion control but only a circuit br= eaker, you should probably not enable ECN. At least it not clear to me why y= ou would enable it, and it's definitely not conform to the ECN spec. Probabl= y we should say something about this in the draft...? >=20 Agree, enabling ECN without a responsive CC is going to lead to trouble. > Mirja >=20 Gorry >> Am 17.06.2016 um 16:03 schrieb Black, David : >>=20 >> Colin, >>=20 >>>>> ... I view the current text as providing implementers with too much >>>>> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't >>>>> want to think about this problem space in the first place). >>>=20 >>> I agree, but the argument is that doing so is less harmful than deployin= g a circuit >>> breaker that triggers too often when ECN is used. >>>=20 >>> I=E2=80=99m not sure I believe this argument, though, since it seems tha= t any new AQM >>> that applies ECN marks much more often than at present will have to cons= ider >>> backwards compatibility, to work with deployed TCP (e.g., draft-briscoe-= tsvwg- >>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new markin= g, >>> while existing implementations set ECT(0)). These compatibility mechanis= ms >>> would seem to prevent the issues with the circuit breaker too. >>=20 >> That roughly matches my line of thinking, and I'll observe that the origi= nal DCTCP >> protocol design that used more aggressive ECN-CE marking was only safe fo= r >> Controlled Environment deployments. See the TSVWG rfc5405bis draft for t= he >> definition of Controlled Environment, and ignore the fact that the rfc540= 5bis >> draft is a UDP draft - this definition is more broadly applicable. >>=20 >> Going back over Section 7 in this avtcore draft, my views are: >>=20 >> [A] None of these drafts justify a "MAY ignore" response to ECN-CE marks:= >> - draft-khademi-tcpm-alternativebackoff-ecn >> - draft-ietf-rmcat-nada >> - draft-ietf-rmcat-scream-cc >>=20 >> [B] In line with Colin's comment on the L4S draft, I think it's incumbent= on >> the authors of draft-briscoe-aqm-dualq-coupled to figure out how that wil= l >> coexist (or avoid) deployed TCP, and this avtcore draft ought not to be >> trying to prejudge what will be done there. >>=20 >> So, I don't think the current text in Section 7 has justified the unfette= red >> "implementations MAY ignore ECN-CE marks" text, as ignoring those marks >> is not consistent with any of the four cited drafts. >>=20 >> In more detail, I think making changes to normative requirements here bas= ed >> on [B] is premature, and I would hope that the rmcat WG could be encourag= ed >> to consider the RTP circuit breaker in its congestion control drafts, as t= hose CC >> mechanisms are related to the circuit breaker mechanism, hence likely >> to be in related areas of an RTP implementation. >>=20 >> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG >> will be looking at in Berlin. If a normative statement about ECN-CE reac= tion >> is going to rest on that draft, then the reference to that draft should b= e >> normative. Something about doing that strikes me as premature ... >>=20 >> I realize that we're trying to predict and accommodate the future, which >> is an imprecise undertaking at best. As an alternative to the current t= ext, >> would it be reasonable to say (without any RFC 2119 keywords) that the >> best current guidance is still to treat ECN-CE marks as indicating drops,= >> with a warning that there is a good possibility of this changing in the >> near future due to all of the work in progress cited in Section 7? >>=20 >> Thanks, --David >>=20 >>> -----Original Message----- >>> From: Colin Perkins [mailto:csp@csperkins.org] >>> Sent: Friday, June 17, 2016 6:14 AM >>> To: John Leslie; Black, David >>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-i= etf- >>> avtcore-rtp-circuit-breakers-16 >>>=20 >>>=20 >>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>>=20 >>>> Black, David wrote: >>>>>=20 >>>>> ... I view the current text as providing implementers with too much >>>>> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't >>>>> want to think about this problem space in the first place). >>>=20 >>> I agree, but the argument is that doing so is less harmful than deployin= g a circuit >>> breaker that triggers too often when ECN is used. >>>=20 >>> I=E2=80=99m not sure I believe this argument, though, since it seems tha= t any new AQM >>> that applies ECN marks much more often than at present will have to cons= ider >>> backwards compatibility, to work with deployed TCP (e.g., draft-briscoe-= tsvwg- >>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new markin= g, >>> while existing implementations set ECT(0)). These compatibility mechanis= ms >>> would seem to prevent the issues with the circuit breaker too. >>>=20 >>>> Understand, we have at least two proposals to make ECN-CE more frequent= >>>> than packet drop would be for non-ECN packets: possibly substantially >>>> more frequent. Unless both are killed off, ECN-CE will show up frequent= ly >>>> enough that closing the flow on ECN-CE would kill too many connections.= >>>>=20 >>>> If you want circuit-breaking on such connections, there are two ways: >>>> 1. convince the forwarding nodes to drop packets if their queue exceeds= >>>> design capacity; or >>>> 2. require the sender to send enough not-ECN-capable packets so that ou= r >>>> receiver will see enough packet-drops when a circuit-breaker should >>>> activate. >>>>=20 >>>> (I prefer the first option; but I wouldn't object to the second.) >>>>=20 >>>> There really isn't any way for our circuit-breaker to know _how_much_ >>>> more frequent the ECN-CE marks may be. :^( >>>=20 >>> This is a problem, both for the circuit breaker, and for the algorithms b= eing >>> defined in RMCAT. We do need some understanding what the expected markin= g >>> rates are likely to be, so congestion control and circuit breakers can b= e defined. >>>=20 >>>> We _will_ be sorry if we >>>> allot the same frequency of CE packets as packet-drops to trigger the >>>> circuit-breaker. >>>>=20 >>>>> Could someone propose initial text to qualifies the current "MAY ignor= e" >>>>> statement? >>>>=20 >>>> Essentially, for the second option, you might propose text to the >>>> effect of: >>>> ] >>>> ] If too many ECN-CE packets are received, the sender SHOULD send some >>>> ] not-ECN-capable packets to determine whether enough packets along the= >>>> ] path are being dropped to justify activating our circuit-breaker. >>>>=20 >>>> I=E2=80=99m not enthusiastic about adding that; but it would resolve th= e issue. >>>=20 >>> I=E2=80=99m not convinced this would work. The circuit breaker is lookin= g at long term >>> trends, and in order to have enough not-ECT packets to determine if it s= hould >>> trigger, you=E2=80=99d essentially have to run without ECN for some seco= nds. >>>=20 >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jun 20 05:50:33 2016 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 673C012D0EF; Mon, 20 Jun 2016 05:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 s3c5LU81jeVM; Mon, 20 Jun 2016 05:50:18 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BEB12B05C; Mon, 20 Jun 2016 05:50:18 -0700 (PDT) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id u5KCoGQR041050; Mon, 20 Jun 2016 21:50:16 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw1.nict.go.jp with ESMTP id u5KCoGpo040929; Mon, 20 Jun 2016 21:50:16 +0900 (JST) Received: from VAIO (unknown [133.243.30.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 992C26197; Mon, 20 Jun 2016 21:50:15 +0900 (JST) From: "Takeshi Takahashi" To: "'Eggert, Lars'" References: <009201d1bb24$1563e4e0$402baea0$@nict.go.jp> <73CCA28B-9857-46E0-A338-A19F2EE4EEDB@netapp.com> In-Reply-To: <73CCA28B-9857-46E0-A338-A19F2EE4EEDB@netapp.com> Date: Mon, 20 Jun 2016 21:50:32 +0900 Message-ID: <001601d1caf2$54b61310$fe223930$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIqTpcD9HVvR9EqZoraa3UouOrYpgHy36zmnzGqVrA= Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: draft-ietf-tsvwg-rfc5405bis.all@ietf.org, tsvwg@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [tsvwg] Secdir review of draft-ietf-tsvwg-rfc5405bis-13 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 12:50:20 -0000 Hi, > > Also I have seen several typos (especially, missing parentheses around > > referenced section numbers) on this document, so please revise the > > texts before the publication of this document. > > No typos come up when using "idnits --spellcheck". I also don't quite > understand what you mean by "missing parentheses around referenced section > numbers" - could you please clarify? These typos are very trivial, but let me list them here. Since I'm not a native speaker (writer) of English, so I might be wrong, but I hope you could take a look at them. I was reading version 13 of the draft, and version 14 (that was published a couple of days ago) already have fixed most of the typo I found. 1. in Section 3.1.7, Old) "requires for" New) "required for" (already fixed in version 14) 2. in Section 3.1.7, Old) "... by the UDP congestion control method Section 3.1 that is not less than the reaction of TCP..." It could be helpful if you could use parentheses, e.g., "...control method (see Section 3.1) that..." or "...control method described in Section 3.1) that..." 3. in Section 3.1.8 Old) "across multiple networks the between ..." New) "across multiple networks between ..." (already fixed in version 14) 4. in Section 3.1.9 Old) "into unprovisioned Internet paths (e.g., [RFC7510]) To protect" The sentence might need a period in between; i.e., "into unprovisioned Internet paths (e.g., [RFC7510]). To protect" 5. in Section 7 Old) "for tunnels carrying IP Traffic," It could be a non-capital letter; i.e., "for tunnels carrying IP traffic," I like the summary table inserted in Section 7. Thank you for preparing the summary table. Kind regards, Take > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Friday, June 17, 2016 9:39 PM > To: Takeshi Takahashi > Cc: iesg@ietf.org; secdir@ietf.org; > draft-ietf-tsvwg-rfc5405bis.all@ietf.org; tsvwg@ietf.org > Subject: Re: Secdir review of draft-ietf-tsvwg-rfc5405bis-13 > > Hi, > > thanks for the review! I'll incorporate respective changes into -14. > > On 2016-05-31, at 12:06, Takeshi Takahashi > wrote: > > In Table 1 "Summary of recommendations", I wonder if the corresponding > > section numbers are correct. > > > > [Now] > > "SHOULD avoid using multiple ports" corresponds to Section 5.1 and > > "SHOULD use a randomized source port or equivalent technique" > > corresponds to Section 5.2 > > > > [New] > > "SHOULD avoid using multiple ports" corresponds to Section 5.1.1 and > > "SHOULD use a randomized source port or equivalent technique" > > corresponds to Section 5.1.2 > > > > I might be wrong, so please check. > > You were right that what we had was wrong (copy/paste bug, I think), but > they pointers should be to Sections 5.1.2 and 6, respectively. > > > Also I have seen several typos (especially, missing parentheses around > > referenced section numbers) on this document, so please revise the > > texts before the publication of this document. > > No typos come up when using "idnits --spellcheck". I also don't quite > understand what you mean by "missing parentheses around referenced section > numbers" - could you please clarify? > > Thanks, > Lars From nobody Mon Jun 20 06:17:43 2016 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 2E17E12D0D3; Mon, 20 Jun 2016 06:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 uVpEIjUgQmoo; Mon, 20 Jun 2016 06:17:38 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A8112D0ED; Mon, 20 Jun 2016 06:17:38 -0700 (PDT) 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 u5KDHLPr009084 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 09:17:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u5KDHLPr009084 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466428644; bh=8Xp72uWLcZCT5fKoLzmAn5etgCA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IwebxAOwqWUN0i5iMpV1G4HvJE6ix0dvZs91TYYHFcsCptOKg+YWjG4rEsdLCfdmo 2Eh6I0zmNSHGew8ya6SvfdumclyauRbSF5h1jPVwuWF+3EUe6EUVKp+/kmb4cZVnA5 Q1Su3kznDMvmlfGbb3+BZi6Yh1vtCAbDhGZ76+eo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u5KDHLPr009084 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 20 Jun 2016 09:16:36 -0400 Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5KDGxoQ000644 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 20 Jun 2016 09:16:59 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0266.001; Mon, 20 Jun 2016 09:16:59 -0400 From: "Black, David" To: "Gorry (erg)" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRySnSO2oWwmhohkOlLHzEpySa4p/yV2bA Date: Mon, 20 Jun 2016 13:16:58 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> In-Reply-To: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Magnus Westerlund , tsvwg , "rtcweb@ietf.org" , Colin Perkins , IETF AVTCore WG Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 13:17:42 -0000 PiA+IEJ1dCBJ4oCZbSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0IGV2ZW50dWFsbHkg aWdub3JpbmcgaXQgZm9yIGNpcmN1aXQNCj4gYnJlYWtlci4NCj4gPg0KPiBBZ3JlZS4gTG9zcyBp cyB0aGUgbWVhc3VyZW1lbnQgdGhhdCBhIENCIE1VU1QgcmVzcG9uZCB0by4NCg0KTXVtYmxlLiAg IEkgd291bGQgYmUgb2sgd2l0aCBhIGNsZWFyIGRpc2NvdXJhZ2VtZW50IGZvciB1c2Ugb2YgRUNO LUNFIG1hcmtzLCBhY2NvbXBhbmllZCBieSB0aGUgc29ydCBvZiBkZXNpZ24gcmF0aW9uYWxlIGhl cmUsIG9yIGV2ZW4gYmV0dGVyLCBhIGNsZWFyIHN0YXRlbWVudCB0aGF0IGxvc3QgcGFja2V0cyBm b3IgdGhlIHB1cnBvc2Ugb2YgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1 YWxseSBsb3N0IHdpdGhvdXQgZ2V0dGluZyBpbnRvIHdoZXRoZXIgb3Igbm90IEVDTi1DRSBtYXJr cyBhcmUgaW52b2x2ZWQgLWkuZS4sIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGlzIHNwZWNpZmll ZCBhZ2FpbnN0IGFjdHVhbCBkcm9wcyBhcyBhIG5ldHdvcmsgcHJvdGVjdGlvbiBiYWNrc3RvcC4N Cg0KQSByZWxhdGVkIGNvbmNlcm4gaXMgdGhhdCBFQ04gbWFya3MgbWF5IG92ZXJzdGF0ZSBlcXVp dmFsZW50IGxvc3MgYmVoYXZpb3IgLSBhIHNpbXBsaXN0aWMgcXVldWUgbWFuYWdlbWVudCBkaXNj aXBsaW5lIHRoYXQgbWFya3MgZXZlcnkgcGFja2V0IHdoZW4gdGhlIHF1ZXVlIGlzIG92ZXIgYSB0 aHJlc2hvbGQgKE5COiB0aGlzIGNsYXNzIG9mIG1hcmtpbmcgYmVoYXZpb3IgaXMgTk9UIFJFQ09N TUVOREVEIC0gYSByZWFsIEFRTSBTSE9VTEQgYmUgdXNlZCkgY291bGQgeWllbGQgYSBydW4gb2Yg RUNOLUNFIG1hcmtzIHRoYXQgd291bGQgbm90IGNhdXNlIGEgY29ycmVzcG9uZGluZyB3aXRoIGEg cnVuIG9mIHBhY2tldCBkcm9wcy4gICBUaGlzIGlzIGFtb25nIHRoZSByZWFzb25zIHRoYXQgVENQ IHJlYWN0cyB0byBFQ04tQ0UgbWFya3Mgb25seSBvbmNlIHBlciBSVFQsIGFuZCBtaWdodCBiZSBh IHJlYXNvbiB0byB0cmVhdCBtdWx0aXBsZSBFQ04tQ0UgbWFya3MgaW4gYW4gUlRUIGludGVydmFs IGFzIG5vdCByZXByZXNlbnRpbmcgZHJvcHMgb2YgYWxsIHBhY2tldHMgZm9yIHRoZSBSVFAgY2ly Y3VpdCBicmVha2VyJ3MgVENQLWVxdWl2YWxlbnQgdGhyb3VnaHB1dCBjYWxjdWxhdGlvbi4NCg0K VGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog R29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gU2VudDogU2F0dXJk YXksIEp1bmUgMTgsIDIwMTYgMjoyMyBBTQ0KPiBUbzogTWlyamEgS8O8aGxld2luZA0KPiBDYzog QmxhY2ssIERhdmlkOyBNYWdudXMgV2VzdGVybHVuZDsgQ29saW4gUGVya2luczsgcnRjd2ViQGll dGYub3JnOyBJRVRGDQo+IEFWVENvcmUgV0c7IHRzdndnDQo+IFN1YmplY3Q6IFJlOiBbdHN2d2dd IFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJhZnQtaWV0Zi0N Cj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gSSB0aGluayB3ZSBTSE9V TEQgTk9UIHJlY29tbWVuZCB0byB1c2UgRUNOIG1hcmtzIGFzIGlucHV0cyB0byBhIENCLiBTZWUN Cj4gYmVsb3c6DQo+IA0KPiA+IE9uIDE3IEp1biAyMDE2LCBhdCAxNjowMiwgTWlyamEgS8O8aGxl d2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4NCj4gd3JvdGU6DQo+ID4NCj4g PiArMSB0byBub3QgdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSBoZXJlLg0KPiA+DQo+ID4gSG93ZXZl ciwgcGxlYXNlIG5vdGUgdGhhdCBoYXZpbmcgYSBoaWdoIGxldmVsIG9mIEVDTi1DRSBtYXJrcyAo d2l0aG91dCBhbnkNCj4gbG9zc2VzKSBtZWFucyB0aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2 ZWQgY29ycmVjdGx5LiBUaGlzIHNpdHVhdGlvbiBjYW4gZXZlbg0KPiBvY2N1cnMgd2l0aG91dCBo aWdoIGRlbGF5cyAoZGVwZW5kaW5nIG9uIHRoZSBBUU0gdXNlZCksIHdoaWNoIHdvdWxkIGp1c3QN Cj4gbWVhbiB0aGUgc2VydmljZXMgd29ya3MgcGVyZmVjdGx5LiBUaGVyZWZvcmUgZm9yIG1lIENF IG1hcmtzIGFyZSBhIHBlcmZlY3QgaW5wdXQNCj4gc2lnbmFsIGZvciBhIGNvbmdlc3Rpb24gY29u dHJvbCBsb29wICh3aGVyZSB0aGUgQVFNIHRlbGwgdGhlIHNlbmRlciB0byB0YWtlIGFjdGlvbg0K PiAtIHdoYXRldmVyIHRoYXQgbWVhbnMpLg0KPiANCj4gV2UgbWF5IGluIGZ1dHVyZSBmaWd1cmUg b3V0IHdheXMgdG8gZG8gdGhpcyB0byBkZXRlY3Qgc2lnbmlmaWNhbnQgZmFpbHVyZSB1c2luZyBh DQo+IHJhdGUgYWRhcHRpdmUgdHJhbnNwb3J0IGFuZCBFQ04gZS5nLiAgT2JzZXJ2aW5nIDEwMCUg Q0UgbWFya3Mgb3Igc29tZXRoaW5nLCBmb3INCj4gYW4gUlRQIGZsb3cgdGhhdCBpcyB0cnlpbmcg dG8gc2VuZCB3ZWxsIGJlbG93IGl0cyBwZWFrIHJhdGUgZGVjaWRlZCBieSBDQyAtLSBidXQgSQ0K PiB0aGluayB0aGlzIGlzIHNwZWN1bGF0aW5nIGF0IGFuIGFsZ29yaXRobSBhbmQgYWRkaW5nIGRl dGFpbHMgaGVyZSBpcyBub3QgYSBnb29kIGlkZWEuDQo+IEVzcGVjaWFsbHkgYXMgQVFNIGNvbnRp bnVlcyB0byBldm9sdmUuDQo+IA0KPiA+IEJ1dCBJ4oCZbSBsZXNzIGNvbmNlcm5lZCB0aGFuIERh dmlkIGFib3V0IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQgZm9yIGNpcmN1aXQNCj4gYnJlYWtlci4N Cj4gPg0KPiBBZ3JlZS4gTG9zcyBpcyB0aGUgbWVhc3VyZW1lbnQgdGhhdCBhIENCIE1VU1QgcmVz cG9uZCB0by4NCj4gDQo+ID4gSW4gYWRkaXRpb24gb25lIHBvaW50IG9uIHNvbWV0aGluZyBNYWdu dXMgd3JvdGUgZWFybGllcjoNCj4gPiAiSWYgdGhlIGltcGxlbWVudGF0aW9uIG9ubHkgaGF2ZSBj aXJjdWl0IGJyZWFrZXIsIGkuZS4gbm8gZnVsbCBmbGVkZ2VkIGNvbmdlc3Rpb24NCj4gY29udHJv bGxlciBhbmQgdXNlcyBFQ04sIHRoZXkgY2FuIGluIHdvcnN0IGNhc2UgZHJpdmUgdGhlIGJ1ZmZl ciBpbnRvIHRoZSBvdmVybG9hZA0KPiByZWdpbWUgd2hlcmUgaXQgc3RhcnRzIGRyb3BwaW5nIHBh Y2tldHMuIOKAng0KPiA+DQo+ID4gSeKAmW0gbm90IHN1cmUgYWJvdXQgdGhpcyBjYXNlLiBFQ04g aXMgYW4gaW5wdXQgc2lnbmFsIGZvciBjb25nZXN0aW9uIGNvbnRyb2wuIElmIHlvdQ0KPiBkb27i gJl0IHVzZSBjb25nZXN0aW9uIGNvbnRyb2wgYnV0IG9ubHkgYSBjaXJjdWl0IGJyZWFrZXIsIHlv dSBzaG91bGQgcHJvYmFibHkgbm90DQo+IGVuYWJsZSBFQ04uIEF0IGxlYXN0IGl0IG5vdCBjbGVh ciB0byBtZSB3aHkgeW91IHdvdWxkIGVuYWJsZSBpdCwgYW5kIGl0J3MgZGVmaW5pdGVseQ0KPiBu b3QgY29uZm9ybSB0byB0aGUgRUNOIHNwZWMuIFByb2JhYmx5IHdlIHNob3VsZCBzYXkgc29tZXRo aW5nIGFib3V0IHRoaXMgaW4gdGhlDQo+IGRyYWZ0Li4uPw0KPiA+DQo+IEFncmVlLCBlbmFibGlu ZyBFQ04gd2l0aG91dCBhIHJlc3BvbnNpdmUgQ0MgaXMgZ29pbmcgdG8gbGVhZCB0byB0cm91Ymxl Lg0KPiANCj4gPiBNaXJqYQ0KPiA+DQo+IEdvcnJ5DQo+IA0KPiA+PiBBbSAxNy4wNi4yMDE2IHVt IDE2OjAzIHNjaHJpZWIgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPjoNCj4gPj4N Cj4gPj4gQ29saW4sDQo+ID4+DQo+ID4+Pj4+IC4uLiAgSSB2aWV3IHRoZSBjdXJyZW50IHRleHQg YXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoIHRvbyBtdWNoDQo+ID4+Pj4+IGxhdGl0dWRl IHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4gaW1wbGVtZW50ZXIgZG9l c24ndA0KPiA+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSBzcGFjZSBpbiB0 aGUgZmlyc3QgcGxhY2UpLg0KPiA+Pj4NCj4gPj4+IEkgYWdyZWUsIGJ1dCB0aGUgYXJndW1lbnQg aXMgdGhhdCBkb2luZyBzbyBpcyBsZXNzIGhhcm1mdWwgdGhhbiBkZXBsb3lpbmcgYQ0KPiBjaXJj dWl0DQo+ID4+PiBicmVha2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVuIHdoZW4gRUNOIGlzIHVz ZWQuDQo+ID4+Pg0KPiA+Pj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQs IHRob3VnaCwgc2luY2UgaXQgc2VlbXMgdGhhdCBhbnkgbmV3DQo+IEFRTQ0KPiA+Pj4gdGhhdCBh cHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwgaGF2 ZSB0bw0KPiBjb25zaWRlcg0KPiA+Pj4gYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdvcmsg d2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sIGRyYWZ0LWJyaXNjb2UtDQo+IHRzdndnLQ0KPiA+Pj4g YXFtLXRjcG0tcm1jYXQtbDRzLXByb2JsZW0gdXNlcyBFQ1QoMSkgYXMgYSBzaWduYWwgdG8gdXNl IHRoZSBuZXcgbWFya2luZywNCj4gPj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBz ZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eSBtZWNoYW5pc21zDQo+ID4+PiB3b3VsZCBz ZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG9vLg0K PiA+Pg0KPiA+PiBUaGF0IHJvdWdobHkgbWF0Y2hlcyBteSBsaW5lIG9mIHRoaW5raW5nLCBhbmQg SSdsbCBvYnNlcnZlIHRoYXQgdGhlIG9yaWdpbmFsDQo+IERDVENQDQo+ID4+IHByb3RvY29sIGRl c2lnbiB0aGF0IHVzZWQgbW9yZSBhZ2dyZXNzaXZlIEVDTi1DRSBtYXJraW5nIHdhcyBvbmx5IHNh ZmUgZm9yDQo+ID4+IENvbnRyb2xsZWQgRW52aXJvbm1lbnQgZGVwbG95bWVudHMuICAgU2VlIHRo ZSBUU1ZXRyByZmM1NDA1YmlzIGRyYWZ0IGZvcg0KPiB0aGUNCj4gPj4gZGVmaW5pdGlvbiBvZiBD b250cm9sbGVkIEVudmlyb25tZW50LCBhbmQgaWdub3JlIHRoZSBmYWN0IHRoYXQgdGhlIHJmYzU0 MDViaXMNCj4gPj4gZHJhZnQgaXMgYSBVRFAgZHJhZnQgLSB0aGlzIGRlZmluaXRpb24gaXMgbW9y ZSBicm9hZGx5IGFwcGxpY2FibGUuDQo+ID4+DQo+ID4+IEdvaW5nIGJhY2sgb3ZlciBTZWN0aW9u IDcgaW4gdGhpcyBhdnRjb3JlIGRyYWZ0LCBteSB2aWV3cyBhcmU6DQo+ID4+DQo+ID4+IFtBXSBO b25lIG9mIHRoZXNlIGRyYWZ0cyBqdXN0aWZ5IGEgIk1BWSBpZ25vcmUiIHJlc3BvbnNlIHRvIEVD Ti1DRSBtYXJrczoNCj4gPj4gICAgLSBkcmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNr b2ZmLWVjbg0KPiA+PiAgICAtIGRyYWZ0LWlldGYtcm1jYXQtbmFkYQ0KPiA+PiAgICAtIGRyYWZ0 LWlldGYtcm1jYXQtc2NyZWFtLWNjDQo+ID4+DQo+ID4+IFtCXSBJbiBsaW5lIHdpdGggQ29saW4n cyBjb21tZW50IG9uIHRoZSBMNFMgZHJhZnQsIEkgdGhpbmsgaXQncyBpbmN1bWJlbnQgb24NCj4g Pj4gdGhlIGF1dGhvcnMgb2YgZHJhZnQtYnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBmaWd1 cmUgb3V0IGhvdyB0aGF0IHdpbGwNCj4gPj4gY29leGlzdCAob3IgYXZvaWQpIGRlcGxveWVkIFRD UCwgYW5kIHRoaXMgYXZ0Y29yZSBkcmFmdCBvdWdodCBub3QgdG8gYmUNCj4gPj4gdHJ5aW5nIHRv IHByZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KPiA+Pg0KPiA+PiBTbywgSSBkb24n dCB0aGluayB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gNyBoYXMganVzdGlmaWVkIHRoZSB1 bmZldHRlcmVkDQo+ID4+ICJpbXBsZW1lbnRhdGlvbnMgTUFZIGlnbm9yZSBFQ04tQ0UgbWFya3Mi IHRleHQsIGFzIGlnbm9yaW5nIHRob3NlIG1hcmtzDQo+ID4+IGlzIG5vdCBjb25zaXN0ZW50IHdp dGggYW55IG9mIHRoZSBmb3VyIGNpdGVkIGRyYWZ0cy4NCj4gPj4NCj4gPj4gSW4gbW9yZSBkZXRh aWwsIEkgdGhpbmsgbWFraW5nIGNoYW5nZXMgdG8gbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBoZXJl IGJhc2VkDQo+ID4+IG9uIFtCXSBpcyBwcmVtYXR1cmUsIGFuZCBJIHdvdWxkIGhvcGUgdGhhdCB0 aGUgcm1jYXQgV0cgY291bGQgYmUNCj4gZW5jb3VyYWdlZA0KPiA+PiB0byBjb25zaWRlciB0aGUg UlRQIGNpcmN1aXQgYnJlYWtlciBpbiBpdHMgY29uZ2VzdGlvbiBjb250cm9sIGRyYWZ0cywgYXMg dGhvc2UgQ0MNCj4gPj4gbWVjaGFuaXNtcyBhcmUgcmVsYXRlZCB0byB0aGUgY2lyY3VpdCBicmVh a2VyIG1lY2hhbmlzbSwgaGVuY2UgbGlrZWx5DQo+ID4+IHRvIGJlIGluIHJlbGF0ZWQgYXJlYXMg b2YgYW4gUlRQIGltcGxlbWVudGF0aW9uLg0KPiA+Pg0KPiA+PiBUaGF0IGxlYXZlcyBkcmFmdC1r aGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbiwgd2hpY2ggVFNWV0cNCj4gPj4gd2ls bCBiZSBsb29raW5nIGF0IGluIEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudCBhYm91 dCBFQ04tQ0UgcmVhY3Rpb24NCj4gPj4gaXMgZ29pbmcgdG8gcmVzdCBvbiB0aGF0IGRyYWZ0LCB0 aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdCBkcmFmdCBzaG91bGQgYmUNCj4gPj4gbm9ybWF0aXZl LiAgU29tZXRoaW5nIGFib3V0IGRvaW5nIHRoYXQgc3RyaWtlcyBtZSBhcyBwcmVtYXR1cmUgLi4u DQo+ID4+DQo+ID4+IEkgcmVhbGl6ZSB0aGF0IHdlJ3JlIHRyeWluZyB0byBwcmVkaWN0IGFuZCBh Y2NvbW1vZGF0ZSB0aGUgZnV0dXJlLCB3aGljaA0KPiA+PiBpcyBhbiBpbXByZWNpc2UgdW5kZXJ0 YWtpbmcgYXQgYmVzdC4gICBBcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgY3VycmVudCB0ZXh0LA0K PiA+PiB3b3VsZCBpdCBiZSByZWFzb25hYmxlIHRvIHNheSAod2l0aG91dCBhbnkgUkZDIDIxMTkg a2V5d29yZHMpIHRoYXQgdGhlDQo+ID4+IGJlc3QgY3VycmVudCBndWlkYW5jZSBpcyBzdGlsbCB0 byB0cmVhdCBFQ04tQ0UgbWFya3MgYXMgaW5kaWNhdGluZyBkcm9wcywNCj4gPj4gd2l0aCBhIHdh cm5pbmcgdGhhdCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkgb2YgdGhpcyBjaGFuZ2luZyBp biB0aGUNCj4gPj4gbmVhciBmdXR1cmUgZHVlIHRvIGFsbCBvZiB0aGUgd29yayBpbiBwcm9ncmVz cyBjaXRlZCBpbiBTZWN0aW9uIDc/DQo+ID4+DQo+ID4+IFRoYW5rcywgLS1EYXZpZA0KPiA+Pg0K PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IENvbGluIFBlcmtp bnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAx NywgMjAxNiA2OjE0IEFNDQo+ID4+PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+ Pj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZzsgSUVURiBBVlRDb3JlIFdHOyB0c3Z3Zw0KPiA+Pj4gU3Vi amVjdDogUmU6IFtydGN3ZWJdIFtBVlRDT1JFXSBbdHN2d2ddIFdHIExhc3QgQ2FsbCBvbiBjaGFu Z2VzOiBkcmFmdC1pZXRmLQ0KPiA+Pj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0K PiA+Pj4NCj4gPj4+DQo+ID4+Pj4gT24gMTYgSnVuIDIwMTYsIGF0IDIzOjI1LCBKb2huIExlc2xp ZSA8am9obkBqbGMubmV0PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+IEJsYWNrLCBEYXZpZCA8ZGF2 aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+IC4uLiAgSSB2aWV3IHRo ZSBjdXJyZW50IHRleHQgYXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoIHRvbyBtdWNoDQo+ ID4+Pj4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4g aW1wbGVtZW50ZXIgZG9lc24ndA0KPiA+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJv YmxlbSBzcGFjZSBpbiB0aGUgZmlyc3QgcGxhY2UpLg0KPiA+Pj4NCj4gPj4+IEkgYWdyZWUsIGJ1 dCB0aGUgYXJndW1lbnQgaXMgdGhhdCBkb2luZyBzbyBpcyBsZXNzIGhhcm1mdWwgdGhhbiBkZXBs b3lpbmcgYQ0KPiBjaXJjdWl0DQo+ID4+PiBicmVha2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVu IHdoZW4gRUNOIGlzIHVzZWQuDQo+ID4+Pg0KPiA+Pj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZl IHRoaXMgYXJndW1lbnQsIHRob3VnaCwgc2luY2UgaXQgc2VlbXMgdGhhdCBhbnkgbmV3DQo+IEFR TQ0KPiA+Pj4gdGhhdCBhcHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBw cmVzZW50IHdpbGwgaGF2ZSB0bw0KPiBjb25zaWRlcg0KPiA+Pj4gYmFja3dhcmRzIGNvbXBhdGli aWxpdHksIHRvIHdvcmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sIGRyYWZ0LWJyaXNjb2UtDQo+ IHRzdndnLQ0KPiA+Pj4gYXFtLXRjcG0tcm1jYXQtbDRzLXByb2JsZW0gdXNlcyBFQ1QoMSkgYXMg YSBzaWduYWwgdG8gdXNlIHRoZSBuZXcgbWFya2luZywNCj4gPj4+IHdoaWxlIGV4aXN0aW5nIGlt cGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eSBtZWNoYW5pc21z DQo+ID4+PiB3b3VsZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0 IGJyZWFrZXIgdG9vLg0KPiA+Pj4NCj4gPj4+PiBVbmRlcnN0YW5kLCB3ZSBoYXZlIGF0IGxlYXN0 IHR3byBwcm9wb3NhbHMgdG8gbWFrZSBFQ04tQ0UgbW9yZQ0KPiBmcmVxdWVudA0KPiA+Pj4+IHRo YW4gcGFja2V0IGRyb3Agd291bGQgYmUgZm9yIG5vbi1FQ04gcGFja2V0czogcG9zc2libHkgc3Vi c3RhbnRpYWxseQ0KPiA+Pj4+IG1vcmUgZnJlcXVlbnQuIFVubGVzcyBib3RoIGFyZSBraWxsZWQg b2ZmLCBFQ04tQ0Ugd2lsbCBzaG93IHVwIGZyZXF1ZW50bHkNCj4gPj4+PiBlbm91Z2ggdGhhdCBj bG9zaW5nIHRoZSBmbG93IG9uIEVDTi1DRSB3b3VsZCBraWxsIHRvbyBtYW55IGNvbm5lY3Rpb25z Lg0KPiA+Pj4+DQo+ID4+Pj4gSWYgeW91IHdhbnQgY2lyY3VpdC1icmVha2luZyBvbiBzdWNoIGNv bm5lY3Rpb25zLCB0aGVyZSBhcmUgdHdvIHdheXM6DQo+ID4+Pj4gMS4gY29udmluY2UgdGhlIGZv cndhcmRpbmcgbm9kZXMgdG8gZHJvcCBwYWNrZXRzIGlmIHRoZWlyIHF1ZXVlIGV4Y2VlZHMNCj4g Pj4+PiBkZXNpZ24gY2FwYWNpdHk7IG9yDQo+ID4+Pj4gMi4gcmVxdWlyZSB0aGUgc2VuZGVyIHRv IHNlbmQgZW5vdWdoIG5vdC1FQ04tY2FwYWJsZSBwYWNrZXRzIHNvIHRoYXQgb3VyDQo+ID4+Pj4g cmVjZWl2ZXIgd2lsbCBzZWUgZW5vdWdoIHBhY2tldC1kcm9wcyB3aGVuIGEgY2lyY3VpdC1icmVh a2VyIHNob3VsZA0KPiA+Pj4+IGFjdGl2YXRlLg0KPiA+Pj4+DQo+ID4+Pj4gKEkgcHJlZmVyIHRo ZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0IG9iamVjdCB0byB0aGUgc2Vjb25kLikNCj4g Pj4+Pg0KPiA+Pj4+IFRoZXJlIHJlYWxseSBpc24ndCBhbnkgd2F5IGZvciBvdXIgY2lyY3VpdC1i cmVha2VyIHRvIGtub3cgX2hvd19tdWNoXw0KPiA+Pj4+IG1vcmUgZnJlcXVlbnQgdGhlIEVDTi1D RSBtYXJrcyBtYXkgYmUuIDpeKA0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgYSBwcm9ibGVtLCBib3Ro IGZvciB0aGUgY2lyY3VpdCBicmVha2VyLCBhbmQgZm9yIHRoZSBhbGdvcml0aG1zIGJlaW5nDQo+ ID4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNvbWUgdW5kZXJzdGFuZGluZyB3aGF0 IHRoZSBleHBlY3RlZA0KPiBtYXJraW5nDQo+ID4+PiByYXRlcyBhcmUgbGlrZWx5IHRvIGJlLCBz byBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIGNpcmN1aXQgYnJlYWtlcnMgY2FuIGJlDQo+IGRlZmlu ZWQuDQo+ID4+Pg0KPiA+Pj4+IFdlIF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+Pj4+IGFsbG90 IHRoZSBzYW1lIGZyZXF1ZW5jeSBvZiBDRSBwYWNrZXRzIGFzIHBhY2tldC1kcm9wcyB0byB0cmln Z2VyIHRoZQ0KPiA+Pj4+IGNpcmN1aXQtYnJlYWtlci4NCj4gPj4+Pg0KPiA+Pj4+PiBDb3VsZCBz b21lb25lIHByb3Bvc2UgaW5pdGlhbCB0ZXh0IHRvIHF1YWxpZmllcyB0aGUgY3VycmVudCAiTUFZ IGlnbm9yZSINCj4gPj4+Pj4gc3RhdGVtZW50Pw0KPiA+Pj4+DQo+ID4+Pj4gRXNzZW50aWFsbHks IGZvciB0aGUgc2Vjb25kIG9wdGlvbiwgeW91IG1pZ2h0IHByb3Bvc2UgdGV4dCB0byB0aGUNCj4g Pj4+PiBlZmZlY3Qgb2Y6DQo+ID4+Pj4gXQ0KPiA+Pj4+IF0gSWYgdG9vIG1hbnkgRUNOLUNFIHBh Y2tldHMgYXJlIHJlY2VpdmVkLCB0aGUgc2VuZGVyIFNIT1VMRCBzZW5kIHNvbWUNCj4gPj4+PiBd IG5vdC1FQ04tY2FwYWJsZSBwYWNrZXRzIHRvIGRldGVybWluZSB3aGV0aGVyIGVub3VnaCBwYWNr ZXRzIGFsb25nIHRoZQ0KPiA+Pj4+IF0gcGF0aCBhcmUgYmVpbmcgZHJvcHBlZCB0byBqdXN0aWZ5 IGFjdGl2YXRpbmcgb3VyIGNpcmN1aXQtYnJlYWtlci4NCj4gPj4+Pg0KPiA+Pj4+IEnigJltIG5v dCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3VsZCByZXNvbHZlIHRo ZSBpc3N1ZS4NCj4gPj4+DQo+ID4+PiBJ4oCZbSBub3QgY29udmluY2VkIHRoaXMgd291bGQgd29y ay4gVGhlIGNpcmN1aXQgYnJlYWtlciBpcyBsb29raW5nIGF0IGxvbmcgdGVybQ0KPiA+Pj4gdHJl bmRzLCBhbmQgaW4gb3JkZXIgdG8gaGF2ZSBlbm91Z2ggbm90LUVDVCBwYWNrZXRzIHRvIGRldGVy bWluZSBpZiBpdA0KPiBzaG91bGQNCj4gPj4+IHRyaWdnZXIsIHlvdeKAmWQgZXNzZW50aWFsbHkg aGF2ZSB0byBydW4gd2l0aG91dCBFQ04gZm9yIHNvbWUgc2Vjb25kcy4NCj4gPj4+DQo+ID4+PiAt LQ0KPiA+Pj4gQ29saW4gUGVya2lucw0KPiA+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiA+ Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= From nobody Mon Jun 20 07:44:05 2016 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 4A4FD12D10C; Mon, 20 Jun 2016 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 AWTXZ-hMHGcg; Mon, 20 Jun 2016 07:43:50 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AED112D08E; Mon, 20 Jun 2016 07:43:50 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5KEhmKf026171; Mon, 20 Jun 2016 07:43:48 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1472B4D4685C; Mon, 20 Jun 2016 10:44:56 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document57987.jpg X-URL-1: http://www.icir.org/mallman-files/Document52629.doc X-URL-2: http://www.icir.org/mallman-files/Document76540.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 20 Jun 2016 10:44:56 -0400 Message-ID: <16792.1466433896@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 14:43:51 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > If [rto-consider] is IETF consensus, IMHO a 6298bis document would > be a no-brainer in TCPM. But, it isn't necessary. RFC 6298 is a document about *one* algorithm. We could invent parallel algorithms. And, write an RFC that specifies each. RFC 6298 just happens to be the only RTO we have taken the bother to develop and write up. So, RFC 6298 (or a bis) doesn't have to convey all of our TCP RTO understanding. It is just one algorithm for doing it. So, yeah, we can write a preamble to RFC 6298 that says "this agrees with [rto-consider]", but that doesn't change the algorithm. It isn't a technical change at all. It is more words in service of what? A tidy---by some definition---document progression is all I can come up with. It doesn't advance things in any meaningful way. > One added value of 6298bis is that it applies the > generic wording in [rto-consider] specifically to the TCP. I > believe that this is simpler to read for a TCP implementer than to > reverse-engineer protocol-agnostic wording in a draft that gets > longer and longer to be protocol-agnostic (and likely will have to > be further extended when it hits IETF last call)? The whole thing hasn't really gotten much longer. And, it is still quite short. And, I don't think that someone steeped in TCP will have a difficult time reading the generic form of the requirements there now. These are not particularly foreign concepts we're talking about. > So is your concern that nobody would invest cycles to author a > 6298bis in TCPM? Or something equivalent e.g. for SCTP?=20 My concern is for doing work that just doesn't need to be done. How many times do you want to re-state the same thing? TCP, SCTP. What about UDP? I doubt you'll find the notions in 5405bis to be quite right because they apply the rto-consider requirements to all UDP-based protocols. And, so, I think all the same arguments you're making now would have to be applied there, too, and so we'll have to go and write N more of these things for N UDP-based apps. That's saying the same thing a lot. And, God forbid if we ever had to change something... The point is that except for document series tidiness I have seen no reason to make these requirements only apply to future specs---and not implementations---as you advocate. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldoAWcACgkQWyrrWs4yIs6/jwCfcRW8FOX2UDCZB6TVdiepNoGq JswAnAvxm+mXZs4r/eM1H5BV0D48K8WH =ow6K -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jun 20 08:29:59 2016 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 E0B5312D1A3; Mon, 20 Jun 2016 08:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 0yEMi2xnnhQo; Mon, 20 Jun 2016 08:29:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D64612D1A7; Mon, 20 Jun 2016 08:29:53 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DC3E3B38D58FA; Mon, 20 Jun 2016 15:29:47 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5KFTot6029151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 15:29:50 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5KFTovD013242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jun 2016 17:29:50 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 17:29:50 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRywJPoDoEKDWkakuYZCmVs3o6/5/ybzxg Date: Mon, 20 Jun 2016 15:29:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DEC5B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16792.1466433896@lawyers.icir.org> In-Reply-To: <16792.1466433896@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 15:29:55 -0000 > > If [rto-consider] is IETF consensus, IMHO a 6298bis document would be=20 > > a no-brainer in TCPM. > But, it isn't necessary. RFC 6298 is a document about *one* algorithm. This is not how I read RFC 6298. It already has a MUST in the abstract: This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. RFC 6298 does mention that other algorithms could exist, with the following= wording: In some situations, it may be beneficial for a TCP sender to be more conservative than the algorithms detailed in this document allow. However, a TCP MUST NOT be more aggressive than the following algorithms allow. This document obsoletes RFC 2988 [PA00]. But RFC 6298 does not have the notion of *one* algorithm. So, in my reading, [rto-consider] contradicts quite explicitly the standard= s track specification of TCP. What do I miss here? In my view RFC 6298 needs to be updated if TCPM believes that a TCP impleme= ntation fully compliant to IETF standards should be allowed to have other a= lgorithms. As mentioned already, I would support publishing a 6298bis for that purpose= . I believe that it is important that TCPM standards track documents are (1= ) consistent and (2) well aligned with the major TCP implementations. The following to me is a very straightforward and clean approach: * [rto-consider] provides the general protocol-agnostic requirements, as sp= ecified in the wording of my review * 5405bis applies it to UDP * 6298bis applies it TCP and cleanly updates 6298 on standards track * SCTP should be a low-hanging fruit as well * Other protocols owned by other working groups have to review [rto-conside= r] and come to an own consensus anyway And, possibly even more importantly, reading protocol-specific guidance sho= uld typically also be simpler for implementers since they don't have to gue= ss how to apply generic wording to the specific protocol semantics. In short, I am not aware of any relevant downside of that very clean approa= ch. Michael From nobody Mon Jun 20 09:30:43 2016 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 67F1812D759; Mon, 20 Jun 2016 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 oNBD5Y12JY11; Mon, 20 Jun 2016 09:30:41 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BCA12D787; Mon, 20 Jun 2016 09:30:40 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5KGUZab008311 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 12:30:37 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u5KGUZab008311 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466440238; bh=Tj79K18VPFhccnWUtja4M8zFV1Q=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=I/VA47gkAwdP2mHH22Zieaw7cE3O+s+xtWRwJ964dquoJaBLk2jvvAuSL0EotcoIB asfj4/qz2lRdNRZM+mYAk4G0wa08drYH1kMVlLi/Lcu13bg7e30IxQghM8zlZE1t6U zFxp/MEp/slXGMuABYGtBV6cO7iDjXwGDjCVPdPw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u5KGUZab008311 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 20 Jun 2016 12:30:11 -0400 Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5KGUIYG007717 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 20 Jun 2016 12:30:18 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0266.001; Mon, 20 Jun 2016 12:30:17 -0400 From: "Black, David" To: "mallman@icir.org" , "Scharf, Michael (Nokia - DE)" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyKEIFD4HxyHbKEOjUwlosyFckZ/uPaKAgAAJDYCAAANXAIAACrgAgAA3OACABCp1AP//0Rlg Date: Mon, 20 Jun 2016 16:30:16 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16792.1466433896@lawyers.icir.org> In-Reply-To: <16792.1466433896@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:30:42 -0000 Addressing solely this UDP item ... > What about UDP? I doubt you'll find the notions in 5405bis to be quite > right because they apply the rto-consider requirements to all > UDP-based protocols. The desired structure here (IMHO) is that the TCPM rto-consider draft states the general principles, and the TSVWG rfc5405bis draft applies them to UDP. Then individual UDP-based protocol drafts are expected to follow the guidance in rfc5405bis, or explain why there are good reasons for doing otherwise. > And, so, I think all the same arguments you're > making now would have to be applied there, too, and so we'll have to > go and write N more of these things for N UDP-based apps. =20 Not exactly - any UDP-based protocol RFC-to-be is going to have to reference rfc5405bis, as I'd expect the TSV ADs to Discuss drafts that don't ;-). The resulting RTO considerations will show up in each main protocol draft, not a small separate stand-alone draft. In practice, we'll probably see more cross-area interaction to head off this class of issue before it hits the IESG. FWIW, draft-ietf-forces-inter= felfb is a recently-worked example in the area of congestion considerations, and I do want to thank the responsible RTG AD (Alia) for noticing that the congestion concerns could use a bit more attention, and encouraging the draft authors to address them in advance of the draft going to the IESG= . Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Mark Allman > Sent: Monday, June 20, 2016 10:45 AM > To: Scharf, Michael (Nokia - DE) > Cc: tcpm@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) >=20 >=20 > > If [rto-consider] is IETF consensus, IMHO a 6298bis document would > > be a no-brainer in TCPM. >=20 > But, it isn't necessary. RFC 6298 is a document about *one* > algorithm. We could invent parallel algorithms. And, write an RFC > that specifies each. RFC 6298 just happens to be the only RTO we > have taken the bother to develop and write up. So, RFC 6298 (or a > bis) doesn't have to convey all of our TCP RTO understanding. It is > just one algorithm for doing it. >=20 > So, yeah, we can write a preamble to RFC 6298 that says "this agrees > with [rto-consider]", but that doesn't change the algorithm. It > isn't a technical change at all. It is more words in service of > what? A tidy---by some definition---document progression is all I > can come up with. It doesn't advance things in any meaningful way. >=20 > > One added value of 6298bis is that it applies the > > generic wording in [rto-consider] specifically to the TCP. I > > believe that this is simpler to read for a TCP implementer than to > > reverse-engineer protocol-agnostic wording in a draft that gets > > longer and longer to be protocol-agnostic (and likely will have to > > be further extended when it hits IETF last call)? >=20 > The whole thing hasn't really gotten much longer. And, it is still > quite short. And, I don't think that someone steeped in TCP will > have a difficult time reading the generic form of the requirements > there now. These are not particularly foreign concepts we're > talking about. >=20 > > So is your concern that nobody would invest cycles to author a > > 6298bis in TCPM? Or something equivalent e.g. for SCTP? >=20 > My concern is for doing work that just doesn't need to be done. How > many times do you want to re-state the same thing? TCP, SCTP. What > about UDP? I doubt you'll find the notions in 5405bis to be quite > right because they apply the rto-consider requirements to all > UDP-based protocols. And, so, I think all the same arguments you're > making now would have to be applied there, too, and so we'll have to > go and write N more of these things for N UDP-based apps. That's > saying the same thing a lot. And, God forbid if we ever had to > change something... >=20 > The point is that except for document series tidiness I have seen no > reason to make these requirements only apply to future specs---and > not implementations---as you advocate. >=20 > allman >=20 >=20 From nobody Mon Jun 20 09:35:58 2016 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 D116512D650; Mon, 20 Jun 2016 09:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 qEuh64FlejmJ; Mon, 20 Jun 2016 09:35:46 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 431A012D77E; Mon, 20 Jun 2016 09:35:46 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bF2An-0000AQ-N2; Mon, 20 Jun 2016 18:35:41 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.104]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bF2Am-0002lH-MC; Mon, 20 Jun 2016 18:35:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 20 Jun 2016 18:35:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 15 msgs/h 5 sum rcpts/h 15 sum msgs/h 5 total rcpts 43389 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D44EF8E5A0B4DDC7002F5832F45A733540B00FCB X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1352 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Magnus Westerlund , tsvwg , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:35:50 -0000 > On 20. jun. 2016, at 15.16, Black, David wrote: >=20 >>> But I=E2=80=99m less concerned than David about eventually ignoring = it for circuit >> breaker. >>>=20 >> Agree. Loss is the measurement that a CB MUST respond to. >=20 > Mumble. I would be ok with a clear discouragement for use of ECN-CE = marks, accompanied by the sort of design rationale here, or even better, = a clear statement that lost packets for the purpose of the RTP circuit = breaker have to be actually lost without getting into whether or not = ECN-CE marks are involved -i.e., the RTP circuit breaker is specified = against actual drops as a network protection backstop. >=20 > A related concern is that ECN marks may overstate equivalent loss = behavior - a simplistic queue management discipline that marks every = packet when the queue is over a threshold (NB: this class of marking = behavior is NOT RECOMMENDED - a real AQM SHOULD be used) could yield a = run of ECN-CE marks that would not cause a corresponding with a run of = packet drops. This is among the reasons that TCP reacts to ECN-CE = marks only once per RTT, and might be a reason to treat multiple ECN-CE = marks in an RTT interval as not representing drops of all packets for = the RTP circuit breaker's TCP-equivalent throughput calculation. I=E2=80=99m not sure we need such complicated logic to find a case where = ECN marks are different from packet drops: Basically, they simply aren=E2=80=99t - even =E2=80=9Creal=E2=80=9D AQMs = marking isn=E2=80=99t exactly the same as a packet drop: the marks = themselves inform you that an AQM did its job, and with modern AQMs like = CoDel / PIE etc., you=E2=80=99re probably getting this from a shallow = queue. Chances are that this is less than a BDP worth of queuing, which = is our justification for recommending a different back-off behavior in = draft-khademi-tsvwg-ecn-response-00 and = draft-khademi-tcpm-alternativebackoff-ecn-00 So the point is not that AQMs would treat ECN marking and dropping = differently - it=E2=80=99s that ECN indicates an AQM, and hence probably = a shallow queue. With a drop, you just don=E2=80=99t know. Back to the CB, I think an AQM marking at a shallow queue (like e.g. = CoDel) is indeed quite different from a =E2=80=9Cbroken connection=E2=80=9D= . Cheers, Michael >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] >> Sent: Saturday, June 18, 2016 2:23 AM >> To: Mirja K=C3=BChlewind >> Cc: Black, David; Magnus Westerlund; Colin Perkins; rtcweb@ietf.org; = IETF >> AVTCore WG; tsvwg >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: = draft-ietf- >> avtcore-rtp-circuit-breakers-16 >>=20 >> I think we SHOULD NOT recommend to use ECN marks as inputs to a CB. = See >> below: >>=20 >>> On 17 Jun 2016, at 16:02, Mirja K=C3=BChlewind = >> wrote: >>>=20 >>> +1 to not use normative language here. >>>=20 >>> However, please note that having a high level of ECN-CE marks = (without any >> losses) means that all packets were received correctly. This = situation can even >> occurs without high delays (depending on the AQM used), which would = just >> mean the services works perfectly. Therefore for me CE marks are a = perfect input >> signal for a congestion control loop (where the AQM tell the sender = to take action >> - whatever that means). >>=20 >> We may in future figure out ways to do this to detect significant = failure using a >> rate adaptive transport and ECN e.g. Observing 100% CE marks or = something, for >> an RTP flow that is trying to send well below its peak rate decided = by CC -- but I >> think this is speculating at an algorithm and adding details here is = not a good idea. >> Especially as AQM continues to evolve. >>=20 >>> But I=E2=80=99m less concerned than David about eventually ignoring = it for circuit >> breaker. >>>=20 >> Agree. Loss is the measurement that a CB MUST respond to. >>=20 >>> In addition one point on something Magnus wrote earlier: >>> "If the implementation only have circuit breaker, i.e. no full = fledged congestion >> controller and uses ECN, they can in worst case drive the buffer into = the overload >> regime where it starts dropping packets. =E2=80=9E >>>=20 >>> I=E2=80=99m not sure about this case. ECN is an input signal for = congestion control. If you >> don=E2=80=99t use congestion control but only a circuit breaker, you = should probably not >> enable ECN. At least it not clear to me why you would enable it, and = it's definitely >> not conform to the ECN spec. Probably we should say something about = this in the >> draft...? >>>=20 >> Agree, enabling ECN without a responsive CC is going to lead to = trouble. >>=20 >>> Mirja >>>=20 >> Gorry >>=20 >>>> Am 17.06.2016 um 16:03 schrieb Black, David : >>>>=20 >>>> Colin, >>>>=20 >>>>>>> ... I view the current text as providing implementers with too = much >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>>>>> want to think about this problem space in the first place). >>>>>=20 >>>>> I agree, but the argument is that doing so is less harmful than = deploying a >> circuit >>>>> breaker that triggers too often when ECN is used. >>>>>=20 >>>>> I=E2=80=99m not sure I believe this argument, though, since it = seems that any new >> AQM >>>>> that applies ECN marks much more often than at present will have = to >> consider >>>>> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe- >> tsvwg- >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >>>>> while existing implementations set ECT(0)). These compatibility = mechanisms >>>>> would seem to prevent the issues with the circuit breaker too. >>>>=20 >>>> That roughly matches my line of thinking, and I'll observe that the = original >> DCTCP >>>> protocol design that used more aggressive ECN-CE marking was only = safe for >>>> Controlled Environment deployments. See the TSVWG rfc5405bis = draft for >> the >>>> definition of Controlled Environment, and ignore the fact that the = rfc5405bis >>>> draft is a UDP draft - this definition is more broadly applicable. >>>>=20 >>>> Going back over Section 7 in this avtcore draft, my views are: >>>>=20 >>>> [A] None of these drafts justify a "MAY ignore" response to ECN-CE = marks: >>>> - draft-khademi-tcpm-alternativebackoff-ecn >>>> - draft-ietf-rmcat-nada >>>> - draft-ietf-rmcat-scream-cc >>>>=20 >>>> [B] In line with Colin's comment on the L4S draft, I think it's = incumbent on >>>> the authors of draft-briscoe-aqm-dualq-coupled to figure out how = that will >>>> coexist (or avoid) deployed TCP, and this avtcore draft ought not = to be >>>> trying to prejudge what will be done there. >>>>=20 >>>> So, I don't think the current text in Section 7 has justified the = unfettered >>>> "implementations MAY ignore ECN-CE marks" text, as ignoring those = marks >>>> is not consistent with any of the four cited drafts. >>>>=20 >>>> In more detail, I think making changes to normative requirements = here based >>>> on [B] is premature, and I would hope that the rmcat WG could be >> encouraged >>>> to consider the RTP circuit breaker in its congestion control = drafts, as those CC >>>> mechanisms are related to the circuit breaker mechanism, hence = likely >>>> to be in related areas of an RTP implementation. >>>>=20 >>>> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG >>>> will be looking at in Berlin. If a normative statement about = ECN-CE reaction >>>> is going to rest on that draft, then the reference to that draft = should be >>>> normative. Something about doing that strikes me as premature ... >>>>=20 >>>> I realize that we're trying to predict and accommodate the future, = which >>>> is an imprecise undertaking at best. As an alternative to the = current text, >>>> would it be reasonable to say (without any RFC 2119 keywords) that = the >>>> best current guidance is still to treat ECN-CE marks as indicating = drops, >>>> with a warning that there is a good possibility of this changing in = the >>>> near future due to all of the work in progress cited in Section 7? >>>>=20 >>>> Thanks, --David >>>>=20 >>>>> -----Original Message----- >>>>> From: Colin Perkins [mailto:csp@csperkins.org] >>>>> Sent: Friday, June 17, 2016 6:14 AM >>>>> To: John Leslie; Black, David >>>>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >>>>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: = draft-ietf- >>>>> avtcore-rtp-circuit-breakers-16 >>>>>=20 >>>>>=20 >>>>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>>>>=20 >>>>>> Black, David wrote: >>>>>>>=20 >>>>>>> ... I view the current text as providing implementers with too = much >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>>>>> want to think about this problem space in the first place). >>>>>=20 >>>>> I agree, but the argument is that doing so is less harmful than = deploying a >> circuit >>>>> breaker that triggers too often when ECN is used. >>>>>=20 >>>>> I=E2=80=99m not sure I believe this argument, though, since it = seems that any new >> AQM >>>>> that applies ECN marks much more often than at present will have = to >> consider >>>>> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe- >> tsvwg- >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >>>>> while existing implementations set ECT(0)). These compatibility = mechanisms >>>>> would seem to prevent the issues with the circuit breaker too. >>>>>=20 >>>>>> Understand, we have at least two proposals to make ECN-CE more >> frequent >>>>>> than packet drop would be for non-ECN packets: possibly = substantially >>>>>> more frequent. Unless both are killed off, ECN-CE will show up = frequently >>>>>> enough that closing the flow on ECN-CE would kill too many = connections. >>>>>>=20 >>>>>> If you want circuit-breaking on such connections, there are two = ways: >>>>>> 1. convince the forwarding nodes to drop packets if their queue = exceeds >>>>>> design capacity; or >>>>>> 2. require the sender to send enough not-ECN-capable packets so = that our >>>>>> receiver will see enough packet-drops when a circuit-breaker = should >>>>>> activate. >>>>>>=20 >>>>>> (I prefer the first option; but I wouldn't object to the second.) >>>>>>=20 >>>>>> There really isn't any way for our circuit-breaker to know = _how_much_ >>>>>> more frequent the ECN-CE marks may be. :^( >>>>>=20 >>>>> This is a problem, both for the circuit breaker, and for the = algorithms being >>>>> defined in RMCAT. We do need some understanding what the expected >> marking >>>>> rates are likely to be, so congestion control and circuit breakers = can be >> defined. >>>>>=20 >>>>>> We _will_ be sorry if we >>>>>> allot the same frequency of CE packets as packet-drops to trigger = the >>>>>> circuit-breaker. >>>>>>=20 >>>>>>> Could someone propose initial text to qualifies the current "MAY = ignore" >>>>>>> statement? >>>>>>=20 >>>>>> Essentially, for the second option, you might propose text to the >>>>>> effect of: >>>>>> ] >>>>>> ] If too many ECN-CE packets are received, the sender SHOULD send = some >>>>>> ] not-ECN-capable packets to determine whether enough packets = along the >>>>>> ] path are being dropped to justify activating our = circuit-breaker. >>>>>>=20 >>>>>> I=E2=80=99m not enthusiastic about adding that; but it would = resolve the issue. >>>>>=20 >>>>> I=E2=80=99m not convinced this would work. The circuit breaker is = looking at long term >>>>> trends, and in order to have enough not-ECT packets to determine = if it >> should >>>>> trigger, you=E2=80=99d essentially have to run without ECN for = some seconds. >>>>>=20 >>>>> -- >>>>> Colin Perkins >>>>> https://csperkins.org/ >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Jun 20 09:52:59 2016 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 BA5E912D587; Mon, 20 Jun 2016 09:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 XE4PSCc8yXIb; Mon, 20 Jun 2016 09:52:56 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413A212D581; Mon, 20 Jun 2016 09:52:56 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5KGqtfr012689; Mon, 20 Jun 2016 09:52:55 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9A4B14D48FDA; Mon, 20 Jun 2016 12:54:02 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DEC5B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Revolution X-URL-0: http://www.icir.org/mallman-files/Document95559.html X-URL-1: http://www.icir.org/mallman-files/Document90706.pdf X-URL-2: http://www.icir.org/mallman-files/Document60263.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 20 Jun 2016 12:54:02 -0400 Message-ID: <27581.1466441642@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:52:58 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > So, in my reading, [rto-consider] contradicts quite explicitly the > standards track specification of TCP. What do I miss here?=20 "Contradict" ... maybe. In the strict sense of the word. What it says is that we have learned things and figured out that only a subset of 6298 is necessary for network safety and so we can offer flexibility in the areas that are not as important for network safety. But, it doesn't alter or call into question the algorithm in 6298 and folks can readily use it as they always have. But, deviation from the precise details is also in some cases quite fine, as well. The usual thing we do is to learn and update things. We increase the initial cwnd recommendation (which obsoletes the previous recommendation). Or, we refine SACK-based loss recovery (which obsoletes the old scheme with new thinking). Or, whatnot. But, in this case we are saying simultaneously that (a) we can relax on the details and (b) the details of this one existing spec are still valid and fine. This is different than our Usual Case, I think. But, since we are not taking something and making it different or better this is not the Usual Case. We are saying is we have learned: - that there are a class of specific RTO mechanisms that are safe and fine, - that there is no one-size-fits-all in the class and=20 - that the class includes the old thing so we cannot simply replace it Instead of honing our view or changing our view we are broadening our view. And, this is (I guess) difficult. On the rest, I could reply. But, we know where each other stands at this point and you and I don't need to continue to circle. We simply disagree. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldoH6cACgkQWyrrWs4yIs5WsQCglNcNZhpS1P6B2WcmFh5s3Bm0 6+AAn2/wW56zV4l0l1EueZvq4S19jGC3 =BZFi -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jun 20 23:57:54 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D62412D111; Mon, 20 Jun 2016 23:57:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160621065753.30115.36804.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2016 23:57:53 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 06:57:53 -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 of the IETF. Title : Diffserv-Interconnection classes and practice Authors : Ruediger Geib David L. Black Filename : draft-ietf-tsvwg-diffserv-intercon-06.txt Pages : 21 Date : 2016-06-20 Abstract: This document defines a limited common set of Diffserv PHBs and codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and explains how this approach can simplify network configuration and operation. Many network providers operate MPLS using Treatment Aggregates for traffic marked with different Diffserv PHBs, and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short- Pipe tunnel mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-diffserv-intercon-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 21 00:23:51 2016 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 6B46012D61D for ; Tue, 21 Jun 2016 00:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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, RP_MATCHES_RCVD=-1.426] 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 Dbyzwg0yXXP3 for ; Tue, 21 Jun 2016 00:23:47 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7200412D1A7 for ; Tue, 21 Jun 2016 00:23:47 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 21 Jun 2016 09:23:44 +0200 X-IronPort-AV: E=Sophos;i="5.26,502,1459807200"; d="scan'208";a="903964688" Received: from he101654.emea1.cds.t-internal.com ([10.134.226.15]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 09:23:44 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101654.emea1.cds.t-internal.com (10.134.226.15) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Jun 2016 09:23:49 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Tue, 21 Jun 2016 09:23:48 +0200 From: To: Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-06.txt Thread-Index: AQHRy4pH9LnUF27ECUarDfDhIXhoGZ/zgYFA Date: Tue, 21 Jun 2016 07:23:48 +0000 Message-ID: <4016bae6ace54242824f00929d610270@HE101653.emea1.cds.t-internal.com> References: <20160621065753.30115.36804.idtracker@ietfa.amsl.com> In-Reply-To: <20160621065753.30115.36804.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.160.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-diffserv-intercon-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 07:23:50 -0000 R29ycnksDQoNCnRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gVGhlIGNoYW5nZXMgcHJvcG9zZWQg YnkgeW91IGhhdmUgYmVlbiBpbmNsdWRlZCBpbiB0aGUgdmVyc2lvbiBiZWxvdyAoYXMgZGlzY3Vz c2VkIGJ5IHRoZSBsaXN0IG9yIHByaXZhdGVseSBpbiB0aGUgY2FzZXMgd2hlcmUgd2UgaGFkIGEg ZGlzY3Vzc2lvbikuIEluIG9uZSBjYXNlLCBJIGNsYXJpZmllZCB0ZXh0IChCcm9hZGNhc3QgVmlk ZW8sIFJlYWwtVGltZSBJbnRlcmFjdGl2ZSBhbmQgTXVsdGltZWRpYSBDb25mZXJlbmNpbmcgYXJl IFJGQzQ1OTQgY2xhc3NlcykuDQoNClJlZ2FyZHMsIFJ1ZWRpZ2VyDQoNCg0KLS0tLS1VcnNwcsO8 bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNA aWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KR2VzZW5k ZXQ6IERpZW5zdGFnLCAyMS4gSnVuaSAyMDE2IDA4OjU4DQpBbjogaS1kLWFubm91bmNlQGlldGYu b3JnDQpDYzogdHN2d2dAaWV0Zi5vcmcNCkJldHJlZmY6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vydi1pbnRlcmNvbi0wNi50eHQNCg0KDQpBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFuc3BvcnQgQXJl YSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6 IERpZmZzZXJ2LUludGVyY29ubmVjdGlvbiBjbGFzc2VzIGFuZCBwcmFjdGljZQ0KICAgICAgICBB dXRob3JzICAgICAgICAgOiBSdWVkaWdlciBHZWliDQogICAgICAgICAgICAgICAgICAgICAgICAg IERhdmlkIEwuIEJsYWNrDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10c3Z3Zy1kaWZm c2Vydi1pbnRlcmNvbi0wNi50eHQNCglQYWdlcyAgICAgICAgICAgOiAyMQ0KCURhdGUgICAgICAg ICAgICA6IDIwMTYtMDYtMjANCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMg YSBsaW1pdGVkIGNvbW1vbiBzZXQgb2YgRGlmZnNlcnYgUEhCcyBhbmQNCiAgIGNvZGVwb2ludHMg KERTQ1BzKSB0byBiZSBhcHBsaWVkIGF0IChpbnRlciljb25uZWN0aW9ucyBvZiB0d28NCiAgIHNl cGFyYXRlbHkgYWRtaW5pc3RlcmVkIGFuZCBvcGVyYXRlZCBuZXR3b3JrcywgYW5kIGV4cGxhaW5z IGhvdyB0aGlzDQogICBhcHByb2FjaCBjYW4gc2ltcGxpZnkgbmV0d29yayBjb25maWd1cmF0aW9u IGFuZCBvcGVyYXRpb24uICBNYW55DQogICBuZXR3b3JrIHByb3ZpZGVycyBvcGVyYXRlIE1QTFMg dXNpbmcgVHJlYXRtZW50IEFnZ3JlZ2F0ZXMgZm9yIHRyYWZmaWMNCiAgIG1hcmtlZCB3aXRoIGRp ZmZlcmVudCBEaWZmc2VydiBQSEJzLCBhbmQgdXNlIE1QTFMgZm9yIGludGVyY29ubmVjdGlvbg0K ICAgd2l0aCBvdGhlciBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnQgb2ZmZXJzIGEgc2ltcGxlIGlu dGVyY29ubmVjdGlvbg0KICAgYXBwcm9hY2ggdGhhdCBtYXkgc2ltcGxpZnkgb3BlcmF0aW9uIG9m IERpZmZzZXJ2IGZvciBuZXR3b3JrDQogICBpbnRlcmNvbm5lY3Rpb24gYW1vbmcgcHJvdmlkZXJz IHRoYXQgdXNlIE1QTFMgYW5kIGFwcGx5IHRoZSBTaG9ydC0NCiAgIFBpcGUgdHVubmVsIG1vZGUu DQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLWRpZmZz ZXJ2LWludGVyY29uLw0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJs ZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWRpZmZz ZXJ2LWludGVyY29uLTA2DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXRzdndnLWRpZmZzZXJ2LWludGVyY29uLTA2DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQo= From nobody Tue Jun 21 00:32:23 2016 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 4936512D7F2 for ; Tue, 21 Jun 2016 00:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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, RP_MATCHES_RCVD=-1.426] 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 LP_pWg577MjO for ; Tue, 21 Jun 2016 00:32:19 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B69112D7EE for ; Tue, 21 Jun 2016 00:32:18 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 21 Jun 2016 09:32:11 +0200 X-IronPort-AV: E=Sophos;i="5.26,502,1459807200"; d="scan'208";a="903975159" Received: from he101659.emea1.cds.t-internal.com ([10.134.226.19]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 09:32:11 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101659.emea1.cds.t-internal.com (10.134.226.19) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Jun 2016 09:32:16 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Tue, 21 Jun 2016 09:32:15 +0200 From: To: Thread-Topic: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 Thread-Index: AdHCDchogAyx4sMnQ9q77258V6wqAgJgSvHw Date: Tue, 21 Jun 2016 07:32:15 +0000 Message-ID: <9584e9a07c444367ba9b7d28d9397f69@HE101653.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.160.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 07:32:22 -0000 David, I support adaption. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Black, David Gesendet: Donnerstag, 9. Juni 2016 07:14 An: tsvwg@ietf.org Betreff: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - throug= h June 25 This is a TSVWG call for interest in WG adoption of draft-szigeti-tsvwg-iee= e-802-11. If you have read the draft and support WG adoption of it as a work item and= WG draft, please send an email to the list (tsvwg@ietf.org) saying so. NB: It is important to say that you've read the draft. If you're willing t= o review/comment on future versions of this draft and/or implement this dra= ft, please say so on the list or in email directly to the chairs (tsvwg-cha= irs@ietf.org). Authors: We (chairs) assume that you support WG adoption of your draft, so = there's no need to say so on the list. However, we do need each author to = publicly state on the list that their direct, personal knowledge (if any) o= f any IPR related to this document has already been disclosed, in conforman= ce with BCPs 78 and 79. This adoption call will run for about 2 weeks, ending at midnight, prevaili= ng US Eastern Time on Saturday June 25. To get things started, I hereby st= ate as an individual that I have read the draft and support WG adoption of = it. Guidelines for DiffServ to IEEE 802.11 Mapping draft-szigeti-tsvwg-ieee-802-11-01 Abstract As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This is due to the fact that two independent standards bodies provide QoS guidance on wired and wireless networks: specifically, the IETF specifies standards and design recommendations for wired IP networks, while a separate and autonomous standards- body, the IEEE, administers the standards for wireless 802.11 networks. The purpose of this document is to propose a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by these two standards bodies, and, as such, to optimize wired-and-wireless interconnect QoS. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 david.black@emc.com ---------------------------------------------------- From nobody Thu Jun 23 07:14:00 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0A12B013; Thu, 23 Jun 2016 07:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623141359.31233.80433.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 07:13:59 -0700 Archived-At: Subject: [tsvwg] The TSVWG WG has placed draft-szigeti-tsvwg-ieee-802-11 in state "Call For Adoption By WG Issued" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:13:59 -0000 The TSVWG WG has placed draft-szigeti-tsvwg-ieee-802-11 in state Call For Adoption By WG Issued (entered by Gorry Fairhurst) The document is available at https://datatracker.ietf.org/doc/draft-szigeti-tsvwg-ieee-802-11/ Comment: To end June 25th 2016 From nobody Thu Jun 23 07:39:51 2016 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 956E412D0DA for ; Thu, 23 Jun 2016 07:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 KB_P9Njiyu18 for ; Thu, 23 Jun 2016 07:39:46 -0700 (PDT) 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 6F6EF126B6D for ; Thu, 23 Jun 2016 07:39:46 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id A3EFD1B001C2 for ; Thu, 23 Jun 2016 15:39:43 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 23 Jun 2016 15:39:45 +0100 Message-ID: Date: Thu, 23 Jun 2016 15:39:45 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [tsvwg] WGLC for draft-ietf-tsvwg-diffserv-intercon - to end 10th July 2016 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:39:49 -0000 This email announces a TSVWG Working Group Last Call (WGLC) on: Diffserv-Interconnection classes and practice Intended status: Informational https://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-06 This WGLC will run for 2 weeks, ending on 10th July 2016. The results of the WGLC will be presented at the Berlin IETF meeting. Comments should be sent to the tsvwg@ietf.org list. Please cc: the WG chairs at tsvwg-chairs@ietf.org to track your comments as part of the WGLC process. As part of this WGLC, comments are requested on the usability of this draft, and the relation to published RFCs. Thanks, Gorry (TSVWG Co-Chair) From nobody Thu Jun 23 07:47:12 2016 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 1202912D14B for ; Thu, 23 Jun 2016 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 NGp_Py_SC74b for ; Thu, 23 Jun 2016 07:47:08 -0700 (PDT) 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 9B8D012D0D9 for ; Thu, 23 Jun 2016 07:47:08 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id C70EC1B001C2 for ; Thu, 23 Jun 2016 15:47:05 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 23 Jun 2016 15:47:07 +0100 Message-ID: Date: Thu, 23 Jun 2016 15:47:07 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [tsvwg] Please tell us if you have new work or would like to present a draft in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 14:47:10 -0000 Hi tsvwg'ers, This is a request for people to offer presentations on drafts they would like to be presented to the tsvwg working group at the Berlin IETF. Priority will be assigned to time that progresses WG drafts, to bring individual drafts to the attention of the WG and (in least order of priority) to describe new work relevant to the TSVWG Charter. Please send all requests and any corrections to the chairs asap, and we'll publish a preliminary meeting agenda. Gorry and David (tsvwg co-chairs) From nobody Thu Jun 23 09:38:42 2016 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 7AAF612B065 for ; Thu, 23 Jun 2016 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.946 X-Spam-Level: X-Spam-Status: No, score=-115.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 oYbrtNL7oJ5T for ; Thu, 23 Jun 2016 09:38:39 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D397B12B037 for ; Thu, 23 Jun 2016 09:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2455; q=dns/txt; s=iport; t=1466699918; x=1467909518; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iHwHLl1xcJA3QEqi9bbb8xCwzgWdTgOQkjaxPRnwLtg=; b=gRpc4lvXtnUw0mHM62HUH0Ate5R+p0OwgsvET90YOt3sR4l6UDJhkqwU eJAmRKzeCkqzB64tAz8Xla08hiOoMkDT4N9YJjxlD7vhq8yHplZG7Yz3T pWqfxmf0yRnQKaBDe9JsLDak3Mtosjnn37Kj+h84wpUnIfU6Iv1iiBth0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAgBAEGxX/4kNJK1dgz6BUwa1M4UBg?= =?us-ascii?q?XqGGAKBLDgUAQEBAQEBAWUnhE0BAQQdXBACAQgEAUEyFBECBA4FiDDHDAEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyIHgiCToE5glkRAYNIgi8FmH8BiDuFdYFphFODL?= =?us-ascii?q?oU6j30BHjaCFYFbbohvNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,517,1459814400"; d="scan'208,217";a="287357297" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2016 16:38:38 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5NGcbOp025270 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jun 2016 16:38:38 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 23 Jun 2016 12:38:37 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Thu, 23 Jun 2016 12:38:37 -0400 From: "Cullen Jennings (fluffy)" To: "Black, David" Thread-Topic: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 Thread-Index: AQHRzW2w40Tn72uFVEWIrEdk7dqyHQ== Date: Thu, 23 Jun 2016 16:38:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: multipart/alternative; boundary="_000_FA73E76812D64FD4967184F9FC2766ADciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June 25 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 16:38:40 -0000 --_000_FA73E76812D64FD4967184F9FC2766ADciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The authors and I discussed some changes to address all of my comments on t= his draft. I strongly support adoptions of this draft - the industry needs some common= default behavior on theses mappings and we need them sooner rather than la= ter. On Jun 8, 2016, at 11:14 PM, Black, David wrote: This is a TSVWG call for interest in WG adoption of draft-szigeti-tsvwg-iee= e-802-11. If you have read the draft and support WG adoption of it as a work item and WG draft, please send an email to the list (tsvwg@ietf.org) saying so. NB: It is important to say that you've read the draft. If you're willing to review/comment on future versions of this draft and/or implement this draft, please say so on the list or in email directly to the chairs (tsvwg-chairs@ietf.org). --_000_FA73E76812D64FD4967184F9FC2766ADciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The authors and I discussed some changes to address all of my comments on t= his draft.

I strongly support adoptions of this draft - the industry needs some common= default behavior on theses mappings and we need them sooner rather than la= ter.


On Jun 8, 2016, at 11:14 PM, Black, David <dav= id.black@emc.com> wrote:

This is a TSVWG call for interest in WG adoption of draft-szigeti-tsvwg-iee= e-802-11.
If you have read the draft and support WG adoption of it as a work item
and WG draft, please send an email to the list (tsvwg@ietf.org) saying so.<= br>
NB: It is important to say that you've read the draft.  If you're will= ing
to review/comment on future versions of this draft and/or implement this draft, please say so on the list or in email directly to the chairs
(tsvwg-chairs@ietf.org).

--_000_FA73E76812D64FD4967184F9FC2766ADciscocom_-- From nobody Thu Jun 23 20:34:06 2016 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 4CE7112D87D; Thu, 23 Jun 2016 20:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hfXPp4O2hNqY; Thu, 23 Jun 2016 20:34:03 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 31CE312D548; Thu, 23 Jun 2016 20:34:03 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id t190so34803471pfb.3; Thu, 23 Jun 2016 20:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fdT/VPKsG15OMa72yek7lNQDuThvM5ydWnQZkgbIQ6A=; b=v0vqFQjpGqEJ6x4VD4r5vWGRY8dxwk5TIAts3L+r0fKP04aJJW2jhhRg44PZXGqzXD wbLmxv4ExJ+el2IQElTToM1Oo5uG6eA1VCnxJzEWdyXhbUzT45spxh+Vo5PMzDofZEU6 sJFzA6C4y2WKKDvr3KkvN3aWinIlXFSB7IWznC0Z6a+psbVYv8gpv5t7u74ZdVAR9M3N PD17USiTJSjOn4a5clGzxB7ye5PLAlMzPXraZJ4f/2xWGP2oAmuHOPVbn5JyHnU6iCCd ZA7PzpmODKhuQmvn6GZasxtRQwaghEeZLYjNJFwnbquLXPLy7sjdTTOAs59due4fs5L3 KF5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=fdT/VPKsG15OMa72yek7lNQDuThvM5ydWnQZkgbIQ6A=; b=bdYhYbxbV6NHQvSPWHaSo5UNF6oxccabHto7N76qaJhClOelOKz8G35OYDFxk7S08x QqgacQewzxtSjE+LHc327hbZ5nGw0iCnG6mZQM5Wp6+5hamCrnrypdP9o2+pOPhiHL1C nzq8jzY2CAnOEYJ7HNb6SZ3VLjwuNJWUxlKM3/mdYKLDEBdK2jpnMrKoS1DaG6ZemJ54 d15OZ0BxXDIhwMX4AW7ubmBmSV7KtvCweho2XY33QRqzuIci/XkW1KNyhQcrnSejpkrJ +h+GKUXIxJKj3EfQW8YaarSIijzsCBq6O3NxwwaZx89ATvHRhh40mt6rXg45XXUrazUN VcTw== X-Gm-Message-State: ALyK8tL3MOBX4GtQdjGIuhaO00+7FuCl8n3hqe1qnjGnuwqmmxx6j9eb6hYpqmtSsdNTHg== X-Received: by 10.98.149.149 with SMTP id c21mr3251528pfk.73.1466739242607; Thu, 23 Jun 2016 20:34:02 -0700 (PDT) Received: from [192.168.178.23] (210.223.47.163.dynamic.snap.net.nz. [163.47.223.210]) by smtp.gmail.com with ESMTPSA id 203sm3304351pfz.35.2016.06.23.20.34.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 20:34:01 -0700 (PDT) To: tsvwg@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <124e9c95-2cb4-d9ee-5555-5de6e5d94874@gmail.com> Date: Fri, 24 Jun 2016 15:34:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: tsvwg-chairs@ietf.org Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-diffserv-intercon - to end 10th July 2016 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 03:34:05 -0000 I've been tracking this document since its inception. IMHO it is ready for publication and should be of considerable value to operators, especially if RTCWEB gets off the ground. I think it correctly fits in with the other diffserv-related RFCs. Regards Brian Carpenter On 24/06/2016 02:39, gorry@erg.abdn.ac.uk wrote: > > This email announces a TSVWG Working Group Last Call (WGLC) on: > > Diffserv-Interconnection classes and practice > Intended status: Informational > https://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-06 > > This WGLC will run for 2 weeks, ending on 10th July 2016. The results > of the WGLC will be presented at the Berlin IETF meeting. > > Comments should be sent to the tsvwg@ietf.org list. Please cc: the WG > chairs at tsvwg-chairs@ietf.org to track your comments as part of the WGLC > process. > > As part of this WGLC, comments are requested on the usability of this > draft, and the relation to published RFCs. > > Thanks, Gorry > (TSVWG Co-Chair) > > > From nobody Fri Jun 24 05:17:15 2016 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 44A2D12D77E for ; Fri, 24 Jun 2016 05:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 0LNOAEFu5ZDD for ; Fri, 24 Jun 2016 05:17:12 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 01EA012D600 for ; Fri, 24 Jun 2016 05:17:11 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bGQ2n-0004E3-Jb for tsvwg@ietf.org; Fri, 24 Jun 2016 14:17:09 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bGQ2m-000790-Vf for tsvwg@ietf.org; Fri, 24 Jun 2016 14:17:09 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 24 Jun 2016 14:17:07 +0200 To: tsvwg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 43629 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.4, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.359, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DE1946695B08D1216E0AEE2BB3BF3671EC7191D9 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -73 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10614 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 12:17:15 -0000 Dear all, We recently did DSCP related measurements that lead us to propose a = change to draft-ietf-tsvwg-rtcweb-qos. These measurements are reported in this paper: = http://heim.ifi.uio.no/~michawe/research/publications/anrw16-measurement.p= df ... which will be presented at the ANRW workshop, the Saturday before = the IETF meeting. The paper reports on tests between people's homes and 3 servers that we = ran - one in Oregon (amazon cloud) and two in Norway. This gave us 185 = distinct paths (IP address pairs). The test was a TCP handshake, done = with raw sockets, and we played around with values in the IP header. = Meanwhile, Runa (main author) did some more tests from various public = places during a trip from Norway to India, essentially confirming the = finding we discuss here; we'll ask for a slot to report about both the = data in the ANRW paper and the newer data in the MAPRG session. The number of data points isn't exactly huge in both cases, but still = relevant, we believe: it is about a persistent failure that we saw on = different paths, and so we think it's probably reasonable to take it = into account (given that a fix shouldn't be very complicated either). We used, as input, DSCP values from the table in = draft-ietf-tsvwg-rtcweb-qos. Here are some sentences copy + pasted from our paper: *** "To minimize the chance that congestion-based drops make us believe in a = failure to communicate using certain values in the IP header, we re-tried failed = packet exchanges up to three times, and we sent an ICMP packet just ahead of = every measurement packet. We only assumed a communication failure when the = test failed three times and the ICMP packet succeeded." "Considering table 1 in [6], we assumed the flow type =E2=80=9CInteractive= Video with or without Audio=E2=80=9D with application priorities =E2=80=9CVery low=E2=80= =9D (DSCP value CS1 (8)), =E2=80=9CLow=E2=80=9D (DF (0)) or =E2=80=9CMedium=E2=80=9D (AF42 (36)), and flow type = =E2=80=9CAudio=E2=80=9D with application prioritiy =E2=80=9CHigh=E2=80=9D (EF PHB (46))." "We did see consistent packet drops too: on 23 paths for DSCP value 8, = 21 paths for 36, 19 for 46." *** We also saw DSCP value changes, but nothing very alarming there - in one = case, AF42 was changed to AF41, which is even nice :) however, this = consistent drop behavior that appears only when using a DSCP value !=3D = 0 isn't good at all. Now these things could in principle have happened = close to our 3 servers, meaning there were only few devices that did it, = but in fact this measurement was a part of a larger measurement campaign = in which we also checked where such packet drops typically happened. The = result was: most such drops seem to be close to the client, which may = indicate that there were in fact multiple such boxes. We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting the = DSCP values as proposed here consistently produces packet drops, senders = should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP. Cheers, Michael From nobody Fri Jun 24 09:09:30 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 395A312DC8A; Fri, 24 Jun 2016 09:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160100.10933.4425.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:01:00 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] tsvwg - Requested sessions have been scheduled for IETF 96 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:01:01 -0000 Dear Gorry Fairhurst, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tsvwg Session 1 (2:00:00) Friday, Morning Session I 1000-1200 Room Name: Bellevue size: 200 --------------------------------------------- tsvwg Session 2 (1:30:00) Wednesday, Afternoon Session II 1550-1720 Room Name: Charlottenburg II/III size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: tsvarea iccrg aqm rmcat rtcweb tcpm mptcp nvo3 dclcrg taps ippm opsawg opsarea intarea Second Priority: v6ops tram tcpinc nfsv4 dispatch Third Priority: ccamp artarea precis Special Requests: [If rtcweb has 2 sessions, 1 must not conflict] [Must not conflict with Transport Area BoFs] --------------------------------------------------------- From nobody Fri Jun 24 13:25:15 2016 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 4D29612D5D8 for ; Fri, 24 Jun 2016 13:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XACW8pGjDD2S for ; Fri, 24 Jun 2016 13:25:11 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 3A24F12D1C2 for ; Fri, 24 Jun 2016 13:25:11 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id b13so40388580pat.0 for ; Fri, 24 Jun 2016 13:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=htukJ5klfbZDQBrRwnefBUn9N0S5y16d6Ot2oFW8Lto=; b=B2S5+p06O7NSmTbSZsrM7HYlhQnbdCqFahoyohZRJFV48uOxH195OdDDdwbxqUEqp5 mrW+M2py6u0x/WZDNaYHLGLcrhQu6pBsXjyYJ8ZMwLGHWTSAK9zFYS/MoynP0ey7d+i2 bY4CfJc7NH76uoURQZRdxeoLctISG1SfvBnr5s5pk0N7nCu+C8Hrp/D64hT24IdhRpsH 2COje5hma3+0C9R1JoCg9PqAQfOy9x4HOhpyUiH0SwNiPkV+wIiR3DWecIJEGt5OV8nc 8ijrHFQMIzp+1SyQY1nilpoiuvG13SA4kcjelR8i7YYFkQnZIR83+Rb1AG0FumNpCg6b DE4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=htukJ5klfbZDQBrRwnefBUn9N0S5y16d6Ot2oFW8Lto=; b=gAfs64p7+OsKjnMevmawO2n0kaEaZPMvu6PG4y2dgtLGpzsHozX/5pmc6NBJczASO7 Up0eIZPVx8JeKtyITpRKaNdkJX43vLKPTsSU3CSMqaNkmEexkvvddGq8QLzg9AyPWfN+ wGPwntpyZPT37fr9UiLXb3a2k2DnZ2k5QARZ7TIotAxHhfqTgcvY4042AD0dzAja/MrA bJAGFIFO7MFetAOv9QOGlRWY0FBarqwrZJaG1SgvpyssW27vA6UBqDJ1BP1L+pG1CLlj uBwdNQj9Jto0HKAXPVCvYfU+ufJd01yUEwu2vX7zcNziqtGl3v57qxsIQb0n+JyMxsoG 1jLA== X-Gm-Message-State: ALyK8tJ8d4lC4X8YPcg0gQr4C1afbYPxyYCG5XM/x8t41ZK3AvIJv1KxPwpk6F8kaCkQ1g== X-Received: by 10.66.85.197 with SMTP id j5mr10857182paz.87.1466799910726; Fri, 24 Jun 2016 13:25:10 -0700 (PDT) Received: from [192.168.178.23] ([118.148.79.95]) by smtp.gmail.com with ESMTPSA id i124sm2065174pfg.77.2016.06.24.13.25.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jun 2016 13:25:10 -0700 (PDT) To: Michael Welzl , tsvwg@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 25 Jun 2016 08:25:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:25:13 -0000 > We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting the = DSCP values as proposed here consistently produces packet drops, senders = should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP. This is an interesting and worrying result indeed, but it's in no way spe= cific to WebRTC. I think a generic RFC ("Happy Eyeballs with Differentiated Ser= vices"?) would be the way to go. But (as with a lot of recent discussion about IPv= 6 extension headers causing packet drops) we really need to understand why = this happens. Is it traffic policing that fails to reclassify and re-mark pack= ets, misguided firewalls, or what? Regards Brian On 25/06/2016 00:17, Michael Welzl wrote: > Dear all, >=20 > We recently did DSCP related measurements that lead us to propose a cha= nge to draft-ietf-tsvwg-rtcweb-qos. > These measurements are reported in this paper: > http://heim.ifi.uio.no/~michawe/research/publications/anrw16-measuremen= t.pdf > ... which will be presented at the ANRW workshop, the Saturday before t= he IETF meeting. >=20 > The paper reports on tests between people's homes and 3 servers that we= ran - one in Oregon (amazon cloud) and two in Norway. This gave us 185 d= istinct paths (IP address pairs). The test was a TCP handshake, done with= raw sockets, and we played around with values in the IP header. Meanwhil= e, Runa (main author) did some more tests from various public places duri= ng a trip from Norway to India, essentially confirming the finding we dis= cuss here; we'll ask for a slot to report about both the data in the ANRW= paper and the newer data in the MAPRG session. >=20 > The number of data points isn't exactly huge in both cases, but still r= elevant, we believe: it is about a persistent failure that we saw on diff= erent paths, and so we think it's probably reasonable to take it into acc= ount (given that a fix shouldn't be very complicated either). >=20 > We used, as input, DSCP values from the table in draft-ietf-tsvwg-rtcwe= b-qos. > Here are some sentences copy + pasted from our paper: >=20 > *** > "To minimize the chance that congestion-based drops make us believe in = a failure > to communicate using certain values in the IP header, we re-tried faile= d packet > exchanges up to three times, and we sent an ICMP packet just ahead of e= very > measurement packet. We only assumed a communication failure when the te= st > failed three times and the ICMP packet succeeded." >=20 > "Considering table 1 in [6], we assumed the flow type =E2=80=9CInteract= ive Video with or > without Audio=E2=80=9D with application priorities =E2=80=9CVery low=E2= =80=9D (DSCP value CS1 (8)), =E2=80=9CLow=E2=80=9D > (DF (0)) or =E2=80=9CMedium=E2=80=9D (AF42 (36)), and flow type =E2=80=9C= Audio=E2=80=9D with application prioritiy > =E2=80=9CHigh=E2=80=9D (EF PHB (46))." >=20 > "We did see consistent packet drops too: on 23 paths for DSCP value 8, = 21 paths > for 36, 19 for 46." > *** >=20 > We also saw DSCP value changes, but nothing very alarming there - in on= e case, AF42 was changed to AF41, which is even nice :) however, thi= s consistent drop behavior that appears only when using a DSCP value !=3D= 0 isn't good at all. Now these things could in principle have happened c= lose to our 3 servers, meaning there were only few devices that did it, b= ut in fact this measurement was a part of a larger measurement campaign i= n which we also checked where such packet drops typically happened. The r= esult was: most such drops seem to be close to the client, which may indi= cate that there were in fact multiple such boxes. >=20 > We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting the = DSCP values as proposed here consistently produces packet drops, senders = should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP. >=20 > Cheers, > Michael >=20 >=20 From nobody Fri Jun 24 13:36:50 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD6112D6B9; Fri, 24 Jun 2016 13:36:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624203643.10825.16557.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 13:36:43 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-szigeti-tsvwg-ieee-802-11-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:36: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 of the IETF. Title : Guidelines for DiffServ to IEEE 802.11 Mapping Authors : Tim Szigeti Fred Baker Filename : draft-szigeti-tsvwg-ieee-802-11-02.txt Pages : 27 Date : 2016-06-24 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This is due to the fact that two independent standards bodies provide QoS guidance on wired and wireless networks: specifically, the IETF specifies standards and design recommendations for wired IP networks, while a separate and autonomous standards- body, the IEEE, administers the standards for wireless 802.11 networks. The purpose of this document is to propose a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by these two standards bodies, and, as such, to optimize wired-and-wireless interconnect QoS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-szigeti-tsvwg-ieee-802-11/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-szigeti-tsvwg-ieee-802-11-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-szigeti-tsvwg-ieee-802-11-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 Fri Jun 24 13:52:25 2016 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 6178012D743 for ; Fri, 24 Jun 2016 13:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Qx4Zmdb92QnB for ; Fri, 24 Jun 2016 13:52:20 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D0112D740 for ; Fri, 24 Jun 2016 13:52:20 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bGY5K-0002ou-D9; Fri, 24 Jun 2016 22:52:18 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.104]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bGY5J-0006wj-Dp; Fri, 24 Jun 2016 22:52:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Fri, 24 Jun 2016 22:52:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> References: To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 7 sum msgs/h 2 total rcpts 43645 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 37D56A7882846199FE7C64C79238BE23BABB2BD3 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1442 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:52:23 -0000 Hi, > On 24. jun. 2016, at 22.25, Brian E Carpenter = wrote: >=20 >> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting = the DSCP values as proposed here consistently produces packet drops, = senders should fall back to DSCP 0. WebRTC shouldn't "fail" because of = the DSCP. >=20 > This is an interesting and worrying result indeed, but it's in no way = specific > to WebRTC. I think a generic RFC ("Happy Eyeballs with Differentiated = Services"?) > would be the way to go. Well, if you use the DSCP within your own administrative domain for = DiffServ, you should be safe=E2=80=A6. so I guess this problem mostly = matters for usage across domains, or even end-to-end. =3D> It seems to me that it=E2=80=99s broader than WebRTC in exactly the = same way as RFC7657 is broader than WebRTC.=20 As a side note, I think the term =E2=80=9CHappy Eyeballs=E2=80=9D is = misleading here. This term, to me, indicates parallel usage of multiple = packet types to see which one(s) succeed(s) and then try to make the = best choice. This isn=E2=80=99t what you would do here - we=E2=80=99re talking about = a rare failure situation. It=E2=80=99s really only something I=E2=80=99d = suggest as a fall-back, upon seeing communication failing entirely, over = a longer period (perhaps in line with a circuit-breaker). > But (as with a lot of recent discussion about IPv6 > extension headers causing packet drops) we really need to understand = why this > happens. Is it traffic policing that fails to reclassify and re-mark = packets, > misguided firewalls, or what? I have no clue=E2=80=A6 but as my previous email said, we have = indications that this behavior occurred close to the senders (most of = them being in people=E2=80=99s homes), hence it=E2=80=99s more likely = that this was done by a middlebox or an edge router than by a core = router. That=E2=80=99s as much as we know... Cheers, Michael >=20 > Regards > Brian >=20 > On 25/06/2016 00:17, Michael Welzl wrote: >> Dear all, >>=20 >> We recently did DSCP related measurements that lead us to propose a = change to draft-ietf-tsvwg-rtcweb-qos. >> These measurements are reported in this paper: >> = http://heim.ifi.uio.no/~michawe/research/publications/anrw16-measurement.p= df >> ... which will be presented at the ANRW workshop, the Saturday before = the IETF meeting. >>=20 >> The paper reports on tests between people's homes and 3 servers that = we ran - one in Oregon (amazon cloud) and two in Norway. This gave us = 185 distinct paths (IP address pairs). The test was a TCP handshake, = done with raw sockets, and we played around with values in the IP = header. Meanwhile, Runa (main author) did some more tests from various = public places during a trip from Norway to India, essentially confirming = the finding we discuss here; we'll ask for a slot to report about both = the data in the ANRW paper and the newer data in the MAPRG session. >>=20 >> The number of data points isn't exactly huge in both cases, but still = relevant, we believe: it is about a persistent failure that we saw on = different paths, and so we think it's probably reasonable to take it = into account (given that a fix shouldn't be very complicated either). >>=20 >> We used, as input, DSCP values from the table in = draft-ietf-tsvwg-rtcweb-qos. >> Here are some sentences copy + pasted from our paper: >>=20 >> *** >> "To minimize the chance that congestion-based drops make us believe = in a failure >> to communicate using certain values in the IP header, we re-tried = failed packet >> exchanges up to three times, and we sent an ICMP packet just ahead of = every >> measurement packet. We only assumed a communication failure when the = test >> failed three times and the ICMP packet succeeded." >>=20 >> "Considering table 1 in [6], we assumed the flow type =E2=80=9CInteract= ive Video with or >> without Audio=E2=80=9D with application priorities =E2=80=9CVery = low=E2=80=9D (DSCP value CS1 (8)), =E2=80=9CLow=E2=80=9D >> (DF (0)) or =E2=80=9CMedium=E2=80=9D (AF42 (36)), and flow type = =E2=80=9CAudio=E2=80=9D with application prioritiy >> =E2=80=9CHigh=E2=80=9D (EF PHB (46))." >>=20 >> "We did see consistent packet drops too: on 23 paths for DSCP value = 8, 21 paths >> for 36, 19 for 46." >> *** >>=20 >> We also saw DSCP value changes, but nothing very alarming there - in = one case, AF42 was changed to AF41, which is even nice :) however, = this consistent drop behavior that appears only when using a DSCP value = !=3D 0 isn't good at all. Now these things could in principle have = happened close to our 3 servers, meaning there were only few devices = that did it, but in fact this measurement was a part of a larger = measurement campaign in which we also checked where such packet drops = typically happened. The result was: most such drops seem to be close to = the client, which may indicate that there were in fact multiple such = boxes. >>=20 >> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting = the DSCP values as proposed here consistently produces packet drops, = senders should fall back to DSCP 0. WebRTC shouldn't "fail" because of = the DSCP. >>=20 >> Cheers, >> Michael >>=20 >>=20 >=20 From nobody Sat Jun 25 07:12:51 2016 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 B143B12B025; Sat, 25 Jun 2016 07:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 DjjHq7z2RcJS; Sat, 25 Jun 2016 07:12:45 -0700 (PDT) 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 9323412D0C3; Sat, 25 Jun 2016 07:07:06 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 4096A1B0025B; Sat, 25 Jun 2016 15:06:59 +0100 (BST) Message-ID: <576E9003.8050806@erg.abdn.ac.uk> Date: Sat, 25 Jun 2016 15:06:59 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mallman@icir.org References: <27581.1466441642@lawyers.icir.org> In-Reply-To: <27581.1466441642@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org" , "Scharf, Michael \(Nokia - DE\)" , "tsvwg@ietf.org" Subject: [tsvwg] My comments on draft-ietf-tcpm-rto-consider-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 14:12:47 -0000 https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-04 I have previously made many comments on the text in rev-03 of this draft, and after a careful read, I'd like to now note that in large part, rev -04 addresses my concerns regarding scope and applicability. There still appears to be a global scope for the document as “ SHOULD” in (R.2), and then a nested “MUST” within that “SHOULD”. I see others have also noted this, but I'd prefer an AD or someone with more insight into RFC2119 to decide on this. Likewise, I understand TCPM needs to decide upon the set of requirements for TCP, and TSVWG for SCTP and UDP. That said, I'd thank Mark for his heavy work to make this more applicable. A small number of comments follow. Gorry --- Comments on draft-ietf-tcpm-rto-consider-04 Section 1. This sentence is rather cumbersome to read: OLD: However, despite our best intentions and most robust mechanisms, the only thing we can truly depend on is the passage of time and therefore our ultimate backstop to ensuring reliability is a timeout and re-try mechanism. Is it worth considering reordering the thoughts, say: NEW: However, despite our best intentions and most robust mechanisms, the ultimate backstop to ensuring reliability is a timeout and re-try mechanism, because the only thing we can truly depend on is the passage of time. — /a for/ OLD: protocol-agnostic requirements for RTO mechanisms that provide a for network safety. NEW: OLD: protocol-agnostic requirements for RTO mechanisms that provide network safety. —— Section 2: NiT: Is it worth replacing “must” with needs to, or deciding this actually is a requirement and then using RFC2119 MUST. I’d be happy either way, but don’t think “MUST” fits in this section either. OLD: independently. I.e., if host A communicates with hosts B and C, A must use independent RTOs for traffic sent to B and C. NEW: independently. I.e., if host A communicates with hosts B and C, A needs to use independent RTOs for traffic sent to B and C. — OLD: "like UDP-based DNS []" - missing reference. --- OLD: than the 1 second specified in [RFC6298]. While the implication of these deviations from the standard may be more spurious retransmits (per [AP99]), we are aware of no large scale problems caused by this change to the minimum RTO.” - I do not see the wisdom in the last clause. As an example there have been issues (albeit a time ago with a RTO less than 1 second being the default - I think in,one version of Solaris) that resulted in TCP having much degraded throughput over paths with a RTT greater than the RTO. A small initial RTO may still be a problem (e.g., when traffic after a failure is routed over a backup path), and I suggest this is not a case we should advocate. Indeed, this ID currently makes a requirement that: "RTO MUST be conservatively set to no less than 1 second”, which to me seems a correct interpretation of the RFC-series, so why does the sentence above appear to suggest otherwise? --- From nobody Sun Jun 26 07:52:01 2016 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 800BF12B036; Sun, 26 Jun 2016 07:52:00 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 rOwg_rztvBCj; Sun, 26 Jun 2016 07:51:58 -0700 (PDT) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 29D1912B024; Sun, 26 Jun 2016 07:51:57 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 01A114425D; Sun, 26 Jun 2016 16:51:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id 7GmJ7GLgIu_c; Sun, 26 Jun 2016 16:51:49 +0200 (CEST) Date: Sun, 26 Jun 2016 16:51:48 +0200 From: Hagen Paul Pfeifer To: "tcpm@ietf.org" Message-ID: <20160626145148.GA9627@virgo.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 Archived-At: Cc: "tsvwg@ietf.org" Subject: [tsvwg] Linux TCP RTO X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2016 14:52:00 -0000 For the fellows not constantly following the Linux kernel maillinglist: we are currently try to adjust Linux's TCP RTO behavior to implement a RFC 6298 compliant calculation[1]: https://www.mail-archive.com/netdev@vger.kernel.org/msg114487.html We wrote an small document where we highlighted the current Linux implementation, validated our 6298 compliant implementation and presented measurements comparing both mechanisms: https://docs.google.com/document/d/1pKmPfnQb6fDK4qpiNVkN8cQyGE4wYDZukcuZfR-BnnM Yuchung tested the modification in large scale at Googles web servers (HTTP, HTTP2) and first results looks promising: https://www.mail-archive.com/netdev@vger.kernel.org/msg116052.html Hagen [1] some aspects of Linux differs too much to implement a 100% compliant RFC 6298 mechanism - especially the MinRTO definition differs. From nobody Mon Jun 27 00:34:44 2016 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 11E1312B061 for ; Mon, 27 Jun 2016 00:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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, RP_MATCHES_RCVD=-1.426] 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 q200Ir80hIy7 for ; Mon, 27 Jun 2016 00:34:40 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394AB12B042 for ; Mon, 27 Jun 2016 00:34:39 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 27 Jun 2016 09:34:27 +0200 X-IronPort-AV: E=Sophos;i="5.26,536,1459807200"; d="scan'208";a="481226534" Received: from he101659.emea1.cds.t-internal.com ([10.134.226.19]) by qde0ps.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 09:34:16 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101659.emea1.cds.t-internal.com (10.134.226.19) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Jun 2016 09:34:15 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Mon, 27 Jun 2016 09:34:22 +0200 From: To: Thread-Topic: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHRzhJdUZJUKKysbka8+SGQjLiUkZ/472IAgAAHhgCAA+sAkA== Date: Mon, 27 Jun 2016 07:34:22 +0000 Message-ID: <8f8006e13c5248c2bbc004c71ec74535@HE101653.emea1.cds.t-internal.com> References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> In-Reply-To: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.168.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 07:34:43 -0000 SGkgTWljaGFlbCwNCg0KVGhhbmtzLCBhbiBpbnRlcmVzdGluZyB0ZXN0IHNldCB1cC4NCg0KVGhl IGZpcnN0IElQIGxheWVyIHBvbGljeSBwb2ludCBpbiBhIG5ldHdvcmsgbWF5IGJlIHRoZSAoZml4 ZWQgbmV0d29yaykgQlJBUyBvciBhbm90aGVyIG5vZGUgdGVybWluYXRpbmcgYW5kIGF1dGhvcml6 aW5nIG5ldHdvcmsgYWNjZXNzLiBJIGNhbid0IHRlbGwgeW91IGV4YWN0bHkgaG93IHRoZXNlIGFy ZSBjb25maWd1cmVkIGluIHRoZSBuZXR3b3JrIG9mIHRoZSBjb21wYW55IEkgd29yayBmb3IsIGJ1 dCBJIHRoaW5rIGl0IGlzIHJld3JpdGUgd2l0aCBDUzAgYW5kIHRyYW5zcG9ydC4gSSBrbm93IHRo YXQgdGhlIHBlZXJpbmcgcm91dGVycyBhcmUgY29uZmlndXJlZCB0aGF0IHdheS4NCg0KWW91ciBk b2Mgc2F5czogDQpNYXJraW5nIHBhY2tldHMgYXMgQUY0MiAoMzYpIHByb3Zva2VkIGFub3RoZXIg dW5kZWZpbmVkIHZhbHVlICg0KSBvbiAxNCBwYXRocywgLi4uLiBWYWx1ZSA0NiAoRUYgUEhCKSwg b24gdGhlIG90aGVyIGhhbmQsIHdhcyB0dXJuZWQgaW50byA2IOKAkyB5ZXQgYW5vdGhlciB1bmRl ZmluZWQgdmFsdWUg4oCTIG9uIDE3IHBhdGhzLiANCg0KVGhpcyBsb29rcyBsaWtlIGEgc28gY2Fs bGVkICJJUCBwcmVjZWRlbmNlIiByZXdyaXRlOiAxMDAxMDAgaXMgcmV3cml0dGVuIHRvIDAwMDEw MCBhbmQgMTAxMTEwIHRvIDAwMDExMC4gSXQncyBwb3NzaWJsZSB0aGF0IDAwMTAwMCB3YXMgcmV3 cml0dGVuIHRvIDAwMDAwMCB0aGF0IHdheSB0b28gaW4gYSBzaW1pbGFyIG51bWJlciBvZiBjYXNl cy4NCkkgZmF2b3Igc3RhbmRhcmRpemluZyB0aGlzIGJlaGF2aW9yLCBhcyBpdCBpcyBhIHR5cGlj YWwgYW5kIHNpbXBsZSBNUExTIGVkZ2Ugbm9kZSBjb25maWd1cmF0aW9uLiAgDQoNCkluIEdlcm1h bnksIGxheWVyIDIgaW50ZXJjb25uZWN0aW9uIGFncmVlbWVudHMgYmV0d2VlbiBuYXRpb25hbCBw cm92aWRlcnMgcmVzdWx0ZWQgaW4gYSByZWNvbW1lbmRhdGlvbiB0byBkcm9wIHBhY2tldHMgd2l0 aCB1bmV4cGVjdGVkIEV0aGVybmV0IHByaW9yaXR5IG1hcmtpbmdzIGF0IGNhcnJpZXIgaW50ZXJj b25uZWN0aW9uLiBJIGRpc2xpa2UgdGhpcyBpZGVhIGFuZCBjb21tZW50ZWQgYWdhaW5zdCBpdCwg YnV0IEkgd2Fzbid0IGRpcmVjdGx5IGludm9sdmVkIGluIG5lZ290aWF0aW9ucy4NCg0KRnJvbSBl eHBlcmllbmNlIGluIHJvbGxpbmcgb3V0IG5ldyBzZXJ2aWNlcywgdGhlcmUgc2VlbSB0byBiZSBH ZXJtYW4gbmV0d29yayBvcGVyYXRvcnMgZHJvcHBpbmcgcGFja2V0cyB3aXRoIHVuZXhwZWN0ZWQg RFNDUHMgYXQgSVAgaW50ZXJjb25uZWN0aW9ucy4NCg0KSSBjb3VsZG4ndCByZWFkIGZyb20geW91 ciBkb2Mgd2hldGhlciB5b3UgZGlmZmVyZW50aWF0ZWQgYmV0d2VlbiBmaXhlZCwgV2lGaSBhbmQg TFRFLzNHIGFjY2Vzcy4gUGxlYXNlIGFkZCB0aGlzIGluZm9ybWF0aW9uLCBhcyBwb2xpY2llcyBt YXkgZGlmZmVyIGRlcGVuZGluZyBvbiB0aGUgdHlwZSBvZiBhY2Nlc3MuIEkgdGhpbmsgdG8gcmVj YWxsIHRoYXQgZS5nLiBEUEkgd2FzIGRldGVjdGVkIG1vcmUgb2Z0ZW4gaW4gd2lyZWxlc3MgbmV0 d29ya3Mgd2hlbiBFVSByZWd1bGF0aW9uIHByb2JlZCBmb3IgdGhhdCAobm8sIEkgZG9uJ3QgdGhp bmsgb25lIG5lZWRzIERQSSB0byBkZXRlY3QgYW4gdW5leHBlY3RlZCBEU0NQIC0gbXkgcG9pbnQg aXMgdG8gaW5kaWNhdGUgdGhhdCB0aGVyZSBkaWZmZXJlbmNlcyBpbiBwb2xpY3kgaW4gZ2VuZXJh bCkuDQoNClJlZ2FyZHMsDQoNClJ1ZWRpZ2VyDQoNCg0KDQoNCg0KDQoNCj4gQnV0IChhcyB3aXRo IGEgbG90IG9mIHJlY2VudCBkaXNjdXNzaW9uIGFib3V0IElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMg DQo+IGNhdXNpbmcgcGFja2V0IGRyb3BzKSB3ZSByZWFsbHkgbmVlZCB0byB1bmRlcnN0YW5kIHdo eSB0aGlzIGhhcHBlbnMuIA0KPiBJcyBpdCB0cmFmZmljIHBvbGljaW5nIHRoYXQgZmFpbHMgdG8g cmVjbGFzc2lmeSBhbmQgcmUtbWFyayBwYWNrZXRzLCANCj4gbWlzZ3VpZGVkIGZpcmV3YWxscywg b3Igd2hhdD8NCg0KW01XXSBJIGhhdmUgbm8gY2x1ZeKApiBidXQgYXMgbXkgcHJldmlvdXMgZW1h aWwgc2FpZCwgd2UgaGF2ZSBpbmRpY2F0aW9ucyB0aGF0IHRoaXMgYmVoYXZpb3Igb2NjdXJyZWQg Y2xvc2UgdG8gdGhlIHNlbmRlcnMgKG1vc3Qgb2YgdGhlbSBiZWluZyBpbiBwZW9wbGXigJlzIGhv bWVzKSwgaGVuY2UgaXTigJlzIG1vcmUgbGlrZWx5IHRoYXQgdGhpcyB3YXMgZG9uZSBieSBhIG1p ZGRsZWJveCBvciBhbiBlZGdlIHJvdXRlciB0aGFuIGJ5IGEgY29yZSByb3V0ZXIuDQpUaGF04oCZ cyBhcyBtdWNoIGFzIHdlIGtub3cuLi4NCg0KDQo= From nobody Mon Jun 27 06:46:23 2016 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 9381E12D1B7; Mon, 27 Jun 2016 06:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 ytMGopx8Qd3T; Mon, 27 Jun 2016 06:46:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FE112D1AD; Mon, 27 Jun 2016 06:46:13 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-25-57712e24f2d3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.08.27088.42E21775; Mon, 27 Jun 2016 15:46:12 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.294.0; Mon, 27 Jun 2016 15:46:09 +0200 To: IETF AVTCore WG References: From: Magnus Westerlund Message-ID: Date: Mon, 27 Jun 2016 15:46:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM2K7pa6KXmG4wY8LkhYve1ayW8zvPM1u 8eL6R2aLtf/a2S2OvbnL5sDqsWTJTyaPlo8LWT1m7XzCEsAcxWWTkpqTWZZapG+XwJWx7spP poItIhXLbx5nbGC8L9DFyMEhIWAi8eSabRcjJ5ApJnHh3no2EFtI4AijRMNh4S5GLiB7OaPE 61V7mEASwgLREqeO/WIGsUUElCR2TNrGDNFgL3Flxz1GkAZmgU5GibaDe8AmsQlYSNz80Qhm 8wIV9X89DtbAIqAq8W/ebEYQW1QgRqLx9mF2iBpBiZMzn7CA2JwCDhJXH/YwghzKDNT7YGsZ SJhZQF6ieetsqL3aEg1NHawTGAVnIemehdAxC0nHAkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiBIX1wy2+DHYwvnzseYhTgYFTi4U0IKAgXYk0sK67MPcQowcGsJMJrrlsYLsSbklhZ lVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoGx6MybwwuOOqZkHZ1o uubcyqtvnutHlz3e8DXn5OOEkPKN61Od2QK499Qdv5VVpBAvcWnNneKzTsvq0mreTni1bU2O ncrV/dtfaB2T0Hi25PyMvvUr9J3/l5q/3G166drL3Yr2nD52Py63MhkYrt3xcWFP/b/uz26y +XU/3uaLWcg5ORv0Zm55rcRSnJFoqMVcVJwIABPbM/9lAgAA Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , Mirja Kuehlewind Subject: Re: [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 13:46:17 -0000 AVT, RTCWEB, TSVWG and ADS. I have to conclude that there is not consensus on the proposed text. It does appear that this subject do require additional discussion and most likely drafting of new text. Please continue to provide input into the matter. I would like to conclude this subject no later than by the end of the Berlin meeting. Cheers Magnus Den 2016-06-14 kl. 10:14, skrev Magnus Westerlund: > AVT, RTCWEB and TSVWG > > This announces an additional one week WG last call (in AVT) on the > changes done to "Multimedia Congestion Control: Circuit Breakers for > Unicast RTP Sessions" that is intended for Proposed Standard. The last > call concludes on the 21st of June. > > So this last call is deemed necessary due to normative changes in the > behaviour as result of the conclusions of how to resolve the Discuss > regarding reaction to ECN markings. > > If there are no issues in this additional WG last call, the draft will > be approved for publication as it has already passed IESG review. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-16 > > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 27 07:42:46 2016 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 A9A5612D1C8; Mon, 27 Jun 2016 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 k3KGxu1zAOHk; Mon, 27 Jun 2016 07:42:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A327512D65E; Mon, 27 Jun 2016 07:40:17 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5REeBsi052206 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2016 09:40:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Magnus Westerlund" Date: Mon, 27 Jun 2016 09:40:17 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Mirja Kuehlewind , "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 14:42:38 -0000 Thanks, Magnus! On 27 Jun 2016, at 8:46, Magnus Westerlund wrote: > AVT, RTCWEB, TSVWG and ADS. > > I have to conclude that there is not consensus on the proposed text. > It does appear that this subject do require additional discussion and > most likely drafting of new text. > > Please continue to provide input into the matter. I would like to > conclude this subject no later than by the end of the Berlin meeting. > > Cheers > > Magnus > > Den 2016-06-14 kl. 10:14, skrev Magnus Westerlund: >> AVT, RTCWEB and TSVWG >> >> This announces an additional one week WG last call (in AVT) on the >> changes done to "Multimedia Congestion Control: Circuit Breakers for >> Unicast RTP Sessions" that is intended for Proposed Standard. The >> last >> call concludes on the 21st of June. >> >> So this last call is deemed necessary due to normative changes in the >> behaviour as result of the conclusions of how to resolve the Discuss >> regarding reaction to ECN markings. >> >> If there are no issues in this additional WG last call, the draft >> will >> be approved for publication as it has already passed IESG review. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-16 >> >> >> Cheers >> >> Magnus Westerlund >> AVTCORE WG chair >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Mon Jun 27 07:57:58 2016 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 AE3E212D58C for ; Mon, 27 Jun 2016 07:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 4RcZKMgXCe97 for ; Mon, 27 Jun 2016 07:57:54 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89DA12D7CE for ; Mon, 27 Jun 2016 07:52:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHXtc-0000kt-TB; Mon, 27 Jun 2016 16:52:20 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHXtc-0004pB-IX; Mon, 27 Jun 2016 16:52:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <8f8006e13c5248c2bbc004c71ec74535@HE101653.emea1.cds.t-internal.com> Date: Mon, 27 Jun 2016 16:52:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <569FCE61-A424-4B3E-838A-AEE4343766DD@ifi.uio.no> References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <8f8006e13c5248c2bbc004c71ec74535@HE101653.emea1.cds.t-internal.com> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 5 sum rcpts/h 13 sum msgs/h 7 total rcpts 43693 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 022F9C72CB55A58171DBE5CDF394C35B90DF2F69 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 10633 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 14:57:57 -0000 Dear Ruediger, Thanks a lot for your interest! More below: > On 27 Jun 2016, at 09:34, Ruediger.Geib@telekom.de wrote: >=20 > Hi Michael, >=20 > Thanks, an interesting test set up. >=20 > The first IP layer policy point in a network may be the (fixed = network) BRAS or another node terminating and authorizing network = access. I can't tell you exactly how these are configured in the network = of the company I work for, but I think it is rewrite with CS0 and = transport. I know that the peering routers are configured that way. >=20 > Your doc says:=20 > Marking packets as AF42 (36) provoked another undefined value (4) on = 14 paths, .... Value 46 (EF PHB), on the other hand, was turned into 6 = =E2=80=93 yet another undefined value =E2=80=93 on 17 paths.=20 >=20 > This looks like a so called "IP precedence" rewrite: 100100 is = rewritten to 000100 and 101110 to 000110. It's possible that 001000 was = rewritten to 000000 that way too in a similar number of cases. > I favor standardizing this behavior, as it is a typical and simple = MPLS edge node configuration. =20 Interesting, thanks! > In Germany, layer 2 interconnection agreements between national = providers resulted in a recommendation to drop packets with unexpected = Ethernet priority markings at carrier interconnection. I dislike this = idea and commented against it, but I wasn't directly involved in = negotiations. >=20 > =46rom experience in rolling out new services, there seem to be German = network operators dropping packets with unexpected DSCPs at IP = interconnections. This is very interesting - and I agree it's the wrong thing to do ("be = liberal in what you accept" ...). Runa Barik (the Ph.D. student whose work this is) is planning to give a = presentation to MAPRG about this, where he'll also talk about a new set = of measurements that he did during a trip from Norway to India. There, = he saw the same problem, and he also carried out traceroute-type = measurements with the changed packets to see where it happened - with = the result that it often is *inside* the network, i.e. not just 2-3 hops = or so away from the client (which is where many other packet drops = happened). Even though it's a very small datapoint, it would confirm = what you say about the location of this problem. > I couldn't read from your doc whether you differentiated between = fixed, WiFi and LTE/3G access. Please add this information, as policies = may differ depending on the type of access. I think to recall that e.g. = DPI was detected more often in wireless networks when EU regulation = probed for that (no, I don't think one needs DPI to detect an unexpected = DSCP - my point is to indicate that there differences in policy in = general). Sorry: we didn't - but it's good advice, we will incorporate this in the = future! Cheers, Michael From nobody Mon Jun 27 08:04:44 2016 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 D939E12D69E; Mon, 27 Jun 2016 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 OpIQgnt2hTHk; Mon, 27 Jun 2016 08:04:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FBF12D66B; Mon, 27 Jun 2016 07:56:04 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D205CEF8A2240; Mon, 27 Jun 2016 14:55:58 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5REtTAX001691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jun 2016 14:56:01 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5RErb3a017606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jun 2016 16:55:20 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 27 Jun 2016 16:53:13 +0200 From: "De Schepper, Koen (Nokia - BE)" To: Michael Welzl , "Black, David" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4Xv7l4815Xu02SCqscZNZxsp/tUDQAgABAKwCAABBvgIABAQmAgAOYcQCAADeCAIAK/Ekg Date: Mon, 27 Jun 2016 14:53:12 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> In-Reply-To: <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: " Fairhurst" , Magnus Westerlund , tsvwg , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:04:34 -0000 QXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhpcyBkcmFmdCBpcyByZWxhdGVkIHRvIGNpcmN1aXQg YnJlYWtlcnMgaW4gZW5kLXN5c3RlbXMsIHJpZ2h0Pw0KSXQgaXMgdGhlIGVuZCBzeXN0ZW0gdGhh dCBkZXRlcm1pbmVzIHRoZSB1c2Ugb2YgRUNOIChjdXJyZW50bHkgbWFya2luZyBub24tZWN0IGZv ciBkcm9wIGFuZCBlY3QoMCkgZm9yIENsYXNzaWMgRUNOKS4gDQpJbiBMNFMgd2UgZG9uJ3QgcGxh biB0byBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIENsYXNzaWMgRUNOLCBhbmQgQUJFJ3MgYmVoYXZp b3Igc2hvdWxkIGJlIGNsb3NlIHRvIG5vbi1BQkUgRUNOLiBTbyBJIGd1ZXNzIHRoZXJlIGlzIG5v IHByb2JsZW0gb2YgZGVzY3JpYmluZyB0aGUgYmVoYXZpb3Igb2YgaG93IGEgQ2xhc3NpYyBFQ04g YmFzZWQgc2VuZGVyIHdvdWxkIHJlc3BvbmQgdG9kYXkuIA0KDQpBcyB3ZSBvbmx5IHdhbnQgdG8g c2lnbmlmaWNhbnRseSBjaGFuZ2UgdGhlIG5ldHdvcmsgYmVoYXZpb3Igb2YgZWN0KDEpIG1hcmtp bmcsIGNhbiB3ZSBzb2x2ZSB0aGlzIGlzc3VlIGJ5IHJlY29tbWVuZGluZyAob3IgZXZlbiByZXF1 aXJpbmcpIHNlbmRlcnMgdG8gbWFyayBvbmx5IGVjdCgwKSBhbmQgZGVzY3JpYmluZyB0aGUgY2xh c3NpYyBFQ04gY2lyY3VpdCBicmVha2VyPyBXaGVuIEw0UyBnZXRzIGRlZmluZWQsIGFsc28gYW4g TDRTIGJhc2VkIGNpcmN1aXQgYnJlYWtlciBleHRlbnNpb24gY2FuIGJlIGRlZmluZWQgZm9yIHNl bmRlcnMgdGhhdCB3YW50IHRvIHVzZSB0aGUgTDRTIHNlcnZpY2UgKHdoZW4gc2VuZGVycyBzZW5k IGVjdCgxKSBwYWNrZXRzKS4NCg0KUmVnYXJkcywNCktvZW4uDQoNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFdlbHpsDQo+IFNlbnQ6IG1hYW5kYWcgMjAganVuaSAy MDE2IDE4OjM2DQo+IFRvOiBCbGFjaywgRGF2aWQNCj4gQ2M6IDxnb3JyeUBlcmcuYWJkbi5hYy51 az4gRmFpcmh1cnN0OyBNYWdudXMgV2VzdGVybHVuZDsgdHN2d2c7IElFVEYNCj4gQVZUQ29yZSBX RzsgcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+IFN1YmplY3Q6IFJlOiBbdHN2d2dd IFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJhZnQtDQo+IGll dGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gDQo+ID4gT24gMjAuIGp1 bi4gMjAxNiwgYXQgMTUuMTYsIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gd3Jv dGU6DQo+ID4NCj4gPj4+IEJ1dCBJ4oCZbSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0 IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQgZm9yDQo+IGNpcmN1aXQNCj4gPj4gYnJlYWtlci4NCj4g Pj4+DQo+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFzdXJlbWVudCB0aGF0IGEgQ0IgTVVTVCBy ZXNwb25kIHRvLg0KPiA+DQo+ID4gTXVtYmxlLiAgIEkgd291bGQgYmUgb2sgd2l0aCBhIGNsZWFy IGRpc2NvdXJhZ2VtZW50IGZvciB1c2Ugb2YgRUNOLUNFDQo+IG1hcmtzLCBhY2NvbXBhbmllZCBi eSB0aGUgc29ydCBvZiBkZXNpZ24gcmF0aW9uYWxlIGhlcmUsIG9yIGV2ZW4gYmV0dGVyLA0KPiBh IGNsZWFyIHN0YXRlbWVudCB0aGF0IGxvc3QgcGFja2V0cyBmb3IgdGhlIHB1cnBvc2Ugb2YgdGhl IFJUUCBjaXJjdWl0DQo+IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1YWxseSBsb3N0IHdpdGhvdXQg Z2V0dGluZyBpbnRvIHdoZXRoZXIgb3Igbm90DQo+IEVDTi1DRSBtYXJrcyBhcmUgaW52b2x2ZWQg LWkuZS4sIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGlzIHNwZWNpZmllZA0KPiBhZ2FpbnN0IGFj dHVhbCBkcm9wcyBhcyBhIG5ldHdvcmsgcHJvdGVjdGlvbiBiYWNrc3RvcC4NCj4gPg0KPiA+IEEg cmVsYXRlZCBjb25jZXJuIGlzIHRoYXQgRUNOIG1hcmtzIG1heSBvdmVyc3RhdGUgZXF1aXZhbGVu dCBsb3NzDQo+IGJlaGF2aW9yIC0gYSBzaW1wbGlzdGljIHF1ZXVlIG1hbmFnZW1lbnQgZGlzY2lw bGluZSB0aGF0IG1hcmtzIGV2ZXJ5DQo+IHBhY2tldCB3aGVuIHRoZSBxdWV1ZSBpcyBvdmVyIGEg dGhyZXNob2xkIChOQjogdGhpcyBjbGFzcyBvZiBtYXJraW5nDQo+IGJlaGF2aW9yIGlzIE5PVCBS RUNPTU1FTkRFRCAtIGEgcmVhbCBBUU0gU0hPVUxEIGJlIHVzZWQpIGNvdWxkIHlpZWxkIGENCj4g cnVuIG9mIEVDTi1DRSBtYXJrcyB0aGF0IHdvdWxkIG5vdCBjYXVzZSBhIGNvcnJlc3BvbmRpbmcg d2l0aCBhIHJ1biBvZg0KPiBwYWNrZXQgZHJvcHMuICAgVGhpcyBpcyBhbW9uZyB0aGUgcmVhc29u cyB0aGF0IFRDUCByZWFjdHMgdG8gRUNOLUNFDQo+IG1hcmtzIG9ubHkgb25jZSBwZXIgUlRULCBh bmQgbWlnaHQgYmUgYSByZWFzb24gdG8gdHJlYXQgbXVsdGlwbGUgRUNOLUNFDQo+IG1hcmtzIGlu IGFuIFJUVCBpbnRlcnZhbCBhcyBub3QgcmVwcmVzZW50aW5nIGRyb3BzIG9mIGFsbCBwYWNrZXRz IGZvcg0KPiB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlcidzIFRDUC1lcXVpdmFsZW50IHRocm91Z2hw dXQgY2FsY3VsYXRpb24uDQo+IA0KPiBJ4oCZbSBub3Qgc3VyZSB3ZSBuZWVkIHN1Y2ggY29tcGxp Y2F0ZWQgbG9naWMgdG8gZmluZCBhIGNhc2Ugd2hlcmUgRUNODQo+IG1hcmtzIGFyZSBkaWZmZXJl bnQgZnJvbSBwYWNrZXQgZHJvcHM6DQo+IA0KPiBCYXNpY2FsbHksIHRoZXkgc2ltcGx5IGFyZW7i gJl0IC0gZXZlbiDigJxyZWFs4oCdIEFRTXMgbWFya2luZyBpc27igJl0IGV4YWN0bHkNCj4gdGhl IHNhbWUgYXMgYSBwYWNrZXQgZHJvcDogdGhlIG1hcmtzIHRoZW1zZWx2ZXMgaW5mb3JtIHlvdSB0 aGF0IGFuIEFRTQ0KPiBkaWQgaXRzIGpvYiwgYW5kIHdpdGggbW9kZXJuIEFRTXMgbGlrZSBDb0Rl bCAvIFBJRSBldGMuLCB5b3XigJlyZSBwcm9iYWJseQ0KPiBnZXR0aW5nIHRoaXMgZnJvbSBhIHNo YWxsb3cgcXVldWUuIENoYW5jZXMgYXJlIHRoYXQgdGhpcyBpcyBsZXNzIHRoYW4gYQ0KPiBCRFAg d29ydGggb2YgcXVldWluZywgd2hpY2ggaXMgb3VyIGp1c3RpZmljYXRpb24gZm9yIHJlY29tbWVu ZGluZyBhDQo+IGRpZmZlcmVudCBiYWNrLW9mZiBiZWhhdmlvciBpbiBkcmFmdC1raGFkZW1pLXRz dndnLWVjbi1yZXNwb25zZS0wMCBhbmQNCj4gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZl YmFja29mZi1lY24tMDANCj4gDQo+IFNvIHRoZSBwb2ludCBpcyBub3QgdGhhdCBBUU1zIHdvdWxk IHRyZWF0IEVDTiBtYXJraW5nIGFuZCBkcm9wcGluZw0KPiBkaWZmZXJlbnRseSAtIGl04oCZcyB0 aGF0IEVDTiBpbmRpY2F0ZXMgYW4gQVFNLCBhbmQgaGVuY2UgcHJvYmFibHkgYQ0KPiBzaGFsbG93 IHF1ZXVlLiBXaXRoIGEgZHJvcCwgeW91IGp1c3QgZG9u4oCZdCBrbm93Lg0KPiANCj4gQmFjayB0 byB0aGUgQ0IsIEkgdGhpbmsgYW4gQVFNIG1hcmtpbmcgYXQgYSBzaGFsbG93IHF1ZXVlIChsaWtl IGUuZy4NCj4gQ29EZWwpIGlzIGluZGVlZCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSBhIOKAnGJyb2tl biBjb25uZWN0aW9u4oCdLg0KPiANCj4gQ2hlZXJzLA0KPiBNaWNoYWVsDQo+IA0KPiANCj4gPg0K PiA+IFRoYW5rcywgLS1EYXZpZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IEdvcnJ5IChlcmcpIFttYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWtdDQo+ ID4+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDE4LCAyMDE2IDI6MjMgQU0NCj4gPj4gVG86IE1pcmph IEvDvGhsZXdpbmQNCj4gPj4gQ2M6IEJsYWNrLCBEYXZpZDsgTWFnbnVzIFdlc3Rlcmx1bmQ7IENv bGluIFBlcmtpbnM7IHJ0Y3dlYkBpZXRmLm9yZzsNCj4gSUVURg0KPiA+PiBBVlRDb3JlIFdHOyB0 c3Z3Zw0KPiA+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBbcnRjd2ViXSBbQVZUQ09SRV0gV0cgTGFz dCBDYWxsIG9uIGNoYW5nZXM6DQo+IGRyYWZ0LWlldGYtDQo+ID4+IGF2dGNvcmUtcnRwLWNpcmN1 aXQtYnJlYWtlcnMtMTYNCj4gPj4NCj4gPj4gSSB0aGluayB3ZSBTSE9VTEQgTk9UIHJlY29tbWVu ZCB0byB1c2UgRUNOIG1hcmtzIGFzIGlucHV0cyB0byBhIENCLg0KPiBTZWUNCj4gPj4gYmVsb3c6 DQo+ID4+DQo+ID4+PiBPbiAxNyBKdW4gMjAxNiwgYXQgMTY6MDIsIE1pcmphIEvDvGhsZXdpbmQN Cj4gPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+DQo+ID4+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+ICsxIHRvIG5vdCB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIGhlcmUuDQo+ID4+Pg0KPiA+ Pj4gSG93ZXZlciwgcGxlYXNlIG5vdGUgdGhhdCBoYXZpbmcgYSBoaWdoIGxldmVsIG9mIEVDTi1D RSBtYXJrcw0KPiAod2l0aG91dCBhbnkNCj4gPj4gbG9zc2VzKSBtZWFucyB0aGF0IGFsbCBwYWNr ZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVjdGx5LiBUaGlzDQo+IHNpdHVhdGlvbiBjYW4gZXZlbg0K PiA+PiBvY2N1cnMgd2l0aG91dCBoaWdoIGRlbGF5cyAoZGVwZW5kaW5nIG9uIHRoZSBBUU0gdXNl ZCksIHdoaWNoIHdvdWxkDQo+IGp1c3QNCj4gPj4gbWVhbiB0aGUgc2VydmljZXMgd29ya3MgcGVy ZmVjdGx5LiBUaGVyZWZvcmUgZm9yIG1lIENFIG1hcmtzIGFyZSBhDQo+IHBlcmZlY3QgaW5wdXQN Cj4gPj4gc2lnbmFsIGZvciBhIGNvbmdlc3Rpb24gY29udHJvbCBsb29wICh3aGVyZSB0aGUgQVFN IHRlbGwgdGhlIHNlbmRlcg0KPiB0byB0YWtlIGFjdGlvbg0KPiA+PiAtIHdoYXRldmVyIHRoYXQg bWVhbnMpLg0KPiA+Pg0KPiA+PiBXZSBtYXkgaW4gZnV0dXJlIGZpZ3VyZSBvdXQgd2F5cyB0byBk byB0aGlzIHRvIGRldGVjdCBzaWduaWZpY2FudA0KPiBmYWlsdXJlIHVzaW5nIGENCj4gPj4gcmF0 ZSBhZGFwdGl2ZSB0cmFuc3BvcnQgYW5kIEVDTiBlLmcuICBPYnNlcnZpbmcgMTAwJSBDRSBtYXJr cyBvcg0KPiBzb21ldGhpbmcsIGZvcg0KPiA+PiBhbiBSVFAgZmxvdyB0aGF0IGlzIHRyeWluZyB0 byBzZW5kIHdlbGwgYmVsb3cgaXRzIHBlYWsgcmF0ZSBkZWNpZGVkDQo+IGJ5IENDIC0tIGJ1dCBJ DQo+ID4+IHRoaW5rIHRoaXMgaXMgc3BlY3VsYXRpbmcgYXQgYW4gYWxnb3JpdGhtIGFuZCBhZGRp bmcgZGV0YWlscyBoZXJlIGlzDQo+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPj4gRXNwZWNpYWxseSBh cyBBUU0gY29udGludWVzIHRvIGV2b2x2ZS4NCj4gPj4NCj4gPj4+IEJ1dCBJ4oCZbSBsZXNzIGNv bmNlcm5lZCB0aGFuIERhdmlkIGFib3V0IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQgZm9yDQo+IGNp cmN1aXQNCj4gPj4gYnJlYWtlci4NCj4gPj4+DQo+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFz dXJlbWVudCB0aGF0IGEgQ0IgTVVTVCByZXNwb25kIHRvLg0KPiA+Pg0KPiA+Pj4gSW4gYWRkaXRp b24gb25lIHBvaW50IG9uIHNvbWV0aGluZyBNYWdudXMgd3JvdGUgZWFybGllcjoNCj4gPj4+ICJJ ZiB0aGUgaW1wbGVtZW50YXRpb24gb25seSBoYXZlIGNpcmN1aXQgYnJlYWtlciwgaS5lLiBubyBm dWxsDQo+IGZsZWRnZWQgY29uZ2VzdGlvbg0KPiA+PiBjb250cm9sbGVyIGFuZCB1c2VzIEVDTiwg dGhleSBjYW4gaW4gd29yc3QgY2FzZSBkcml2ZSB0aGUgYnVmZmVyIGludG8NCj4gdGhlIG92ZXJs b2FkDQo+ID4+IHJlZ2ltZSB3aGVyZSBpdCBzdGFydHMgZHJvcHBpbmcgcGFja2V0cy4g4oCeDQo+ ID4+Pg0KPiA+Pj4gSeKAmW0gbm90IHN1cmUgYWJvdXQgdGhpcyBjYXNlLiBFQ04gaXMgYW4gaW5w dXQgc2lnbmFsIGZvciBjb25nZXN0aW9uDQo+IGNvbnRyb2wuIElmIHlvdQ0KPiA+PiBkb27igJl0 IHVzZSBjb25nZXN0aW9uIGNvbnRyb2wgYnV0IG9ubHkgYSBjaXJjdWl0IGJyZWFrZXIsIHlvdSBz aG91bGQNCj4gcHJvYmFibHkgbm90DQo+ID4+IGVuYWJsZSBFQ04uIEF0IGxlYXN0IGl0IG5vdCBj bGVhciB0byBtZSB3aHkgeW91IHdvdWxkIGVuYWJsZSBpdCwgYW5kDQo+IGl0J3MgZGVmaW5pdGVs eQ0KPiA+PiBub3QgY29uZm9ybSB0byB0aGUgRUNOIHNwZWMuIFByb2JhYmx5IHdlIHNob3VsZCBz YXkgc29tZXRoaW5nIGFib3V0DQo+IHRoaXMgaW4gdGhlDQo+ID4+IGRyYWZ0Li4uPw0KPiA+Pj4N Cj4gPj4gQWdyZWUsIGVuYWJsaW5nIEVDTiB3aXRob3V0IGEgcmVzcG9uc2l2ZSBDQyBpcyBnb2lu ZyB0byBsZWFkIHRvDQo+IHRyb3VibGUuDQo+ID4+DQo+ID4+PiBNaXJqYQ0KPiA+Pj4NCj4gPj4g R29ycnkNCj4gPj4NCj4gPj4+PiBBbSAxNy4wNi4yMDE2IHVtIDE2OjAzIHNjaHJpZWIgQmxhY2ss IERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPjoNCj4gPj4+Pg0KPiA+Pj4+IENvbGluLA0KPiA+ Pj4+DQo+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcg aW1wbGVtZW50ZXJzIHdpdGggdG9vDQo+IG11Y2gNCj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25v cmUgRUNOLUNFIG1hcmtzIChlLmcuLCBiZWNhdXNlIGFuIGltcGxlbWVudGVyDQo+IGRvZXNuJ3QN Cj4gPj4+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSBzcGFjZSBpbiB0aGUg Zmlyc3QgcGxhY2UpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGFncmVlLCBidXQgdGhlIGFyZ3VtZW50 IGlzIHRoYXQgZG9pbmcgc28gaXMgbGVzcyBoYXJtZnVsIHRoYW4NCj4gZGVwbG95aW5nIGENCj4g Pj4gY2lyY3VpdA0KPiA+Pj4+PiBicmVha2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVuIHdoZW4g RUNOIGlzIHVzZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEnigJltIG5vdCBzdXJlIEkgYmVsaWV2ZSB0 aGlzIGFyZ3VtZW50LCB0aG91Z2gsIHNpbmNlIGl0IHNlZW1zIHRoYXQNCj4gYW55IG5ldw0KPiA+ PiBBUU0NCj4gPj4+Pj4gdGhhdCBhcHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhh biBhdCBwcmVzZW50IHdpbGwgaGF2ZQ0KPiB0bw0KPiA+PiBjb25zaWRlcg0KPiA+Pj4+PiBiYWNr d2FyZHMgY29tcGF0aWJpbGl0eSwgdG8gd29yayB3aXRoIGRlcGxveWVkIFRDUCAoZS5nLiwgZHJh ZnQtDQo+IGJyaXNjb2UtDQo+ID4+IHRzdndnLQ0KPiA+Pj4+PiBhcW0tdGNwbS1ybWNhdC1sNHMt cHJvYmxlbSB1c2VzIEVDVCgxKSBhcyBhIHNpZ25hbCB0byB1c2UgdGhlIG5ldw0KPiBtYXJraW5n LA0KPiA+Pj4+PiB3aGlsZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgc2V0IEVDVCgwKSkuIFRo ZXNlIGNvbXBhdGliaWxpdHkNCj4gbWVjaGFuaXNtcw0KPiA+Pj4+PiB3b3VsZCBzZWVtIHRvIHBy ZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG9vLg0KPiA+Pj4+DQo+ ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNoZXMgbXkgbGluZSBvZiB0aGlua2luZywgYW5kIEknbGwg b2JzZXJ2ZSB0aGF0IHRoZQ0KPiBvcmlnaW5hbA0KPiA+PiBEQ1RDUA0KPiA+Pj4+IHByb3RvY29s IGRlc2lnbiB0aGF0IHVzZWQgbW9yZSBhZ2dyZXNzaXZlIEVDTi1DRSBtYXJraW5nIHdhcyBvbmx5 DQo+IHNhZmUgZm9yDQo+ID4+Pj4gQ29udHJvbGxlZCBFbnZpcm9ubWVudCBkZXBsb3ltZW50cy4g ICBTZWUgdGhlIFRTVldHIHJmYzU0MDViaXMNCj4gZHJhZnQgZm9yDQo+ID4+IHRoZQ0KPiA+Pj4+ IGRlZmluaXRpb24gb2YgQ29udHJvbGxlZCBFbnZpcm9ubWVudCwgYW5kIGlnbm9yZSB0aGUgZmFj dCB0aGF0IHRoZQ0KPiByZmM1NDA1YmlzDQo+ID4+Pj4gZHJhZnQgaXMgYSBVRFAgZHJhZnQgLSB0 aGlzIGRlZmluaXRpb24gaXMgbW9yZSBicm9hZGx5IGFwcGxpY2FibGUuDQo+ID4+Pj4NCj4gPj4+ PiBHb2luZyBiYWNrIG92ZXIgU2VjdGlvbiA3IGluIHRoaXMgYXZ0Y29yZSBkcmFmdCwgbXkgdmll d3MgYXJlOg0KPiA+Pj4+DQo+ID4+Pj4gW0FdIE5vbmUgb2YgdGhlc2UgZHJhZnRzIGp1c3RpZnkg YSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8gRUNOLUNFDQo+IG1hcmtzOg0KPiA+Pj4+ICAgLSBk cmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbg0KPiA+Pj4+ICAgLSBkcmFm dC1pZXRmLXJtY2F0LW5hZGENCj4gPj4+PiAgIC0gZHJhZnQtaWV0Zi1ybWNhdC1zY3JlYW0tY2MN Cj4gPj4+Pg0KPiA+Pj4+IFtCXSBJbiBsaW5lIHdpdGggQ29saW4ncyBjb21tZW50IG9uIHRoZSBM NFMgZHJhZnQsIEkgdGhpbmsgaXQncw0KPiBpbmN1bWJlbnQgb24NCj4gPj4+PiB0aGUgYXV0aG9y cyBvZiBkcmFmdC1icmlzY29lLWFxbS1kdWFscS1jb3VwbGVkIHRvIGZpZ3VyZSBvdXQgaG93DQo+ IHRoYXQgd2lsbA0KPiA+Pj4+IGNvZXhpc3QgKG9yIGF2b2lkKSBkZXBsb3llZCBUQ1AsIGFuZCB0 aGlzIGF2dGNvcmUgZHJhZnQgb3VnaHQgbm90DQo+IHRvIGJlDQo+ID4+Pj4gdHJ5aW5nIHRvIHBy ZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KPiA+Pj4+DQo+ID4+Pj4gU28sIEkgZG9u J3QgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCBpbiBTZWN0aW9uIDcgaGFzIGp1c3RpZmllZCB0aGUN Cj4gdW5mZXR0ZXJlZA0KPiA+Pj4+ICJpbXBsZW1lbnRhdGlvbnMgTUFZIGlnbm9yZSBFQ04tQ0Ug bWFya3MiIHRleHQsIGFzIGlnbm9yaW5nIHRob3NlDQo+IG1hcmtzDQo+ID4+Pj4gaXMgbm90IGNv bnNpc3RlbnQgd2l0aCBhbnkgb2YgdGhlIGZvdXIgY2l0ZWQgZHJhZnRzLg0KPiA+Pj4+DQo+ID4+ Pj4gSW4gbW9yZSBkZXRhaWwsIEkgdGhpbmsgbWFraW5nIGNoYW5nZXMgdG8gbm9ybWF0aXZlIHJl cXVpcmVtZW50cw0KPiBoZXJlIGJhc2VkDQo+ID4+Pj4gb24gW0JdIGlzIHByZW1hdHVyZSwgYW5k IEkgd291bGQgaG9wZSB0aGF0IHRoZSBybWNhdCBXRyBjb3VsZCBiZQ0KPiA+PiBlbmNvdXJhZ2Vk DQo+ID4+Pj4gdG8gY29uc2lkZXIgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaW4gaXRzIGNvbmdl c3Rpb24gY29udHJvbA0KPiBkcmFmdHMsIGFzIHRob3NlIENDDQo+ID4+Pj4gbWVjaGFuaXNtcyBh cmUgcmVsYXRlZCB0byB0aGUgY2lyY3VpdCBicmVha2VyIG1lY2hhbmlzbSwgaGVuY2UNCj4gbGlr ZWx5DQo+ID4+Pj4gdG8gYmUgaW4gcmVsYXRlZCBhcmVhcyBvZiBhbiBSVFAgaW1wbGVtZW50YXRp b24uDQo+ID4+Pj4NCj4gPj4+PiBUaGF0IGxlYXZlcyBkcmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJu YXRpdmViYWNrb2ZmLWVjbiwgd2hpY2ggVFNWV0cNCj4gPj4+PiB3aWxsIGJlIGxvb2tpbmcgYXQg aW4gQmVybGluLiAgSWYgYSBub3JtYXRpdmUgc3RhdGVtZW50IGFib3V0IEVDTi0NCj4gQ0UgcmVh Y3Rpb24NCj4gPj4+PiBpcyBnb2luZyB0byByZXN0IG9uIHRoYXQgZHJhZnQsIHRoZW4gdGhlIHJl ZmVyZW5jZSB0byB0aGF0IGRyYWZ0DQo+IHNob3VsZCBiZQ0KPiA+Pj4+IG5vcm1hdGl2ZS4gIFNv bWV0aGluZyBhYm91dCBkb2luZyB0aGF0IHN0cmlrZXMgbWUgYXMgcHJlbWF0dXJlIC4uLg0KPiA+ Pj4+DQo+ID4+Pj4gSSByZWFsaXplIHRoYXQgd2UncmUgdHJ5aW5nIHRvIHByZWRpY3QgYW5kIGFj Y29tbW9kYXRlIHRoZSBmdXR1cmUsDQo+IHdoaWNoDQo+ID4+Pj4gaXMgYW4gaW1wcmVjaXNlIHVu ZGVydGFraW5nIGF0IGJlc3QuICAgQXMgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlDQo+IGN1cnJlbnQg dGV4dCwNCj4gPj4+PiB3b3VsZCBpdCBiZSByZWFzb25hYmxlIHRvIHNheSAod2l0aG91dCBhbnkg UkZDIDIxMTkga2V5d29yZHMpIHRoYXQNCj4gdGhlDQo+ID4+Pj4gYmVzdCBjdXJyZW50IGd1aWRh bmNlIGlzIHN0aWxsIHRvIHRyZWF0IEVDTi1DRSBtYXJrcyBhcyBpbmRpY2F0aW5nDQo+IGRyb3Bz LA0KPiA+Pj4+IHdpdGggYSB3YXJuaW5nIHRoYXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5 IG9mIHRoaXMgY2hhbmdpbmcgaW4NCj4gdGhlDQo+ID4+Pj4gbmVhciBmdXR1cmUgZHVlIHRvIGFs bCBvZiB0aGUgd29yayBpbiBwcm9ncmVzcyBjaXRlZCBpbiBTZWN0aW9uIDc/DQo+ID4+Pj4NCj4g Pj4+PiBUaGFua3MsIC0tRGF2aWQNCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+Pj4+PiBGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lu cy5vcmddDQo+ID4+Pj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAxNiA2OjE0IEFNDQo+ID4+ Pj4+IFRvOiBKb2huIExlc2xpZTsgQmxhY2ssIERhdmlkDQo+ID4+Pj4+IENjOiBydGN3ZWJAaWV0 Zi5vcmc7IElFVEYgQVZUQ29yZSBXRzsgdHN2d2cNCj4gPj4+Pj4gU3ViamVjdDogUmU6IFtydGN3 ZWJdIFtBVlRDT1JFXSBbdHN2d2ddIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0KPiBkcmFmdC1p ZXRmLQ0KPiA+Pj4+PiBhdnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2DQo+ID4+Pj4+DQo+ ID4+Pj4+DQo+ID4+Pj4+PiBPbiAxNiBKdW4gMjAxNiwgYXQgMjM6MjUsIEpvaG4gTGVzbGllIDxq b2huQGpsYy5uZXQ+IHdyb3RlOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEJsYWNrLCBEYXZpZCA8ZGF2 aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAuLi4gIEkgdmll dyB0aGUgY3VycmVudCB0ZXh0IGFzIHByb3ZpZGluZyBpbXBsZW1lbnRlcnMgd2l0aCB0b28NCj4g bXVjaA0KPiA+Pj4+Pj4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJl Y2F1c2UgYW4gaW1wbGVtZW50ZXINCj4gZG9lc24ndA0KPiA+Pj4+Pj4+IHdhbnQgdG8gdGhpbmsg YWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJzdCBwbGFjZSkuDQo+ID4+Pj4+DQo+ ID4+Pj4+IEkgYWdyZWUsIGJ1dCB0aGUgYXJndW1lbnQgaXMgdGhhdCBkb2luZyBzbyBpcyBsZXNz IGhhcm1mdWwgdGhhbg0KPiBkZXBsb3lpbmcgYQ0KPiA+PiBjaXJjdWl0DQo+ID4+Pj4+IGJyZWFr ZXIgdGhhdCB0cmlnZ2VycyB0b28gb2Z0ZW4gd2hlbiBFQ04gaXMgdXNlZC4NCj4gPj4+Pj4NCj4g Pj4+Pj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQsIHRob3VnaCwgc2lu Y2UgaXQgc2VlbXMgdGhhdA0KPiBhbnkgbmV3DQo+ID4+IEFRTQ0KPiA+Pj4+PiB0aGF0IGFwcGxp ZXMgRUNOIG1hcmtzIG11Y2ggbW9yZSBvZnRlbiB0aGFuIGF0IHByZXNlbnQgd2lsbCBoYXZlDQo+ IHRvDQo+ID4+IGNvbnNpZGVyDQo+ID4+Pj4+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3 b3JrIHdpdGggZGVwbG95ZWQgVENQIChlLmcuLCBkcmFmdC0NCj4gYnJpc2NvZS0NCj4gPj4gdHN2 d2ctDQo+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEg c2lnbmFsIHRvIHVzZSB0aGUgbmV3DQo+IG1hcmtpbmcsDQo+ID4+Pj4+IHdoaWxlIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eQ0KPiBtZWNo YW5pc21zDQo+ID4+Pj4+IHdvdWxkIHNlZW0gdG8gcHJldmVudCB0aGUgaXNzdWVzIHdpdGggdGhl IGNpcmN1aXQgYnJlYWtlciB0b28uDQo+ID4+Pj4+DQo+ID4+Pj4+PiBVbmRlcnN0YW5kLCB3ZSBo YXZlIGF0IGxlYXN0IHR3byBwcm9wb3NhbHMgdG8gbWFrZSBFQ04tQ0UgbW9yZQ0KPiA+PiBmcmVx dWVudA0KPiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3VsZCBiZSBmb3Igbm9uLUVDTiBwYWNr ZXRzOiBwb3NzaWJseQ0KPiBzdWJzdGFudGlhbGx5DQo+ID4+Pj4+PiBtb3JlIGZyZXF1ZW50LiBV bmxlc3MgYm90aCBhcmUga2lsbGVkIG9mZiwgRUNOLUNFIHdpbGwgc2hvdyB1cA0KPiBmcmVxdWVu dGx5DQo+ID4+Pj4+PiBlbm91Z2ggdGhhdCBjbG9zaW5nIHRoZSBmbG93IG9uIEVDTi1DRSB3b3Vs ZCBraWxsIHRvbyBtYW55DQo+IGNvbm5lY3Rpb25zLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IElmIHlv dSB3YW50IGNpcmN1aXQtYnJlYWtpbmcgb24gc3VjaCBjb25uZWN0aW9ucywgdGhlcmUgYXJlIHR3 bw0KPiB3YXlzOg0KPiA+Pj4+Pj4gMS4gY29udmluY2UgdGhlIGZvcndhcmRpbmcgbm9kZXMgdG8g ZHJvcCBwYWNrZXRzIGlmIHRoZWlyIHF1ZXVlDQo+IGV4Y2VlZHMNCj4gPj4+Pj4+IGRlc2lnbiBj YXBhY2l0eTsgb3INCj4gPj4+Pj4+IDIuIHJlcXVpcmUgdGhlIHNlbmRlciB0byBzZW5kIGVub3Vn aCBub3QtRUNOLWNhcGFibGUgcGFja2V0cyBzbw0KPiB0aGF0IG91cg0KPiA+Pj4+Pj4gcmVjZWl2 ZXIgd2lsbCBzZWUgZW5vdWdoIHBhY2tldC1kcm9wcyB3aGVuIGEgY2lyY3VpdC1icmVha2VyDQo+ IHNob3VsZA0KPiA+Pj4+Pj4gYWN0aXZhdGUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKEkgcHJlZmVy IHRoZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0IG9iamVjdCB0byB0aGUgc2Vjb25kLikN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGVyZSByZWFsbHkgaXNuJ3QgYW55IHdheSBmb3Igb3VyIGNp cmN1aXQtYnJlYWtlciB0byBrbm93DQo+IF9ob3dfbXVjaF8NCj4gPj4+Pj4+IG1vcmUgZnJlcXVl bnQgdGhlIEVDTi1DRSBtYXJrcyBtYXkgYmUuIDpeKA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGlzIGlz IGEgcHJvYmxlbSwgYm90aCBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciwgYW5kIGZvciB0aGUNCj4g YWxnb3JpdGhtcyBiZWluZw0KPiA+Pj4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNv bWUgdW5kZXJzdGFuZGluZyB3aGF0IHRoZSBleHBlY3RlZA0KPiA+PiBtYXJraW5nDQo+ID4+Pj4+ IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUsIHNvIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgY2lyY3Vp dCBicmVha2Vycw0KPiBjYW4gYmUNCj4gPj4gZGVmaW5lZC4NCj4gPj4+Pj4NCj4gPj4+Pj4+IFdl IF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+Pj4+Pj4gYWxsb3QgdGhlIHNhbWUgZnJlcXVlbmN5 IG9mIENFIHBhY2tldHMgYXMgcGFja2V0LWRyb3BzIHRvIHRyaWdnZXINCj4gdGhlDQo+ID4+Pj4+ PiBjaXJjdWl0LWJyZWFrZXIuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IENvdWxkIHNvbWVvbmUgcHJv cG9zZSBpbml0aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZSBjdXJyZW50ICJNQVkNCj4gaWdub3Jl Ig0KPiA+Pj4+Pj4+IHN0YXRlbWVudD8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBFc3NlbnRpYWxseSwg Zm9yIHRoZSBzZWNvbmQgb3B0aW9uLCB5b3UgbWlnaHQgcHJvcG9zZSB0ZXh0IHRvIHRoZQ0KPiA+ Pj4+Pj4gZWZmZWN0IG9mOg0KPiA+Pj4+Pj4gXQ0KPiA+Pj4+Pj4gXSBJZiB0b28gbWFueSBFQ04t Q0UgcGFja2V0cyBhcmUgcmVjZWl2ZWQsIHRoZSBzZW5kZXIgU0hPVUxEIHNlbmQNCj4gc29tZQ0K PiA+Pj4+Pj4gXSBub3QtRUNOLWNhcGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUgd2hldGhlciBl bm91Z2ggcGFja2V0cw0KPiBhbG9uZyB0aGUNCj4gPj4+Pj4+IF0gcGF0aCBhcmUgYmVpbmcgZHJv cHBlZCB0byBqdXN0aWZ5IGFjdGl2YXRpbmcgb3VyIGNpcmN1aXQtDQo+IGJyZWFrZXIuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gSeKAmW0gbm90IGVudGh1c2lhc3RpYyBhYm91dCBhZGRpbmcgdGhhdDsg YnV0IGl0IHdvdWxkIHJlc29sdmUgdGhlDQo+IGlzc3VlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJ4oCZ bSBub3QgY29udmluY2VkIHRoaXMgd291bGQgd29yay4gVGhlIGNpcmN1aXQgYnJlYWtlciBpcyBs b29raW5nDQo+IGF0IGxvbmcgdGVybQ0KPiA+Pj4+PiB0cmVuZHMsIGFuZCBpbiBvcmRlciB0byBo YXZlIGVub3VnaCBub3QtRUNUIHBhY2tldHMgdG8gZGV0ZXJtaW5lDQo+IGlmIGl0DQo+ID4+IHNo b3VsZA0KPiA+Pj4+PiB0cmlnZ2VyLCB5b3XigJlkIGVzc2VudGlhbGx5IGhhdmUgdG8gcnVuIHdp dGhvdXQgRUNOIGZvciBzb21lDQo+IHNlY29uZHMuDQo+ID4+Pj4+DQo+ID4+Pj4+IC0tDQo+ID4+ Pj4+IENvbGluIFBlcmtpbnMNCj4gPj4+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiA+Pj4+ DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4+Pj4gcnRjd2ViQGlldGYub3JnDQo+ID4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4gPg0KDQo= From nobody Mon Jun 27 08:41:41 2016 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 191CE12D5B5; Mon, 27 Jun 2016 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-1.426] 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 DFNKh2IxLZfS; Mon, 27 Jun 2016 08:41:35 -0700 (PDT) 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 4324912D868; Mon, 27 Jun 2016 08:38:18 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 778361B00277; Mon, 27 Jun 2016 16:38:06 +0100 (BST) Received: from 148.122.56.254 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 27 Jun 2016 16:38:16 +0100 Message-ID: <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> Date: Mon, 27 Jun 2016 16:38:16 +0100 From: gorry@erg.abdn.ac.uk To: "De Schepper, Koen (Nokia - BE)" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, Magnus Westerlund , tsvwg , Michael Welzl , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:41:39 -0000 I think thinking of L4S is maybe off at a tangent. The question really is about the interpretation of loss and CE-mark as equivalent. I argued that each ECN-CE mark should not be counted as equivalent to a lost segment - in this context we should use ECN to drive a CC algorithm and we should be cautious to avoid requiring its use within a Circuit Breaker - optional use, if you understand how to interpret a reaction to many CE-marks as excessive congestion, are permitted. Gorry > As far as I understand, this draft is related to circuit breakers in > end-systems, right? > > It is the end system that determines the use of ECN (currently marking > non-ect for drop and ect(0) for Classic ECN). > > In L4S we don't plan to change the behavior of Classic ECN, and ABE's > behavior should be close to non-ABE ECN. So I guess there is no problem of > describing the behavior of how a Classic ECN based sender would respond > today. > > As we only want to significantly change the network behavior of ect(1) > marking, can we solve this issue by recommending (or even requiring) > senders to mark only ect(0) and describing the classic ECN circuit > breaker? When L4S gets defined, also an L4S based circuit breaker > extension can be defined for senders that want to use the L4S service > (when senders send ect(1) packets). > > Regards, > Koen. > > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael Welzl >> Sent: maandag 20 juni 2016 18:36 >> To: Black, David >> Cc: Fairhurst; Magnus Westerlund; tsvwg; IETF >> AVTCore WG; rtcweb@ietf.org; Colin Perkins >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft- >> ietf-avtcore-rtp-circuit-breakers-16 >> >> >> > On 20. jun. 2016, at 15.16, Black, David wrote: >> > >> >>> But I’m less concerned than David about eventually ignoring it >> for >> circuit >> >> breaker. >> >>> >> >> Agree. Loss is the measurement that a CB MUST respond to. >> > >> > Mumble. I would be ok with a clear discouragement for use of ECN-CE >> marks, accompanied by the sort of design rationale here, or even >> better, >> a clear statement that lost packets for the purpose of the RTP circuit >> breaker have to be actually lost without getting into whether or not >> ECN-CE marks are involved -i.e., the RTP circuit breaker is specified >> against actual drops as a network protection backstop. >> > >> > A related concern is that ECN marks may overstate equivalent loss >> behavior - a simplistic queue management discipline that marks every >> packet when the queue is over a threshold (NB: this class of marking >> behavior is NOT RECOMMENDED - a real AQM SHOULD be used) could yield a >> run of ECN-CE marks that would not cause a corresponding with a run of >> packet drops. This is among the reasons that TCP reacts to ECN-CE >> marks only once per RTT, and might be a reason to treat multiple ECN-CE >> marks in an RTT interval as not representing drops of all packets for >> the RTP circuit breaker's TCP-equivalent throughput calculation. >> >> I’m not sure we need such complicated logic to find a case where ECN >> marks are different from packet drops: >> >> Basically, they simply aren’t - even “real†AQMs marking isn’t >> exactly >> the same as a packet drop: the marks themselves inform you that an AQM >> did its job, and with modern AQMs like CoDel / PIE etc., you’re >> probably >> getting this from a shallow queue. Chances are that this is less than a >> BDP worth of queuing, which is our justification for recommending a >> different back-off behavior in draft-khademi-tsvwg-ecn-response-00 and >> draft-khademi-tcpm-alternativebackoff-ecn-00 >> >> So the point is not that AQMs would treat ECN marking and dropping >> differently - it’s that ECN indicates an AQM, and hence probably a >> shallow queue. With a drop, you just don’t know. >> >> Back to the CB, I think an AQM marking at a shallow queue (like e.g. >> CoDel) is indeed quite different from a “broken connectionâ€. >> >> Cheers, >> Michael >> >> >> > >> > Thanks, --David >> > >> >> -----Original Message----- >> >> From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] >> >> Sent: Saturday, June 18, 2016 2:23 AM >> >> To: Mirja Kühlewind >> >> Cc: Black, David; Magnus Westerlund; Colin Perkins; rtcweb@ietf.org; >> IETF >> >> AVTCore WG; tsvwg >> >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: >> draft-ietf- >> >> avtcore-rtp-circuit-breakers-16 >> >> >> >> I think we SHOULD NOT recommend to use ECN marks as inputs to a CB. >> See >> >> below: >> >> >> >>> On 17 Jun 2016, at 16:02, Mirja Kühlewind >> >> >> wrote: >> >>> >> >>> +1 to not use normative language here. >> >>> >> >>> However, please note that having a high level of ECN-CE marks >> (without any >> >> losses) means that all packets were received correctly. This >> situation can even >> >> occurs without high delays (depending on the AQM used), which would >> just >> >> mean the services works perfectly. Therefore for me CE marks are a >> perfect input >> >> signal for a congestion control loop (where the AQM tell the sender >> to take action >> >> - whatever that means). >> >> >> >> We may in future figure out ways to do this to detect significant >> failure using a >> >> rate adaptive transport and ECN e.g. Observing 100% CE marks or >> something, for >> >> an RTP flow that is trying to send well below its peak rate decided >> by CC -- but I >> >> think this is speculating at an algorithm and adding details here is >> not a good idea. >> >> Especially as AQM continues to evolve. >> >> >> >>> But I’m less concerned than David about eventually ignoring it >> for >> circuit >> >> breaker. >> >>> >> >> Agree. Loss is the measurement that a CB MUST respond to. >> >> >> >>> In addition one point on something Magnus wrote earlier: >> >>> "If the implementation only have circuit breaker, i.e. no full >> fledged congestion >> >> controller and uses ECN, they can in worst case drive the buffer >> into >> the overload >> >> regime where it starts dropping packets. „ >> >>> >> >>> I’m not sure about this case. ECN is an input signal for >> congestion >> control. If you >> >> don’t use congestion control but only a circuit breaker, you >> should >> probably not >> >> enable ECN. At least it not clear to me why you would enable it, and >> it's definitely >> >> not conform to the ECN spec. Probably we should say something about >> this in the >> >> draft...? >> >>> >> >> Agree, enabling ECN without a responsive CC is going to lead to >> trouble. >> >> >> >>> Mirja >> >>> >> >> Gorry >> >> >> >>>> Am 17.06.2016 um 16:03 schrieb Black, David : >> >>>> >> >>>> Colin, >> >>>> >> >>>>>>> ... I view the current text as providing implementers with too >> much >> >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer >> doesn't >> >>>>>>> want to think about this problem space in the first place). >> >>>>> >> >>>>> I agree, but the argument is that doing so is less harmful than >> deploying a >> >> circuit >> >>>>> breaker that triggers too often when ECN is used. >> >>>>> >> >>>>> I’m not sure I believe this argument, though, since it seems >> that >> any new >> >> AQM >> >>>>> that applies ECN marks much more often than at present will have >> to >> >> consider >> >>>>> backwards compatibility, to work with deployed TCP (e.g., draft- >> briscoe- >> >> tsvwg- >> >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new >> marking, >> >>>>> while existing implementations set ECT(0)). These compatibility >> mechanisms >> >>>>> would seem to prevent the issues with the circuit breaker too. >> >>>> >> >>>> That roughly matches my line of thinking, and I'll observe that >> the >> original >> >> DCTCP >> >>>> protocol design that used more aggressive ECN-CE marking was only >> safe for >> >>>> Controlled Environment deployments. See the TSVWG rfc5405bis >> draft for >> >> the >> >>>> definition of Controlled Environment, and ignore the fact that the >> rfc5405bis >> >>>> draft is a UDP draft - this definition is more broadly applicable. >> >>>> >> >>>> Going back over Section 7 in this avtcore draft, my views are: >> >>>> >> >>>> [A] None of these drafts justify a "MAY ignore" response to ECN-CE >> marks: >> >>>> - draft-khademi-tcpm-alternativebackoff-ecn >> >>>> - draft-ietf-rmcat-nada >> >>>> - draft-ietf-rmcat-scream-cc >> >>>> >> >>>> [B] In line with Colin's comment on the L4S draft, I think it's >> incumbent on >> >>>> the authors of draft-briscoe-aqm-dualq-coupled to figure out how >> that will >> >>>> coexist (or avoid) deployed TCP, and this avtcore draft ought not >> to be >> >>>> trying to prejudge what will be done there. >> >>>> >> >>>> So, I don't think the current text in Section 7 has justified the >> unfettered >> >>>> "implementations MAY ignore ECN-CE marks" text, as ignoring those >> marks >> >>>> is not consistent with any of the four cited drafts. >> >>>> >> >>>> In more detail, I think making changes to normative requirements >> here based >> >>>> on [B] is premature, and I would hope that the rmcat WG could be >> >> encouraged >> >>>> to consider the RTP circuit breaker in its congestion control >> drafts, as those CC >> >>>> mechanisms are related to the circuit breaker mechanism, hence >> likely >> >>>> to be in related areas of an RTP implementation. >> >>>> >> >>>> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG >> >>>> will be looking at in Berlin. If a normative statement about ECN- >> CE reaction >> >>>> is going to rest on that draft, then the reference to that draft >> should be >> >>>> normative. Something about doing that strikes me as premature ... >> >>>> >> >>>> I realize that we're trying to predict and accommodate the future, >> which >> >>>> is an imprecise undertaking at best. As an alternative to the >> current text, >> >>>> would it be reasonable to say (without any RFC 2119 keywords) that >> the >> >>>> best current guidance is still to treat ECN-CE marks as indicating >> drops, >> >>>> with a warning that there is a good possibility of this changing >> in >> the >> >>>> near future due to all of the work in progress cited in Section 7? >> >>>> >> >>>> Thanks, --David >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Colin Perkins [mailto:csp@csperkins.org] >> >>>>> Sent: Friday, June 17, 2016 6:14 AM >> >>>>> To: John Leslie; Black, David >> >>>>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >> >>>>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: >> draft-ietf- >> >>>>> avtcore-rtp-circuit-breakers-16 >> >>>>> >> >>>>> >> >>>>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >> >>>>>> >> >>>>>> Black, David wrote: >> >>>>>>> >> >>>>>>> ... I view the current text as providing implementers with too >> much >> >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer >> doesn't >> >>>>>>> want to think about this problem space in the first place). >> >>>>> >> >>>>> I agree, but the argument is that doing so is less harmful than >> deploying a >> >> circuit >> >>>>> breaker that triggers too often when ECN is used. >> >>>>> >> >>>>> I’m not sure I believe this argument, though, since it seems >> that >> any new >> >> AQM >> >>>>> that applies ECN marks much more often than at present will have >> to >> >> consider >> >>>>> backwards compatibility, to work with deployed TCP (e.g., draft- >> briscoe- >> >> tsvwg- >> >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new >> marking, >> >>>>> while existing implementations set ECT(0)). These compatibility >> mechanisms >> >>>>> would seem to prevent the issues with the circuit breaker too. >> >>>>> >> >>>>>> Understand, we have at least two proposals to make ECN-CE more >> >> frequent >> >>>>>> than packet drop would be for non-ECN packets: possibly >> substantially >> >>>>>> more frequent. Unless both are killed off, ECN-CE will show up >> frequently >> >>>>>> enough that closing the flow on ECN-CE would kill too many >> connections. >> >>>>>> >> >>>>>> If you want circuit-breaking on such connections, there are two >> ways: >> >>>>>> 1. convince the forwarding nodes to drop packets if their queue >> exceeds >> >>>>>> design capacity; or >> >>>>>> 2. require the sender to send enough not-ECN-capable packets so >> that our >> >>>>>> receiver will see enough packet-drops when a circuit-breaker >> should >> >>>>>> activate. >> >>>>>> >> >>>>>> (I prefer the first option; but I wouldn't object to the >> second.) >> >>>>>> >> >>>>>> There really isn't any way for our circuit-breaker to know >> _how_much_ >> >>>>>> more frequent the ECN-CE marks may be. :^( >> >>>>> >> >>>>> This is a problem, both for the circuit breaker, and for the >> algorithms being >> >>>>> defined in RMCAT. We do need some understanding what the expected >> >> marking >> >>>>> rates are likely to be, so congestion control and circuit >> breakers >> can be >> >> defined. >> >>>>> >> >>>>>> We _will_ be sorry if we >> >>>>>> allot the same frequency of CE packets as packet-drops to >> trigger >> the >> >>>>>> circuit-breaker. >> >>>>>> >> >>>>>>> Could someone propose initial text to qualifies the current >> "MAY >> ignore" >> >>>>>>> statement? >> >>>>>> >> >>>>>> Essentially, for the second option, you might propose text to >> the >> >>>>>> effect of: >> >>>>>> ] >> >>>>>> ] If too many ECN-CE packets are received, the sender SHOULD >> send >> some >> >>>>>> ] not-ECN-capable packets to determine whether enough packets >> along the >> >>>>>> ] path are being dropped to justify activating our circuit- >> breaker. >> >>>>>> >> >>>>>> I’m not enthusiastic about adding that; but it would resolve >> the >> issue. >> >>>>> >> >>>>> I’m not convinced this would work. The circuit breaker is >> looking >> at long term >> >>>>> trends, and in order to have enough not-ECT packets to determine >> if it >> >> should >> >>>>> trigger, you’d essentially have to run without ECN for some >> seconds. >> >>>>> >> >>>>> -- >> >>>>> Colin Perkins >> >>>>> https://csperkins.org/ >> >>>> >> >>>> _______________________________________________ >> >>>> rtcweb mailing list >> >>>> rtcweb@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > From nobody Mon Jun 27 12:13:05 2016 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 24A1512D7F8; Mon, 27 Jun 2016 12:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 unfi0uI2xgCz; Mon, 27 Jun 2016 12:12:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC35A12D7D1; Mon, 27 Jun 2016 12:12:54 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B03A0F90A1507; Mon, 27 Jun 2016 19:12:48 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5RJCpTx026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jun 2016 19:12:52 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5RJCpZH011789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jun 2016 21:12:51 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 27 Jun 2016 21:12:51 +0200 From: "De Schepper, Koen (Nokia - BE)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4Xv7l4815Xu02SCqscZNZxsp/tUDQAgABAKwCAABBvgIABAQmAgAOYcQCAADeCAIAK/Ekg///0AQCAAFzOEA== Date: Mon, 27 Jun 2016 19:12:50 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> In-Reply-To: <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Magnus Westerlund , tsvwg , Michael Welzl , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 19:12:59 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGdvcnJ5QGVyZy5hYmRuLmFj LnVrIFttYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWtdDQo+IFNlbnQ6IG1hYW5kYWcgMjcganVu aSAyMDE2IDE3OjM4DQo+IFRvOiBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRSkNCj4gQ2M6 IE1pY2hhZWwgV2Vsemw7IEJsYWNrLCBEYXZpZDsgZ29ycnlAZXJnLmFiZG4uYWMudWs7IE1hZ251 cw0KPiBXZXN0ZXJsdW5kOyB0c3Z3ZzsgSUVURiBBVlRDb3JlIFdHOyBydGN3ZWJAaWV0Zi5vcmc7 IENvbGluIFBlcmtpbnMNCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVd IFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOiBkcmFmdC0NCj4gaWV0Zi1hdnRjb3JlLXJ0cC1jaXJj dWl0LWJyZWFrZXJzLTE2DQo+IA0KPiBJIHRoaW5rIHRoaW5raW5nIG9mIEw0UyBpcyBtYXliZSBv ZmYgYXQgYSB0YW5nZW50LiBUaGUgcXVlc3Rpb24gcmVhbGx5DQo+IGlzDQo+IGFib3V0IHRoZSBp bnRlcnByZXRhdGlvbiBvZiBsb3NzIGFuZCBDRS1tYXJrIGFzIGVxdWl2YWxlbnQuIEkgYXJndWVk DQo+IHRoYXQNCj4gZWFjaCBFQ04tQ0UgbWFyayBzaG91bGQgbm90IGJlIGNvdW50ZWQgYXMgZXF1 aXZhbGVudCB0byBhIGxvc3Qgc2VnbWVudCAtDQoNCldoeSBub3Q/IEFzIGxvbmcgYXMgYW4gQVFN IGlzIG1hcmtpbmcgYXQgdGhlIHNhbWUgcmF0ZSBhcyBkcm9wcGluZywgYSANCjEwMCUgbWFya2lu ZyBtZWFucyB0aGF0IG5vbi1lY24gZmxvd3MgYXJlIGJlaW5nIGRyb3BwZWQgYXQgYSAxMDAlLCBu b3Q/DQoNCktvZW4uDQoNCg0KPiBpbiB0aGlzIGNvbnRleHQgd2Ugc2hvdWxkIHVzZSBFQ04gdG8g ZHJpdmUgYSBDQyBhbGdvcml0aG0gYW5kIHdlIHNob3VsZA0KPiBiZQ0KPiBjYXV0aW91cyB0byBh dm9pZCByZXF1aXJpbmcgaXRzIHVzZSB3aXRoaW4gYSBDaXJjdWl0IEJyZWFrZXIgLSBvcHRpb25h bA0KPiB1c2UsIGlmIHlvdSB1bmRlcnN0YW5kIGhvdyB0byBpbnRlcnByZXQgYSByZWFjdGlvbiB0 byBtYW55IENFLW1hcmtzIGFzDQo+IGV4Y2Vzc2l2ZSBjb25nZXN0aW9uLCBhcmUgcGVybWl0dGVk Lg0KPiANCj4gR29ycnkNCj4gDQo+ID4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhpcyBkcmFm dCBpcyByZWxhdGVkIHRvIGNpcmN1aXQgYnJlYWtlcnMgaW4NCj4gPiBlbmQtc3lzdGVtcywgcmln aHQ/DQo+ID4NCj4gPiBJdCBpcyB0aGUgZW5kIHN5c3RlbSB0aGF0IGRldGVybWluZXMgdGhlIHVz ZSBvZiBFQ04gKGN1cnJlbnRseSBtYXJraW5nDQo+ID4gbm9uLWVjdCBmb3IgZHJvcCBhbmQgZWN0 KDApIGZvciBDbGFzc2ljIEVDTikuDQo+ID4NCj4gPiBJbiBMNFMgd2UgZG9uJ3QgcGxhbiB0byBj aGFuZ2UgdGhlIGJlaGF2aW9yIG9mIENsYXNzaWMgRUNOLCBhbmQgQUJFJ3MNCj4gPiBiZWhhdmlv ciBzaG91bGQgYmUgY2xvc2UgdG8gbm9uLUFCRSBFQ04uIFNvIEkgZ3Vlc3MgdGhlcmUgaXMgbm8N Cj4gcHJvYmxlbSBvZg0KPiA+IGRlc2NyaWJpbmcgdGhlIGJlaGF2aW9yIG9mIGhvdyBhIENsYXNz aWMgRUNOIGJhc2VkIHNlbmRlciB3b3VsZA0KPiByZXNwb25kDQo+ID4gdG9kYXkuDQo+ID4NCj4g PiBBcyB3ZSBvbmx5IHdhbnQgdG8gc2lnbmlmaWNhbnRseSBjaGFuZ2UgdGhlIG5ldHdvcmsgYmVo YXZpb3Igb2YgZWN0KDEpDQo+ID4gbWFya2luZywgY2FuIHdlIHNvbHZlIHRoaXMgaXNzdWUgYnkg cmVjb21tZW5kaW5nIChvciBldmVuIHJlcXVpcmluZykNCj4gPiBzZW5kZXJzIHRvIG1hcmsgb25s eSBlY3QoMCkgYW5kIGRlc2NyaWJpbmcgdGhlIGNsYXNzaWMgRUNOIGNpcmN1aXQNCj4gPiBicmVh a2VyPyBXaGVuIEw0UyBnZXRzIGRlZmluZWQsIGFsc28gYW4gTDRTIGJhc2VkIGNpcmN1aXQgYnJl YWtlcg0KPiA+IGV4dGVuc2lvbiBjYW4gYmUgZGVmaW5lZCBmb3Igc2VuZGVycyB0aGF0IHdhbnQg dG8gdXNlIHRoZSBMNFMgc2VydmljZQ0KPiA+ICh3aGVuIHNlbmRlcnMgc2VuZCBlY3QoMSkgcGFj a2V0cykuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IEtvZW4uDQo+ID4NCj4gPg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsDQo+IFdlbHpsDQo+ID4+IFNlbnQ6 IG1hYW5kYWcgMjAganVuaSAyMDE2IDE4OjM2DQo+ID4+IFRvOiBCbGFjaywgRGF2aWQNCj4gPj4g Q2M6IDxnb3JyeUBlcmcuYWJkbi5hYy51az4gRmFpcmh1cnN0OyBNYWdudXMgV2VzdGVybHVuZDsg dHN2d2c7IElFVEYNCj4gPj4gQVZUQ29yZSBXRzsgcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJr aW5zDQo+ID4+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0 IENhbGwgb24gY2hhbmdlczoNCj4gZHJhZnQtDQo+ID4+IGlldGYtYXZ0Y29yZS1ydHAtY2lyY3Vp dC1icmVha2Vycy0xNg0KPiA+Pg0KPiA+Pg0KPiA+PiA+IE9uIDIwLiBqdW4uIDIwMTYsIGF0IDE1 LjE2LCBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+DQo+IHdyb3RlOg0KPiA+PiA+ DQo+ID4+ID4+PiBCdXQgScOi4oKs4oSibSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0 IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQNCj4gPj4gZm9yDQo+ID4+IGNpcmN1aXQNCj4gPj4gPj4g YnJlYWtlci4NCj4gPj4gPj4+DQo+ID4+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFzdXJlbWVu dCB0aGF0IGEgQ0IgTVVTVCByZXNwb25kIHRvLg0KPiA+PiA+DQo+ID4+ID4gTXVtYmxlLiAgIEkg d291bGQgYmUgb2sgd2l0aCBhIGNsZWFyIGRpc2NvdXJhZ2VtZW50IGZvciB1c2Ugb2YgRUNOLQ0K PiBDRQ0KPiA+PiBtYXJrcywgYWNjb21wYW5pZWQgYnkgdGhlIHNvcnQgb2YgZGVzaWduIHJhdGlv bmFsZSBoZXJlLCBvciBldmVuDQo+ID4+IGJldHRlciwNCj4gPj4gYSBjbGVhciBzdGF0ZW1lbnQg dGhhdCBsb3N0IHBhY2tldHMgZm9yIHRoZSBwdXJwb3NlIG9mIHRoZSBSVFANCj4gY2lyY3VpdA0K PiA+PiBicmVha2VyIGhhdmUgdG8gYmUgYWN0dWFsbHkgbG9zdCB3aXRob3V0IGdldHRpbmcgaW50 byB3aGV0aGVyIG9yIG5vdA0KPiA+PiBFQ04tQ0UgbWFya3MgYXJlIGludm9sdmVkIC1pLmUuLCB0 aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBpcyBzcGVjaWZpZWQNCj4gPj4gYWdhaW5zdCBhY3R1YWwg ZHJvcHMgYXMgYSBuZXR3b3JrIHByb3RlY3Rpb24gYmFja3N0b3AuDQo+ID4+ID4NCj4gPj4gPiBB IHJlbGF0ZWQgY29uY2VybiBpcyB0aGF0IEVDTiBtYXJrcyBtYXkgb3ZlcnN0YXRlIGVxdWl2YWxl bnQgbG9zcw0KPiA+PiBiZWhhdmlvciAtIGEgc2ltcGxpc3RpYyBxdWV1ZSBtYW5hZ2VtZW50IGRp c2NpcGxpbmUgdGhhdCBtYXJrcyBldmVyeQ0KPiA+PiBwYWNrZXQgd2hlbiB0aGUgcXVldWUgaXMg b3ZlciBhIHRocmVzaG9sZCAoTkI6IHRoaXMgY2xhc3Mgb2YgbWFya2luZw0KPiA+PiBiZWhhdmlv ciBpcyBOT1QgUkVDT01NRU5ERUQgLSBhIHJlYWwgQVFNIFNIT1VMRCBiZSB1c2VkKSBjb3VsZCB5 aWVsZA0KPiBhDQo+ID4+IHJ1biBvZiBFQ04tQ0UgbWFya3MgdGhhdCB3b3VsZCBub3QgY2F1c2Ug YSBjb3JyZXNwb25kaW5nIHdpdGggYSBydW4NCj4gb2YNCj4gPj4gcGFja2V0IGRyb3BzLiAgIFRo aXMgaXMgYW1vbmcgdGhlIHJlYXNvbnMgdGhhdCBUQ1AgcmVhY3RzIHRvIEVDTi1DRQ0KPiA+PiBt YXJrcyBvbmx5IG9uY2UgcGVyIFJUVCwgYW5kIG1pZ2h0IGJlIGEgcmVhc29uIHRvIHRyZWF0IG11 bHRpcGxlIEVDTi0NCj4gQ0UNCj4gPj4gbWFya3MgaW4gYW4gUlRUIGludGVydmFsIGFzIG5vdCBy ZXByZXNlbnRpbmcgZHJvcHMgb2YgYWxsIHBhY2tldHMgZm9yDQo+ID4+IHRoZSBSVFAgY2lyY3Vp dCBicmVha2VyJ3MgVENQLWVxdWl2YWxlbnQgdGhyb3VnaHB1dCBjYWxjdWxhdGlvbi4NCj4gPj4N Cj4gPj4gScOi4oKs4oSibSBub3Qgc3VyZSB3ZSBuZWVkIHN1Y2ggY29tcGxpY2F0ZWQgbG9naWMg dG8gZmluZCBhIGNhc2Ugd2hlcmUNCj4gRUNODQo+ID4+IG1hcmtzIGFyZSBkaWZmZXJlbnQgZnJv bSBwYWNrZXQgZHJvcHM6DQo+ID4+DQo+ID4+IEJhc2ljYWxseSwgdGhleSBzaW1wbHkgYXJlbsOi 4oKs4oSidCAtIGV2ZW4gw6LigqzFk3JlYWzDouKCrMKdIEFRTXMgbWFya2luZw0KPiBpc27DouKC rOKEonQNCj4gPj4gZXhhY3RseQ0KPiA+PiB0aGUgc2FtZSBhcyBhIHBhY2tldCBkcm9wOiB0aGUg bWFya3MgdGhlbXNlbHZlcyBpbmZvcm0geW91IHRoYXQgYW4NCj4gQVFNDQo+ID4+IGRpZCBpdHMg am9iLCBhbmQgd2l0aCBtb2Rlcm4gQVFNcyBsaWtlIENvRGVsIC8gUElFIGV0Yy4sIHlvdcOi4oKs 4oSicmUNCj4gPj4gcHJvYmFibHkNCj4gPj4gZ2V0dGluZyB0aGlzIGZyb20gYSBzaGFsbG93IHF1 ZXVlLiBDaGFuY2VzIGFyZSB0aGF0IHRoaXMgaXMgbGVzcyB0aGFuDQo+IGENCj4gPj4gQkRQIHdv cnRoIG9mIHF1ZXVpbmcsIHdoaWNoIGlzIG91ciBqdXN0aWZpY2F0aW9uIGZvciByZWNvbW1lbmRp bmcgYQ0KPiA+PiBkaWZmZXJlbnQgYmFjay1vZmYgYmVoYXZpb3IgaW4gZHJhZnQta2hhZGVtaS10 c3Z3Zy1lY24tcmVzcG9uc2UtMDANCj4gYW5kDQo+ID4+IGRyYWZ0LWtoYWRlbWktdGNwbS1hbHRl cm5hdGl2ZWJhY2tvZmYtZWNuLTAwDQo+ID4+DQo+ID4+IFNvIHRoZSBwb2ludCBpcyBub3QgdGhh dCBBUU1zIHdvdWxkIHRyZWF0IEVDTiBtYXJraW5nIGFuZCBkcm9wcGluZw0KPiA+PiBkaWZmZXJl bnRseSAtIGl0w6LigqzihKJzIHRoYXQgRUNOIGluZGljYXRlcyBhbiBBUU0sIGFuZCBoZW5jZSBw cm9iYWJseSBhDQo+ID4+IHNoYWxsb3cgcXVldWUuIFdpdGggYSBkcm9wLCB5b3UganVzdCBkb27D ouKCrOKEonQga25vdy4NCj4gPj4NCj4gPj4gQmFjayB0byB0aGUgQ0IsIEkgdGhpbmsgYW4gQVFN IG1hcmtpbmcgYXQgYSBzaGFsbG93IHF1ZXVlIChsaWtlIGUuZy4NCj4gPj4gQ29EZWwpIGlzIGlu ZGVlZCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSBhIMOi4oKsxZNicm9rZW4gY29ubmVjdGlvbsOi4oKs wp0uDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4gTWljaGFlbA0KPiA+Pg0KPiA+Pg0KPiA+PiA+ DQo+ID4+ID4gVGhhbmtzLCAtLURhdmlkDQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4gPj4gRnJvbTogR29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcu YWJkbi5hYy51a10NCj4gPj4gPj4gU2VudDogU2F0dXJkYXksIEp1bmUgMTgsIDIwMTYgMjoyMyBB TQ0KPiA+PiA+PiBUbzogTWlyamEgS8ODwrxobGV3aW5kDQo+ID4+ID4+IENjOiBCbGFjaywgRGF2 aWQ7IE1hZ251cyBXZXN0ZXJsdW5kOyBDb2xpbiBQZXJraW5zOw0KPiBydGN3ZWJAaWV0Zi5vcmc7 DQo+ID4+IElFVEYNCj4gPj4gPj4gQVZUQ29yZSBXRzsgdHN2d2cNCj4gPj4gPj4gU3ViamVjdDog UmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0K PiA+PiBkcmFmdC1pZXRmLQ0KPiA+PiA+PiBhdnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2 DQo+ID4+ID4+DQo+ID4+ID4+IEkgdGhpbmsgd2UgU0hPVUxEIE5PVCByZWNvbW1lbmQgdG8gdXNl IEVDTiBtYXJrcyBhcyBpbnB1dHMgdG8gYQ0KPiBDQi4NCj4gPj4gU2VlDQo+ID4+ID4+IGJlbG93 Og0KPiA+PiA+Pg0KPiA+PiA+Pj4gT24gMTcgSnVuIDIwMTYsIGF0IDE2OjAyLCBNaXJqYSBLw4PC vGhsZXdpbmQNCj4gPj4gPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+DQo+ID4+ID4+ IHdyb3RlOg0KPiA+PiA+Pj4NCj4gPj4gPj4+ICsxIHRvIG5vdCB1c2Ugbm9ybWF0aXZlIGxhbmd1 YWdlIGhlcmUuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gSG93ZXZlciwgcGxlYXNlIG5vdGUgdGhhdCBo YXZpbmcgYSBoaWdoIGxldmVsIG9mIEVDTi1DRSBtYXJrcw0KPiA+PiAod2l0aG91dCBhbnkNCj4g Pj4gPj4gbG9zc2VzKSBtZWFucyB0aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVj dGx5LiBUaGlzDQo+ID4+IHNpdHVhdGlvbiBjYW4gZXZlbg0KPiA+PiA+PiBvY2N1cnMgd2l0aG91 dCBoaWdoIGRlbGF5cyAoZGVwZW5kaW5nIG9uIHRoZSBBUU0gdXNlZCksIHdoaWNoDQo+IHdvdWxk DQo+ID4+IGp1c3QNCj4gPj4gPj4gbWVhbiB0aGUgc2VydmljZXMgd29ya3MgcGVyZmVjdGx5LiBU aGVyZWZvcmUgZm9yIG1lIENFIG1hcmtzIGFyZSBhDQo+ID4+IHBlcmZlY3QgaW5wdXQNCj4gPj4g Pj4gc2lnbmFsIGZvciBhIGNvbmdlc3Rpb24gY29udHJvbCBsb29wICh3aGVyZSB0aGUgQVFNIHRl bGwgdGhlDQo+IHNlbmRlcg0KPiA+PiB0byB0YWtlIGFjdGlvbg0KPiA+PiA+PiAtIHdoYXRldmVy IHRoYXQgbWVhbnMpLg0KPiA+PiA+Pg0KPiA+PiA+PiBXZSBtYXkgaW4gZnV0dXJlIGZpZ3VyZSBv dXQgd2F5cyB0byBkbyB0aGlzIHRvIGRldGVjdCBzaWduaWZpY2FudA0KPiA+PiBmYWlsdXJlIHVz aW5nIGENCj4gPj4gPj4gcmF0ZSBhZGFwdGl2ZSB0cmFuc3BvcnQgYW5kIEVDTiBlLmcuICBPYnNl cnZpbmcgMTAwJSBDRSBtYXJrcyBvcg0KPiA+PiBzb21ldGhpbmcsIGZvcg0KPiA+PiA+PiBhbiBS VFAgZmxvdyB0aGF0IGlzIHRyeWluZyB0byBzZW5kIHdlbGwgYmVsb3cgaXRzIHBlYWsgcmF0ZQ0K PiBkZWNpZGVkDQo+ID4+IGJ5IENDIC0tIGJ1dCBJDQo+ID4+ID4+IHRoaW5rIHRoaXMgaXMgc3Bl Y3VsYXRpbmcgYXQgYW4gYWxnb3JpdGhtIGFuZCBhZGRpbmcgZGV0YWlscyBoZXJlDQo+IGlzDQo+ ID4+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPj4gPj4gRXNwZWNpYWxseSBhcyBBUU0gY29udGludWVz IHRvIGV2b2x2ZS4NCj4gPj4gPj4NCj4gPj4gPj4+IEJ1dCBJw6LigqzihKJtIGxlc3MgY29uY2Vy bmVkIHRoYW4gRGF2aWQgYWJvdXQgZXZlbnR1YWxseSBpZ25vcmluZyBpdA0KPiA+PiBmb3INCj4g Pj4gY2lyY3VpdA0KPiA+PiA+PiBicmVha2VyLg0KPiA+PiA+Pj4NCj4gPj4gPj4gQWdyZWUuIExv c3MgaXMgdGhlIG1lYXN1cmVtZW50IHRoYXQgYSBDQiBNVVNUIHJlc3BvbmQgdG8uDQo+ID4+ID4+ DQo+ID4+ID4+PiBJbiBhZGRpdGlvbiBvbmUgcG9pbnQgb24gc29tZXRoaW5nIE1hZ251cyB3cm90 ZSBlYXJsaWVyOg0KPiA+PiA+Pj4gIklmIHRoZSBpbXBsZW1lbnRhdGlvbiBvbmx5IGhhdmUgY2ly Y3VpdCBicmVha2VyLCBpLmUuIG5vIGZ1bGwNCj4gPj4gZmxlZGdlZCBjb25nZXN0aW9uDQo+ID4+ ID4+IGNvbnRyb2xsZXIgYW5kIHVzZXMgRUNOLCB0aGV5IGNhbiBpbiB3b3JzdCBjYXNlIGRyaXZl IHRoZSBidWZmZXINCj4gPj4gaW50bw0KPiA+PiB0aGUgb3ZlcmxvYWQNCj4gPj4gPj4gcmVnaW1l IHdoZXJlIGl0IHN0YXJ0cyBkcm9wcGluZyBwYWNrZXRzLiDDouKCrMW+DQo+ID4+ID4+Pg0KPiA+ PiA+Pj4gScOi4oKs4oSibSBub3Qgc3VyZSBhYm91dCB0aGlzIGNhc2UuIEVDTiBpcyBhbiBpbnB1 dCBzaWduYWwgZm9yDQo+ID4+IGNvbmdlc3Rpb24NCj4gPj4gY29udHJvbC4gSWYgeW91DQo+ID4+ ID4+IGRvbsOi4oKs4oSidCB1c2UgY29uZ2VzdGlvbiBjb250cm9sIGJ1dCBvbmx5IGEgY2lyY3Vp dCBicmVha2VyLCB5b3UNCj4gPj4gc2hvdWxkDQo+ID4+IHByb2JhYmx5IG5vdA0KPiA+PiA+PiBl bmFibGUgRUNOLiBBdCBsZWFzdCBpdCBub3QgY2xlYXIgdG8gbWUgd2h5IHlvdSB3b3VsZCBlbmFi bGUgaXQsDQo+IGFuZA0KPiA+PiBpdCdzIGRlZmluaXRlbHkNCj4gPj4gPj4gbm90IGNvbmZvcm0g dG8gdGhlIEVDTiBzcGVjLiBQcm9iYWJseSB3ZSBzaG91bGQgc2F5IHNvbWV0aGluZw0KPiBhYm91 dA0KPiA+PiB0aGlzIGluIHRoZQ0KPiA+PiA+PiBkcmFmdC4uLj8NCj4gPj4gPj4+DQo+ID4+ID4+ IEFncmVlLCBlbmFibGluZyBFQ04gd2l0aG91dCBhIHJlc3BvbnNpdmUgQ0MgaXMgZ29pbmcgdG8g bGVhZCB0bw0KPiA+PiB0cm91YmxlLg0KPiA+PiA+Pg0KPiA+PiA+Pj4gTWlyamENCj4gPj4gPj4+ DQo+ID4+ID4+IEdvcnJ5DQo+ID4+ID4+DQo+ID4+ID4+Pj4gQW0gMTcuMDYuMjAxNiB1bSAxNjow MyBzY2hyaWViIEJsYWNrLCBEYXZpZA0KPiA8ZGF2aWQuYmxhY2tAZW1jLmNvbT46DQo+ID4+ID4+ Pj4NCj4gPj4gPj4+PiBDb2xpbiwNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+Pj4+IC4uLiAgSSB2aWV3 IHRoZSBjdXJyZW50IHRleHQgYXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoDQo+IHRvbw0K PiA+PiBtdWNoDQo+ID4+ID4+Pj4+Pj4gbGF0aXR1ZGUgdG8gaWdub3JlIEVDTi1DRSBtYXJrcyAo ZS5nLiwgYmVjYXVzZSBhbiBpbXBsZW1lbnRlcg0KPiA+PiBkb2Vzbid0DQo+ID4+ID4+Pj4+Pj4g d2FudCB0byB0aGluayBhYm91dCB0aGlzIHByb2JsZW0gc3BhY2UgaW4gdGhlIGZpcnN0IHBsYWNl KS4NCj4gPj4gPj4+Pj4NCj4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0IHRoZSBhcmd1bWVudCBpcyB0 aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bCB0aGFuDQo+ID4+IGRlcGxveWluZyBhDQo+ID4+ ID4+IGNpcmN1aXQNCj4gPj4gPj4+Pj4gYnJlYWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3 aGVuIEVDTiBpcyB1c2VkLg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBJw6LigqzihKJtIG5vdCBz dXJlIEkgYmVsaWV2ZSB0aGlzIGFyZ3VtZW50LCB0aG91Z2gsIHNpbmNlIGl0IHNlZW1zDQo+ID4+ IHRoYXQNCj4gPj4gYW55IG5ldw0KPiA+PiA+PiBBUU0NCj4gPj4gPj4+Pj4gdGhhdCBhcHBsaWVz IEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gaGF2ZQ0K PiA+PiB0bw0KPiA+PiA+PiBjb25zaWRlcg0KPiA+PiA+Pj4+PiBiYWNrd2FyZHMgY29tcGF0aWJp bGl0eSwgdG8gd29yayB3aXRoIGRlcGxveWVkIFRDUCAoZS5nLiwNCj4gZHJhZnQtDQo+ID4+IGJy aXNjb2UtDQo+ID4+ID4+IHRzdndnLQ0KPiA+PiA+Pj4+PiBhcW0tdGNwbS1ybWNhdC1sNHMtcHJv YmxlbSB1c2VzIEVDVCgxKSBhcyBhIHNpZ25hbCB0byB1c2UgdGhlDQo+IG5ldw0KPiA+PiBtYXJr aW5nLA0KPiA+PiA+Pj4+PiB3aGlsZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgc2V0IEVDVCgw KSkuIFRoZXNlIGNvbXBhdGliaWxpdHkNCj4gPj4gbWVjaGFuaXNtcw0KPiA+PiA+Pj4+PiB3b3Vs ZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG9v Lg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNoZXMgbXkgbGluZSBvZiB0 aGlua2luZywgYW5kIEknbGwgb2JzZXJ2ZSB0aGF0DQo+ID4+IHRoZQ0KPiA+PiBvcmlnaW5hbA0K PiA+PiA+PiBEQ1RDUA0KPiA+PiA+Pj4+IHByb3RvY29sIGRlc2lnbiB0aGF0IHVzZWQgbW9yZSBh Z2dyZXNzaXZlIEVDTi1DRSBtYXJraW5nIHdhcw0KPiBvbmx5DQo+ID4+IHNhZmUgZm9yDQo+ID4+ ID4+Pj4gQ29udHJvbGxlZCBFbnZpcm9ubWVudCBkZXBsb3ltZW50cy4gICBTZWUgdGhlIFRTVldH IHJmYzU0MDViaXMNCj4gPj4gZHJhZnQgZm9yDQo+ID4+ID4+IHRoZQ0KPiA+PiA+Pj4+IGRlZmlu aXRpb24gb2YgQ29udHJvbGxlZCBFbnZpcm9ubWVudCwgYW5kIGlnbm9yZSB0aGUgZmFjdCB0aGF0 DQo+IHRoZQ0KPiA+PiByZmM1NDA1YmlzDQo+ID4+ID4+Pj4gZHJhZnQgaXMgYSBVRFAgZHJhZnQg LSB0aGlzIGRlZmluaXRpb24gaXMgbW9yZSBicm9hZGx5DQo+IGFwcGxpY2FibGUuDQo+ID4+ID4+ Pj4NCj4gPj4gPj4+PiBHb2luZyBiYWNrIG92ZXIgU2VjdGlvbiA3IGluIHRoaXMgYXZ0Y29yZSBk cmFmdCwgbXkgdmlld3MgYXJlOg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gW0FdIE5vbmUgb2YgdGhl c2UgZHJhZnRzIGp1c3RpZnkgYSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8gRUNOLQ0KPiBDRQ0K PiA+PiBtYXJrczoNCj4gPj4gPj4+PiAgIC0gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZl YmFja29mZi1lY24NCj4gPj4gPj4+PiAgIC0gZHJhZnQtaWV0Zi1ybWNhdC1uYWRhDQo+ID4+ID4+ Pj4gICAtIGRyYWZ0LWlldGYtcm1jYXQtc2NyZWFtLWNjDQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBb Ql0gSW4gbGluZSB3aXRoIENvbGluJ3MgY29tbWVudCBvbiB0aGUgTDRTIGRyYWZ0LCBJIHRoaW5r IGl0J3MNCj4gPj4gaW5jdW1iZW50IG9uDQo+ID4+ID4+Pj4gdGhlIGF1dGhvcnMgb2YgZHJhZnQt YnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBmaWd1cmUgb3V0IGhvdw0KPiA+PiB0aGF0IHdp bGwNCj4gPj4gPj4+PiBjb2V4aXN0IChvciBhdm9pZCkgZGVwbG95ZWQgVENQLCBhbmQgdGhpcyBh dnRjb3JlIGRyYWZ0IG91Z2h0DQo+IG5vdA0KPiA+PiB0byBiZQ0KPiA+PiA+Pj4+IHRyeWluZyB0 byBwcmVqdWRnZSB3aGF0IHdpbGwgYmUgZG9uZSB0aGVyZS4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+ IFNvLCBJIGRvbid0IHRoaW5rIHRoZSBjdXJyZW50IHRleHQgaW4gU2VjdGlvbiA3IGhhcyBqdXN0 aWZpZWQNCj4gdGhlDQo+ID4+IHVuZmV0dGVyZWQNCj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb25z IE1BWSBpZ25vcmUgRUNOLUNFIG1hcmtzIiB0ZXh0LCBhcyBpZ25vcmluZw0KPiB0aG9zZQ0KPiA+ PiBtYXJrcw0KPiA+PiA+Pj4+IGlzIG5vdCBjb25zaXN0ZW50IHdpdGggYW55IG9mIHRoZSBmb3Vy IGNpdGVkIGRyYWZ0cy4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IEluIG1vcmUgZGV0YWlsLCBJIHRo aW5rIG1ha2luZyBjaGFuZ2VzIHRvIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMNCj4gPj4gaGVyZSBi YXNlZA0KPiA+PiA+Pj4+IG9uIFtCXSBpcyBwcmVtYXR1cmUsIGFuZCBJIHdvdWxkIGhvcGUgdGhh dCB0aGUgcm1jYXQgV0cgY291bGQgYmUNCj4gPj4gPj4gZW5jb3VyYWdlZA0KPiA+PiA+Pj4+IHRv IGNvbnNpZGVyIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGluIGl0cyBjb25nZXN0aW9uIGNvbnRy b2wNCj4gPj4gZHJhZnRzLCBhcyB0aG9zZSBDQw0KPiA+PiA+Pj4+IG1lY2hhbmlzbXMgYXJlIHJl bGF0ZWQgdG8gdGhlIGNpcmN1aXQgYnJlYWtlciBtZWNoYW5pc20sIGhlbmNlDQo+ID4+IGxpa2Vs eQ0KPiA+PiA+Pj4+IHRvIGJlIGluIHJlbGF0ZWQgYXJlYXMgb2YgYW4gUlRQIGltcGxlbWVudGF0 aW9uLg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gVGhhdCBsZWF2ZXMgZHJhZnQta2hhZGVtaS10Y3Bt LWFsdGVybmF0aXZlYmFja29mZi1lY24sIHdoaWNoDQo+IFRTVldHDQo+ID4+ID4+Pj4gd2lsbCBi ZSBsb29raW5nIGF0IGluIEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudCBhYm91dA0K PiBFQ04tDQo+ID4+IENFIHJlYWN0aW9uDQo+ID4+ID4+Pj4gaXMgZ29pbmcgdG8gcmVzdCBvbiB0 aGF0IGRyYWZ0LCB0aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdCBkcmFmdA0KPiA+PiBzaG91bGQg YmUNCj4gPj4gPj4+PiBub3JtYXRpdmUuICBTb21ldGhpbmcgYWJvdXQgZG9pbmcgdGhhdCBzdHJp a2VzIG1lIGFzIHByZW1hdHVyZQ0KPiAuLi4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IEkgcmVhbGl6 ZSB0aGF0IHdlJ3JlIHRyeWluZyB0byBwcmVkaWN0IGFuZCBhY2NvbW1vZGF0ZSB0aGUNCj4gZnV0 dXJlLA0KPiA+PiB3aGljaA0KPiA+PiA+Pj4+IGlzIGFuIGltcHJlY2lzZSB1bmRlcnRha2luZyBh dCBiZXN0LiAgIEFzIGFuIGFsdGVybmF0aXZlIHRvIHRoZQ0KPiA+PiBjdXJyZW50IHRleHQsDQo+ ID4+ID4+Pj4gd291bGQgaXQgYmUgcmVhc29uYWJsZSB0byBzYXkgKHdpdGhvdXQgYW55IFJGQyAy MTE5IGtleXdvcmRzKQ0KPiB0aGF0DQo+ID4+IHRoZQ0KPiA+PiA+Pj4+IGJlc3QgY3VycmVudCBn dWlkYW5jZSBpcyBzdGlsbCB0byB0cmVhdCBFQ04tQ0UgbWFya3MgYXMNCj4gaW5kaWNhdGluZw0K PiA+PiBkcm9wcywNCj4gPj4gPj4+PiB3aXRoIGEgd2FybmluZyB0aGF0IHRoZXJlIGlzIGEgZ29v ZCBwb3NzaWJpbGl0eSBvZiB0aGlzIGNoYW5naW5nDQo+ID4+IGluDQo+ID4+IHRoZQ0KPiA+PiA+ Pj4+IG5lYXIgZnV0dXJlIGR1ZSB0byBhbGwgb2YgdGhlIHdvcmsgaW4gcHJvZ3Jlc3MgY2l0ZWQg aW4gU2VjdGlvbg0KPiA3Pw0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gVGhhbmtzLCAtLURhdmlkDQo+ ID4+ID4+Pj4NCj4gPj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4+ Pj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0KPiA+PiA+ Pj4+PiBTZW50OiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgNjoxNCBBTQ0KPiA+PiA+Pj4+PiBUbzog Sm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+PiA+Pj4+PiBDYzogcnRjd2ViQGlldGYub3Jn OyBJRVRGIEFWVENvcmUgV0c7IHRzdndnDQo+ID4+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbcnRjd2Vi XSBbQVZUQ09SRV0gW3RzdndnXSBXRyBMYXN0IENhbGwgb24NCj4gY2hhbmdlczoNCj4gPj4gZHJh ZnQtaWV0Zi0NCj4gPj4gPj4+Pj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiA+ PiA+Pj4+Pg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+Pj4gT24gMTYgSnVuIDIwMTYsIGF0IDIzOjI1 LCBKb2huIExlc2xpZSA8am9obkBqbGMubmV0PiB3cm90ZToNCj4gPj4gPj4+Pj4+DQo+ID4+ID4+ Pj4+PiBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+IHdyb3RlOg0KPiA+PiA+Pj4+ Pj4+DQo+ID4+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRp bmcgaW1wbGVtZW50ZXJzIHdpdGgNCj4gdG9vDQo+ID4+IG11Y2gNCj4gPj4gPj4+Pj4+PiBsYXRp dHVkZSB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIChlLmcuLCBiZWNhdXNlIGFuIGltcGxlbWVudGVy DQo+ID4+IGRvZXNuJ3QNCj4gPj4gPj4+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJv YmxlbSBzcGFjZSBpbiB0aGUgZmlyc3QgcGxhY2UpLg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBJ IGFncmVlLCBidXQgdGhlIGFyZ3VtZW50IGlzIHRoYXQgZG9pbmcgc28gaXMgbGVzcyBoYXJtZnVs IHRoYW4NCj4gPj4gZGVwbG95aW5nIGENCj4gPj4gPj4gY2lyY3VpdA0KPiA+PiA+Pj4+PiBicmVh a2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVuIHdoZW4gRUNOIGlzIHVzZWQuDQo+ID4+ID4+Pj4+ DQo+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQs IHRob3VnaCwgc2luY2UgaXQgc2VlbXMNCj4gPj4gdGhhdA0KPiA+PiBhbnkgbmV3DQo+ID4+ID4+ IEFRTQ0KPiA+PiA+Pj4+PiB0aGF0IGFwcGxpZXMgRUNOIG1hcmtzIG11Y2ggbW9yZSBvZnRlbiB0 aGFuIGF0IHByZXNlbnQgd2lsbA0KPiBoYXZlDQo+ID4+IHRvDQo+ID4+ID4+IGNvbnNpZGVyDQo+ ID4+ID4+Pj4+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3b3JrIHdpdGggZGVwbG95ZWQg VENQIChlLmcuLA0KPiBkcmFmdC0NCj4gPj4gYnJpc2NvZS0NCj4gPj4gPj4gdHN2d2ctDQo+ID4+ ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEgc2lnbmFs IHRvIHVzZSB0aGUNCj4gbmV3DQo+ID4+IG1hcmtpbmcsDQo+ID4+ID4+Pj4+IHdoaWxlIGV4aXN0 aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eQ0KPiA+ PiBtZWNoYW5pc21zDQo+ID4+ID4+Pj4+IHdvdWxkIHNlZW0gdG8gcHJldmVudCB0aGUgaXNzdWVz IHdpdGggdGhlIGNpcmN1aXQgYnJlYWtlciB0b28uDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+PiBV bmRlcnN0YW5kLCB3ZSBoYXZlIGF0IGxlYXN0IHR3byBwcm9wb3NhbHMgdG8gbWFrZSBFQ04tQ0Ug bW9yZQ0KPiA+PiA+PiBmcmVxdWVudA0KPiA+PiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3Vs ZCBiZSBmb3Igbm9uLUVDTiBwYWNrZXRzOiBwb3NzaWJseQ0KPiA+PiBzdWJzdGFudGlhbGx5DQo+ ID4+ID4+Pj4+PiBtb3JlIGZyZXF1ZW50LiBVbmxlc3MgYm90aCBhcmUga2lsbGVkIG9mZiwgRUNO LUNFIHdpbGwgc2hvdyB1cA0KPiA+PiBmcmVxdWVudGx5DQo+ID4+ID4+Pj4+PiBlbm91Z2ggdGhh dCBjbG9zaW5nIHRoZSBmbG93IG9uIEVDTi1DRSB3b3VsZCBraWxsIHRvbyBtYW55DQo+ID4+IGNv bm5lY3Rpb25zLg0KPiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+IElmIHlvdSB3YW50IGNpcmN1aXQt YnJlYWtpbmcgb24gc3VjaCBjb25uZWN0aW9ucywgdGhlcmUgYXJlDQo+IHR3bw0KPiA+PiB3YXlz Og0KPiA+PiA+Pj4+Pj4gMS4gY29udmluY2UgdGhlIGZvcndhcmRpbmcgbm9kZXMgdG8gZHJvcCBw YWNrZXRzIGlmIHRoZWlyDQo+IHF1ZXVlDQo+ID4+IGV4Y2VlZHMNCj4gPj4gPj4+Pj4+IGRlc2ln biBjYXBhY2l0eTsgb3INCj4gPj4gPj4+Pj4+IDIuIHJlcXVpcmUgdGhlIHNlbmRlciB0byBzZW5k IGVub3VnaCBub3QtRUNOLWNhcGFibGUgcGFja2V0cw0KPiBzbw0KPiA+PiB0aGF0IG91cg0KPiA+ PiA+Pj4+Pj4gcmVjZWl2ZXIgd2lsbCBzZWUgZW5vdWdoIHBhY2tldC1kcm9wcyB3aGVuIGEgY2ly Y3VpdC1icmVha2VyDQo+ID4+IHNob3VsZA0KPiA+PiA+Pj4+Pj4gYWN0aXZhdGUuDQo+ID4+ID4+ Pj4+Pg0KPiA+PiA+Pj4+Pj4gKEkgcHJlZmVyIHRoZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxk bid0IG9iamVjdCB0byB0aGUNCj4gPj4gc2Vjb25kLikNCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+ PiBUaGVyZSByZWFsbHkgaXNuJ3QgYW55IHdheSBmb3Igb3VyIGNpcmN1aXQtYnJlYWtlciB0byBr bm93DQo+ID4+IF9ob3dfbXVjaF8NCj4gPj4gPj4+Pj4+IG1vcmUgZnJlcXVlbnQgdGhlIEVDTi1D RSBtYXJrcyBtYXkgYmUuIDpeKA0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBUaGlzIGlzIGEgcHJv YmxlbSwgYm90aCBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciwgYW5kIGZvciB0aGUNCj4gPj4gYWxn b3JpdGhtcyBiZWluZw0KPiA+PiA+Pj4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNv bWUgdW5kZXJzdGFuZGluZyB3aGF0IHRoZQ0KPiBleHBlY3RlZA0KPiA+PiA+PiBtYXJraW5nDQo+ ID4+ID4+Pj4+IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUsIHNvIGNvbmdlc3Rpb24gY29udHJvbCBh bmQgY2lyY3VpdA0KPiA+PiBicmVha2Vycw0KPiA+PiBjYW4gYmUNCj4gPj4gPj4gZGVmaW5lZC4N Cj4gPj4gPj4+Pj4NCj4gPj4gPj4+Pj4+IFdlIF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+PiA+ Pj4+Pj4gYWxsb3QgdGhlIHNhbWUgZnJlcXVlbmN5IG9mIENFIHBhY2tldHMgYXMgcGFja2V0LWRy b3BzIHRvDQo+ID4+IHRyaWdnZXINCj4gPj4gdGhlDQo+ID4+ID4+Pj4+PiBjaXJjdWl0LWJyZWFr ZXIuDQo+ID4+ID4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+IENvdWxkIHNvbWVvbmUgcHJvcG9zZSBpbml0 aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZSBjdXJyZW50DQo+ID4+ICJNQVkNCj4gPj4gaWdub3Jl Ig0KPiA+PiA+Pj4+Pj4+IHN0YXRlbWVudD8NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+PiBFc3Nl bnRpYWxseSwgZm9yIHRoZSBzZWNvbmQgb3B0aW9uLCB5b3UgbWlnaHQgcHJvcG9zZSB0ZXh0IHRv DQo+ID4+IHRoZQ0KPiA+PiA+Pj4+Pj4gZWZmZWN0IG9mOg0KPiA+PiA+Pj4+Pj4gXQ0KPiA+PiA+ Pj4+Pj4gXSBJZiB0b28gbWFueSBFQ04tQ0UgcGFja2V0cyBhcmUgcmVjZWl2ZWQsIHRoZSBzZW5k ZXIgU0hPVUxEDQo+ID4+IHNlbmQNCj4gPj4gc29tZQ0KPiA+PiA+Pj4+Pj4gXSBub3QtRUNOLWNh cGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUgd2hldGhlciBlbm91Z2ggcGFja2V0cw0KPiA+PiBh bG9uZyB0aGUNCj4gPj4gPj4+Pj4+IF0gcGF0aCBhcmUgYmVpbmcgZHJvcHBlZCB0byBqdXN0aWZ5 IGFjdGl2YXRpbmcgb3VyIGNpcmN1aXQtDQo+ID4+IGJyZWFrZXIuDQo+ID4+ID4+Pj4+Pg0KPiA+ PiA+Pj4+Pj4gScOi4oKs4oSibSBub3QgZW50aHVzaWFzdGljIGFib3V0IGFkZGluZyB0aGF0OyBi dXQgaXQgd291bGQgcmVzb2x2ZQ0KPiA+PiB0aGUNCj4gPj4gaXNzdWUuDQo+ID4+ID4+Pj4+DQo+ ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IGNvbnZpbmNlZCB0aGlzIHdvdWxkIHdvcmsuIFRoZSBj aXJjdWl0IGJyZWFrZXIgaXMNCj4gPj4gbG9va2luZw0KPiA+PiBhdCBsb25nIHRlcm0NCj4gPj4g Pj4+Pj4gdHJlbmRzLCBhbmQgaW4gb3JkZXIgdG8gaGF2ZSBlbm91Z2ggbm90LUVDVCBwYWNrZXRz IHRvDQo+IGRldGVybWluZQ0KPiA+PiBpZiBpdA0KPiA+PiA+PiBzaG91bGQNCj4gPj4gPj4+Pj4g dHJpZ2dlciwgeW91w6LigqzihKJkIGVzc2VudGlhbGx5IGhhdmUgdG8gcnVuIHdpdGhvdXQgRUNO IGZvciBzb21lDQo+ID4+IHNlY29uZHMuDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IC0tDQo+ID4+ ID4+Pj4+IENvbGluIFBlcmtpbnMNCj4gPj4gPj4+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0K PiA+PiA+Pj4+DQo+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4+ID4+Pj4gcnRj d2ViQGlldGYub3JnDQo+ID4+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCj4gPj4gPg0KPiA+DQo+ID4NCg0K From nobody Mon Jun 27 13:09:58 2016 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 39B1D12D898; Mon, 27 Jun 2016 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 fIQIC4cdKtfO; Mon, 27 Jun 2016 13:09:50 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E5112D899; Mon, 27 Jun 2016 13:09:50 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5RK9lA0009014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jun 2016 16:09:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5RK9lA0009014 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467058189; bh=jCK9zCl9eu7o7TEn25IU/lxbdj4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AA8RMNSr2VaqutfzEGOLZnvIrAoRH4x6xM6gkG31azEwcc22cClAss1+9EvgBexFG 8Gbsa7CgnhIqH/0MetTBcAWPA9CPHemm/hwODMo2wrK5c824u7UX+0FVuh63LT5viu gpLJj8vL77RFtZmsTHz8LeiGcc9muu6e9s8a6tWc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5RK9lA0009014 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Mon, 27 Jun 2016 16:08:42 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5RK9WuX013689 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 27 Jun 2016 16:09:32 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0266.001; Mon, 27 Jun 2016 16:09:31 -0400 From: "Black, David" To: "De Schepper, Koen (Nokia - BE)" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRySnSO2oWwmhohkOlLHzEpySa4p/yV2bAgAB84gCACuOzAIAADJcAgAA78wD//8FkgA== Date: Mon, 27 Jun 2016 20:09:30 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@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.238.45.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 20:09:53 -0000 PiBBcyBsb25nIGFzIGFuIEFRTSBpcyBtYXJraW5nIGF0IHRoZSBzYW1lIHJhdGUgYXMgZHJvcHBp bmcNCg0KVGhhdCdzIGFuIGludGVyZXN0aW5nIGFzc3VtcHRpb24gLSBpdCBzaG91bGQgYmUgdHJ1 ZSBmb3IgQVFNcyB2ZXR0ZWQNCmhlcmUgaW4gdGhlIHBhc3QsIGJ1dCB0aGVyZSBhcmUgZWFzeSB3 YXlzIGZvciBpdCBub3QgdG8gaG9sZCAoZS5nLiwgaWYgZHJvcHBpbmcNCm9yIG1hcmtpbmcgaXMg YmFzZWQgb24gcXVldWUgb2NjdXBhbmN5LCBpdCBpcyBwb3NzaWJsZSB0aGF0IGRyb3BwaW5nDQpy ZWR1Y2VzIHF1ZXVlIG9jY3VwYW5jeSBpbiBhIGZhc2hpb24gdGhhdCBtYXJraW5nIGRvZXMgbm90 KS4NCg0KRm9yIEVDTiAiY2xhc3NpYyIgKGkuZS4sIHNlZSBSRkMgMzE2OCkgd2hlcmUgRUNOLUNF IG1hcmtpbmdzIGFyZSB0cmVhdGVkDQphcyBkcm9wLWVxdWl2YWxlbnQsIHRoYXQgaXMgZm9yIGNv bmdlc3Rpb24gY29udHJvbCBwdXJwb3Nlcywgd2hpY2ggaXMgc2ltaWxhcg0KdG8sIChidXQgbm90 IHRoZSBzYW1lIGFzKSB0aGUgdGhyb3VnaHB1dCBlc3RpbWF0aW9uIHVzYWdlIGZvciB0aGUgUlRQ IGNpcmN1aXQNCmJyZWFrZXIuICAgIEknbGwgbm90ZSB0aGF0IEVDTiAiY2xhc3NpYyIgd2FzIGRl c2lnbmVkIGNvbmdlc3Rpb24gY29udHJvbA0KYWxnb3JpdGhtcyBmb3IgcmVhY3QgdG8gRUNOLUNF IG1hcmtzIG9uY2UgcGVyIFJUVCwgaW5kZXBlbmRlbnQgb2YgaG93DQptYW55IEVDTi1DRSBtYXJr cyBhcmUgb2JzZXJ2ZWQgaW4gYW4gUlRULg0KDQpHb3JyeSB3cm90ZToNCg0KPiA+IGluIHRoaXMg Y29udGV4dCB3ZSBzaG91bGQgdXNlIEVDTiB0byBkcml2ZSBhIENDIGFsZ29yaXRobSBhbmQgd2Ug c2hvdWxkIGJlDQo+ID4gY2F1dGlvdXMgdG8gYXZvaWQgcmVxdWlyaW5nIGl0cyB1c2Ugd2l0aGlu IGEgQ2lyY3VpdCBCcmVha2VyIC0gb3B0aW9uYWwNCj4gPiB1c2UsIGlmIHlvdSB1bmRlcnN0YW5k IGhvdyB0byBpbnRlcnByZXQgYSByZWFjdGlvbiB0byBtYW55IENFLW1hcmtzIGFzDQo+ID4gZXhj ZXNzaXZlIGNvbmdlc3Rpb24sIGFyZSBwZXJtaXR0ZWQuDQoNClNvbWV0aGluZyBsaWtlIHRoYXQg bWF5IGJlIHdvcmthYmxlLCBzdGFydGluZyB3aXRoIGEgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2Vl bg0KdGhlIHVzZSBvZiBFQ04gYnkgQ0MgKHJvdXRpbmUsIGFjdGl2ZSBhdCBhbGwgdGltZXMpIGFu ZCBFQ04gYnkgYSBjaXJjdWl0DQpicmVha2VyIChtb25pdG9ycyBmb3IgZXZpZGVuY2UgdGhhdCB0 aGluZ3MgaGF2ZSBnb3R0ZW4gYmFkLCBvbmx5IGFjdGl2YXRlZA0Kd2hlbiB0aGluZ3MgZ2V0IGJh ZCkuICAgVGhpcyB3b3VsZCBiYXNlbGluZSB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBvbiBkcm9w cw0KYW5kIGFsbG93IHVzZSBvZiBFQ04gYXMgYWRkaXRpb25hbCBldmlkZW5jZSBvZiBwcm9ibGVt cywgaW4gY29udHJhc3QgdG8NCmNvbmdlc3Rpb24gY29udHJvbCB3aGVyZSBFQ04tQ0UgaXMgZWZm ZWN0aXZlbHkgdHJlYXRlZCBhcyBkcm9wLWVxdWl2YWxlbnQuDQoNCkknbSBub3QgcXVpdGUgc3Vy ZSBob3cgdG8gc3BlY2lmeSAidXNlIG9mIEVDTiBhcyBhZGRpdGlvbmFsIGV2aWRlbmNlIiBvZg0K ImV4Y2Vzc2l2ZSBjb25nZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxlbmNlIGlzIGFib3V0IHRoZSBi ZXN0IHdlIGhhdmUNCmZvciBjdXJyZW50IGd1aWRhbmNlLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEZSBTY2hlcHBlciwgS29lbiAo Tm9raWEgLSBCRSkgW21haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtDQo+IGxhYnMu Y29tXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMjcsIDIwMTYgMzoxMyBQTQ0KPiBUbzogZ29ycnlA ZXJnLmFiZG4uYWMudWsNCj4gQ2M6IE1pY2hhZWwgV2Vsemw7IEJsYWNrLCBEYXZpZDsgTWFnbnVz IFdlc3Rlcmx1bmQ7IHRzdndnOyBJRVRGIEFWVENvcmUgV0c7DQo+IHJ0Y3dlYkBpZXRmLm9yZzsg Q29saW4gUGVya2lucw0KPiBTdWJqZWN0OiBSRTogW3RzdndnXSBbcnRjd2ViXSBbQVZUQ09SRV0g V0cgTGFzdCBDYWxsIG9uIGNoYW5nZXM6IGRyYWZ0LWlldGYtDQo+IGF2dGNvcmUtcnRwLWNpcmN1 aXQtYnJlYWtlcnMtMTYNCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogZ29ycnlAZXJnLmFiZG4uYWMudWsgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 a10NCj4gPiBTZW50OiBtYWFuZGFnIDI3IGp1bmkgMjAxNiAxNzozOA0KPiA+IFRvOiBEZSBTY2hl cHBlciwgS29lbiAoTm9raWEgLSBCRSkNCj4gPiBDYzogTWljaGFlbCBXZWx6bDsgQmxhY2ssIERh dmlkOyBnb3JyeUBlcmcuYWJkbi5hYy51azsgTWFnbnVzDQo+ID4gV2VzdGVybHVuZDsgdHN2d2c7 IElFVEYgQVZUQ29yZSBXRzsgcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+ID4gU3Vi amVjdDogUmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFu Z2VzOiBkcmFmdC0NCj4gPiBpZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYNCj4g Pg0KPiA+IEkgdGhpbmsgdGhpbmtpbmcgb2YgTDRTIGlzIG1heWJlIG9mZiBhdCBhIHRhbmdlbnQu IFRoZSBxdWVzdGlvbiByZWFsbHkNCj4gPiBpcw0KPiA+IGFib3V0IHRoZSBpbnRlcnByZXRhdGlv biBvZiBsb3NzIGFuZCBDRS1tYXJrIGFzIGVxdWl2YWxlbnQuIEkgYXJndWVkDQo+ID4gdGhhdA0K PiA+IGVhY2ggRUNOLUNFIG1hcmsgc2hvdWxkIG5vdCBiZSBjb3VudGVkIGFzIGVxdWl2YWxlbnQg dG8gYSBsb3N0IHNlZ21lbnQgLQ0KPiANCj4gV2h5IG5vdD8gQXMgbG9uZyBhcyBhbiBBUU0gaXMg bWFya2luZyBhdCB0aGUgc2FtZSByYXRlIGFzIGRyb3BwaW5nLCBhDQo+IDEwMCUgbWFya2luZyBt ZWFucyB0aGF0IG5vbi1lY24gZmxvd3MgYXJlIGJlaW5nIGRyb3BwZWQgYXQgYSAxMDAlLCBub3Q/ DQo+IA0KPiBLb2VuLg0KPiANCj4gDQo+ID4gaW4gdGhpcyBjb250ZXh0IHdlIHNob3VsZCB1c2Ug RUNOIHRvIGRyaXZlIGEgQ0MgYWxnb3JpdGhtIGFuZCB3ZSBzaG91bGQNCj4gPiBiZQ0KPiA+IGNh dXRpb3VzIHRvIGF2b2lkIHJlcXVpcmluZyBpdHMgdXNlIHdpdGhpbiBhIENpcmN1aXQgQnJlYWtl ciAtIG9wdGlvbmFsDQo+ID4gdXNlLCBpZiB5b3UgdW5kZXJzdGFuZCBob3cgdG8gaW50ZXJwcmV0 IGEgcmVhY3Rpb24gdG8gbWFueSBDRS1tYXJrcyBhcw0KPiA+IGV4Y2Vzc2l2ZSBjb25nZXN0aW9u LCBhcmUgcGVybWl0dGVkLg0KPiA+DQo+ID4gR29ycnkNCj4gPg0KPiA+ID4gQXMgZmFyIGFzIEkg dW5kZXJzdGFuZCwgdGhpcyBkcmFmdCBpcyByZWxhdGVkIHRvIGNpcmN1aXQgYnJlYWtlcnMgaW4N Cj4gPiA+IGVuZC1zeXN0ZW1zLCByaWdodD8NCj4gPiA+DQo+ID4gPiBJdCBpcyB0aGUgZW5kIHN5 c3RlbSB0aGF0IGRldGVybWluZXMgdGhlIHVzZSBvZiBFQ04gKGN1cnJlbnRseSBtYXJraW5nDQo+ ID4gPiBub24tZWN0IGZvciBkcm9wIGFuZCBlY3QoMCkgZm9yIENsYXNzaWMgRUNOKS4NCj4gPiA+ DQo+ID4gPiBJbiBMNFMgd2UgZG9uJ3QgcGxhbiB0byBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIENs YXNzaWMgRUNOLCBhbmQgQUJFJ3MNCj4gPiA+IGJlaGF2aW9yIHNob3VsZCBiZSBjbG9zZSB0byBu b24tQUJFIEVDTi4gU28gSSBndWVzcyB0aGVyZSBpcyBubw0KPiA+IHByb2JsZW0gb2YNCj4gPiA+ IGRlc2NyaWJpbmcgdGhlIGJlaGF2aW9yIG9mIGhvdyBhIENsYXNzaWMgRUNOIGJhc2VkIHNlbmRl ciB3b3VsZA0KPiA+IHJlc3BvbmQNCj4gPiA+IHRvZGF5Lg0KPiA+ID4NCj4gPiA+IEFzIHdlIG9u bHkgd2FudCB0byBzaWduaWZpY2FudGx5IGNoYW5nZSB0aGUgbmV0d29yayBiZWhhdmlvciBvZiBl Y3QoMSkNCj4gPiA+IG1hcmtpbmcsIGNhbiB3ZSBzb2x2ZSB0aGlzIGlzc3VlIGJ5IHJlY29tbWVu ZGluZyAob3IgZXZlbiByZXF1aXJpbmcpDQo+ID4gPiBzZW5kZXJzIHRvIG1hcmsgb25seSBlY3Qo MCkgYW5kIGRlc2NyaWJpbmcgdGhlIGNsYXNzaWMgRUNOIGNpcmN1aXQNCj4gPiA+IGJyZWFrZXI/ IFdoZW4gTDRTIGdldHMgZGVmaW5lZCwgYWxzbyBhbiBMNFMgYmFzZWQgY2lyY3VpdCBicmVha2Vy DQo+ID4gPiBleHRlbnNpb24gY2FuIGJlIGRlZmluZWQgZm9yIHNlbmRlcnMgdGhhdCB3YW50IHRv IHVzZSB0aGUgTDRTIHNlcnZpY2UNCj4gPiA+ICh3aGVuIHNlbmRlcnMgc2VuZCBlY3QoMSkgcGFj a2V0cykuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IEtvZW4uDQo+ID4gPg0KPiA+ID4N Cj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IHRzdndnIFtt YWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gPiBX ZWx6bA0KPiA+ID4+IFNlbnQ6IG1hYW5kYWcgMjAganVuaSAyMDE2IDE4OjM2DQo+ID4gPj4gVG86 IEJsYWNrLCBEYXZpZA0KPiA+ID4+IENjOiA8Z29ycnlAZXJnLmFiZG4uYWMudWs+IEZhaXJodXJz dDsgTWFnbnVzIFdlc3Rlcmx1bmQ7IHRzdndnOyBJRVRGDQo+ID4gPj4gQVZUQ29yZSBXRzsgcnRj d2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+ID4gPj4gU3ViamVjdDogUmU6IFt0c3Z3Z10g W3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0KPiA+IGRyYWZ0LQ0K PiA+ID4+IGlldGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiA+ID4+DQo+ID4g Pj4NCj4gPiA+PiA+IE9uIDIwLiBqdW4uIDIwMTYsIGF0IDE1LjE2LCBCbGFjaywgRGF2aWQgPGRh dmlkLmJsYWNrQGVtYy5jb20+DQo+ID4gd3JvdGU6DQo+ID4gPj4gPg0KPiA+ID4+ID4+PiBCdXQg ScOi4oKs4oSibSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0IGV2ZW50dWFsbHkgaWdu b3JpbmcgaXQNCj4gPiA+PiBmb3INCj4gPiA+PiBjaXJjdWl0DQo+ID4gPj4gPj4gYnJlYWtlci4N Cj4gPiA+PiA+Pj4NCj4gPiA+PiA+PiBBZ3JlZS4gTG9zcyBpcyB0aGUgbWVhc3VyZW1lbnQgdGhh dCBhIENCIE1VU1QgcmVzcG9uZCB0by4NCj4gPiA+PiA+DQo+ID4gPj4gPiBNdW1ibGUuICAgSSB3 b3VsZCBiZSBvayB3aXRoIGEgY2xlYXIgZGlzY291cmFnZW1lbnQgZm9yIHVzZSBvZiBFQ04tDQo+ ID4gQ0UNCj4gPiA+PiBtYXJrcywgYWNjb21wYW5pZWQgYnkgdGhlIHNvcnQgb2YgZGVzaWduIHJh dGlvbmFsZSBoZXJlLCBvciBldmVuDQo+ID4gPj4gYmV0dGVyLA0KPiA+ID4+IGEgY2xlYXIgc3Rh dGVtZW50IHRoYXQgbG9zdCBwYWNrZXRzIGZvciB0aGUgcHVycG9zZSBvZiB0aGUgUlRQDQo+ID4g Y2lyY3VpdA0KPiA+ID4+IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1YWxseSBsb3N0IHdpdGhvdXQg Z2V0dGluZyBpbnRvIHdoZXRoZXIgb3Igbm90DQo+ID4gPj4gRUNOLUNFIG1hcmtzIGFyZSBpbnZv bHZlZCAtaS5lLiwgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaXMgc3BlY2lmaWVkDQo+ID4gPj4g YWdhaW5zdCBhY3R1YWwgZHJvcHMgYXMgYSBuZXR3b3JrIHByb3RlY3Rpb24gYmFja3N0b3AuDQo+ ID4gPj4gPg0KPiA+ID4+ID4gQSByZWxhdGVkIGNvbmNlcm4gaXMgdGhhdCBFQ04gbWFya3MgbWF5 IG92ZXJzdGF0ZSBlcXVpdmFsZW50IGxvc3MNCj4gPiA+PiBiZWhhdmlvciAtIGEgc2ltcGxpc3Rp YyBxdWV1ZSBtYW5hZ2VtZW50IGRpc2NpcGxpbmUgdGhhdCBtYXJrcyBldmVyeQ0KPiA+ID4+IHBh Y2tldCB3aGVuIHRoZSBxdWV1ZSBpcyBvdmVyIGEgdGhyZXNob2xkIChOQjogdGhpcyBjbGFzcyBv ZiBtYXJraW5nDQo+ID4gPj4gYmVoYXZpb3IgaXMgTk9UIFJFQ09NTUVOREVEIC0gYSByZWFsIEFR TSBTSE9VTEQgYmUgdXNlZCkgY291bGQgeWllbGQNCj4gPiBhDQo+ID4gPj4gcnVuIG9mIEVDTi1D RSBtYXJrcyB0aGF0IHdvdWxkIG5vdCBjYXVzZSBhIGNvcnJlc3BvbmRpbmcgd2l0aCBhIHJ1bg0K PiA+IG9mDQo+ID4gPj4gcGFja2V0IGRyb3BzLiAgIFRoaXMgaXMgYW1vbmcgdGhlIHJlYXNvbnMg dGhhdCBUQ1AgcmVhY3RzIHRvIEVDTi1DRQ0KPiA+ID4+IG1hcmtzIG9ubHkgb25jZSBwZXIgUlRU LCBhbmQgbWlnaHQgYmUgYSByZWFzb24gdG8gdHJlYXQgbXVsdGlwbGUgRUNOLQ0KPiA+IENFDQo+ ID4gPj4gbWFya3MgaW4gYW4gUlRUIGludGVydmFsIGFzIG5vdCByZXByZXNlbnRpbmcgZHJvcHMg b2YgYWxsIHBhY2tldHMgZm9yDQo+ID4gPj4gdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIncyBUQ1At ZXF1aXZhbGVudCB0aHJvdWdocHV0IGNhbGN1bGF0aW9uLg0KPiA+ID4+DQo+ID4gPj4gScOi4oKs 4oSibSBub3Qgc3VyZSB3ZSBuZWVkIHN1Y2ggY29tcGxpY2F0ZWQgbG9naWMgdG8gZmluZCBhIGNh c2Ugd2hlcmUNCj4gPiBFQ04NCj4gPiA+PiBtYXJrcyBhcmUgZGlmZmVyZW50IGZyb20gcGFja2V0 IGRyb3BzOg0KPiA+ID4+DQo+ID4gPj4gQmFzaWNhbGx5LCB0aGV5IHNpbXBseSBhcmVuw6Ligqzi hKJ0IC0gZXZlbiDDouKCrMWTcmVhbMOi4oKswp0gQVFNcyBtYXJraW5nDQo+ID4gaXNuw6Ligqzi hKJ0DQo+ID4gPj4gZXhhY3RseQ0KPiA+ID4+IHRoZSBzYW1lIGFzIGEgcGFja2V0IGRyb3A6IHRo ZSBtYXJrcyB0aGVtc2VsdmVzIGluZm9ybSB5b3UgdGhhdCBhbg0KPiA+IEFRTQ0KPiA+ID4+IGRp ZCBpdHMgam9iLCBhbmQgd2l0aCBtb2Rlcm4gQVFNcyBsaWtlIENvRGVsIC8gUElFIGV0Yy4sIHlv dcOi4oKs4oSicmUNCj4gPiA+PiBwcm9iYWJseQ0KPiA+ID4+IGdldHRpbmcgdGhpcyBmcm9tIGEg c2hhbGxvdyBxdWV1ZS4gQ2hhbmNlcyBhcmUgdGhhdCB0aGlzIGlzIGxlc3MgdGhhbg0KPiA+IGEN Cj4gPiA+PiBCRFAgd29ydGggb2YgcXVldWluZywgd2hpY2ggaXMgb3VyIGp1c3RpZmljYXRpb24g Zm9yIHJlY29tbWVuZGluZyBhDQo+ID4gPj4gZGlmZmVyZW50IGJhY2stb2ZmIGJlaGF2aW9yIGlu IGRyYWZ0LWtoYWRlbWktdHN2d2ctZWNuLXJlc3BvbnNlLTAwDQo+ID4gYW5kDQo+ID4gPj4gZHJh ZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZlYmFja29mZi1lY24tMDANCj4gPiA+Pg0KPiA+ID4+ IFNvIHRoZSBwb2ludCBpcyBub3QgdGhhdCBBUU1zIHdvdWxkIHRyZWF0IEVDTiBtYXJraW5nIGFu ZCBkcm9wcGluZw0KPiA+ID4+IGRpZmZlcmVudGx5IC0gaXTDouKCrOKEonMgdGhhdCBFQ04gaW5k aWNhdGVzIGFuIEFRTSwgYW5kIGhlbmNlIHByb2JhYmx5IGENCj4gPiA+PiBzaGFsbG93IHF1ZXVl LiBXaXRoIGEgZHJvcCwgeW91IGp1c3QgZG9uw6LigqzihKJ0IGtub3cuDQo+ID4gPj4NCj4gPiA+ PiBCYWNrIHRvIHRoZSBDQiwgSSB0aGluayBhbiBBUU0gbWFya2luZyBhdCBhIHNoYWxsb3cgcXVl dWUgKGxpa2UgZS5nLg0KPiA+ID4+IENvRGVsKSBpcyBpbmRlZWQgcXVpdGUgZGlmZmVyZW50IGZy b20gYSDDouKCrMWTYnJva2VuIGNvbm5lY3Rpb27DouKCrMKdLg0KPiA+ID4+DQo+ID4gPj4gQ2hl ZXJzLA0KPiA+ID4+IE1pY2hhZWwNCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gPg0KPiA+ID4+ID4g VGhhbmtzLCAtLURhdmlkDQo+ID4gPj4gPg0KPiA+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPj4gPj4gRnJvbTogR29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcuYWJk bi5hYy51a10NCj4gPiA+PiA+PiBTZW50OiBTYXR1cmRheSwgSnVuZSAxOCwgMjAxNiAyOjIzIEFN DQo+ID4gPj4gPj4gVG86IE1pcmphIEvDg8K8aGxld2luZA0KPiA+ID4+ID4+IENjOiBCbGFjaywg RGF2aWQ7IE1hZ251cyBXZXN0ZXJsdW5kOyBDb2xpbiBQZXJraW5zOw0KPiA+IHJ0Y3dlYkBpZXRm Lm9yZzsNCj4gPiA+PiBJRVRGDQo+ID4gPj4gPj4gQVZUQ29yZSBXRzsgdHN2d2cNCj4gPiA+PiA+ PiBTdWJqZWN0OiBSZTogW3RzdndnXSBbcnRjd2ViXSBbQVZUQ09SRV0gV0cgTGFzdCBDYWxsIG9u IGNoYW5nZXM6DQo+ID4gPj4gZHJhZnQtaWV0Zi0NCj4gPiA+PiA+PiBhdnRjb3JlLXJ0cC1jaXJj dWl0LWJyZWFrZXJzLTE2DQo+ID4gPj4gPj4NCj4gPiA+PiA+PiBJIHRoaW5rIHdlIFNIT1VMRCBO T1QgcmVjb21tZW5kIHRvIHVzZSBFQ04gbWFya3MgYXMgaW5wdXRzIHRvIGENCj4gPiBDQi4NCj4g PiA+PiBTZWUNCj4gPiA+PiA+PiBiZWxvdzoNCj4gPiA+PiA+Pg0KPiA+ID4+ID4+PiBPbiAxNyBK dW4gMjAxNiwgYXQgMTY6MDIsIE1pcmphIEvDg8K8aGxld2luZA0KPiA+ID4+IDxtaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KPiA+ID4+ID4+IHdyb3RlOg0KPiA+ID4+ID4+Pg0KPiA+ ID4+ID4+PiArMSB0byBub3QgdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSBoZXJlLg0KPiA+ID4+ID4+ Pg0KPiA+ID4+ID4+PiBIb3dldmVyLCBwbGVhc2Ugbm90ZSB0aGF0IGhhdmluZyBhIGhpZ2ggbGV2 ZWwgb2YgRUNOLUNFIG1hcmtzDQo+ID4gPj4gKHdpdGhvdXQgYW55DQo+ID4gPj4gPj4gbG9zc2Vz KSBtZWFucyB0aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVjdGx5LiBUaGlzDQo+ ID4gPj4gc2l0dWF0aW9uIGNhbiBldmVuDQo+ID4gPj4gPj4gb2NjdXJzIHdpdGhvdXQgaGlnaCBk ZWxheXMgKGRlcGVuZGluZyBvbiB0aGUgQVFNIHVzZWQpLCB3aGljaA0KPiA+IHdvdWxkDQo+ID4g Pj4ganVzdA0KPiA+ID4+ID4+IG1lYW4gdGhlIHNlcnZpY2VzIHdvcmtzIHBlcmZlY3RseS4gVGhl cmVmb3JlIGZvciBtZSBDRSBtYXJrcyBhcmUgYQ0KPiA+ID4+IHBlcmZlY3QgaW5wdXQNCj4gPiA+ PiA+PiBzaWduYWwgZm9yIGEgY29uZ2VzdGlvbiBjb250cm9sIGxvb3AgKHdoZXJlIHRoZSBBUU0g dGVsbCB0aGUNCj4gPiBzZW5kZXINCj4gPiA+PiB0byB0YWtlIGFjdGlvbg0KPiA+ID4+ID4+IC0g d2hhdGV2ZXIgdGhhdCBtZWFucykuDQo+ID4gPj4gPj4NCj4gPiA+PiA+PiBXZSBtYXkgaW4gZnV0 dXJlIGZpZ3VyZSBvdXQgd2F5cyB0byBkbyB0aGlzIHRvIGRldGVjdCBzaWduaWZpY2FudA0KPiA+ ID4+IGZhaWx1cmUgdXNpbmcgYQ0KPiA+ID4+ID4+IHJhdGUgYWRhcHRpdmUgdHJhbnNwb3J0IGFu ZCBFQ04gZS5nLiAgT2JzZXJ2aW5nIDEwMCUgQ0UgbWFya3Mgb3INCj4gPiA+PiBzb21ldGhpbmcs IGZvcg0KPiA+ID4+ID4+IGFuIFJUUCBmbG93IHRoYXQgaXMgdHJ5aW5nIHRvIHNlbmQgd2VsbCBi ZWxvdyBpdHMgcGVhayByYXRlDQo+ID4gZGVjaWRlZA0KPiA+ID4+IGJ5IENDIC0tIGJ1dCBJDQo+ ID4gPj4gPj4gdGhpbmsgdGhpcyBpcyBzcGVjdWxhdGluZyBhdCBhbiBhbGdvcml0aG0gYW5kIGFk ZGluZyBkZXRhaWxzIGhlcmUNCj4gPiBpcw0KPiA+ID4+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPiA+ PiA+PiBFc3BlY2lhbGx5IGFzIEFRTSBjb250aW51ZXMgdG8gZXZvbHZlLg0KPiA+ID4+ID4+DQo+ ID4gPj4gPj4+IEJ1dCBJw6LigqzihKJtIGxlc3MgY29uY2VybmVkIHRoYW4gRGF2aWQgYWJvdXQg ZXZlbnR1YWxseSBpZ25vcmluZyBpdA0KPiA+ID4+IGZvcg0KPiA+ID4+IGNpcmN1aXQNCj4gPiA+ PiA+PiBicmVha2VyLg0KPiA+ID4+ID4+Pg0KPiA+ID4+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBt ZWFzdXJlbWVudCB0aGF0IGEgQ0IgTVVTVCByZXNwb25kIHRvLg0KPiA+ID4+ID4+DQo+ID4gPj4g Pj4+IEluIGFkZGl0aW9uIG9uZSBwb2ludCBvbiBzb21ldGhpbmcgTWFnbnVzIHdyb3RlIGVhcmxp ZXI6DQo+ID4gPj4gPj4+ICJJZiB0aGUgaW1wbGVtZW50YXRpb24gb25seSBoYXZlIGNpcmN1aXQg YnJlYWtlciwgaS5lLiBubyBmdWxsDQo+ID4gPj4gZmxlZGdlZCBjb25nZXN0aW9uDQo+ID4gPj4g Pj4gY29udHJvbGxlciBhbmQgdXNlcyBFQ04sIHRoZXkgY2FuIGluIHdvcnN0IGNhc2UgZHJpdmUg dGhlIGJ1ZmZlcg0KPiA+ID4+IGludG8NCj4gPiA+PiB0aGUgb3ZlcmxvYWQNCj4gPiA+PiA+PiBy ZWdpbWUgd2hlcmUgaXQgc3RhcnRzIGRyb3BwaW5nIHBhY2tldHMuIMOi4oKsxb4NCj4gPiA+PiA+ Pj4NCj4gPiA+PiA+Pj4gScOi4oKs4oSibSBub3Qgc3VyZSBhYm91dCB0aGlzIGNhc2UuIEVDTiBp cyBhbiBpbnB1dCBzaWduYWwgZm9yDQo+ID4gPj4gY29uZ2VzdGlvbg0KPiA+ID4+IGNvbnRyb2wu IElmIHlvdQ0KPiA+ID4+ID4+IGRvbsOi4oKs4oSidCB1c2UgY29uZ2VzdGlvbiBjb250cm9sIGJ1 dCBvbmx5IGEgY2lyY3VpdCBicmVha2VyLCB5b3UNCj4gPiA+PiBzaG91bGQNCj4gPiA+PiBwcm9i YWJseSBub3QNCj4gPiA+PiA+PiBlbmFibGUgRUNOLiBBdCBsZWFzdCBpdCBub3QgY2xlYXIgdG8g bWUgd2h5IHlvdSB3b3VsZCBlbmFibGUgaXQsDQo+ID4gYW5kDQo+ID4gPj4gaXQncyBkZWZpbml0 ZWx5DQo+ID4gPj4gPj4gbm90IGNvbmZvcm0gdG8gdGhlIEVDTiBzcGVjLiBQcm9iYWJseSB3ZSBz aG91bGQgc2F5IHNvbWV0aGluZw0KPiA+IGFib3V0DQo+ID4gPj4gdGhpcyBpbiB0aGUNCj4gPiA+ PiA+PiBkcmFmdC4uLj8NCj4gPiA+PiA+Pj4NCj4gPiA+PiA+PiBBZ3JlZSwgZW5hYmxpbmcgRUNO IHdpdGhvdXQgYSByZXNwb25zaXZlIENDIGlzIGdvaW5nIHRvIGxlYWQgdG8NCj4gPiA+PiB0cm91 YmxlLg0KPiA+ID4+ID4+DQo+ID4gPj4gPj4+IE1pcmphDQo+ID4gPj4gPj4+DQo+ID4gPj4gPj4g R29ycnkNCj4gPiA+PiA+Pg0KPiA+ID4+ID4+Pj4gQW0gMTcuMDYuMjAxNiB1bSAxNjowMyBzY2hy aWViIEJsYWNrLCBEYXZpZA0KPiA+IDxkYXZpZC5ibGFja0BlbWMuY29tPjoNCj4gPiA+PiA+Pj4+ DQo+ID4gPj4gPj4+PiBDb2xpbiwNCj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+Pj4+PiAuLi4gIEkg dmlldyB0aGUgY3VycmVudCB0ZXh0IGFzIHByb3ZpZGluZyBpbXBsZW1lbnRlcnMgd2l0aA0KPiA+ IHRvbw0KPiA+ID4+IG11Y2gNCj4gPiA+PiA+Pj4+Pj4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04t Q0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4gaW1wbGVtZW50ZXINCj4gPiA+PiBkb2Vzbid0DQo+ ID4gPj4gPj4+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSBzcGFjZSBpbiB0 aGUgZmlyc3QgcGxhY2UpLg0KPiA+ID4+ID4+Pj4+DQo+ID4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0 IHRoZSBhcmd1bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bCB0aGFuDQo+ID4g Pj4gZGVwbG95aW5nIGENCj4gPiA+PiA+PiBjaXJjdWl0DQo+ID4gPj4gPj4+Pj4gYnJlYWtlciB0 aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2VkLg0KPiA+ID4+ID4+Pj4+DQo+ ID4gPj4gPj4+Pj4gScOi4oKs4oSibSBub3Qgc3VyZSBJIGJlbGlldmUgdGhpcyBhcmd1bWVudCwg dGhvdWdoLCBzaW5jZSBpdCBzZWVtcw0KPiA+ID4+IHRoYXQNCj4gPiA+PiBhbnkgbmV3DQo+ID4g Pj4gPj4gQVFNDQo+ID4gPj4gPj4+Pj4gdGhhdCBhcHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUg b2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gPiBoYXZlDQo+ID4gPj4gdG8NCj4gPiA+PiA+ PiBjb25zaWRlcg0KPiA+ID4+ID4+Pj4+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3b3Jr IHdpdGggZGVwbG95ZWQgVENQIChlLmcuLA0KPiA+IGRyYWZ0LQ0KPiA+ID4+IGJyaXNjb2UtDQo+ ID4gPj4gPj4gdHN2d2ctDQo+ID4gPj4gPj4+Pj4gYXFtLXRjcG0tcm1jYXQtbDRzLXByb2JsZW0g dXNlcyBFQ1QoMSkgYXMgYSBzaWduYWwgdG8gdXNlIHRoZQ0KPiA+IG5ldw0KPiA+ID4+IG1hcmtp bmcsDQo+ID4gPj4gPj4+Pj4gd2hpbGUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHNldCBFQ1Qo MCkpLiBUaGVzZSBjb21wYXRpYmlsaXR5DQo+ID4gPj4gbWVjaGFuaXNtcw0KPiA+ID4+ID4+Pj4+ IHdvdWxkIHNlZW0gdG8gcHJldmVudCB0aGUgaXNzdWVzIHdpdGggdGhlIGNpcmN1aXQgYnJlYWtl ciB0b28uDQo+ID4gPj4gPj4+Pg0KPiA+ID4+ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNoZXMgbXkg bGluZSBvZiB0aGlua2luZywgYW5kIEknbGwgb2JzZXJ2ZSB0aGF0DQo+ID4gPj4gdGhlDQo+ID4g Pj4gb3JpZ2luYWwNCj4gPiA+PiA+PiBEQ1RDUA0KPiA+ID4+ID4+Pj4gcHJvdG9jb2wgZGVzaWdu IHRoYXQgdXNlZCBtb3JlIGFnZ3Jlc3NpdmUgRUNOLUNFIG1hcmtpbmcgd2FzDQo+ID4gb25seQ0K PiA+ID4+IHNhZmUgZm9yDQo+ID4gPj4gPj4+PiBDb250cm9sbGVkIEVudmlyb25tZW50IGRlcGxv eW1lbnRzLiAgIFNlZSB0aGUgVFNWV0cgcmZjNTQwNWJpcw0KPiA+ID4+IGRyYWZ0IGZvcg0KPiA+ ID4+ID4+IHRoZQ0KPiA+ID4+ID4+Pj4gZGVmaW5pdGlvbiBvZiBDb250cm9sbGVkIEVudmlyb25t ZW50LCBhbmQgaWdub3JlIHRoZSBmYWN0IHRoYXQNCj4gPiB0aGUNCj4gPiA+PiByZmM1NDA1Ymlz DQo+ID4gPj4gPj4+PiBkcmFmdCBpcyBhIFVEUCBkcmFmdCAtIHRoaXMgZGVmaW5pdGlvbiBpcyBt b3JlIGJyb2FkbHkNCj4gPiBhcHBsaWNhYmxlLg0KPiA+ID4+ID4+Pj4NCj4gPiA+PiA+Pj4+IEdv aW5nIGJhY2sgb3ZlciBTZWN0aW9uIDcgaW4gdGhpcyBhdnRjb3JlIGRyYWZ0LCBteSB2aWV3cyBh cmU6DQo+ID4gPj4gPj4+Pg0KPiA+ID4+ID4+Pj4gW0FdIE5vbmUgb2YgdGhlc2UgZHJhZnRzIGp1 c3RpZnkgYSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8gRUNOLQ0KPiA+IENFDQo+ID4gPj4gbWFy a3M6DQo+ID4gPj4gPj4+PiAgIC0gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZlYmFja29m Zi1lY24NCj4gPiA+PiA+Pj4+ICAgLSBkcmFmdC1pZXRmLXJtY2F0LW5hZGENCj4gPiA+PiA+Pj4+ ICAgLSBkcmFmdC1pZXRmLXJtY2F0LXNjcmVhbS1jYw0KPiA+ID4+ID4+Pj4NCj4gPiA+PiA+Pj4+ IFtCXSBJbiBsaW5lIHdpdGggQ29saW4ncyBjb21tZW50IG9uIHRoZSBMNFMgZHJhZnQsIEkgdGhp bmsgaXQncw0KPiA+ID4+IGluY3VtYmVudCBvbg0KPiA+ID4+ID4+Pj4gdGhlIGF1dGhvcnMgb2Yg ZHJhZnQtYnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBmaWd1cmUgb3V0IGhvdw0KPiA+ID4+ IHRoYXQgd2lsbA0KPiA+ID4+ID4+Pj4gY29leGlzdCAob3IgYXZvaWQpIGRlcGxveWVkIFRDUCwg YW5kIHRoaXMgYXZ0Y29yZSBkcmFmdCBvdWdodA0KPiA+IG5vdA0KPiA+ID4+IHRvIGJlDQo+ID4g Pj4gPj4+PiB0cnlpbmcgdG8gcHJlanVkZ2Ugd2hhdCB3aWxsIGJlIGRvbmUgdGhlcmUuDQo+ID4g Pj4gPj4+Pg0KPiA+ID4+ID4+Pj4gU28sIEkgZG9uJ3QgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCBp biBTZWN0aW9uIDcgaGFzIGp1c3RpZmllZA0KPiA+IHRoZQ0KPiA+ID4+IHVuZmV0dGVyZWQNCj4g PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbnMgTUFZIGlnbm9yZSBFQ04tQ0UgbWFya3MiIHRleHQs IGFzIGlnbm9yaW5nDQo+ID4gdGhvc2UNCj4gPiA+PiBtYXJrcw0KPiA+ID4+ID4+Pj4gaXMgbm90 IGNvbnNpc3RlbnQgd2l0aCBhbnkgb2YgdGhlIGZvdXIgY2l0ZWQgZHJhZnRzLg0KPiA+ID4+ID4+ Pj4NCj4gPiA+PiA+Pj4+IEluIG1vcmUgZGV0YWlsLCBJIHRoaW5rIG1ha2luZyBjaGFuZ2VzIHRv IG5vcm1hdGl2ZSByZXF1aXJlbWVudHMNCj4gPiA+PiBoZXJlIGJhc2VkDQo+ID4gPj4gPj4+PiBv biBbQl0gaXMgcHJlbWF0dXJlLCBhbmQgSSB3b3VsZCBob3BlIHRoYXQgdGhlIHJtY2F0IFdHIGNv dWxkIGJlDQo+ID4gPj4gPj4gZW5jb3VyYWdlZA0KPiA+ID4+ID4+Pj4gdG8gY29uc2lkZXIgdGhl IFJUUCBjaXJjdWl0IGJyZWFrZXIgaW4gaXRzIGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ID4+IGRy YWZ0cywgYXMgdGhvc2UgQ0MNCj4gPiA+PiA+Pj4+IG1lY2hhbmlzbXMgYXJlIHJlbGF0ZWQgdG8g dGhlIGNpcmN1aXQgYnJlYWtlciBtZWNoYW5pc20sIGhlbmNlDQo+ID4gPj4gbGlrZWx5DQo+ID4g Pj4gPj4+PiB0byBiZSBpbiByZWxhdGVkIGFyZWFzIG9mIGFuIFJUUCBpbXBsZW1lbnRhdGlvbi4N Cj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+PiBUaGF0IGxlYXZlcyBkcmFmdC1raGFkZW1pLXRjcG0t YWx0ZXJuYXRpdmViYWNrb2ZmLWVjbiwgd2hpY2gNCj4gPiBUU1ZXRw0KPiA+ID4+ID4+Pj4gd2ls bCBiZSBsb29raW5nIGF0IGluIEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudCBhYm91 dA0KPiA+IEVDTi0NCj4gPiA+PiBDRSByZWFjdGlvbg0KPiA+ID4+ID4+Pj4gaXMgZ29pbmcgdG8g cmVzdCBvbiB0aGF0IGRyYWZ0LCB0aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdCBkcmFmdA0KPiA+ ID4+IHNob3VsZCBiZQ0KPiA+ID4+ID4+Pj4gbm9ybWF0aXZlLiAgU29tZXRoaW5nIGFib3V0IGRv aW5nIHRoYXQgc3RyaWtlcyBtZSBhcyBwcmVtYXR1cmUNCj4gPiAuLi4NCj4gPiA+PiA+Pj4+DQo+ ID4gPj4gPj4+PiBJIHJlYWxpemUgdGhhdCB3ZSdyZSB0cnlpbmcgdG8gcHJlZGljdCBhbmQgYWNj b21tb2RhdGUgdGhlDQo+ID4gZnV0dXJlLA0KPiA+ID4+IHdoaWNoDQo+ID4gPj4gPj4+PiBpcyBh biBpbXByZWNpc2UgdW5kZXJ0YWtpbmcgYXQgYmVzdC4gICBBcyBhbiBhbHRlcm5hdGl2ZSB0byB0 aGUNCj4gPiA+PiBjdXJyZW50IHRleHQsDQo+ID4gPj4gPj4+PiB3b3VsZCBpdCBiZSByZWFzb25h YmxlIHRvIHNheSAod2l0aG91dCBhbnkgUkZDIDIxMTkga2V5d29yZHMpDQo+ID4gdGhhdA0KPiA+ ID4+IHRoZQ0KPiA+ID4+ID4+Pj4gYmVzdCBjdXJyZW50IGd1aWRhbmNlIGlzIHN0aWxsIHRvIHRy ZWF0IEVDTi1DRSBtYXJrcyBhcw0KPiA+IGluZGljYXRpbmcNCj4gPiA+PiBkcm9wcywNCj4gPiA+ PiA+Pj4+IHdpdGggYSB3YXJuaW5nIHRoYXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5IG9m IHRoaXMgY2hhbmdpbmcNCj4gPiA+PiBpbg0KPiA+ID4+IHRoZQ0KPiA+ID4+ID4+Pj4gbmVhciBm dXR1cmUgZHVlIHRvIGFsbCBvZiB0aGUgd29yayBpbiBwcm9ncmVzcyBjaXRlZCBpbiBTZWN0aW9u DQo+ID4gNz8NCj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+PiBUaGFua3MsIC0tRGF2aWQNCj4gPiA+ PiA+Pj4+DQo+ID4gPj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiA+ Pj4+PiBGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo+ID4g Pj4gPj4+Pj4gU2VudDogRnJpZGF5LCBKdW5lIDE3LCAyMDE2IDY6MTQgQU0NCj4gPiA+PiA+Pj4+ PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+ID4+ID4+Pj4+IENjOiBydGN3ZWJA aWV0Zi5vcmc7IElFVEYgQVZUQ29yZSBXRzsgdHN2d2cNCj4gPiA+PiA+Pj4+PiBTdWJqZWN0OiBS ZTogW3J0Y3dlYl0gW0FWVENPUkVdIFt0c3Z3Z10gV0cgTGFzdCBDYWxsIG9uDQo+ID4gY2hhbmdl czoNCj4gPiA+PiBkcmFmdC1pZXRmLQ0KPiA+ID4+ID4+Pj4+IGF2dGNvcmUtcnRwLWNpcmN1aXQt YnJlYWtlcnMtMTYNCj4gPiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+DQo+ID4gPj4gPj4+Pj4+IE9u IDE2IEp1biAyMDE2LCBhdCAyMzoyNSwgSm9obiBMZXNsaWUgPGpvaG5AamxjLm5ldD4gd3JvdGU6 DQo+ID4gPj4gPj4+Pj4+DQo+ID4gPj4gPj4+Pj4+IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tA ZW1jLmNvbT4gd3JvdGU6DQo+ID4gPj4gPj4+Pj4+Pg0KPiA+ID4+ID4+Pj4+Pj4gLi4uICBJIHZp ZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcgaW1wbGVtZW50ZXJzIHdpdGgNCj4gPiB0 b28NCj4gPiA+PiBtdWNoDQo+ID4gPj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25vcmUgRUNOLUNF IG1hcmtzIChlLmcuLCBiZWNhdXNlIGFuIGltcGxlbWVudGVyDQo+ID4gPj4gZG9lc24ndA0KPiA+ ID4+ID4+Pj4+Pj4gd2FudCB0byB0aGluayBhYm91dCB0aGlzIHByb2JsZW0gc3BhY2UgaW4gdGhl IGZpcnN0IHBsYWNlKS4NCj4gPiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+IEkgYWdyZWUsIGJ1dCB0 aGUgYXJndW1lbnQgaXMgdGhhdCBkb2luZyBzbyBpcyBsZXNzIGhhcm1mdWwgdGhhbg0KPiA+ID4+ IGRlcGxveWluZyBhDQo+ID4gPj4gPj4gY2lyY3VpdA0KPiA+ID4+ID4+Pj4+IGJyZWFrZXIgdGhh dCB0cmlnZ2VycyB0b28gb2Z0ZW4gd2hlbiBFQ04gaXMgdXNlZC4NCj4gPiA+PiA+Pj4+Pg0KPiA+ ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQsIHRo b3VnaCwgc2luY2UgaXQgc2VlbXMNCj4gPiA+PiB0aGF0DQo+ID4gPj4gYW55IG5ldw0KPiA+ID4+ ID4+IEFRTQ0KPiA+ID4+ID4+Pj4+IHRoYXQgYXBwbGllcyBFQ04gbWFya3MgbXVjaCBtb3JlIG9m dGVuIHRoYW4gYXQgcHJlc2VudCB3aWxsDQo+ID4gaGF2ZQ0KPiA+ID4+IHRvDQo+ID4gPj4gPj4g Y29uc2lkZXINCj4gPiA+PiA+Pj4+PiBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgdG8gd29yayB3 aXRoIGRlcGxveWVkIFRDUCAoZS5nLiwNCj4gPiBkcmFmdC0NCj4gPiA+PiBicmlzY29lLQ0KPiA+ ID4+ID4+IHRzdndnLQ0KPiA+ID4+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVz ZXMgRUNUKDEpIGFzIGEgc2lnbmFsIHRvIHVzZSB0aGUNCj4gPiBuZXcNCj4gPiA+PiBtYXJraW5n LA0KPiA+ID4+ID4+Pj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDAp KS4gVGhlc2UgY29tcGF0aWJpbGl0eQ0KPiA+ID4+IG1lY2hhbmlzbXMNCj4gPiA+PiA+Pj4+PiB3 b3VsZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIg dG9vLg0KPiA+ID4+ID4+Pj4+DQo+ID4gPj4gPj4+Pj4+IFVuZGVyc3RhbmQsIHdlIGhhdmUgYXQg bGVhc3QgdHdvIHByb3Bvc2FscyB0byBtYWtlIEVDTi1DRSBtb3JlDQo+ID4gPj4gPj4gZnJlcXVl bnQNCj4gPiA+PiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3VsZCBiZSBmb3Igbm9uLUVDTiBw YWNrZXRzOiBwb3NzaWJseQ0KPiA+ID4+IHN1YnN0YW50aWFsbHkNCj4gPiA+PiA+Pj4+Pj4gbW9y ZSBmcmVxdWVudC4gVW5sZXNzIGJvdGggYXJlIGtpbGxlZCBvZmYsIEVDTi1DRSB3aWxsIHNob3cg dXANCj4gPiA+PiBmcmVxdWVudGx5DQo+ID4gPj4gPj4+Pj4+IGVub3VnaCB0aGF0IGNsb3Npbmcg dGhlIGZsb3cgb24gRUNOLUNFIHdvdWxkIGtpbGwgdG9vIG1hbnkNCj4gPiA+PiBjb25uZWN0aW9u cy4NCj4gPiA+PiA+Pj4+Pj4NCj4gPiA+PiA+Pj4+Pj4gSWYgeW91IHdhbnQgY2lyY3VpdC1icmVh a2luZyBvbiBzdWNoIGNvbm5lY3Rpb25zLCB0aGVyZSBhcmUNCj4gPiB0d28NCj4gPiA+PiB3YXlz Og0KPiA+ID4+ID4+Pj4+PiAxLiBjb252aW5jZSB0aGUgZm9yd2FyZGluZyBub2RlcyB0byBkcm9w IHBhY2tldHMgaWYgdGhlaXINCj4gPiBxdWV1ZQ0KPiA+ID4+IGV4Y2VlZHMNCj4gPiA+PiA+Pj4+ Pj4gZGVzaWduIGNhcGFjaXR5OyBvcg0KPiA+ID4+ID4+Pj4+PiAyLiByZXF1aXJlIHRoZSBzZW5k ZXIgdG8gc2VuZCBlbm91Z2ggbm90LUVDTi1jYXBhYmxlIHBhY2tldHMNCj4gPiBzbw0KPiA+ID4+ IHRoYXQgb3VyDQo+ID4gPj4gPj4+Pj4+IHJlY2VpdmVyIHdpbGwgc2VlIGVub3VnaCBwYWNrZXQt ZHJvcHMgd2hlbiBhIGNpcmN1aXQtYnJlYWtlcg0KPiA+ID4+IHNob3VsZA0KPiA+ID4+ID4+Pj4+ PiBhY3RpdmF0ZS4NCj4gPiA+PiA+Pj4+Pj4NCj4gPiA+PiA+Pj4+Pj4gKEkgcHJlZmVyIHRoZSBm aXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0IG9iamVjdCB0byB0aGUNCj4gPiA+PiBzZWNvbmQu KQ0KPiA+ID4+ID4+Pj4+Pg0KPiA+ID4+ID4+Pj4+PiBUaGVyZSByZWFsbHkgaXNuJ3QgYW55IHdh eSBmb3Igb3VyIGNpcmN1aXQtYnJlYWtlciB0byBrbm93DQo+ID4gPj4gX2hvd19tdWNoXw0KPiA+ ID4+ID4+Pj4+PiBtb3JlIGZyZXF1ZW50IHRoZSBFQ04tQ0UgbWFya3MgbWF5IGJlLiA6XigNCj4g PiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+IFRoaXMgaXMgYSBwcm9ibGVtLCBib3RoIGZvciB0aGUg Y2lyY3VpdCBicmVha2VyLCBhbmQgZm9yIHRoZQ0KPiA+ID4+IGFsZ29yaXRobXMgYmVpbmcNCj4g PiA+PiA+Pj4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNvbWUgdW5kZXJzdGFuZGlu ZyB3aGF0IHRoZQ0KPiA+IGV4cGVjdGVkDQo+ID4gPj4gPj4gbWFya2luZw0KPiA+ID4+ID4+Pj4+ IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUsIHNvIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgY2lyY3Vp dA0KPiA+ID4+IGJyZWFrZXJzDQo+ID4gPj4gY2FuIGJlDQo+ID4gPj4gPj4gZGVmaW5lZC4NCj4g PiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+PiBXZSBfd2lsbF8gYmUgc29ycnkgaWYgd2UNCj4gPiA+ PiA+Pj4+Pj4gYWxsb3QgdGhlIHNhbWUgZnJlcXVlbmN5IG9mIENFIHBhY2tldHMgYXMgcGFja2V0 LWRyb3BzIHRvDQo+ID4gPj4gdHJpZ2dlcg0KPiA+ID4+IHRoZQ0KPiA+ID4+ID4+Pj4+PiBjaXJj dWl0LWJyZWFrZXIuDQo+ID4gPj4gPj4+Pj4+DQo+ID4gPj4gPj4+Pj4+PiBDb3VsZCBzb21lb25l IHByb3Bvc2UgaW5pdGlhbCB0ZXh0IHRvIHF1YWxpZmllcyB0aGUgY3VycmVudA0KPiA+ID4+ICJN QVkNCj4gPiA+PiBpZ25vcmUiDQo+ID4gPj4gPj4+Pj4+PiBzdGF0ZW1lbnQ/DQo+ID4gPj4gPj4+ Pj4+DQo+ID4gPj4gPj4+Pj4+IEVzc2VudGlhbGx5LCBmb3IgdGhlIHNlY29uZCBvcHRpb24sIHlv dSBtaWdodCBwcm9wb3NlIHRleHQgdG8NCj4gPiA+PiB0aGUNCj4gPiA+PiA+Pj4+Pj4gZWZmZWN0 IG9mOg0KPiA+ID4+ID4+Pj4+PiBdDQo+ID4gPj4gPj4+Pj4+IF0gSWYgdG9vIG1hbnkgRUNOLUNF IHBhY2tldHMgYXJlIHJlY2VpdmVkLCB0aGUgc2VuZGVyIFNIT1VMRA0KPiA+ID4+IHNlbmQNCj4g PiA+PiBzb21lDQo+ID4gPj4gPj4+Pj4+IF0gbm90LUVDTi1jYXBhYmxlIHBhY2tldHMgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgZW5vdWdoIHBhY2tldHMNCj4gPiA+PiBhbG9uZyB0aGUNCj4gPiA+PiA+ Pj4+Pj4gXSBwYXRoIGFyZSBiZWluZyBkcm9wcGVkIHRvIGp1c3RpZnkgYWN0aXZhdGluZyBvdXIg Y2lyY3VpdC0NCj4gPiA+PiBicmVha2VyLg0KPiA+ID4+ID4+Pj4+Pg0KPiA+ID4+ID4+Pj4+PiBJ w6LigqzihKJtIG5vdCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3Vs ZCByZXNvbHZlDQo+ID4gPj4gdGhlDQo+ID4gPj4gaXNzdWUuDQo+ID4gPj4gPj4+Pj4NCj4gPiA+ PiA+Pj4+PiBJw6LigqzihKJtIG5vdCBjb252aW5jZWQgdGhpcyB3b3VsZCB3b3JrLiBUaGUgY2ly Y3VpdCBicmVha2VyIGlzDQo+ID4gPj4gbG9va2luZw0KPiA+ID4+IGF0IGxvbmcgdGVybQ0KPiA+ ID4+ID4+Pj4+IHRyZW5kcywgYW5kIGluIG9yZGVyIHRvIGhhdmUgZW5vdWdoIG5vdC1FQ1QgcGFj a2V0cyB0bw0KPiA+IGRldGVybWluZQ0KPiA+ID4+IGlmIGl0DQo+ID4gPj4gPj4gc2hvdWxkDQo+ ID4gPj4gPj4+Pj4gdHJpZ2dlciwgeW91w6LigqzihKJkIGVzc2VudGlhbGx5IGhhdmUgdG8gcnVu IHdpdGhvdXQgRUNOIGZvciBzb21lDQo+ID4gPj4gc2Vjb25kcy4NCj4gPiA+PiA+Pj4+Pg0KPiA+ ID4+ID4+Pj4+IC0tDQo+ID4gPj4gPj4+Pj4gQ29saW4gUGVya2lucw0KPiA+ID4+ID4+Pj4+IGh0 dHBzOi8vY3NwZXJraW5zLm9yZy8NCj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+ID4+Pj4gcnRjd2Vi IG1haWxpbmcgbGlzdA0KPiA+ID4+ID4+Pj4gcnRjd2ViQGlldGYub3JnDQo+ID4gPj4gPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+ID4+ID4NCj4g PiA+DQo+ID4gPg0KDQo= From nobody Mon Jun 27 13:44:03 2016 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 D745012D8E6; Mon, 27 Jun 2016 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 A1ikFbNLwd5R; Mon, 27 Jun 2016 13:43:53 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 B43E212D8C9; Mon, 27 Jun 2016 13:43:51 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHdNj-0003hj-GG; Mon, 27 Jun 2016 22:43:47 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHdNi-0008Hm-4k; Mon, 27 Jun 2016 22:43:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 27 Jun 2016 22:43:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> To: "De Schepper, Koen (Nokia - BE)" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 15 sum msgs/h 6 total rcpts 43711 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DC59AF59C13BC0D4F28E9F553A241CEB4D1FF3F9 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1460 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , Magnus Westerlund , tsvwg , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 20:43:58 -0000 > On 27. jun. 2016, at 21.12, De Schepper, Koen (Nokia - BE) = wrote: >=20 >=20 >> -----Original Message----- >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >> Sent: maandag 27 juni 2016 17:38 >> To: De Schepper, Koen (Nokia - BE) >> Cc: Michael Welzl; Black, David; gorry@erg.abdn.ac.uk; Magnus >> Westerlund; tsvwg; IETF AVTCore WG; rtcweb@ietf.org; Colin Perkins >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: = draft- >> ietf-avtcore-rtp-circuit-breakers-16 >>=20 >> I think thinking of L4S is maybe off at a tangent. The question = really >> is >> about the interpretation of loss and CE-mark as equivalent. I argued >> that >> each ECN-CE mark should not be counted as equivalent to a lost = segment - >=20 > Why not? As long as an AQM is marking at the same rate as dropping, a=20= > 100% marking means that non-ecn flows are being dropped at a 100%, = not? Yes you can construct an AQM mechanism to act precisely like that. Do we want rules that make every other behavior =E2=80=9Cillegal=E2=80=9D = ? Should this really be how end systems should interpret all forms of = CE-marking? I think we both would agree that the answer is no: both the L4S and the = ABE work are based on the premise that a CE-mark does *NOT* necessarily = mean the same as packet loss would. So I agree with Gorry here - a circuit breaker is a bit of a special = beast. It really mustn=E2=80=99t trigger by accident. Cheers, Michael >=20 > Koen. >=20 >=20 >> in this context we should use ECN to drive a CC algorithm and we = should >> be >> cautious to avoid requiring its use within a Circuit Breaker - = optional >> use, if you understand how to interpret a reaction to many CE-marks = as >> excessive congestion, are permitted. >>=20 >> Gorry >>=20 >>> As far as I understand, this draft is related to circuit breakers in >>> end-systems, right? >>>=20 >>> It is the end system that determines the use of ECN (currently = marking >>> non-ect for drop and ect(0) for Classic ECN). >>>=20 >>> In L4S we don't plan to change the behavior of Classic ECN, and = ABE's >>> behavior should be close to non-ABE ECN. So I guess there is no >> problem of >>> describing the behavior of how a Classic ECN based sender would >> respond >>> today. >>>=20 >>> As we only want to significantly change the network behavior of = ect(1) >>> marking, can we solve this issue by recommending (or even requiring) >>> senders to mark only ect(0) and describing the classic ECN circuit >>> breaker? When L4S gets defined, also an L4S based circuit breaker >>> extension can be defined for senders that want to use the L4S = service >>> (when senders send ect(1) packets). >>>=20 >>> Regards, >>> Koen. >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael >> Welzl >>>> Sent: maandag 20 juni 2016 18:36 >>>> To: Black, David >>>> Cc: Fairhurst; Magnus Westerlund; tsvwg; = IETF >>>> AVTCore WG; rtcweb@ietf.org; Colin Perkins >>>> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: >> draft- >>>> ietf-avtcore-rtp-circuit-breakers-16 >>>>=20 >>>>=20 >>>>> On 20. jun. 2016, at 15.16, Black, David >> wrote: >>>>>=20 >>>>>>> But I=C3=A2=E2=82=AC=E2=84=A2m less concerned than David about = eventually ignoring it >>>> for >>>> circuit >>>>>> breaker. >>>>>>>=20 >>>>>> Agree. Loss is the measurement that a CB MUST respond to. >>>>>=20 >>>>> Mumble. I would be ok with a clear discouragement for use of = ECN- >> CE >>>> marks, accompanied by the sort of design rationale here, or even >>>> better, >>>> a clear statement that lost packets for the purpose of the RTP >> circuit >>>> breaker have to be actually lost without getting into whether or = not >>>> ECN-CE marks are involved -i.e., the RTP circuit breaker is = specified >>>> against actual drops as a network protection backstop. >>>>>=20 >>>>> A related concern is that ECN marks may overstate equivalent loss >>>> behavior - a simplistic queue management discipline that marks = every >>>> packet when the queue is over a threshold (NB: this class of = marking >>>> behavior is NOT RECOMMENDED - a real AQM SHOULD be used) could = yield >> a >>>> run of ECN-CE marks that would not cause a corresponding with a run >> of >>>> packet drops. This is among the reasons that TCP reacts to ECN-CE >>>> marks only once per RTT, and might be a reason to treat multiple = ECN- >> CE >>>> marks in an RTT interval as not representing drops of all packets = for >>>> the RTP circuit breaker's TCP-equivalent throughput calculation. >>>>=20 >>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure we need such complicated logic = to find a case where >> ECN >>>> marks are different from packet drops: >>>>=20 >>>> Basically, they simply aren=C3=A2=E2=82=AC=E2=84=A2t - even = =C3=A2=E2=82=AC=C5=93real=C3=A2=E2=82=AC=C2=9D AQMs marking >> isn=C3=A2=E2=82=AC=E2=84=A2t >>>> exactly >>>> the same as a packet drop: the marks themselves inform you that an >> AQM >>>> did its job, and with modern AQMs like CoDel / PIE etc., = you=C3=A2=E2=82=AC=E2=84=A2re >>>> probably >>>> getting this from a shallow queue. Chances are that this is less = than >> a >>>> BDP worth of queuing, which is our justification for recommending a >>>> different back-off behavior in draft-khademi-tsvwg-ecn-response-00 >> and >>>> draft-khademi-tcpm-alternativebackoff-ecn-00 >>>>=20 >>>> So the point is not that AQMs would treat ECN marking and dropping >>>> differently - it=C3=A2=E2=82=AC=E2=84=A2s that ECN indicates an = AQM, and hence probably a >>>> shallow queue. With a drop, you just don=C3=A2=E2=82=AC=E2=84=A2t = know. >>>>=20 >>>> Back to the CB, I think an AQM marking at a shallow queue (like = e.g. >>>> CoDel) is indeed quite different from a =C3=A2=E2=82=AC=C5=93broken = connection=C3=A2=E2=82=AC=C2=9D. >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] >>>>>> Sent: Saturday, June 18, 2016 2:23 AM >>>>>> To: Mirja K=C3=83=C2=BChlewind >>>>>> Cc: Black, David; Magnus Westerlund; Colin Perkins; >> rtcweb@ietf.org; >>>> IETF >>>>>> AVTCore WG; tsvwg >>>>>> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: >>>> draft-ietf- >>>>>> avtcore-rtp-circuit-breakers-16 >>>>>>=20 >>>>>> I think we SHOULD NOT recommend to use ECN marks as inputs to a >> CB. >>>> See >>>>>> below: >>>>>>=20 >>>>>>> On 17 Jun 2016, at 16:02, Mirja K=C3=83=C2=BChlewind >>>> >>>>>> wrote: >>>>>>>=20 >>>>>>> +1 to not use normative language here. >>>>>>>=20 >>>>>>> However, please note that having a high level of ECN-CE marks >>>> (without any >>>>>> losses) means that all packets were received correctly. This >>>> situation can even >>>>>> occurs without high delays (depending on the AQM used), which >> would >>>> just >>>>>> mean the services works perfectly. Therefore for me CE marks are = a >>>> perfect input >>>>>> signal for a congestion control loop (where the AQM tell the >> sender >>>> to take action >>>>>> - whatever that means). >>>>>>=20 >>>>>> We may in future figure out ways to do this to detect significant >>>> failure using a >>>>>> rate adaptive transport and ECN e.g. Observing 100% CE marks or >>>> something, for >>>>>> an RTP flow that is trying to send well below its peak rate >> decided >>>> by CC -- but I >>>>>> think this is speculating at an algorithm and adding details here >> is >>>> not a good idea. >>>>>> Especially as AQM continues to evolve. >>>>>>=20 >>>>>>> But I=C3=A2=E2=82=AC=E2=84=A2m less concerned than David about = eventually ignoring it >>>> for >>>> circuit >>>>>> breaker. >>>>>>>=20 >>>>>> Agree. Loss is the measurement that a CB MUST respond to. >>>>>>=20 >>>>>>> In addition one point on something Magnus wrote earlier: >>>>>>> "If the implementation only have circuit breaker, i.e. no full >>>> fledged congestion >>>>>> controller and uses ECN, they can in worst case drive the buffer >>>> into >>>> the overload >>>>>> regime where it starts dropping packets. =C3=A2=E2=82=AC=C5=BE >>>>>>>=20 >>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure about this case. ECN is an = input signal for >>>> congestion >>>> control. If you >>>>>> don=C3=A2=E2=82=AC=E2=84=A2t use congestion control but only a = circuit breaker, you >>>> should >>>> probably not >>>>>> enable ECN. At least it not clear to me why you would enable it, >> and >>>> it's definitely >>>>>> not conform to the ECN spec. Probably we should say something >> about >>>> this in the >>>>>> draft...? >>>>>>>=20 >>>>>> Agree, enabling ECN without a responsive CC is going to lead to >>>> trouble. >>>>>>=20 >>>>>>> Mirja >>>>>>>=20 >>>>>> Gorry >>>>>>=20 >>>>>>>> Am 17.06.2016 um 16:03 schrieb Black, David >> : >>>>>>>>=20 >>>>>>>> Colin, >>>>>>>>=20 >>>>>>>>>>> ... I view the current text as providing implementers with >> too >>>> much >>>>>>>>>>> latitude to ignore ECN-CE marks (e.g., because an = implementer >>>> doesn't >>>>>>>>>>> want to think about this problem space in the first place). >>>>>>>>>=20 >>>>>>>>> I agree, but the argument is that doing so is less harmful = than >>>> deploying a >>>>>> circuit >>>>>>>>> breaker that triggers too often when ECN is used. >>>>>>>>>=20 >>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure I believe this argument, = though, since it seems >>>> that >>>> any new >>>>>> AQM >>>>>>>>> that applies ECN marks much more often than at present will >> have >>>> to >>>>>> consider >>>>>>>>> backwards compatibility, to work with deployed TCP (e.g., >> draft- >>>> briscoe- >>>>>> tsvwg- >>>>>>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the >> new >>>> marking, >>>>>>>>> while existing implementations set ECT(0)). These = compatibility >>>> mechanisms >>>>>>>>> would seem to prevent the issues with the circuit breaker too. >>>>>>>>=20 >>>>>>>> That roughly matches my line of thinking, and I'll observe that >>>> the >>>> original >>>>>> DCTCP >>>>>>>> protocol design that used more aggressive ECN-CE marking was >> only >>>> safe for >>>>>>>> Controlled Environment deployments. See the TSVWG rfc5405bis >>>> draft for >>>>>> the >>>>>>>> definition of Controlled Environment, and ignore the fact that >> the >>>> rfc5405bis >>>>>>>> draft is a UDP draft - this definition is more broadly >> applicable. >>>>>>>>=20 >>>>>>>> Going back over Section 7 in this avtcore draft, my views are: >>>>>>>>=20 >>>>>>>> [A] None of these drafts justify a "MAY ignore" response to = ECN- >> CE >>>> marks: >>>>>>>> - draft-khademi-tcpm-alternativebackoff-ecn >>>>>>>> - draft-ietf-rmcat-nada >>>>>>>> - draft-ietf-rmcat-scream-cc >>>>>>>>=20 >>>>>>>> [B] In line with Colin's comment on the L4S draft, I think it's >>>> incumbent on >>>>>>>> the authors of draft-briscoe-aqm-dualq-coupled to figure out = how >>>> that will >>>>>>>> coexist (or avoid) deployed TCP, and this avtcore draft ought >> not >>>> to be >>>>>>>> trying to prejudge what will be done there. >>>>>>>>=20 >>>>>>>> So, I don't think the current text in Section 7 has justified >> the >>>> unfettered >>>>>>>> "implementations MAY ignore ECN-CE marks" text, as ignoring >> those >>>> marks >>>>>>>> is not consistent with any of the four cited drafts. >>>>>>>>=20 >>>>>>>> In more detail, I think making changes to normative = requirements >>>> here based >>>>>>>> on [B] is premature, and I would hope that the rmcat WG could = be >>>>>> encouraged >>>>>>>> to consider the RTP circuit breaker in its congestion control >>>> drafts, as those CC >>>>>>>> mechanisms are related to the circuit breaker mechanism, hence >>>> likely >>>>>>>> to be in related areas of an RTP implementation. >>>>>>>>=20 >>>>>>>> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which >> TSVWG >>>>>>>> will be looking at in Berlin. If a normative statement about >> ECN- >>>> CE reaction >>>>>>>> is going to rest on that draft, then the reference to that = draft >>>> should be >>>>>>>> normative. Something about doing that strikes me as premature >> ... >>>>>>>>=20 >>>>>>>> I realize that we're trying to predict and accommodate the >> future, >>>> which >>>>>>>> is an imprecise undertaking at best. As an alternative to the >>>> current text, >>>>>>>> would it be reasonable to say (without any RFC 2119 keywords) >> that >>>> the >>>>>>>> best current guidance is still to treat ECN-CE marks as >> indicating >>>> drops, >>>>>>>> with a warning that there is a good possibility of this = changing >>>> in >>>> the >>>>>>>> near future due to all of the work in progress cited in Section >> 7? >>>>>>>>=20 >>>>>>>> Thanks, --David >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Colin Perkins [mailto:csp@csperkins.org] >>>>>>>>> Sent: Friday, June 17, 2016 6:14 AM >>>>>>>>> To: John Leslie; Black, David >>>>>>>>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >>>>>>>>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on >> changes: >>>> draft-ietf- >>>>>>>>> avtcore-rtp-circuit-breakers-16 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>>>>>>>>=20 >>>>>>>>>> Black, David wrote: >>>>>>>>>>>=20 >>>>>>>>>>> ... I view the current text as providing implementers with >> too >>>> much >>>>>>>>>>> latitude to ignore ECN-CE marks (e.g., because an = implementer >>>> doesn't >>>>>>>>>>> want to think about this problem space in the first place). >>>>>>>>>=20 >>>>>>>>> I agree, but the argument is that doing so is less harmful = than >>>> deploying a >>>>>> circuit >>>>>>>>> breaker that triggers too often when ECN is used. >>>>>>>>>=20 >>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure I believe this argument, = though, since it seems >>>> that >>>> any new >>>>>> AQM >>>>>>>>> that applies ECN marks much more often than at present will >> have >>>> to >>>>>> consider >>>>>>>>> backwards compatibility, to work with deployed TCP (e.g., >> draft- >>>> briscoe- >>>>>> tsvwg- >>>>>>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the >> new >>>> marking, >>>>>>>>> while existing implementations set ECT(0)). These = compatibility >>>> mechanisms >>>>>>>>> would seem to prevent the issues with the circuit breaker too. >>>>>>>>>=20 >>>>>>>>>> Understand, we have at least two proposals to make ECN-CE = more >>>>>> frequent >>>>>>>>>> than packet drop would be for non-ECN packets: possibly >>>> substantially >>>>>>>>>> more frequent. Unless both are killed off, ECN-CE will show = up >>>> frequently >>>>>>>>>> enough that closing the flow on ECN-CE would kill too many >>>> connections. >>>>>>>>>>=20 >>>>>>>>>> If you want circuit-breaking on such connections, there are >> two >>>> ways: >>>>>>>>>> 1. convince the forwarding nodes to drop packets if their >> queue >>>> exceeds >>>>>>>>>> design capacity; or >>>>>>>>>> 2. require the sender to send enough not-ECN-capable packets >> so >>>> that our >>>>>>>>>> receiver will see enough packet-drops when a circuit-breaker >>>> should >>>>>>>>>> activate. >>>>>>>>>>=20 >>>>>>>>>> (I prefer the first option; but I wouldn't object to the >>>> second.) >>>>>>>>>>=20 >>>>>>>>>> There really isn't any way for our circuit-breaker to know >>>> _how_much_ >>>>>>>>>> more frequent the ECN-CE marks may be. :^( >>>>>>>>>=20 >>>>>>>>> This is a problem, both for the circuit breaker, and for the >>>> algorithms being >>>>>>>>> defined in RMCAT. We do need some understanding what the >> expected >>>>>> marking >>>>>>>>> rates are likely to be, so congestion control and circuit >>>> breakers >>>> can be >>>>>> defined. >>>>>>>>>=20 >>>>>>>>>> We _will_ be sorry if we >>>>>>>>>> allot the same frequency of CE packets as packet-drops to >>>> trigger >>>> the >>>>>>>>>> circuit-breaker. >>>>>>>>>>=20 >>>>>>>>>>> Could someone propose initial text to qualifies the current >>>> "MAY >>>> ignore" >>>>>>>>>>> statement? >>>>>>>>>>=20 >>>>>>>>>> Essentially, for the second option, you might propose text to >>>> the >>>>>>>>>> effect of: >>>>>>>>>> ] >>>>>>>>>> ] If too many ECN-CE packets are received, the sender SHOULD >>>> send >>>> some >>>>>>>>>> ] not-ECN-capable packets to determine whether enough packets >>>> along the >>>>>>>>>> ] path are being dropped to justify activating our circuit- >>>> breaker. >>>>>>>>>>=20 >>>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not enthusiastic about adding = that; but it would resolve >>>> the >>>> issue. >>>>>>>>>=20 >>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not convinced this would work. The = circuit breaker is >>>> looking >>>> at long term >>>>>>>>> trends, and in order to have enough not-ECT packets to >> determine >>>> if it >>>>>> should >>>>>>>>> trigger, you=C3=A2=E2=82=AC=E2=84=A2d essentially have to run = without ECN for some >>>> seconds. >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Colin Perkins >>>>>>>>> https://csperkins.org/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> rtcweb mailing list >>>>>>>> rtcweb@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>=20 >>>=20 >=20 From nobody Mon Jun 27 13:52:58 2016 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 54ADE12D8ED; Mon, 27 Jun 2016 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Jlimzs4mdFc7; Mon, 27 Jun 2016 13:52:47 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBE812D906; Mon, 27 Jun 2016 13:52:45 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHdWM-0005Li-Ji; Mon, 27 Jun 2016 22:52:42 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHdWL-0001kS-Ua; Mon, 27 Jun 2016 22:52:42 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 27 Jun 2016 22:52:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 6 sum rcpts/h 21 sum msgs/h 8 total rcpts 43717 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EDE3784A2ED8A05C4E7D3F5B76F58C2CF9551B16 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1462 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 20:52:49 -0000 David, > On 27. jun. 2016, at 22.09, Black, David wrote: >=20 >> As long as an AQM is marking at the same rate as dropping >=20 > That's an interesting assumption - it should be true for AQMs vetted > here in the past, but there are easy ways for it not to hold (e.g., if = dropping > or marking is based on queue occupancy, it is possible that dropping > reduces queue occupancy in a fashion that marking does not). >=20 > For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are = treated > as drop-equivalent, that is for congestion control purposes, which is = similar > to, (but not the same as) the throughput estimation usage for the RTP = circuit > breaker. I'll note that ECN "classic" was designed congestion = control > algorithms for react to ECN-CE marks once per RTT, independent of how > many ECN-CE marks are observed in an RTT. >=20 > Gorry wrote: >=20 >>> in this context we should use ECN to drive a CC algorithm and we = should be >>> cautious to avoid requiring its use within a Circuit Breaker - = optional >>> use, if you understand how to interpret a reaction to many CE-marks = as >>> excessive congestion, are permitted. >=20 > Something like that may be workable, starting with a clear distinction = between > the use of ECN by CC (routine, active at all times) and ECN by a = circuit > breaker (monitors for evidence that things have gotten bad, only = activated > when things get bad). This would baseline the RTP circuit breaker on = drops > and allow use of ECN as additional evidence of problems, in contrast = to > congestion control where ECN-CE is effectively treated as = drop-equivalent. >=20 > I'm not quite sure how to specify "use of ECN as additional evidence" = of > "excessive congestion" as drop-equivalence is about the best we have > for current guidance. I fail to parse that sentence, so maybe I=E2=80=99m getting you wrong, = but anyway I wonder: what=E2=80=99s even the point of this? Why even bother considering CE-marks as information for a circuit = breaker? CE-marks may *not* indicate *excessive* congestion - and since you say = =E2=80=9Cadditional evidence=E2=80=9D: I don=E2=80=99t think that a = combination of loss and CE-marks makes this any better? CE-marks may be = produced by a shallow queue, which can be rather =E2=80=9Cmild=E2=80=9D = congestion, at least in the light of what a circuit breaker should = consider=E2=80=A6 Cheers, Michael From nobody Mon Jun 27 15:02:43 2016 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 1499512D8B1; Mon, 27 Jun 2016 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 c90lEi2M0KD5; Mon, 27 Jun 2016 15:02:30 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FE812D9B5; Mon, 27 Jun 2016 15:02:29 -0700 (PDT) Received: from [81.187.2.149] (port=39596 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bHebq-0004LA-92; Mon, 27 Jun 2016 23:02:26 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> Date: Mon, 27 Jun 2016 23:02:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 22:02:33 -0000 > On 27 Jun 2016, at 21:52, Michael Welzl wrote: >=20 > David, >=20 >=20 >> On 27. jun. 2016, at 22.09, Black, David wrote: >>=20 >>> As long as an AQM is marking at the same rate as dropping >>=20 >> That's an interesting assumption - it should be true for AQMs vetted >> here in the past, but there are easy ways for it not to hold (e.g., = if dropping >> or marking is based on queue occupancy, it is possible that dropping >> reduces queue occupancy in a fashion that marking does not). >>=20 >> For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are = treated >> as drop-equivalent, that is for congestion control purposes, which is = similar >> to, (but not the same as) the throughput estimation usage for the RTP = circuit >> breaker. I'll note that ECN "classic" was designed congestion = control >> algorithms for react to ECN-CE marks once per RTT, independent of how >> many ECN-CE marks are observed in an RTT. >>=20 >> Gorry wrote: >>=20 >>>> in this context we should use ECN to drive a CC algorithm and we = should be >>>> cautious to avoid requiring its use within a Circuit Breaker - = optional >>>> use, if you understand how to interpret a reaction to many CE-marks = as >>>> excessive congestion, are permitted. >>=20 >> Something like that may be workable, starting with a clear = distinction between >> the use of ECN by CC (routine, active at all times) and ECN by a = circuit >> breaker (monitors for evidence that things have gotten bad, only = activated >> when things get bad). This would baseline the RTP circuit breaker = on drops >> and allow use of ECN as additional evidence of problems, in contrast = to >> congestion control where ECN-CE is effectively treated as = drop-equivalent. >>=20 >> I'm not quite sure how to specify "use of ECN as additional evidence" = of >> "excessive congestion" as drop-equivalence is about the best we have >> for current guidance. >=20 > I fail to parse that sentence, so maybe I=E2=80=99m getting you wrong, = but anyway I wonder: what=E2=80=99s even the point of this? > Why even bother considering CE-marks as information for a circuit = breaker? Because the alternative is that we only break the circuit once the queue = has been driven into overflow, and packets have been lost. We want to = avoid that, since it causes latency, and too much latency is very bad = for the user experience.=20 > CE-marks may *not* indicate *excessive* congestion - and since you say = =E2=80=9Cadditional evidence=E2=80=9D: I don=E2=80=99t think that a = combination of loss and CE-marks makes this any better? CE-marks may be = produced by a shallow queue, which can be rather =E2=80=9Cmild=E2=80=9D = congestion, at least in the light of what a circuit breaker should = consider=E2=80=A6 Surely this is just arguing for a different threshold for a circuit = breaker triggered by ECN-CE marks (using a modern, small queue, AQM) = than for one triggered by loss (or ECN marks considered equivalent to = loss)?=20 If I understand the L4S proposal correctly, that would be treat ECN-CE = marks on ECT(0) marked flows as equivalent to loss, but treat ECN-CE = marks on ECT(1) marked flows with a (much) higher threshold.=20 Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running (and RMCAT has figured out the right = congestion response for that; the proposals now treat ECN-CE and loss = very similarly). --=20 Colin Perkins https://csperkins.org/ From nobody Mon Jun 27 15:29:37 2016 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 2E3CA12DA1D; Mon, 27 Jun 2016 15:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 srG2c0_PfgM8; Mon, 27 Jun 2016 15:29:32 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 8382B12D9FB; Mon, 27 Jun 2016 15:29:32 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHf21-0000OP-6Q; Tue, 28 Jun 2016 00:29:29 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHf20-0005Rh-3B; Tue, 28 Jun 2016 00:29:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> Date: Tue, 28 Jun 2016 00:29:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 2 sum rcpts/h 21 sum msgs/h 6 total rcpts 43742 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5426A5020F93DC23462A308CEEEE1C860525310A X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1471 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 22:29:36 -0000 > On 28. jun. 2016, at 00.02, Colin Perkins wrote: >=20 >=20 >> On 27 Jun 2016, at 21:52, Michael Welzl wrote: >>=20 >> David, >>=20 >>=20 >>> On 27. jun. 2016, at 22.09, Black, David = wrote: >>>=20 >>>> As long as an AQM is marking at the same rate as dropping >>>=20 >>> That's an interesting assumption - it should be true for AQMs vetted >>> here in the past, but there are easy ways for it not to hold (e.g., = if dropping >>> or marking is based on queue occupancy, it is possible that dropping >>> reduces queue occupancy in a fashion that marking does not). >>>=20 >>> For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are = treated >>> as drop-equivalent, that is for congestion control purposes, which = is similar >>> to, (but not the same as) the throughput estimation usage for the = RTP circuit >>> breaker. I'll note that ECN "classic" was designed congestion = control >>> algorithms for react to ECN-CE marks once per RTT, independent of = how >>> many ECN-CE marks are observed in an RTT. >>>=20 >>> Gorry wrote: >>>=20 >>>>> in this context we should use ECN to drive a CC algorithm and we = should be >>>>> cautious to avoid requiring its use within a Circuit Breaker - = optional >>>>> use, if you understand how to interpret a reaction to many = CE-marks as >>>>> excessive congestion, are permitted. >>>=20 >>> Something like that may be workable, starting with a clear = distinction between >>> the use of ECN by CC (routine, active at all times) and ECN by a = circuit >>> breaker (monitors for evidence that things have gotten bad, only = activated >>> when things get bad). This would baseline the RTP circuit breaker = on drops >>> and allow use of ECN as additional evidence of problems, in contrast = to >>> congestion control where ECN-CE is effectively treated as = drop-equivalent. >>>=20 >>> I'm not quite sure how to specify "use of ECN as additional = evidence" of >>> "excessive congestion" as drop-equivalence is about the best we have >>> for current guidance. >>=20 >> I fail to parse that sentence, so maybe I=E2=80=99m getting you = wrong, but anyway I wonder: what=E2=80=99s even the point of this? >> Why even bother considering CE-marks as information for a circuit = breaker? >=20 > Because the alternative is that we only break the circuit once the = queue has been driven into overflow, and packets have been lost. We want = to avoid that, since it causes latency, and too much latency is very bad = for the user experience.=20 Well - the better way out would be for the application to react. Maybe = this is me misunderstanding the circuit breaker, but I did think it=E2=80=99= s more like a last resort=E2=80=A6 you just don=E2=80=99t want to be = trigger-happy with such a thing? >> CE-marks may *not* indicate *excessive* congestion - and since you = say =E2=80=9Cadditional evidence=E2=80=9D: I don=E2=80=99t think that a = combination of loss and CE-marks makes this any better? CE-marks may be = produced by a shallow queue, which can be rather =E2=80=9Cmild=E2=80=9D = congestion, at least in the light of what a circuit breaker should = consider=E2=80=A6 >=20 > Surely this is just arguing for a different threshold for a circuit = breaker triggered by ECN-CE marks (using a modern, small queue, AQM) = than for one triggered by loss (or ECN marks considered equivalent to = loss)?=20 If you have room for yet another code point, for the circuit breaker = only? :) Or maybe I just misunderstand you here? > If I understand the L4S proposal correctly, that would be treat ECN-CE = marks on ECT(0) marked flows as equivalent to loss, but treat ECN-CE = marks on ECT(1) marked flows with a (much) higher threshold.=20 L4S would not change anything about how ECT(0) marked flows are treated, = and would CE-mark packets carrying ECT(1) with an instantaneous queue - = i.e. a much *lower* threshold. But that=E2=80=99s not the issue - I = agree there=E2=80=99s no problem with L4S. The compatibility problem does exist with the ABE proposal, which works = off ECT(0). The ABE proposal exploits a very simple fact: that CE-marks are, by = definition, *not* the same as loss (see David Black=E2=80=99s previous = email where he says "if dropping or marking is based on queue occupancy, = it is possible that dropping reduces queue occupancy in a fashion that = marking does not=E2=80=9D). Indeed, queue dynamics play out differently = when packets are dropped or marked ( see Section 7 with Figures 13/14 = in = https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434= .pdf ) . Losses may stem from a DropTail (FIFO) queue somewhere along the path - = CE-marks are, however, very likely to only be caused by an AQM = algorithm. TCP=E2=80=99s built-in reaction to loss yields full link = utilization only when there=E2=80=99s at least a BDP worth of queuing. = This is a lot of latency - when the queue is full this doubles the RTT. = Modern AQM mechanisms strive to maintain a much smaller average queue = size, and this is where they mark packets. So: if we react to CE-marks the same way as to loss, CoDel and PIE let = us underutilize the link. Thus, it makes more sense to interpret the signal for what it is: an = indication that there was congestion, but from a queue that might be = much smaller than a BDP. > Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running If you assume that there=E2=80=99s a parallel congestion control = algorithm running, I understand even less why you want to feed ECN = CE-marks into the circuit breaker. The congestion control algorithm = should already deal with them. =20 > (and RMCAT has figured out the right congestion response for that; the = proposals now treat ECN-CE and loss very similarly). I disagree that this is the =E2=80=9Cright=E2=80=9D congestion response. = It=E2=80=99s a workable one, sure. Nothing extremely terrible will = happen if congestion controllers treat ECN-CE and loss similarly - it = just yields unnecessarily poor utilization with ECN, with modern AQMs = (unless one backs off by less than TCP would in response to loss too, = which is good if there=E2=80=99s an AQM in place but may be quite bad = otherwise). Bottom line: it really does mean something different, and it seems wrong = to me to act as if that wasn=E2=80=99t the case - just because we=E2=80=99= ve always done so. Cheers, Michael From nobody Mon Jun 27 16:03:25 2016 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 CDD0612DA5E; Mon, 27 Jun 2016 16:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Kkr2BdaOeAHY; Mon, 27 Jun 2016 16:03:21 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F7C12DA65; Mon, 27 Jun 2016 16:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3195; q=dns/txt; s=iport; t=1467068598; x=1468278198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VAaZX0ROdLwNmX7qcO2RWkRfiRBl3ZH9DbVzO3DLVzc=; b=HQ39jH8Q2tK/fOOhZVqLnFCmA7m7/fxKzwcmXVHbsJ6+CW5mjyBY/fTj bhYZmTgRiVY/hVKsctB7A6KqLciDcR+lcN/AMlktbgd2XBGIscjaeo9fV e1TJ/szpGOoR81xaD6V7UO+XC9Rqy9/EVLDFQzN4tb7Yj8nfT/Oqcof5r c=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBQB8sHFX/5ldJa1bgz6BUwa6J4F7h?= =?us-ascii?q?hgCgTI6EgEBAQEBAQFlJ4RNAQEEeRACAQgYLjIlAgQOBQ6IIsB2AQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEPDogfCIJOh2yCLwWZAQGDLYFsiR2PJI9+ASUCLYI7gTVui?= =?us-ascii?q?Hh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,538,1459814400"; d="asc'?scan'208";a="290689781" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 23:03:04 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5RN34Uf012273 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 23:03:04 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 18:03:03 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 18:03:03 -0500 From: "Fred Baker (fred)" To: John Leslie Thread-Topic: [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0MgPJk4Q/dpdG0yJgW1TNb0Iow== Date: Mon, 27 Jun 2016 23:03:03 +0000 Message-ID: References: <20160614135927.GE39331@verdi> In-Reply-To: <20160614135927.GE39331@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Magnus Westerlund , "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 23:03:24 -0000 --Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 14, 2016, at 6:59 AM, John Leslie wrote: > We must find a way to avoid ECN-CE triggering the congestion circuit > breaker when the forwarding node has not reached a level of congestion > which could trigger packet loss. I'm not sure I agree. I tend to think that ECN is relatively cheap - it asks the sender to = reduce its effective window but doesn't make him retransmit anything and = causes no delivery delay - while packet loss is relatively expensive in = that it makes the sender retransmit and introduces at least a one RTT = hiccup ( to detect and retransmit the lost packet) in the transmission = stream. Neither actually changes the rate at which anyone sends (we talk = about the signal asking the sender to slow down, but the rate = demonstrably doesn't actually change - we're asking the sender to not = pack the pipe so full). When ECN does ask someone to reduce their effective window, if they are = typically increasing it by one per RTT, ECN could very logically reduce = it by a small amount, such as two or three. If it reduced it by two, for = example, that would cause it to skip the next two transmission = opportunities (the next two received acknowledgements, which might = actually arrive in the same ack), and would be back to the same level = two RTTs later. If ECN is typically keeping the delay relatively = shallow, it is oscillating between "a little shallower" and " a little = less shallow". So it gets CE every other RTT? So what? If I'm dropping a = packet, or a couple of packets, every other RTT, we're going to see = notes on NANOG and other lists. "Your network's broken again. It's = dropping packets." I could be argued into setting the CE threshold a little lower than the = discard threshold. There are probably some mechanisms we'd do well to = explore, but... --Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV3Gwp0ayAOS/EQ8MAQIcWQ//RQ78ysjqgFND1AT6aIn+VwNBvFrqLoZG Qmco/8N7hN2JFKH+xLetplT6cFC266SeyxCepbuGh24J5WlUM5NlqtZlf09THS2E /k2ZRDWB5F7Z8FXAFB4TZSyUN02Iz9xr8qiMt3zB8l62F/AMeqhUE63RD9yrW4My oERvVSuqc4MoIvI5hkf7FLPTmK66tPs9bB4+R+XyI3NadhLphSfQG6MoNjk56Q3l AJg7EB2P7OY2hvf9nTqt0GYQDZCL1gmDPZmn2K2EPPuKy90ovQblr9UmNNJOoB+3 FyzZTMAghbdWCgNocB3dDHbeql2PBKDvsi9GiJDu8OxRXGgA5DFUNVFSPWQGaZky JvKN0pImScqr1ZJ+knUdUMfKd+wjIK1MdsAu9dugqQ79AEG/EhiAFezeNeGzQOqZ MN4kJXbLLKuCrKb2HTkTEIMZ1bDlNjT+EWWd9vsdciP7yBGzcAoImRbszagw7aTI VrA/b6tDlxFIv+BChR6tUwTz7Qr10vuhWtsMUPmL5Rn25Ry1/cQggJ/1YA6xQJSB u1ZMUvZAEe6MsHt2GK0CLG3lsg3ykCC3AFyYIU21ACdWBEJOuu/+VaCv9NxcpqjF dblrMlIS5xJAeZMIE+Pv3cOMhJ7fV5dnUcl2dGQh5mUYi3bnjm8/NruvCgAQUQ3x JzxkI2WVSYc= =mQAq -----END PGP SIGNATURE----- --Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1-- From nobody Mon Jun 27 16:59:36 2016 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 1331112DAA3 for ; Mon, 27 Jun 2016 16:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 Xjj0apbyOqoJ for ; Mon, 27 Jun 2016 16:59:32 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5136E12D9EB for ; Mon, 27 Jun 2016 16:59:32 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5RNxVZl025967 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 27 Jun 2016 19:59:31 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5RNxVZl025967 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467071971; bh=ai3nobbkxSHNYUx91L04FAgjynA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rGXE1t6WspW/5dHgAVkuZ8z8YEFrfvDK7Jewr4y1aXFcPaYp4SfiI0yMs5Wn0+C/g yKc6gUw8bFafnB5rfRQTEGVrHbPjlOjSckoxfWH41EtL8GPJjllyLNcbDZpwwqcVZe 8zOCAECV76i04i6/t0JEC3m4EApp3YZ+oZ7H1vzw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5RNxVZl025967 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd04.lss.emc.com (RSA Interceptor) for ; Mon, 27 Jun 2016 19:58:55 -0400 Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5RNxJko013348 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Mon, 27 Jun 2016 19:59:20 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0266.001; Mon, 27 Jun 2016 19:59:19 -0400 From: "Black, David" To: "tsvwg@ietf.org" Thread-Topic: draft-szigeti-tsvwg-ieee-802-11 - Adopted by TSVWG Thread-Index: AdHQz+rJ7Qu39xGFQUm/Y05sX5UQzQ== Date: Mon, 27 Jun 2016 23:59:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] draft-szigeti-tsvwg-ieee-802-11 - Adopted by TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 23:59:34 -0000 The WG chairs conclusion is that the rough consensus of the TSVWG WG is to = adopt this draft as a WG draft. The authors should submit a draft-ietf-tsvwg-* = version, and this draft will be included in the WG drafts portion of the TSVWG Berlin me= eting agenda. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > Sent: Thursday, June 09, 2016 1:14 AM > To: tsvwg@ietf.org > Subject: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - thro= ugh June > 25 >=20 > This is a TSVWG call for interest in WG adoption of draft-szigeti-tsvwg-i= eee-802- > 11. > If you have read the draft and support WG adoption of it as a work item > and WG draft, please send an email to the list (tsvwg@ietf.org) saying so= . >=20 > NB: It is important to say that you've read the draft. If you're willing > to review/comment on future versions of this draft and/or implement this > draft, please say so on the list or in email directly to the chairs > (tsvwg-chairs@ietf.org). >=20 > Authors: We (chairs) assume that you support WG adoption of your draft, s= o > there's no need to say so on the list. However, we do need each author t= o > publicly state on the list that their direct, personal knowledge (if any)= of any > IPR related to this document has already been disclosed, in conformance > with BCPs 78 and 79. >=20 > This adoption call will run for about 2 weeks, ending at midnight, prevai= ling > US Eastern Time on Saturday June 25. To get things started, I hereby sta= te > as an individual that I have read the draft and support WG adoption of it= . >=20 > Guidelines for DiffServ to IEEE 802.11 Mapping > draft-szigeti-tsvwg-ieee-802-11-01 >=20 > Abstract >=20 > As internet traffic is increasingly sourced-from and destined-to > wireless endpoints, it is crucial that Quality of Service be aligned > between wired and wireless networks; however, this is not always the > case by default. This is due to the fact that two independent > standards bodies provide QoS guidance on wired and wireless networks: > specifically, the IETF specifies standards and design recommendations > for wired IP networks, while a separate and autonomous standards- > body, the IEEE, administers the standards for wireless 802.11 > networks. The purpose of this document is to propose a set > Differentiated Services Code Point (DSCP) to IEEE 802.11 User > Priority (UP) mappings to reconcile the marking recommendations > offered by these two standards bodies, and, as such, to optimize > wired-and-wireless interconnect QoS. >=20 > Thanks, --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 > david.black@emc.com > ---------------------------------------------------- >=20 From nobody Mon Jun 27 17:04:08 2016 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 0D1EA12DAB6; Mon, 27 Jun 2016 17:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 C7YmQYi1tzAn; Mon, 27 Jun 2016 17:04:05 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3710412D7F8; Mon, 27 Jun 2016 17:04:05 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id ED3DBC9419; Mon, 27 Jun 2016 20:04:00 -0400 (EDT) Date: Mon, 27 Jun 2016 20:04:00 -0400 From: John Leslie To: Colin Perkins Message-ID: <20160628000400.GA1223@verdi> References: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> User-Agent: Mutt/1.4.1i Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , Michael Welzl , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 00:04:07 -0000 Colin Perkins wrote: > On 27 Jun 2016, at 21:52, Michael Welzl wrote: > >> Why even bother considering CE-marks as information for a circuit breaker? > > Because the alternative is that we only break the circuit once the queue > has been driven into overflow, and packets have been lost. > We want to avoid that, since it causes latency, and too much latency is > very bad for the user experience. If you want a circuit-breaker to control latency, why aren't you measuring latency? -- John Leslie From nobody Mon Jun 27 17:10:55 2016 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 317AA12DAB7; Mon, 27 Jun 2016 17:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 bsFnzNQBIVOO; Mon, 27 Jun 2016 17:10:47 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F3012DAB5; Mon, 27 Jun 2016 17:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1999; q=dns/txt; s=iport; t=1467072647; x=1468282247; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nUh+eRUAkz0MKZNyoZ4kFaO+q0WnI3KbfwC+kI4poHk=; b=TVkZ3Tgo7puW1WfPQcGafjt3T+E7OU9dM/5LKdJBlpZRLvKfyTV7PkDV 9s1lXAD4pLHnGCzR3pq1VYOCS5/yDSWAziB6toITN2+CfXStJNsRCoTG0 W0EoO47OisFX+V4jUIs+TmaiWVJ1g/gsqVbFAk69sGEjB2QLTAlma8Ko1 g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQD1v3FX/4oNJK1bgz6BUwa4G4IPg?= =?us-ascii?q?XuGGAKBMjgUAQEBAQEBAWUnhEwBAQEDAXkFCwIBCBguMiUCBA4FDogaCMEJAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDg6IHwiCTodsgi8FmQIBgy2BbIkfjySPfgEeN?= =?us-ascii?q?oI7gTVuiDF/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,538,1459814400"; d="asc'?scan'208";a="290630131" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 00:10:46 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u5S0AkAg003816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jun 2016 00:10:46 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 19:10:45 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 19:10:42 -0500 From: "Fred Baker (fred)" To: John Leslie Thread-Topic: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0NGCnW55W4e6ZUygJkpoCO5zfg== Date: Tue, 28 Jun 2016 00:10:42 +0000 Message-ID: References: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <20160628000400.GA1223@verdi> In-Reply-To: <20160628000400.GA1223@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins , Michael Welzl , tsvwg Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 00:10:49 -0000 --Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 27, 2016, at 5:04 PM, John Leslie wrote: >=20 > Colin Perkins wrote: >> On 27 Jun 2016, at 21:52, Michael Welzl wrote: >>=20 >>> Why even bother considering CE-marks as information for a circuit = breaker? >>=20 >> Because the alternative is that we only break the circuit once the = queue >> has been driven into overflow, and packets have been lost. >> We want to avoid that, since it causes latency, and too much latency = is >> very bad for the user experience. >=20 > If you want a circuit-breaker to control latency, why aren't you = measuring > latency? You mean, like CoDel? --Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV3HAgUayAOS/EQ8MAQISZA/+M9q0QehOZKM/YkHA3KqcEtDDEXf9IHyI L0qYVOk9f66FFlexKUMiQG5CXmMeLl5kERjSXDPdy3aUyjlNMEUMpn0/tHIwoUfW 6EI3RiypqxBdFDETYeYB0oOFs1j2UBxNpScWv3LhZH1JgWUsbudMaqCXYn4Yu0eK u7Rj0V9AwOCfTma3rjnSIb3lYmrvFmmsBHII+mZdmZ9+J4iWQVjelNYGXjb+Y23b F2sIofnvhIhZvlXF9YxTb1G0wktUjB9geifxW736Tp4dOl6Rt9uIe9wSWIwNk/QM eh3HwCqaE9VA2eZptyAZ47StPBu1FL0SgYEuJreHDF9JEEQnzH3hPc8LphwVyraT LokquZNze3pcsptIlp6OG1YeUPREdOIKgws3UHqc/mJwNg8iT9uqCgYdvu2eRQXO m/AUkKIgaYJ0KusKz8RJS08HaqpJFj340cINDkZ8nPYGZUGJUBPisncKADGYNsoU /m8QTTJOnnzUzRjdzfbamaCijE3f2Ua6uMXL6nSiXINA88uN41Ejllr3qVURARjF 16Fj3tpRB6J7pj1DJs6Is0/ajbm0JdaN2meeE+NsyUjIt2SbOV4nY4FB1lGoHXBL nui7Ckq04kHL7JLgN4m/CuJbkEyI6nyzCKiCL6Ye4RXI8mhXvfkndYFgjIqHmxBQ eNyzmCfEnI8= =uKDi -----END PGP SIGNATURE----- --Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68-- From nobody Mon Jun 27 18:04:41 2016 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 0464412D7D1; Mon, 27 Jun 2016 18:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 oRgaliwB9gGn; Mon, 27 Jun 2016 18:04:33 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132B112D0AD; Mon, 27 Jun 2016 18:04:32 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5S14Rtp022619 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jun 2016 21:04:27 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5S14Rtp022619 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467075868; bh=GP3mzO+j5XxOL31gZdB8kCQpKfo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EBNvq5m4lBjav/2/ABb1U1Mph3UR414wbwYGs9xoKYIdKz2N7hKMy5qX1t9B48tF/ XPMC8IyBaxDLYr8t3uO2nSoWtvkRO+pxxFdnliV9Gx25TBruawmEWsxncOHZp9/8EZ xAdHsnDr+zW0N+vv7PJNFFM2FamUjtaHf6sPqXsE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5S14Rtp022619 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 27 Jun 2016 21:03:52 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5S14C9f018610 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 27 Jun 2016 21:04:13 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Mon, 27 Jun 2016 21:04:12 -0400 From: "Black, David" To: Michael Welzl , Colin Perkins Thread-Topic: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0L+ZFj+KetGouEG7mSRAG7kvVJ/+KEcA///WaKA= Date: Tue, 28 Jun 2016 01:04:11 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 01:04:35 -0000 VHJ5aW5nIHRvIHNob3J0ZW4gdXAgdGhpcyB0aHJlYWQgYWdhaW4gLi4uDQoNCj4gPj4+IEknbSBu b3QgcXVpdGUgc3VyZSBob3cgdG8gc3BlY2lmeSAidXNlIG9mIEVDTiBhcyBhZGRpdGlvbmFsIGV2 aWRlbmNlIiBvZg0KPiA+Pj4gImV4Y2Vzc2l2ZSBjb25nZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxl bmNlIGlzIGFib3V0IHRoZSBiZXN0IHdlIGhhdmUNCj4gPj4+IGZvciBjdXJyZW50IGd1aWRhbmNl Lg0KPiA+Pg0KPiA+PiBJIGZhaWwgdG8gcGFyc2UgdGhhdCBzZW50ZW5jZSwgc28gbWF5YmUgSeKA mW0gZ2V0dGluZyB5b3Ugd3JvbmcsIGJ1dCBhbnl3YXkgSQ0KPiA+PiB3b25kZXI6IHdoYXTigJlz IGV2ZW4gdGhlIHBvaW50IG9mIHRoaXM/DQo+ID4+IFdoeSBldmVuIGJvdGhlciBjb25zaWRlcmlu ZyBDRS1tYXJrcyBhcyBpbmZvcm1hdGlvbiBmb3IgYSBjaXJjdWl0IGJyZWFrZXI/DQo+ID4NCj4g PiBCZWNhdXNlIHRoZSBhbHRlcm5hdGl2ZSBpcyB0aGF0IHdlIG9ubHkgYnJlYWsgdGhlIGNpcmN1 aXQgb25jZSB0aGUgcXVldWUgaGFzDQo+IGJlZW4gZHJpdmVuIGludG8gb3ZlcmZsb3csIGFuZCBw YWNrZXRzIGhhdmUgYmVlbiBsb3N0LiBXZSB3YW50IHRvIGF2b2lkIHRoYXQsDQo+IHNpbmNlIGl0 IGNhdXNlcyBsYXRlbmN5LCBhbmQgdG9vIG11Y2ggbGF0ZW5jeSBpcyB2ZXJ5IGJhZCBmb3IgdGhl IHVzZXIgZXhwZXJpZW5jZS4NCj4gDQo+IFdlbGwgLSB0aGUgYmV0dGVyIHdheSBvdXQgd291bGQg YmUgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byByZWFjdC4gTWF5YmUgdGhpcyBpcyBtZQ0KPiBtaXN1 bmRlcnN0YW5kaW5nIHRoZSBjaXJjdWl0IGJyZWFrZXIsIGJ1dCBJIGRpZCB0aGluayBpdOKAmXMg bW9yZSBsaWtlIGEgbGFzdCByZXNvcnTigKYNCj4geW91IGp1c3QgZG9u4oCZdCB3YW50IHRvIGJl IHRyaWdnZXItaGFwcHkgd2l0aCBzdWNoIGEgdGhpbmc/DQoNCldlbGwsIHRoZSBSVFAgY2lyY3Vp dCBicmVha2VyIGRyYWZ0IGlzIG5vdCB0cmlnZ2VyIGhhcHB5IC0gZm9yIGl0cyBjb25nZXN0aW9u IGNpcmN1aXQNCmJyZWFrZXIgdG8gdHJpcCwgUlRQIGhhcyB0byBiZSBzZW5kaW5nIGF0IDEweCB0 aGUgcmF0ZSB0aGF0IFRDUCB3b3VsZCBzZW5kIHVuZGVyDQp0aG9zZSBjb25kaXRpb25zLCBiYXNl ZCBvbiB0aGUgVENQIHRocm91Z2hwdXQgZXF1YXRpb24uICBTZWU6DQoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYj c2VjdGlvbi00LjMNCg0KVGhlIGlzc3VlIGhlcmUgaXMgLSB3aGVuIGNhbGN1bGF0aW5nIHRoZSBj b21wYXJhYmxlIFRDUCB0aHJvdWdocHV0LCBob3cgYXJlIEVDTi1DRQ0KbWFya3MgdXNlZCB0byBk ZXRlcm1pbmUgdGhlIGxvc3MgcmF0ZSBpbnB1dCB0byB0aGUgVENQIHRocm91Z2hwdXQgZXF1YXRp b24/ICBEbw0KRUNOLUNFIG1hcmtlZCBwYWNrZXRzIGNvdW50IGFzIGhhdmluZyBhcnJpdmVkIG9y IGhhdmluZyBiZWVuIGRyb3BwZWQ/DQoNCldoZW4gdGhpbmdzIGFyZSByZWxhdGl2ZWx5IHN0YWJs ZSBhbmQgdGhlIEVDTi1DRSBtYXJrcyBhcmUgYmVpbmcgdXNlZCB0byBudWRnZQ0KdGhlIHNlbmRl cidzIHJhdGUgYmFzZWQgb24gd2hhdCB0aGUgbmV0d29yayBjYW4gYWJzb3JiLCB3aGV0aGVyIEVD Ti1DRSBtYXJrcw0KY291bnQgYXMgbG9zc2VzIG9yIG5vdCBpcyBwcm9iYWJseSBpbW1hdGVyaWFs IC0gdGhlIDEweCBkaXZlcmdlbmNlIGZyb20gdGhlIFRDUA0KdGhyb3VnaHB1dCBlcXVhdGlvbidz IHJhdGUgaXMgbm90IGdvaW5nIHRvIGFyaXNlLCBhbmQgdGhlIGNpcmN1aXQgYnJlYWtlciB3b24n dCB0cmlwLg0KVGhlIGNpcmN1aXQgYnJlYWtlciBpcyBvbmx5IHN1cHBvc2VkIHRvIHRyaXAgd2hl biB0aGluZ3MgYXJlIHNlcmlvdXNseSB3cm9uZy4NCg0KKDEpIElmIHRoZSBSVFAgY29uZ2VzdGlv biBjaXJjdWl0IGJyZWFrZXIgdHJpcHMgYmFzZWQgb24gRUNOLUNFIG1hcmtzIGFsb25lLA0Kc29t ZXRoaW5nIGZlZWxzIGludHVpdGl2ZWx5IHdyb25nIC0gaG93J2Qgd2UgZ2V0IHRvIFJUUCBydW5u aW5nIGF0IDEweCB0aGUNCmNvbXBhcmFibGUgVENQIHNlbmRpbmcgcmF0ZSB3aXRoIG5vIGxvc3Nl cz8gIFBlcmhhcHMgdGhlIGNpcmN1aXQgYnJlYWtlcg0Kc2hvdWxkbid0IHRyaXAgb24gRUNOLUNF IG1hcmtzIGFsb25lPw0KDQooMikgQXQgdGhlIG90aGVyIGV4dHJlbWUsIHRoZSBjb25nZXN0aW9u IGNpcmN1aXQgYnJlYWtlciBjbGVhcmx5IGhhcyB0byB0cmlwIGlmIFJUUA0KZ2V0cyB0byAxMHgg dGhlIGNvbXBhcmFibGUgVENQIHNlbmRpbmcgcmF0ZSBiYXNlZCBvbiBsb3NzZXMgYWxvbmUuICBU aGlzIGlzIHRoZQ0KYmFzZWxpbmUgZm9yIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG8gcHJvdmlkZSBu ZXR3b3JrIHByb3RlY3Rpb24gYXMgaW50ZW5kZWQuDQoNClNvLCBnb2luZyBiYWNrIHRvIEdvcnJ5 J3Mgc3VnZ2VzdGlvbiB0byB1c2UgRUNOLUNFIG1hcmtzIGFzICJhZGRpdGlvbmFsIGV2aWRlbmNl LCINCmhlcmUncyBhIHN0cmF3IHByb3Bvc2FsIHRvIHNob290IGF0IC4uLiBmYWN0b3IgaW4gRUNO LUNFIG1hcmtzIGFzIGFkZGl0aW9uYWwgbG9zc2VzDQoqb25seSB3aGVuKiBsb3NzZXMgYXJlIGFs cmVhZHkgb2NjdXJyaW5nLiAgIA0KDQpGb3IgZXhhbXBsZSwgd2UgY291bGQgc3BlY2lmeSB0aGF0 IGZvciB0aGUgUlRQIGNvbmdlc3Rpb24gY2lyY3VpdCBicmVha2VyIHRvIHRyaXAsIHRoZQ0KUlRQ IHNlbmRpbmcgcmF0ZSBoYXMgdG8gYmU6DQoJLSAxMHggdGhlIGVxdWl2YWxlbnQgVENQIHNlbmRp bmcgcmF0ZSBiYXNlZCBvbiBjb3VudGluZyBFQ04tQ0UgbWFya2VkDQoJCXBhY2tldHMgYXMgbG9z dDsgQU5EDQoJLSAzeCB0aGUgZXF1aXZhbGVudCBzZW5kaW5nIHJhdGUgYmFzZWQgb24gYWN0dWFs IGRyb3BzIChpLmUuLCBjb3VudGluZw0KCQlFQ04tQ0UgbWFya2VkIHBhY2tldHMgYXMgZGVsaXZl cmVkKS4NClRoZSAiM3giIGFib3ZlIGlzIGFuIG9mZi10aGUtdG9wLW9mLW15LWhlYWQgZmFjdG9y IHRoYXQgYXR0ZW1wdHMgdG8gcm91Z2hseQ0KZXF1YWxseSB3ZWlnaHQgdGhlIGlucHV0cyAoMyBp cyBjbG9zZSB0byB0aGUgc3F1YXJlIHJvb3Qgb2YgMTApIC0gcGljayBhIGRpZmZlcmVudA0KbnVt YmVyIGlmIHRoYXQgd2VpZ2h0aW5nIGZlZWxzIHdyb25nLg0KDQpUaGlzIHdvdWxkIGZvcmNlIGRy b3BzIHRvIG9jY3VyIGFuZCB0aGVuIGNvbnNpZGVyIEVDTi1DRSBtYXJrcyBhcyBhZGRpdGlvbmFs IGV2aWRlbmNlDQp0aGF0IHNvbWV0aGluZyBpcyB3cm9uZyBpbiB0aGUgbmV0d29yay4NCg0KQW5v dGhlciBwb3NzaWJsZSByYXRpb25hbGUgZm9yIHRoaXMgbWl4aW5nIGlzIHRoYXQgaWYgZHJvcHMg c3RhcnQgb2NjdXJyaW5nLCB0aGVuIG1hbnkgb2YNCnRoZSBuZXcgYW5kIHByb3Bvc2VkIHVzZXMg b2YgRUNOIHRoYXQgdHJlYXQgRUNOLUNFIG1hcmtzIGFzIGxlc3MgdGhhbiBsb3NzLWVxdWl2YWxl bnQNCmFyZSBvdXRzaWRlIHRoZWlyIGludGVuZGVkIG9wZXJhdGluZyBlbnZlbG9wZXMvcmVnaW9u cy4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCg== From nobody Mon Jun 27 23:36:50 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2312DAE7; Mon, 27 Jun 2016 23:36:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628063643.5399.17978.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2016 23:36:43 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 06:36: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 of the IETF. Title : Guidelines for DiffServ to IEEE 802.11 Mapping Authors : Tim Szigeti Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-00.txt Pages : 27 Date : 2016-06-27 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This is due to the fact that two independent standards bodies provide QoS guidance on wired and wireless networks: specifically, the IETF specifies standards and design recommendations for wired IP networks, while a separate and autonomous standards- body, the IEEE, administers the standards for wireless 802.11 networks. The purpose of this document is to propose a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by these two standards bodies, and, as such, to optimize wired-and-wireless interconnect QoS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-00 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 Jun 28 07:47:21 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 519FC12D09D; Tue, 28 Jun 2016 07:47:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628144716.24115.72086.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 07:47:16 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-15.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 14:47:16 -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 of the IETF. Title : UDP Usage Guidelines Authors : Lars Eggert Godred Fairhurst Greg Shepherd Filename : draft-ietf-tsvwg-rfc5405bis-15.txt Pages : 58 Date : 2016-06-28 Abstract: The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ECN, DSCPs, and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC5405 and adds guidelines for multicast UDP usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc5405bis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 28 08:01:55 2016 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 F3D9312D158 for ; Tue, 28 Jun 2016 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 Y7VY6xGUaGxz for ; Tue, 28 Jun 2016 08:01:52 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A1012D0C5 for ; Tue, 28 Jun 2016 08:01:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,541,1459839600"; d="asc'?scan'208";a="125652782" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx144-out.netapp.com with ESMTP; 28 Jun 2016 08:01:10 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 28 Jun 2016 08:01:06 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Tue, 28 Jun 2016 08:01:05 -0700 From: "Eggert, Lars" To: tsvwg WG Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-15.txt Thread-Index: AQHR0UwcrHk2sb218kGwMo3SfcuBWZ//bosA Date: Tue, 28 Jun 2016 15:01:05 +0000 Message-ID: <4986A8CB-6648-4D93-A26D-1C1D3C623AF6@netapp.com> References: <20160628144716.24115.72086.idtracker@ietfa.amsl.com> In-Reply-To: <20160628144716.24115.72086.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_08288F61-E7B7-4B36-93AD-4A3A12CB28C6"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-15.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 15:01:54 -0000 --Apple-Mail=_08288F61-E7B7-4B36-93AD-4A3A12CB28C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This should address all comments raised during IETF LC, apart from = Mark's unhappiness about the current RTT/RTO text (although I did = attempt to at least correct the use of the terms). On 2016-06-28, at 16:47, internet-drafts@ietf.org wrote: >=20 >=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 of the = IETF. >=20 > Title : UDP Usage Guidelines > Authors : Lars Eggert > Godred Fairhurst > Greg Shepherd > Filename : draft-ietf-tsvwg-rfc5405bis-15.txt > Pages : 58 > Date : 2016-06-28 >=20 > Abstract: > The User Datagram Protocol (UDP) provides a minimal message-passing > transport that has no inherent congestion control mechanisms. This > document provides guidelines on the use of UDP for the designers of > applications, tunnels and other protocols that use UDP. Congestion > control guidelines are a primary focus, but the document also > provides guidance on other topics, including message sizes, > reliability, checksums, middlebox traversal, the use of ECN, DSCPs, > and ports. >=20 > Because congestion control is critical to the stable operation of = the > Internet, applications and other protocols that choose to use UDP as > an Internet transport must employ mechanisms to prevent congestion > collapse and to establish some degree of fairness with concurrent > traffic. They may also need to implement additional mechanisms, > depending on how they use UDP. >=20 > Some guidance is also applicable to the design of other protocols > (e.g., protocols layered directly on IP or via IP-based tunnels), > especially when these protocols do not themselves provide congestion > control. >=20 > This document obsoletes RFC5405 and adds guidelines for multicast = UDP > usage. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rfc5405bis-15 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_08288F61-E7B7-4B36-93AD-4A3A12CB28C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXcpEzAAoJEFS1wwm/cMFXxAsP/3pkgxqm/2sZFkyeWCVASAPy ahGJcmvRFugRNf8h09fvHq3YEdSSrHmQTuHCxQNGw0oAvCc52I9udqTW7bIVGSO1 fPkM2S7GiWp6jIAQ4POf3Z6hgspvJXjKnog6Leueq5G0/XoLPzCWkNbbbSRgTH97 olOfI6uGnpnnm/fJdwQXjqlERMaFTDMHhmH4d0lMUYjHoJw/bng1Xa2xAWAB2qBE Gmd7we/xtQzlNlv+6JhA0WIRiIy9/ekYTY95ee7XpRRxS7rqkI8oJ0a2VB3jKbhB z9HOxMgHlvpFKfmqvSdb3VUCstMzMPoia8s88k0prDiJvLZ7bo3jmPhFzBIhhF+7 jlh4tCo5PUGRsY/5vFe6PucmNlDwvx1qMaxJO7oKBjNST1fRDEE08+GPkC1bDvfO K38Ygg5XAGljjSpCRxaGE249j74x82bE4QlYVM9cS2RtwyS/TJ4Kxp7WW6nGTZTe acw7oJWAm4vtnBEhXV1R+8jCXbiRlEMrH5ClSecn+QDnPi4YzlG5DnM4EtIMhEF+ NutZdTeA6KKYe4JmES9sJ8UXWNliS6PdiXGLVIBgyFFFcZYPZP+xR+kYHooWDONg YEnpNvbYDwPrl4PtysPlRTEL94jtXX5JNMU6NAE6IWDqFtglrOrZqss2Qacy8jIA iy/iUQ55lDrlxza/9Ssb =LSXB -----END PGP SIGNATURE----- --Apple-Mail=_08288F61-E7B7-4B36-93AD-4A3A12CB28C6-- From nobody Tue Jun 28 08:08:39 2016 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 AE72E12D151; Tue, 28 Jun 2016 08:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 g8gmMdaUluMG; Tue, 28 Jun 2016 08:08:27 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677B412D50B; Tue, 28 Jun 2016 08:08:24 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5SF8JZF009583 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jun 2016 11:08:21 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u5SF8JZF009583 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467126501; bh=l+7x+4ULacQpO2VkLB/UBtZR0gA=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=v43tGZTZ3Qro5crqVyA6XOMZeUYwUxGbYUNhH9SG8b56XjgUwgxVXPoObU3LcAUXP 3A/8Wj5j0kSrSCvdvQyUdAQo3OrAN97YSLLD5ctS04Zw4VcM0tGjxwXVQNyvdYfb8G 7kb4A2ECcsFDOcdxyOzG1kX/0xEbHzxVS3Vrh5h8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u5SF8JZF009583 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 28 Jun 2016 11:07:43 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5SF84ZL006224 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 28 Jun 2016 11:08:04 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0266.001; Tue, 28 Jun 2016 11:08:03 -0400 From: "Black, David" To: Tom Herbert , "adrian@olddog.co.uk" Thread-Topic: RTG Dir QA review of draft-ietf-nvo3-gue - TSVWG coordination Thread-Index: AdHRTt1+Xq96SrglR3WchHXlsv1krA== Date: Tue, 28 Jun 2016 15:08:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtg-dir@ietf.org" , "nvo3@ietf.org" , "draft-ietf-nvo3-gue.all@ietf.org" , "int-area@ietf.org" , "tsvwg@ietf.org" Subject: [tsvwg] RTG Dir QA review of draft-ietf-nvo3-gue - TSVWG coordination X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 15:08:30 -0000 [+tsvwg - this draft is undergoing a WG adoption call to move it from nvo3 = to intarea] Commenting on just the TSVWG coordination concerns, as a TSVWG co-chair. Legend: > > Adrian Farrel (RTG Dir reviewer) > Tom Herbert (GUE draft author) David Black (TSVWG co-chair) > > It seems to me that there is some careful coordination needed with othe= r > > work on encapsulation of transport or network protocols in UDP. This > > idea clearly has value in NVO3, but I should have thought it sat better > > in the TSVWG. I hope the NVO3 chairs have discussed this with the TSVWG > > chairs to ensure that there is no friction. This is particularly > > important because it will be important to recognise that only one of > > this draft and draft-manner-tsvwg-gut is likely to make it to RFC. > > > Much of the content around TSV issues (e.g. zero UDP6 checksum and > congestion control) is based on that in MPLS/UDP and GRE/UDP. And those are the two most relevant documents to work from. GRE/UDP needs a little more tweaking before RFC publication is requested. Specifically, = I need to supply some improved congestion control text to the authors - doing that is= on my "round tuit" list. =20 > > You seem to have correctly addressed the three issues that have most > > worried the TSVWG (checksum, congestion and security), so that is all > > good, but I would recommend getting the TSVWG involved for a full and > > detailed review now and for each future revision of the document. In > > fact, I would have tended towards making this a TSVWG document, but so > > long as the chairs, the ADs, and the WGs are happy, that should be fine= . > > > > --- > > > > Overall, this work is a good idea and needed. When we did MPLS-in-UDP > > there was a background proposal to generalise and only burn one port > > number for al UDP encapsulations. This achieves that end. > > > > However, I think this proposal may be too general and too extensible. > > Future-proof is good, but there seem to be a lot of bells and whistles > > defined here that have no specific use proposed, and no indication that > > a future use might ever be defined. I think it is one thing that it > > should be possible to extend a protocol, and another that it defines > > multiple fields and extension mechanisms that might never be used. > > > Yes, two of the authors on this draft are also authors for GRE/UDP. > GRE/UDP has received excellent review in TSVWG and we would like to > have similar review of GUE. That will definitely happen ;-). My preference is for encapsulation heade= r design to be done in WGs that work on encapsulations - TSVWG is not such a WG, but is more than happy to advise on Transport concerns, such as those identified above. Thanks, --David From nobody Tue Jun 28 09:10:08 2016 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 3CA7712D5AE for ; Tue, 28 Jun 2016 09:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 B_CnE9-OkQvX for ; Tue, 28 Jun 2016 09:10:02 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28B712D14F for ; Tue, 28 Jun 2016 09:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3809; q=dns/txt; s=iport; t=1467130201; x=1468339801; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2cpDqqHhq7Kr93cmSDU1iCGZnDEvgKZyOI1DyA5mYYQ=; b=KLioKnWWYG3eZJZenWc34it6DedyFfHnwc5QSGNW48ogDgsshmZLGFA9 RML/EmvRH0eI2HlR4dcCGERLR05lClZqYzdF4gWIFn1YbiMJIyTfZWv8m iWkMqqKRbcZLaERL8GyMUxxHN2gwt3EMmJnOzD0ygzuxX74TfmIwYrWOV M=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgD8n3JX/4gNJK1bgz5WfQa6LIF7F?= =?us-ascii?q?waFewKBMDgUAQEBAQEBAWUnhEwBAQEDAQEBAWsQCwIBCBguJwslAgQTCQWIGgg?= =?us-ascii?q?Ow2IBAQEBAQEBAQEBAQEBAQEBAQEBAQEODogfCIJOhHKCeoIvBZkCAYMtgWxui?= =?us-ascii?q?DKBaU6EBohniCaHWAEeNoNwbgEBAQGILX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,541,1459814400"; d="asc'?scan'208";a="290936569" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 16:10:00 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5SGA0gO029352 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 16:10:00 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 11:10:00 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Tue, 28 Jun 2016 11:10:00 -0500 From: "Fred Baker (fred)" To: tsvwg Thread-Topic: I-D Action: draft-ietf-tsvwg-ieee-802-11-00.txt Thread-Index: AQHR0VeFm1K2vLwyg06DbamI22t+lg== Date: Tue, 28 Jun 2016 16:09:59 +0000 Message-ID: <65EFFF9E-1053-4E87-BF0E-9F1C20C95FA9@cisco.com> References: <20160628063643.5399.17978.idtracker@ietfa.amsl.com> In-Reply-To: <20160628063643.5399.17978.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_DD16152D-5987-4B7F-95CD-3506942CA276"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 16:10:06 -0000 --Apple-Mail=_DD16152D-5987-4B7F-95CD-3506942CA276 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For the record, a diff against draft-szigeti-* may be found at = https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-szi= geti-tsvwg-ieee-802-11-02.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-= tsvwg-ieee-802-11-00.txt > On Jun 27, 2016, at 11:36 PM, internet-drafts@ietf.org wrote: >=20 >=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 of the = IETF. >=20 > Title : Guidelines for DiffServ to IEEE 802.11 = Mapping > Authors : Tim Szigeti > Fred Baker > Filename : draft-ietf-tsvwg-ieee-802-11-00.txt > Pages : 27 > Date : 2016-06-27 >=20 > Abstract: > As internet traffic is increasingly sourced-from and destined-to > wireless endpoints, it is crucial that Quality of Service be aligned > between wired and wireless networks; however, this is not always the > case by default. This is due to the fact that two independent > standards bodies provide QoS guidance on wired and wireless = networks: > specifically, the IETF specifies standards and design = recommendations > for wired IP networks, while a separate and autonomous standards- > body, the IEEE, administers the standards for wireless 802.11 > networks. The purpose of this document is to propose a set > Differentiated Services Code Point (DSCP) to IEEE 802.11 User > Priority (UP) mappings to reconcile the marking recommendations > offered by these two standards bodies, and, as such, to optimize > wired-and-wireless interconnect QoS. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-00 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_DD16152D-5987-4B7F-95CD-3506942CA276 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV3KhV0ayAOS/EQ8MAQLvHA/9FxT99TpIkM+IgkNHq6d9ZVpbux+I2Qbb BVohUMyoSsj+XfN31atfiILdpupLponGJhS8TKxyltJm4YfKO0nUd3f3sNep9zzU 4cgTFAjd1Tjv0pn/t2t57iV6iICzDgKzM8iRGZwD2beYZmkQNL2BsLrFz64QM/tS 3slyi8DeHhPyFMxk0Z+FzGrJdkOvLSfpnXmSNN5gnRefBZ+jS/zTF2ZyL/UOf82F xbMclOGy0dwLNrsRW4vkAcE5m6KepugGge9aciOm0F67v0DYoiW1xBuzonliCD2j PQjM3eD8Ylx0Runv69ZBwb50SE6QvvP4y95Jwhu6VF2UXpGiMh6mb3dgw4Sg4VGg 7t6O1NHT00OlF5BqMetVChUILwTxglp7TIT5M12Umly4gEl6uQP+E1JbvSwHuNr2 epkO1hV9biUUmf7HTAlvAnf5KTH480J4WoEdLqwVvkElM/OJ9E9FbWVp8jIHa4Tu 8yFl6CaFAjV+XZZ/PX0ENZ+kAkkziT2sVW6X8LtqH2ciLaHQjfsEsO4mY+MgihAZ Dw801+z2/HqOhW68hW2/nX4/DAiRHlkIANLK0i+IYjzA1g76bi0kt9xlZoOdTKOJ TTqr9twzp3GNHBV9T/sJMXE6pXhbo04JT29zsCwhKSj357cTgGXprUpq0cthwO+2 hHsRDZLyPI8= =oR/8 -----END PGP SIGNATURE----- --Apple-Mail=_DD16152D-5987-4B7F-95CD-3506942CA276-- From nobody Tue Jun 28 14:48:40 2016 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 BF8E712D537; Tue, 28 Jun 2016 14:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 rR5EcQJGV8RU; Tue, 28 Jun 2016 14:48:28 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B9412D1D2; Tue, 28 Jun 2016 14:48:28 -0700 (PDT) Received: from [81.187.2.149] (port=37071 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bI0ro-0005cG-G5; Tue, 28 Jun 2016 22:48:25 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <20160628000400.GA1223@verdi> Date: Tue, 28 Jun 2016 22:48:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <20160628000400.GA1223@verdi> To: John Leslie X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , Michael Welzl , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 21:48:31 -0000 > On 28 Jun 2016, at 01:04, John Leslie wrote: > Colin Perkins wrote: >> On 27 Jun 2016, at 21:52, Michael Welzl wrote: >>=20 >>> Why even bother considering CE-marks as information for a circuit = breaker? >>=20 >> Because the alternative is that we only break the circuit once the = queue >> has been driven into overflow, and packets have been lost. >> We want to avoid that, since it causes latency, and too much latency = is >> very bad for the user experience.=20 >=20 > If you want a circuit-breaker to control latency, why aren't you = measuring > latency? Because the RTP circuit breaker needs to work with unmodified RFC = 3550-style RTCP, which doesn=E2=80=99t return RTT samples sufficiently = often to allow that, and because we don=E2=80=99t care about the precise = latency, we just don=E2=80=99t want to fill a large queue. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 28 15:03:07 2016 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 D25D012D83A; Tue, 28 Jun 2016 15:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 BoulhWdapYVq; Tue, 28 Jun 2016 15:02:59 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3863E12D790; Tue, 28 Jun 2016 15:02:58 -0700 (PDT) Received: from [81.187.2.149] (port=47431 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bI15q-0007Ir-IC; Tue, 28 Jun 2016 23:02:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 28 Jun 2016 23:02:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , Michael Welzl , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:03:03 -0000 > On 28 Jun 2016, at 02:04, Black, David wrote: >=20 > Trying to shorten up this thread again ... >=20 >>>>> I'm not quite sure how to specify "use of ECN as additional = evidence" of >>>>> "excessive congestion" as drop-equivalence is about the best we = have >>>>> for current guidance. >>>>=20 >>>> I fail to parse that sentence, so maybe I=E2=80=99m getting you = wrong, but anyway I >>>> wonder: what=E2=80=99s even the point of this? >>>> Why even bother considering CE-marks as information for a circuit = breaker? >>>=20 >>> Because the alternative is that we only break the circuit once the = queue has >> been driven into overflow, and packets have been lost. We want to = avoid that, >> since it causes latency, and too much latency is very bad for the = user experience. >>=20 >> Well - the better way out would be for the application to react. = Maybe this is me >> misunderstanding the circuit breaker, but I did think it=E2=80=99s = more like a last resort=E2=80=A6 >> you just don=E2=80=99t want to be trigger-happy with such a thing? >=20 > Well, the RTP circuit breaker draft is not trigger happy - for its = congestion circuit > breaker to trip, RTP has to be sending at 10x the rate that TCP would = send under > those conditions, based on the TCP throughput equation. See: >=20 > = https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16#sec= tion-4.3 >=20 > The issue here is - when calculating the comparable TCP throughput, = how are ECN-CE > marks used to determine the loss rate input to the TCP throughput = equation? Do > ECN-CE marked packets count as having arrived or having been dropped? Right - or do they count somewhere between the two. > When things are relatively stable and the ECN-CE marks are being used = to nudge > the sender's rate based on what the network can absorb, whether ECN-CE = marks > count as losses or not is probably immaterial - the 10x divergence = from the TCP > throughput equation's rate is not going to arise, and the circuit = breaker won't trip. > The circuit breaker is only supposed to trip when things are seriously = wrong. Correct. > (1) If the RTP congestion circuit breaker trips based on ECN-CE marks = alone, > something feels intuitively wrong - how'd we get to RTP running at 10x = the > comparable TCP sending rate with no losses? Perhaps the circuit = breaker > shouldn=E2=80=99t trip on ECN-CE marks alone? Shouldn=E2=80=99t the comparable rate to trigger the circuit breaker be = 10x that given to a TCP flow subject to the same ECN-CE marking rate? If = the TCP treats ECN-CE as equivalent to loss, for congestion response, = then the circuit breaker should do so to, etc. > (2) At the other extreme, the congestion circuit breaker clearly has = to trip if RTP > gets to 10x the comparable TCP sending rate based on losses alone. = This is the > baseline for the circuit breaker to provide network protection as = intended. >=20 > So, going back to Gorry's suggestion to use ECN-CE marks as = "additional evidence," > here's a straw proposal to shoot at ... factor in ECN-CE marks as = additional losses > *only when* losses are already occurring. =20 >=20 > For example, we could specify that for the RTP congestion circuit = breaker to trip, the > RTP sending rate has to be: > - 10x the equivalent TCP sending rate based on counting ECN-CE = marked > packets as lost; AND > - 3x the equivalent sending rate based on actual drops (i.e., = counting > ECN-CE marked packets as delivered). > The "3x" above is an off-the-top-of-my-head factor that attempts to = roughly > equally weight the inputs (3 is close to the square root of 10) - pick = a different > number if that weighting feels wrong. >=20 > This would force drops to occur and then consider ECN-CE marks as = additional evidence > that something is wrong in the network. >=20 > Another possible rationale for this mixing is that if drops start = occurring, then many of > the new and proposed uses of ECN that treat ECN-CE marks as less than = loss-equivalent > are outside their intended operating envelopes/regions. Clearly if the queue has been driven to overflow, so that packet loss is = occurring, then the AQM is outside its intended operating regime. I=E2=80=99= m not sure we need to push it so far, though. Is there not a regime = where the ECN-CE marking rate indicates excessive congestion, before the = queue overflows and drops packets?=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 28 15:08:41 2016 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 C1D9C12D8DC for ; Tue, 28 Jun 2016 15:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 qPFO6ufRfjm0 for ; Tue, 28 Jun 2016 15:08:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0078A12D537 for ; Tue, 28 Jun 2016 15:08:37 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5SM8SwZ009551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jun 2016 15:08:28 -0700 (PDT) References: <20160628220253.5953.16529.idtracker@ietfa.amsl.com> To: tsvwg From: Joe Touch X-Forwarded-Message-Id: <20160628220253.5953.16529.idtracker@ietfa.amsl.com> Message-ID: <5772F55A.2080604@isi.edu> Date: Tue, 28 Jun 2016 15:08:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160628220253.5953.16529.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080003010304090102020904" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:08:40 -0000 This is a multi-part message in MIME format. --------------080003010304090102020904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, See below. Updated to correct/clarify text, legacy issues, etc. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-03.txt Date: Tue, 28 Jun 2016 15:02:53 -0700 From: internet-drafts@ietf.org To: Joe Touch , Dr. Joseph D. Touch A new version of I-D, draft-touch-tsvwg-udp-options-03.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 03 Title: Transport Options for UDP Document date: 2016-06-28 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-03.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-03 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------080003010304090102020904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all,

See below.

Updated to correct/clarify text, legacy issues, etc.

Joe


-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-03.txt
Date: Tue, 28 Jun 2016 15:02:53 -0700
From: internet-drafts@ietf.org
To: Joe Touch <touch@isi.edu>, Dr. Joseph D. Touch <touch@isi.edu> 


A new version of I-D, draft-touch-tsvwg-udp-options-03.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	03
Title:		Transport Options for UDP
Document date:	2016-06-28
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-03.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-03

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP to provide a
   location, syntax, and semantics for transport layer options.

                                                                                  


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

The IETF Secretariat


--------------080003010304090102020904-- From nobody Tue Jun 28 23:50:23 2016 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 F27C612D7F0; Tue, 28 Jun 2016 23:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 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, RP_MATCHES_RCVD=-1.426] 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 cDc-Wk1J3f79; Tue, 28 Jun 2016 23:50:14 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C999212B009; Tue, 28 Jun 2016 23:50:11 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 29 Jun 2016 08:50:09 +0200 X-IronPort-AV: E=Sophos;i="5.26,545,1459807200"; d="scan'208";a="909211051" Received: from he101654.emea1.cds.t-internal.com ([10.134.226.15]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 08:50:08 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101654.emea1.cds.t-internal.com (10.134.226.15) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 29 Jun 2016 08:50:16 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Wed, 29 Jun 2016 08:50:08 +0200 From: To: , Thread-Topic: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0YjOJ/Ww8HzxYEqxGgZcc0m8Op//+RNA Date: Wed, 29 Jun 2016 06:50:08 +0000 Message-ID: <577acdb4599440439f92480c9875fba6@HE101653.emea1.cds.t-internal.com> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> In-Reply-To: <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.170.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: rtcweb@ietf.org, tsvwg@ietf.org, avt@ietf.org Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 06:50:17 -0000 Q29saW4sIERhdmlkLA0KDQpJIGRvbid0IGludGVuZCB0byBiZSBkaXN0dXJiaW5nLiBJcyB0aGVy ZSBhIHN0YW5kYXJkcyB0cmFjayBSRkMgaW5kaWNhdGluZyBob3cgYSByb3V0ZXIgc2hvdWxkIGJl IGNvbmZpZ3VyZWQgdG8gc3VwcG9ydCBFQ04gbWFya2luZyBzbyB0aGF0IHRoZXJlIGlzIGEgbmV0 d29yayBiZWhhdmlvciBieSB3aGljaCBhbiBlbmQgc3lzdGVtIGlzIGFibGUgdG8gcmVsYXRlIEVD TiBtYXJraW5nIHJhdGVzIHVuYW1iaWd1b3VzbHkgdG8gZHJvcCByYXRlcyBpbiB0aGUgbmV0d29y ayAoYXNzdW1pbmcgYm90aCB0byBiZSBjYXVzZWQgYnkgdGhlIHNhbWUgYm90dGxlbmVjayk/DQoN CkkgZG9uJ3QgbmVlZCBhbiBSRkMgbnVtYmVyLCAieWVzIiBvciAibm8iIHdpbGwgZG8uIFRoZSBS RkMgc2hvdWxkIGJlIGNsZWFyIGVub3VnaCB0byBhbGxvdyBhbnkgdGVybWluYWwgdG8gaW50ZXJw cmV0IHRoZSBFQ04gc2lnbmFscyBjb3JyZWN0bHksIG5vIG1hdHRlciB0byB3aGljaCBFQ04gc3Vw cG9ydGluZyBuZXR3b3JrIGl0IGNvbm5lY3RzLiANCg0KUmVnYXJkcywNCg0KUnVlZGlnZXINCg0K DQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IHRzdndnIFttYWlsdG86 dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQ29saW4gUGVya2lucw0KR2Vz ZW5kZXQ6IE1pdHR3b2NoLCAyOS4gSnVuaSAyMDE2IDAwOjAzDQpBbjogQmxhY2ssIERhdmlkDQpD YzogcnRjd2ViQGlldGYub3JnOyB0c3Z3ZzsgTWljaGFlbCBXZWx6bDsgSUVURiBBVlRDb3JlIFdH DQpCZXRyZWZmOiBSZTogW3RzdndnXSBbQVZUQ09SRV0gW3J0Y3dlYl0gV0cgTGFzdCBDYWxsIG9u IGNoYW5nZXM6IGRyYWZ0LWlldGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KDQoN Cj4gT24gMjggSnVuIDIwMTYsIGF0IDAyOjA0LCBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVt Yy5jb20+IHdyb3RlOg0KPiANCj4gVHJ5aW5nIHRvIHNob3J0ZW4gdXAgdGhpcyB0aHJlYWQgYWdh aW4gLi4uDQo+IA0KPj4+Pj4gSSdtIG5vdCBxdWl0ZSBzdXJlIGhvdyB0byBzcGVjaWZ5ICJ1c2Ug b2YgRUNOIGFzIGFkZGl0aW9uYWwgDQo+Pj4+PiBldmlkZW5jZSIgb2YgImV4Y2Vzc2l2ZSBjb25n ZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxlbmNlIGlzIGFib3V0IA0KPj4+Pj4gdGhlIGJlc3Qgd2Ug aGF2ZSBmb3IgY3VycmVudCBndWlkYW5jZS4NCj4+Pj4gDQo+Pj4+IEkgZmFpbCB0byBwYXJzZSB0 aGF0IHNlbnRlbmNlLCBzbyBtYXliZSBJ4oCZbSBnZXR0aW5nIHlvdSB3cm9uZywgYnV0IA0KPj4+ PiBhbnl3YXkgSQ0KPj4+PiB3b25kZXI6IHdoYXTigJlzIGV2ZW4gdGhlIHBvaW50IG9mIHRoaXM/ DQo+Pj4+IFdoeSBldmVuIGJvdGhlciBjb25zaWRlcmluZyBDRS1tYXJrcyBhcyBpbmZvcm1hdGlv biBmb3IgYSBjaXJjdWl0IGJyZWFrZXI/DQo+Pj4gDQo+Pj4gQmVjYXVzZSB0aGUgYWx0ZXJuYXRp dmUgaXMgdGhhdCB3ZSBvbmx5IGJyZWFrIHRoZSBjaXJjdWl0IG9uY2UgdGhlIA0KPj4+IHF1ZXVl IGhhcw0KPj4gYmVlbiBkcml2ZW4gaW50byBvdmVyZmxvdywgYW5kIHBhY2tldHMgaGF2ZSBiZWVu IGxvc3QuIFdlIHdhbnQgdG8gDQo+PiBhdm9pZCB0aGF0LCBzaW5jZSBpdCBjYXVzZXMgbGF0ZW5j eSwgYW5kIHRvbyBtdWNoIGxhdGVuY3kgaXMgdmVyeSBiYWQgZm9yIHRoZSB1c2VyIGV4cGVyaWVu Y2UuDQo+PiANCj4+IFdlbGwgLSB0aGUgYmV0dGVyIHdheSBvdXQgd291bGQgYmUgZm9yIHRoZSBh cHBsaWNhdGlvbiB0byByZWFjdC4gDQo+PiBNYXliZSB0aGlzIGlzIG1lIG1pc3VuZGVyc3RhbmRp bmcgdGhlIGNpcmN1aXQgYnJlYWtlciwgYnV0IEkgZGlkIA0KPj4gdGhpbmsgaXTigJlzIG1vcmUg bGlrZSBhIGxhc3QgcmVzb3J04oCmIHlvdSBqdXN0IGRvbuKAmXQgd2FudCB0byBiZSB0cmlnZ2Vy LWhhcHB5IHdpdGggc3VjaCBhIHRoaW5nPw0KPiANCj4gV2VsbCwgdGhlIFJUUCBjaXJjdWl0IGJy ZWFrZXIgZHJhZnQgaXMgbm90IHRyaWdnZXIgaGFwcHkgLSBmb3IgaXRzIA0KPiBjb25nZXN0aW9u IGNpcmN1aXQgYnJlYWtlciB0byB0cmlwLCBSVFAgaGFzIHRvIGJlIHNlbmRpbmcgYXQgMTB4IHRo ZSANCj4gcmF0ZSB0aGF0IFRDUCB3b3VsZCBzZW5kIHVuZGVyIHRob3NlIGNvbmRpdGlvbnMsIGJh c2VkIG9uIHRoZSBUQ1AgdGhyb3VnaHB1dCBlcXVhdGlvbi4gIFNlZToNCj4gDQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtl cnMtMTYNCj4gI3NlY3Rpb24tNC4zDQo+IA0KPiBUaGUgaXNzdWUgaGVyZSBpcyAtIHdoZW4gY2Fs Y3VsYXRpbmcgdGhlIGNvbXBhcmFibGUgVENQIHRocm91Z2hwdXQsIA0KPiBob3cgYXJlIEVDTi1D RSBtYXJrcyB1c2VkIHRvIGRldGVybWluZSB0aGUgbG9zcyByYXRlIGlucHV0IHRvIHRoZSBUQ1Ag DQo+IHRocm91Z2hwdXQgZXF1YXRpb24/ICBEbyBFQ04tQ0UgbWFya2VkIHBhY2tldHMgY291bnQg YXMgaGF2aW5nIGFycml2ZWQgb3IgaGF2aW5nIGJlZW4gZHJvcHBlZD8NCg0KUmlnaHQgLSBvciBk byB0aGV5IGNvdW50IHNvbWV3aGVyZSBiZXR3ZWVuIHRoZSB0d28uDQoNCj4gV2hlbiB0aGluZ3Mg YXJlIHJlbGF0aXZlbHkgc3RhYmxlIGFuZCB0aGUgRUNOLUNFIG1hcmtzIGFyZSBiZWluZyB1c2Vk IA0KPiB0byBudWRnZSB0aGUgc2VuZGVyJ3MgcmF0ZSBiYXNlZCBvbiB3aGF0IHRoZSBuZXR3b3Jr IGNhbiBhYnNvcmIsIA0KPiB3aGV0aGVyIEVDTi1DRSBtYXJrcyBjb3VudCBhcyBsb3NzZXMgb3Ig bm90IGlzIHByb2JhYmx5IGltbWF0ZXJpYWwgLSANCj4gdGhlIDEweCBkaXZlcmdlbmNlIGZyb20g dGhlIFRDUCB0aHJvdWdocHV0IGVxdWF0aW9uJ3MgcmF0ZSBpcyBub3QgZ29pbmcgdG8gYXJpc2Us IGFuZCB0aGUgY2lyY3VpdCBicmVha2VyIHdvbid0IHRyaXAuDQo+IFRoZSBjaXJjdWl0IGJyZWFr ZXIgaXMgb25seSBzdXBwb3NlZCB0byB0cmlwIHdoZW4gdGhpbmdzIGFyZSBzZXJpb3VzbHkgd3Jv bmcuDQoNCkNvcnJlY3QuDQoNCj4gKDEpIElmIHRoZSBSVFAgY29uZ2VzdGlvbiBjaXJjdWl0IGJy ZWFrZXIgdHJpcHMgYmFzZWQgb24gRUNOLUNFIG1hcmtzIA0KPiBhbG9uZSwgc29tZXRoaW5nIGZl ZWxzIGludHVpdGl2ZWx5IHdyb25nIC0gaG93J2Qgd2UgZ2V0IHRvIFJUUCBydW5uaW5nIA0KPiBh dCAxMHggdGhlIGNvbXBhcmFibGUgVENQIHNlbmRpbmcgcmF0ZSB3aXRoIG5vIGxvc3Nlcz8gIFBl cmhhcHMgdGhlIA0KPiBjaXJjdWl0IGJyZWFrZXIgc2hvdWxkbuKAmXQgdHJpcCBvbiBFQ04tQ0Ug bWFya3MgYWxvbmU/DQoNClNob3VsZG7igJl0IHRoZSBjb21wYXJhYmxlIHJhdGUgdG8gdHJpZ2dl ciB0aGUgY2lyY3VpdCBicmVha2VyIGJlIDEweCB0aGF0IGdpdmVuIHRvIGEgVENQIGZsb3cgc3Vi amVjdCB0byB0aGUgc2FtZSBFQ04tQ0UgbWFya2luZyByYXRlPyBJZiB0aGUgVENQIHRyZWF0cyBF Q04tQ0UgYXMgZXF1aXZhbGVudCB0byBsb3NzLCBmb3IgY29uZ2VzdGlvbiByZXNwb25zZSwgdGhl biB0aGUgY2lyY3VpdCBicmVha2VyIHNob3VsZCBkbyBzbyB0bywgZXRjLg0KDQo+ICgyKSBBdCB0 aGUgb3RoZXIgZXh0cmVtZSwgdGhlIGNvbmdlc3Rpb24gY2lyY3VpdCBicmVha2VyIGNsZWFybHkg aGFzIA0KPiB0byB0cmlwIGlmIFJUUCBnZXRzIHRvIDEweCB0aGUgY29tcGFyYWJsZSBUQ1Agc2Vu ZGluZyByYXRlIGJhc2VkIG9uIA0KPiBsb3NzZXMgYWxvbmUuICBUaGlzIGlzIHRoZSBiYXNlbGlu ZSBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciB0byBwcm92aWRlIG5ldHdvcmsgcHJvdGVjdGlvbiBh cyBpbnRlbmRlZC4NCj4gDQo+IFNvLCBnb2luZyBiYWNrIHRvIEdvcnJ5J3Mgc3VnZ2VzdGlvbiB0 byB1c2UgRUNOLUNFIG1hcmtzIGFzICJhZGRpdGlvbmFsIGV2aWRlbmNlLCINCj4gaGVyZSdzIGEg c3RyYXcgcHJvcG9zYWwgdG8gc2hvb3QgYXQgLi4uIGZhY3RvciBpbiBFQ04tQ0UgbWFya3MgYXMg YWRkaXRpb25hbCBsb3NzZXMNCj4gKm9ubHkgd2hlbiogbG9zc2VzIGFyZSBhbHJlYWR5IG9jY3Vy cmluZy4gICANCj4gDQo+IEZvciBleGFtcGxlLCB3ZSBjb3VsZCBzcGVjaWZ5IHRoYXQgZm9yIHRo ZSBSVFAgY29uZ2VzdGlvbiBjaXJjdWl0IA0KPiBicmVha2VyIHRvIHRyaXAsIHRoZSBSVFAgc2Vu ZGluZyByYXRlIGhhcyB0byBiZToNCj4gCS0gMTB4IHRoZSBlcXVpdmFsZW50IFRDUCBzZW5kaW5n IHJhdGUgYmFzZWQgb24gY291bnRpbmcgRUNOLUNFIG1hcmtlZA0KPiAJCXBhY2tldHMgYXMgbG9z dDsgQU5EDQo+IAktIDN4IHRoZSBlcXVpdmFsZW50IHNlbmRpbmcgcmF0ZSBiYXNlZCBvbiBhY3R1 YWwgZHJvcHMgKGkuZS4sIGNvdW50aW5nDQo+IAkJRUNOLUNFIG1hcmtlZCBwYWNrZXRzIGFzIGRl bGl2ZXJlZCkuDQo+IFRoZSAiM3giIGFib3ZlIGlzIGFuIG9mZi10aGUtdG9wLW9mLW15LWhlYWQg ZmFjdG9yIHRoYXQgYXR0ZW1wdHMgdG8gDQo+IHJvdWdobHkgZXF1YWxseSB3ZWlnaHQgdGhlIGlu cHV0cyAoMyBpcyBjbG9zZSB0byB0aGUgc3F1YXJlIHJvb3Qgb2YgDQo+IDEwKSAtIHBpY2sgYSBk aWZmZXJlbnQgbnVtYmVyIGlmIHRoYXQgd2VpZ2h0aW5nIGZlZWxzIHdyb25nLg0KPiANCj4gVGhp cyB3b3VsZCBmb3JjZSBkcm9wcyB0byBvY2N1ciBhbmQgdGhlbiBjb25zaWRlciBFQ04tQ0UgbWFy a3MgYXMgDQo+IGFkZGl0aW9uYWwgZXZpZGVuY2UgdGhhdCBzb21ldGhpbmcgaXMgd3JvbmcgaW4g dGhlIG5ldHdvcmsuDQo+IA0KPiBBbm90aGVyIHBvc3NpYmxlIHJhdGlvbmFsZSBmb3IgdGhpcyBt aXhpbmcgaXMgdGhhdCBpZiBkcm9wcyBzdGFydCANCj4gb2NjdXJyaW5nLCB0aGVuIG1hbnkgb2Yg dGhlIG5ldyBhbmQgcHJvcG9zZWQgdXNlcyBvZiBFQ04gdGhhdCB0cmVhdCANCj4gRUNOLUNFIG1h cmtzIGFzIGxlc3MgdGhhbiBsb3NzLWVxdWl2YWxlbnQgYXJlIG91dHNpZGUgdGhlaXIgaW50ZW5k ZWQgb3BlcmF0aW5nIGVudmVsb3Blcy9yZWdpb25zLg0KDQpDbGVhcmx5IGlmIHRoZSBxdWV1ZSBo YXMgYmVlbiBkcml2ZW4gdG8gb3ZlcmZsb3csIHNvIHRoYXQgcGFja2V0IGxvc3MgaXMgb2NjdXJy aW5nLCB0aGVuIHRoZSBBUU0gaXMgb3V0c2lkZSBpdHMgaW50ZW5kZWQgb3BlcmF0aW5nIHJlZ2lt ZS4gSeKAmW0gbm90IHN1cmUgd2UgbmVlZCB0byBwdXNoIGl0IHNvIGZhciwgdGhvdWdoLiBJcyB0 aGVyZSBub3QgYSByZWdpbWUgd2hlcmUgdGhlIEVDTi1DRSBtYXJraW5nIHJhdGUgaW5kaWNhdGVz IGV4Y2Vzc2l2ZSBjb25nZXN0aW9uLCBiZWZvcmUgdGhlIHF1ZXVlIG92ZXJmbG93cyBhbmQgZHJv cHMgcGFja2V0cz8gDQoNCi0tDQpDb2xpbiBQZXJraW5zDQpodHRwczovL2NzcGVya2lucy5vcmcv DQoNCg0KDQoNCg== From nobody Wed Jun 29 01:54:54 2016 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 BDDDF12D178; Wed, 29 Jun 2016 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 fggf8ucP1sw6; Wed, 29 Jun 2016 01:54:40 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A0512DA5B; Wed, 29 Jun 2016 01:54:40 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bIBGV-0005qd-UY; Wed, 29 Jun 2016 10:54:35 +0200 Received: from 1x-193-157-240-251.uio.no ([193.157.240.251]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bIBGV-0007N9-7B; Wed, 29 Jun 2016 10:54:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> Date: Wed, 29 Jun 2016 10:54:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 11 sum msgs/h 5 total rcpts 43797 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 987467064C5EE9518D5076116F92D0BC8280545D X-UiO-SPAM-Test: remote_host: 193.157.240.251 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 117 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 08:54:44 -0000 > On 29. jun. 2016, at 00.02, Colin Perkins wrote: >=20 >=20 >> On 28 Jun 2016, at 02:04, Black, David wrote: >>=20 >> Trying to shorten up this thread again ... >>=20 >>>>>> I'm not quite sure how to specify "use of ECN as additional = evidence" of >>>>>> "excessive congestion" as drop-equivalence is about the best we = have >>>>>> for current guidance. >>>>>=20 >>>>> I fail to parse that sentence, so maybe I=E2=80=99m getting you = wrong, but anyway I >>>>> wonder: what=E2=80=99s even the point of this? >>>>> Why even bother considering CE-marks as information for a circuit = breaker? >>>>=20 >>>> Because the alternative is that we only break the circuit once the = queue has >>> been driven into overflow, and packets have been lost. We want to = avoid that, >>> since it causes latency, and too much latency is very bad for the = user experience. >>>=20 >>> Well - the better way out would be for the application to react. = Maybe this is me >>> misunderstanding the circuit breaker, but I did think it=E2=80=99s = more like a last resort=E2=80=A6 >>> you just don=E2=80=99t want to be trigger-happy with such a thing? >>=20 >> Well, the RTP circuit breaker draft is not trigger happy - for its = congestion circuit >> breaker to trip, RTP has to be sending at 10x the rate that TCP would = send under >> those conditions, based on the TCP throughput equation. See: >>=20 >> = https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16#sec= tion-4.3 >>=20 >> The issue here is - when calculating the comparable TCP throughput, = how are ECN-CE >> marks used to determine the loss rate input to the TCP throughput = equation? Do >> ECN-CE marked packets count as having arrived or having been dropped? >=20 > Right - or do they count somewhere between the two. Let=E2=80=99s see them clearly for what they are. They mean: the path is *not* broken (they have arrived!), and a probably = an AQM mechanism, potentially using a shallow queue, marked them to = indicate congestion. I think =E2=80=9Csomewhere between the two=E2=80=9D = really doesn=E2=80=99t capture this well. >> When things are relatively stable and the ECN-CE marks are being used = to nudge >> the sender's rate based on what the network can absorb, whether = ECN-CE marks >> count as losses or not is probably immaterial - the 10x divergence = from the TCP >> throughput equation's rate is not going to arise, and the circuit = breaker won't trip. >> The circuit breaker is only supposed to trip when things are = seriously wrong. >=20 > Correct. >=20 >> (1) If the RTP congestion circuit breaker trips based on ECN-CE marks = alone, >> something feels intuitively wrong - how'd we get to RTP running at = 10x the >> comparable TCP sending rate with no losses? Perhaps the circuit = breaker >> shouldn=E2=80=99t trip on ECN-CE marks alone? >=20 > Shouldn=E2=80=99t the comparable rate to trigger the circuit breaker = be 10x that given to a TCP flow subject to the same ECN-CE marking rate? = If the TCP treats ECN-CE as equivalent to loss, for congestion response, = then the circuit breaker should do so to, etc. First, TCP shouldn=E2=80=99t (treat ECN-CE as equivalent to loss), and = so the circuit breaker shouldn=E2=80=99t. Second, I guess you=E2=80=99re talking about the equation. Well that = goes completely wrong anyway (the derivation assumes packets to be lost, = not marked; then again, you=E2=80=99re using loss, not the loss event = ratio; then again, you=E2=80=99re close to this with ECN perhaps, using = =E2=80=9Ctraditional=E2=80=9D ECN receiver behavior). >> (2) At the other extreme, the congestion circuit breaker clearly has = to trip if RTP >> gets to 10x the comparable TCP sending rate based on losses alone. = This is the >> baseline for the circuit breaker to provide network protection as = intended. >>=20 >> So, going back to Gorry's suggestion to use ECN-CE marks as = "additional evidence," >> here's a straw proposal to shoot at ... factor in ECN-CE marks as = additional losses >> *only when* losses are already occurring. =20 I think this is very reasonable. >> For example, we could specify that for the RTP congestion circuit = breaker to trip, the >> RTP sending rate has to be: >> - 10x the equivalent TCP sending rate based on counting ECN-CE = marked >> packets as lost; AND >> - 3x the equivalent sending rate based on actual drops (i.e., = counting >> ECN-CE marked packets as delivered). >> The "3x" above is an off-the-top-of-my-head factor that attempts to = roughly >> equally weight the inputs (3 is close to the square root of 10) - = pick a different >> number if that weighting feels wrong. >>=20 >> This would force drops to occur and then consider ECN-CE marks as = additional evidence >> that something is wrong in the network. >>=20 >> Another possible rationale for this mixing is that if drops start = occurring, then many of >> the new and proposed uses of ECN that treat ECN-CE marks as less than = loss-equivalent >> are outside their intended operating envelopes/regions. >=20 > Clearly if the queue has been driven to overflow, so that packet loss = is occurring, then the AQM is outside its intended operating regime. = I=E2=80=99m not sure we need to push it so far, though. Is there not a = regime where the ECN-CE marking rate indicates excessive congestion, = before the queue overflows and drops packets?=20 Shouldn=E2=80=99t a congestion control mechanism react well before that? Cheers, Michael From nobody Wed Jun 29 07:02:21 2016 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 30B9812DEB7 for ; Wed, 29 Jun 2016 07:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 CY9bykSNiT21 for ; Wed, 29 Jun 2016 07:02:06 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF49012DEB2 for ; Wed, 29 Jun 2016 07:01:53 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5TE1oIU008088 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jun 2016 10:01:51 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5TE1oIU008088 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467208911; bh=opdtTGOtb4eq6ScPi9X4wOmIeHk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hsZb45xT1vJONxsTnPHx748G/gzPumD+4qtYUki6VoBwwYUuoRphXjNX5K/D/KCYm VSVfPwsbjH2boat/8wHhLRk25E4SNpKMJd/Zl/KXklqiP165KdLUQQ4Jfa0GB76Sq+ Vyd4XgFc+S6TQoFhJA4ORMFt7y39zEUVUD5RMNhI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5TE1oIU008088 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Wed, 29 Jun 2016 10:01:21 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5TE1eKC004233 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 29 Jun 2016 10:01:41 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Wed, 29 Jun 2016 10:01:40 -0400 From: "Black, David" To: "Black, David" , Martin Stiemerling , "tsvwg@ietf.org" Thread-Topic: RFC 5405bis draft - non-congestion-controlled IP traffic Thread-Index: AdHSDr4yaUy437LrT6qIFydk7GP8rA== Date: Wed, 29 Jun 2016 14:01:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] RFC 5405bis draft - non-congestion-controlled IP traffic X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:02:18 -0000 QSB3aGlsZSBiYWNrLCBpbiByZXNwb25zZSB0byBNYXJ0aW4gU3RpZW1lcmxpbmcncyBjb21tZW50 cyBvbiB0aGUgR1JFL1VEUCBkcmFmdCwNCkkgd3JvdGU6DQoNCj4gWzJdIElQIHRyYWZmaWMgY29u Z2VzdGlvbiBjb250cm9sIGFzc3VtcHRpb25zLg0KPiANCj4gPiAtIEkgZG8gZGlzYWdyZWUgd2l0 aCAiSVAtdHJhZmZpYyBjYW4gYmUgYXNzdW1lZCB0byBiZQ0KPiA+IGNvbmdlc3Rpb24tY29udHJv bGxlZC4iLCBldmVuIHRob3VnaCBpdCBpcyBzdGF0ZWQgaW4gUkZDIDU0MDUsIGFzIHRoZXJlDQo+ ID4gaXMgYSBsb3Qgb2YgSVAgdHJhZmZpYyB0aGF0IGlzIG5vdCBjb25nZXN0aW9uIGNvbnRyb2xs ZWQsIHN1Y2ggYXMNCj4gPiBtdWx0aWNhc3QgdHJhZmZpYy4uLg0KPiA+IFNlY3Rpb24gNCwgZXZl biBzdGF0ZXMgdGhhdCBtdWx0aWNhc3QgYW5kIGJyb2FkY2FzdCB0cmFmZmljIGNhbiBiZQ0KPiA+ IGNhcnJpZWQgb3ZlciBHUkUtVURQISBOb25lIG9mIGJvdGggaXMgaW4gZ2VuZXJhbCBjb25nZXN0 aW9uIGNvbnRyb2xsZWQhDQo+IA0KPiBXZWxsLCB0aGlzIGlzIGFjdHVhbGx5IGFuIGlzc3VlIHdp dGggdGhlIHJmYzU0MDViaXMgZHJhZnQsIGFuZCB0aGlzIGlzc3VlIG5lZWRzDQo+IHRvIGJlIGZp eGVkIHRoZXJlLCBhcyBSRkMgNTQwNSBpcyAoYW5kIHRoZSByZmM1NDA1YmlzIGRyYWZ0IHdpbGwg YmUpIHRoZQ0KPiBUcmFuc3BvcnQgQXJlYSdzIHN0YXRlbWVudCB0byB0aGUgcmVzdCBvZiB0aGUg SUVURiBvbiBjb25nZXN0aW9uIGNvbnRyb2wNCj4gZ3VpZGVsaW5lcyBhbmQgcmVxdWlyZW1lbnRz IGZvciBVRFAgdXNhZ2UuDQoNClRoaXMgaXMgaW5kZWVkIGFuIGlzc3VlIHdpdGggdGhlIDU0MDVi aXMgZHJhZnQuICBJbiBwYXJ0aWN1bGFyLCBNYXJ0aW4gaGFzDQplZmZlY3RpdmVseSBwb2ludGVk IG91dCB0aGF0IHRoaXMgdGV4dCBpbiBTZWN0aW9uIDMuMS4xMSBpcyB3cm9uZyBiZWNhdXNlDQpp dCBlbmNvbXBhc3NlcyBtdWx0aWNhc3QgYW5kIGJyb2FkY2FzdCB0cmFmZmljOg0KDQogICBJUC1i YXNlZCB0cmFmZmljIGlzIGdlbmVyYWxseSBhc3N1bWVkIHRvIGJlIGNvbmdlc3Rpb24tY29udHJv bGxlZCwNCiAgIGkuZS4sIGl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgdHJhbnNwb3J0IHByb3RvY29s cyBnZW5lcmF0aW5nIElQLWJhc2VkDQogICB0cmFmZmljIGF0IHRoZSBzZW5kZXIgYWxyZWFkeSBl bXBsb3kgbWVjaGFuaXNtcyB0aGF0IGFyZSBzdWZmaWNpZW50DQogICB0byBhZGRyZXNzIGNvbmdl c3Rpb24gb24gdGhlIHBhdGguICBDb25zZXF1ZW50bHksIGEgdHVubmVsIGNhcnJ5aW5nDQogICBJ UC1iYXNlZCB0cmFmZmljIHNob3VsZCBhbHJlYWR5IGludGVyYWN0IGFwcHJvcHJpYXRlbHkgd2l0 aCBvdGhlcg0KICAgdHJhZmZpYyBzaGFyaW5nIHRoZSBwYXRoLCBhbmQgc3BlY2lmaWMgY29uZ2Vz dGlvbiBjb250cm9sIG1lY2hhbmlzbXMNCiAgIGZvciB0aGUgdHVubmVsIGFyZSBub3QgbmVjZXNz YXJ5Lg0KDQpDaGFuZ2luZyAiSVAtYmFzZWQgdHJhZmZpYyIgdG8gIklQLWJhc2VkIHVuaWNhc3Qg dHJhZmZpYyIgaW4gdGhyZWUgcGxhY2VzDQppbiB0aGUgYWJvdmUgcGFyYWdyYXBoIHNob3VsZCBj b3JyZWN0IHRoaXMgcHJvYmxlbS4NCg0KSW4gYWRkaXRpb24sIG11bHRpY2FzdCBuZWVkcyB0byBi ZSBjYWxsZWQgb3V0IGFzIGFuIGV4Y2VwdGlvbiBpbiB0aGUgbmV4dA0KcGFyYWdyYXBoOg0KDQpP TEQNCiAgIEhvd2V2ZXIsIGlmIHRoZSBJUCB0cmFmZmljIGluIHRoZSB0dW5uZWwgaXMga25vd24g dG8gbm90IGJlDQogICBjb25nZXN0aW9uLWNvbnRyb2xsZWQsIGFkZGl0aW9uYWwgbWVhc3VyZXMg YXJlIFJFQ09NTUVOREVEIHRvIGxpbWl0DQogICB0aGUgaW1wYWN0IG9mIHRoZSB0dW5uZWxlZCB0 cmFmZmljIG9uIG90aGVyIHRyYWZmaWMgc2hhcmluZyB0aGUgcGF0aC4NCg0KICAgVGhlIGZvbGxv d2luZyBndWlkZWxpbmVzIGRlZmluZSB0aGVzZSBwb3NzaWJsZSBjYXNlcyBpbiBtb3JlIGRldGFp bDoNCk5FVw0KICAgSG93ZXZlciwgaWYgdGhlIElQIHRyYWZmaWMgaW4gdGhlIHR1bm5lbCBpcyBr bm93biB0byBub3QgYmUNCiAgIGNvbmdlc3Rpb24tY29udHJvbGxlZCwgYWRkaXRpb25hbCBtZWFz dXJlcyBhcmUgUkVDT01NRU5ERUQgdG8gbGltaXQNCiAgIHRoZSBpbXBhY3Qgb2YgdGhlIHR1bm5l bGVkIHRyYWZmaWMgb24gb3RoZXIgdHJhZmZpYyBzaGFyaW5nIHRoZSBwYXRoLiAgIEZvcg0KICAg dGhlIHNwZWNpZmljIGNhc2Ugb2YgYSB0dW5uZWwgdGhhdCBjYXJyaWVzIElQIG11bHRpY2FzdCB0 cmFmZmljLCBzZWUgc2VjdGlvbiA0LjEuDQoNCiAgIFRoZSBmb2xsb3dpbmcgZ3VpZGVsaW5lcyBk ZWZpbmUgdGhlc2UgcG9zc2libGUgY2FzZXMgaW4gbW9yZSBkZXRhaWw6DQoNCkFzIGEgV0cgY2hh aXIgYW5kIGRyYWZ0IHNoZXBoZXJkLCBJIHRoaW5rIHRoZXNlIGNoYW5nZXMgYXJlIGltcG9ydGFu dCwNCmFzIHRoZSBvcmlnaW5hbCB0ZXh0IGhhcyBhbHJlYWR5IGJlZW4gbWlzcmVhZC9taXNpbnRl cnByZXRlZCBieSBtb3JlDQp0aGFuIG9uZSBVRFAgdHVubmVsIGRlc2lnbmVyLg0KDQpUaGFua3Ms IC0tRGF2aWQNCg== From nobody Wed Jun 29 07:44:45 2016 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 CD5E612D192; Wed, 29 Jun 2016 07:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 bD8v5AFiMknX; Wed, 29 Jun 2016 07:44:33 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A7E12B069; Wed, 29 Jun 2016 07:44:33 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5TEiPHj006676 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jun 2016 10:44:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5TEiPHj006676 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467211466; bh=kSkJdhAqpefg+rp93A8/ncTCzz8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lSlZ4owL5+qyQq8sxDeCrzLKDDW5LWAVBVwHz0EvgoAEYwgN0/KSmOtrF1IdvjiCR fEgPvt0fR3/LXuKuMnhUufGVsdCV+L9AAytgIU3VW6Qaf87L/BrIiquhXwpUW6q4qB Dl/9KFDlSqsYUXByrLRDAsFobce4cE8ZLY967nns= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5TEiPHj006676 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 29 Jun 2016 10:43:36 -0400 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5TEiAqD019619 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 29 Jun 2016 10:44:11 -0400 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.0266.001; Wed, 29 Jun 2016 10:44:10 -0400 From: "Black, David" To: Michael Welzl , Colin Perkins Thread-Topic: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0L+ZFj+KetGouEG7mSRAG7kvVJ/+KEcA///WaKCAAbR8AIAAthgAgAAb1mA= Date: Wed, 29 Jun 2016 14:44:09 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:44:36 -0000 SSB3cm90ZTogDQoNCj4+IEFub3RoZXIgcG9zc2libGUgcmF0aW9uYWxlIGZvciB0aGlzIG1peGlu ZyBpcyB0aGF0IGlmIGRyb3BzIHN0YXJ0IG9jY3VycmluZywgdGhlbiBtYW55IG9mDQo+PiB0aGUg bmV3IGFuZCBwcm9wb3NlZCB1c2VzIG9mIEVDTiB0aGF0IHRyZWF0IEVDTi1DRSBtYXJrcyBhcyBs ZXNzIHRoYW4gbG9zcy1lcXVpdmFsZW50DQo+PiBhcmUgb3V0c2lkZSB0aGVpciBpbnRlbmRlZCBv cGVyYXRpbmcgZW52ZWxvcGVzL3JlZ2lvbnMuDQoNCkNvbGluIHJlc3BvbmRlZDoNCg0KPiBDbGVh cmx5IGlmIHRoZSBxdWV1ZSBoYXMgYmVlbiBkcml2ZW4gdG8gb3ZlcmZsb3csIHNvIHRoYXQgcGFj a2V0IGxvc3MgaXMNCj4gb2NjdXJyaW5nLCB0aGVuIHRoZSBBUU0gaXMgb3V0c2lkZSBpdHMgaW50 ZW5kZWQgb3BlcmF0aW5nIHJlZ2ltZS4gSeKAmW0gbm90IHN1cmUNCj4gd2UgbmVlZCB0byBwdXNo IGl0IHNvIGZhciwgdGhvdWdoLiBJcyB0aGVyZSBub3QgYSByZWdpbWUgd2hlcmUgdGhlIEVDTi1D RQ0KPiBtYXJraW5nIHJhdGUgaW5kaWNhdGVzIGV4Y2Vzc2l2ZSBjb25nZXN0aW9uLCBiZWZvcmUg dGhlIHF1ZXVlIG92ZXJmbG93cyBhbmQNCj4gZHJvcHMgcGFja2V0cz8NCg0KWWVzLCBidXQgdGhh dCBtYXkgbm90IGJlIHJlbGV2YW50IHRvIHRoaXMgZGlzY3Vzc2lvbi4gICBNeSBoeXBvdGhlc2lz IGZvciB0aGlzIGRpc2N1c3Npb24NCmlzIHRoYXQgYWN0dWFsIGRyb3BzIHdpbGwgb2NjdXIgd2Vs bCBiZWZvcmUgUlRQICBpcyBydW5uaW5nIGF0IDEweCB0aGUgVENQIGVxdWl2YWxlbnQgcmF0ZQ0K KGJhc2VkIG9uIGRyb3BzIGFuZCBFQ04tQ0UgbWFya3MpLCBhbmQgdGhhdCAxMHggZmFjdG9yIGlz IHRoZSB0cmlwIHRocmVzaG9sZCBmb3IgdGhlDQpjaXJjdWl0IGJyZWFrZXIsIHdoaWNoIGlzIHRo ZSBmb2N1cyBvZiB0aGlzIGRpc2N1c3Npb24uIA0KDQpJIHdvdWxkIHRoaW5rIHRoYXQgdGhlICJy ZWdpbWUgd2hlcmUgdGhlIEVDTi1DRSBtYXJraW5nIHJhdGUgaW5kaWNhdGVzIGV4Y2Vzc2l2ZQ0K Y29uZ2VzdGlvbiwgYmVmb3JlIHRoZSBxdWV1ZSBvdmVyZmxvd3MgYW5kIGRyb3BzIHBhY2tldHM/ IiB3b3VsZCBub3QgZXh0ZW5kIGFzDQpmYXIgYXMgUlRQIHJ1bm5pbmcgYXQgMTB4IHRoZSBUQ1Ag ZXF1aXZhbGVudCByYXRlLCB3aGljaCBpcyB3aGVyZSB0aGUgUlRQIGNpcmN1aXQNCmJyZWFrZXIg dHJpcHMuDQoNClRoaXMgaXMgYWxsIGEgdGhvdWdodCBleGVyY2lzZSAtIEknbSBoYXBweSB0byBi ZSBzaG93biB0byBiZSB3cm9uZyBiYXNlZCBvbiBhY3R1YWwNCmRhdGEgYW5kIGV4cGVyaWVuY2Ug d2l0aCAicnVubmluZyBjb2RlIiAuLi4NCg0KVG8gd2hpY2ggTWljaGFlbCByZXNwb25kZWQ6IA0K DQo+IFNob3VsZG7igJl0IGEgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSByZWFjdCB3ZWxs IGJlZm9yZSB0aGF0Pw0KDQpZZXMsIGlmIHRoZXJlIGlzIG9uZSA7LSkuICBUaGlzIGlzIFJUUCAu Li4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogTWljaGFlbCBXZWx6bCBbbWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ub10NCj4gU2VudDog V2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDQ6NTUgQU0NCj4gVG86IENvbGluIFBlcmtpbnMNCj4g Q2M6IEJsYWNrLCBEYXZpZDsgcnRjd2ViQGlldGYub3JnOyB0c3Z3ZzsgSUVURiBBVlRDb3JlIFdH DQo+IFN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gW3J0Y3dlYl0gW3RzdndnXSBXRyBMYXN0IENhbGwg b24gY2hhbmdlczogZHJhZnQtaWV0Zi0NCj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0x Ng0KPiANCj4gDQo+ID4gT24gMjkuIGp1bi4gMjAxNiwgYXQgMDAuMDIsIENvbGluIFBlcmtpbnMg PGNzcEBjc3BlcmtpbnMub3JnPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4+IE9uIDI4IEp1biAyMDE2 LCBhdCAwMjowNCwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPiB3cm90ZToNCj4g Pj4NCj4gPj4gVHJ5aW5nIHRvIHNob3J0ZW4gdXAgdGhpcyB0aHJlYWQgYWdhaW4gLi4uDQo+ID4+ DQo+ID4+Pj4+PiBJJ20gbm90IHF1aXRlIHN1cmUgaG93IHRvIHNwZWNpZnkgInVzZSBvZiBFQ04g YXMgYWRkaXRpb25hbCBldmlkZW5jZSIgb2YNCj4gPj4+Pj4+ICJleGNlc3NpdmUgY29uZ2VzdGlv biIgYXMgZHJvcC1lcXVpdmFsZW5jZSBpcyBhYm91dCB0aGUgYmVzdCB3ZSBoYXZlDQo+ID4+Pj4+ PiBmb3IgY3VycmVudCBndWlkYW5jZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gSSBmYWlsIHRvIHBhcnNl IHRoYXQgc2VudGVuY2UsIHNvIG1heWJlIEnigJltIGdldHRpbmcgeW91IHdyb25nLCBidXQgYW55 d2F5DQo+IEkNCj4gPj4+Pj4gd29uZGVyOiB3aGF04oCZcyBldmVuIHRoZSBwb2ludCBvZiB0aGlz Pw0KPiA+Pj4+PiBXaHkgZXZlbiBib3RoZXIgY29uc2lkZXJpbmcgQ0UtbWFya3MgYXMgaW5mb3Jt YXRpb24gZm9yIGEgY2lyY3VpdA0KPiBicmVha2VyPw0KPiA+Pj4+DQo+ID4+Pj4gQmVjYXVzZSB0 aGUgYWx0ZXJuYXRpdmUgaXMgdGhhdCB3ZSBvbmx5IGJyZWFrIHRoZSBjaXJjdWl0IG9uY2UgdGhl IHF1ZXVlIGhhcw0KPiA+Pj4gYmVlbiBkcml2ZW4gaW50byBvdmVyZmxvdywgYW5kIHBhY2tldHMg aGF2ZSBiZWVuIGxvc3QuIFdlIHdhbnQgdG8gYXZvaWQNCj4gdGhhdCwNCj4gPj4+IHNpbmNlIGl0 IGNhdXNlcyBsYXRlbmN5LCBhbmQgdG9vIG11Y2ggbGF0ZW5jeSBpcyB2ZXJ5IGJhZCBmb3IgdGhl IHVzZXINCj4gZXhwZXJpZW5jZS4NCj4gPj4+DQo+ID4+PiBXZWxsIC0gdGhlIGJldHRlciB3YXkg b3V0IHdvdWxkIGJlIGZvciB0aGUgYXBwbGljYXRpb24gdG8gcmVhY3QuIE1heWJlIHRoaXMgaXMN Cj4gbWUNCj4gPj4+IG1pc3VuZGVyc3RhbmRpbmcgdGhlIGNpcmN1aXQgYnJlYWtlciwgYnV0IEkg ZGlkIHRoaW5rIGl04oCZcyBtb3JlIGxpa2UgYSBsYXN0DQo+IHJlc29ydOKApg0KPiA+Pj4geW91 IGp1c3QgZG9u4oCZdCB3YW50IHRvIGJlIHRyaWdnZXItaGFwcHkgd2l0aCBzdWNoIGEgdGhpbmc/ DQo+ID4+DQo+ID4+IFdlbGwsIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGRyYWZ0IGlzIG5vdCB0 cmlnZ2VyIGhhcHB5IC0gZm9yIGl0cyBjb25nZXN0aW9uDQo+IGNpcmN1aXQNCj4gPj4gYnJlYWtl ciB0byB0cmlwLCBSVFAgaGFzIHRvIGJlIHNlbmRpbmcgYXQgMTB4IHRoZSByYXRlIHRoYXQgVENQ IHdvdWxkIHNlbmQNCj4gdW5kZXINCj4gPj4gdGhvc2UgY29uZGl0aW9ucywgYmFzZWQgb24gdGhl IFRDUCB0aHJvdWdocHV0IGVxdWF0aW9uLiAgU2VlOg0KPiA+Pg0KPiA+PiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2 I3NlY3Rpb24tDQo+IDQuMw0KPiA+Pg0KPiA+PiBUaGUgaXNzdWUgaGVyZSBpcyAtIHdoZW4gY2Fs Y3VsYXRpbmcgdGhlIGNvbXBhcmFibGUgVENQIHRocm91Z2hwdXQsIGhvdyBhcmUNCj4gRUNOLUNF DQo+ID4+IG1hcmtzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBsb3NzIHJhdGUgaW5wdXQgdG8gdGhl IFRDUCB0aHJvdWdocHV0IGVxdWF0aW9uPw0KPiBEbw0KPiA+PiBFQ04tQ0UgbWFya2VkIHBhY2tl dHMgY291bnQgYXMgaGF2aW5nIGFycml2ZWQgb3IgaGF2aW5nIGJlZW4gZHJvcHBlZD8NCj4gPg0K PiA+IFJpZ2h0IC0gb3IgZG8gdGhleSBjb3VudCBzb21ld2hlcmUgYmV0d2VlbiB0aGUgdHdvLg0K PiANCj4gTGV04oCZcyBzZWUgdGhlbSBjbGVhcmx5IGZvciB3aGF0IHRoZXkgYXJlLg0KPiBUaGV5 IG1lYW46IHRoZSBwYXRoIGlzICpub3QqIGJyb2tlbiAodGhleSBoYXZlIGFycml2ZWQhKSwgYW5k IGEgcHJvYmFibHkgYW4NCj4gQVFNIG1lY2hhbmlzbSwgcG90ZW50aWFsbHkgdXNpbmcgYSBzaGFs bG93IHF1ZXVlLCBtYXJrZWQgdGhlbSB0byBpbmRpY2F0ZQ0KPiBjb25nZXN0aW9uLiBJIHRoaW5r IOKAnHNvbWV3aGVyZSBiZXR3ZWVuIHRoZSB0d2/igJ0gcmVhbGx5IGRvZXNu4oCZdCBjYXB0dXJl IHRoaXMNCj4gd2VsbC4NCj4gDQo+IA0KPiA+PiBXaGVuIHRoaW5ncyBhcmUgcmVsYXRpdmVseSBz dGFibGUgYW5kIHRoZSBFQ04tQ0UgbWFya3MgYXJlIGJlaW5nIHVzZWQgdG8NCj4gbnVkZ2UNCj4g Pj4gdGhlIHNlbmRlcidzIHJhdGUgYmFzZWQgb24gd2hhdCB0aGUgbmV0d29yayBjYW4gYWJzb3Ji LCB3aGV0aGVyIEVDTi1DRQ0KPiBtYXJrcw0KPiA+PiBjb3VudCBhcyBsb3NzZXMgb3Igbm90IGlz IHByb2JhYmx5IGltbWF0ZXJpYWwgLSB0aGUgMTB4IGRpdmVyZ2VuY2UgZnJvbSB0aGUNCj4gVENQ DQo+ID4+IHRocm91Z2hwdXQgZXF1YXRpb24ncyByYXRlIGlzIG5vdCBnb2luZyB0byBhcmlzZSwg YW5kIHRoZSBjaXJjdWl0IGJyZWFrZXIgd29uJ3QNCj4gdHJpcC4NCj4gPj4gVGhlIGNpcmN1aXQg YnJlYWtlciBpcyBvbmx5IHN1cHBvc2VkIHRvIHRyaXAgd2hlbiB0aGluZ3MgYXJlIHNlcmlvdXNs eSB3cm9uZy4NCj4gPg0KPiA+IENvcnJlY3QuDQo+ID4NCj4gPj4gKDEpIElmIHRoZSBSVFAgY29u Z2VzdGlvbiBjaXJjdWl0IGJyZWFrZXIgdHJpcHMgYmFzZWQgb24gRUNOLUNFIG1hcmtzIGFsb25l LA0KPiA+PiBzb21ldGhpbmcgZmVlbHMgaW50dWl0aXZlbHkgd3JvbmcgLSBob3cnZCB3ZSBnZXQg dG8gUlRQIHJ1bm5pbmcgYXQgMTB4IHRoZQ0KPiA+PiBjb21wYXJhYmxlIFRDUCBzZW5kaW5nIHJh dGUgd2l0aCBubyBsb3NzZXM/ICBQZXJoYXBzIHRoZSBjaXJjdWl0IGJyZWFrZXINCj4gPj4gc2hv dWxkbuKAmXQgdHJpcCBvbiBFQ04tQ0UgbWFya3MgYWxvbmU/DQo+ID4NCj4gPiBTaG91bGRu4oCZ dCB0aGUgY29tcGFyYWJsZSByYXRlIHRvIHRyaWdnZXIgdGhlIGNpcmN1aXQgYnJlYWtlciBiZSAx MHggdGhhdCBnaXZlbiB0bw0KPiBhIFRDUCBmbG93IHN1YmplY3QgdG8gdGhlIHNhbWUgRUNOLUNF IG1hcmtpbmcgcmF0ZT8gSWYgdGhlIFRDUCB0cmVhdHMgRUNOLUNFIGFzDQo+IGVxdWl2YWxlbnQg dG8gbG9zcywgZm9yIGNvbmdlc3Rpb24gcmVzcG9uc2UsIHRoZW4gdGhlIGNpcmN1aXQgYnJlYWtl ciBzaG91bGQgZG8gc28NCj4gdG8sIGV0Yy4NCj4gDQo+IEZpcnN0LCBUQ1Agc2hvdWxkbuKAmXQg KHRyZWF0IEVDTi1DRSBhcyBlcXVpdmFsZW50IHRvIGxvc3MpLCBhbmQgc28gdGhlIGNpcmN1aXQg YnJlYWtlcg0KPiBzaG91bGRu4oCZdC4NCj4gU2Vjb25kLCBJIGd1ZXNzIHlvdeKAmXJlIHRhbGtp bmcgYWJvdXQgdGhlIGVxdWF0aW9uLiBXZWxsIHRoYXQgZ29lcyBjb21wbGV0ZWx5DQo+IHdyb25n IGFueXdheSAodGhlIGRlcml2YXRpb24gYXNzdW1lcyBwYWNrZXRzIHRvIGJlIGxvc3QsIG5vdCBt YXJrZWQ7IHRoZW4NCj4gYWdhaW4sIHlvdeKAmXJlIHVzaW5nIGxvc3MsIG5vdCB0aGUgbG9zcyBl dmVudCByYXRpbzsgdGhlbiBhZ2FpbiwgeW914oCZcmUgY2xvc2UgdG8gdGhpcw0KPiB3aXRoIEVD TiBwZXJoYXBzLCB1c2luZyDigJx0cmFkaXRpb25hbOKAnSBFQ04gcmVjZWl2ZXIgYmVoYXZpb3Ip Lg0KPiANCj4gDQo+ID4+ICgyKSBBdCB0aGUgb3RoZXIgZXh0cmVtZSwgdGhlIGNvbmdlc3Rpb24g Y2lyY3VpdCBicmVha2VyIGNsZWFybHkgaGFzIHRvIHRyaXAgaWYNCj4gUlRQDQo+ID4+IGdldHMg dG8gMTB4IHRoZSBjb21wYXJhYmxlIFRDUCBzZW5kaW5nIHJhdGUgYmFzZWQgb24gbG9zc2VzIGFs b25lLiAgVGhpcyBpcyB0aGUNCj4gPj4gYmFzZWxpbmUgZm9yIHRoZSBjaXJjdWl0IGJyZWFrZXIg dG8gcHJvdmlkZSBuZXR3b3JrIHByb3RlY3Rpb24gYXMgaW50ZW5kZWQuDQo+ID4+DQo+ID4+IFNv LCBnb2luZyBiYWNrIHRvIEdvcnJ5J3Mgc3VnZ2VzdGlvbiB0byB1c2UgRUNOLUNFIG1hcmtzIGFz ICJhZGRpdGlvbmFsDQo+IGV2aWRlbmNlLCINCj4gPj4gaGVyZSdzIGEgc3RyYXcgcHJvcG9zYWwg dG8gc2hvb3QgYXQgLi4uIGZhY3RvciBpbiBFQ04tQ0UgbWFya3MgYXMgYWRkaXRpb25hbA0KPiBs b3NzZXMNCj4gPj4gKm9ubHkgd2hlbiogbG9zc2VzIGFyZSBhbHJlYWR5IG9jY3VycmluZy4NCj4g DQo+IEkgdGhpbmsgdGhpcyBpcyB2ZXJ5IHJlYXNvbmFibGUuDQo+IA0KPiANCj4gPj4gRm9yIGV4 YW1wbGUsIHdlIGNvdWxkIHNwZWNpZnkgdGhhdCBmb3IgdGhlIFJUUCBjb25nZXN0aW9uIGNpcmN1 aXQgYnJlYWtlciB0bw0KPiB0cmlwLCB0aGUNCj4gPj4gUlRQIHNlbmRpbmcgcmF0ZSBoYXMgdG8g YmU6DQo+ID4+IAktIDEweCB0aGUgZXF1aXZhbGVudCBUQ1Agc2VuZGluZyByYXRlIGJhc2VkIG9u IGNvdW50aW5nIEVDTi1DRSBtYXJrZWQNCj4gPj4gCQlwYWNrZXRzIGFzIGxvc3Q7IEFORA0KPiA+ PiAJLSAzeCB0aGUgZXF1aXZhbGVudCBzZW5kaW5nIHJhdGUgYmFzZWQgb24gYWN0dWFsIGRyb3Bz IChpLmUuLCBjb3VudGluZw0KPiA+PiAJCUVDTi1DRSBtYXJrZWQgcGFja2V0cyBhcyBkZWxpdmVy ZWQpLg0KPiA+PiBUaGUgIjN4IiBhYm92ZSBpcyBhbiBvZmYtdGhlLXRvcC1vZi1teS1oZWFkIGZh Y3RvciB0aGF0IGF0dGVtcHRzIHRvIHJvdWdobHkNCj4gPj4gZXF1YWxseSB3ZWlnaHQgdGhlIGlu cHV0cyAoMyBpcyBjbG9zZSB0byB0aGUgc3F1YXJlIHJvb3Qgb2YgMTApIC0gcGljayBhIGRpZmZl cmVudA0KPiA+PiBudW1iZXIgaWYgdGhhdCB3ZWlnaHRpbmcgZmVlbHMgd3JvbmcuDQo+ID4+DQo+ ID4+IFRoaXMgd291bGQgZm9yY2UgZHJvcHMgdG8gb2NjdXIgYW5kIHRoZW4gY29uc2lkZXIgRUNO LUNFIG1hcmtzIGFzIGFkZGl0aW9uYWwNCj4gZXZpZGVuY2UNCj4gPj4gdGhhdCBzb21ldGhpbmcg aXMgd3JvbmcgaW4gdGhlIG5ldHdvcmsuDQo+ID4+DQo+ID4+IEFub3RoZXIgcG9zc2libGUgcmF0 aW9uYWxlIGZvciB0aGlzIG1peGluZyBpcyB0aGF0IGlmIGRyb3BzIHN0YXJ0IG9jY3VycmluZywg dGhlbg0KPiBtYW55IG9mDQo+ID4+IHRoZSBuZXcgYW5kIHByb3Bvc2VkIHVzZXMgb2YgRUNOIHRo YXQgdHJlYXQgRUNOLUNFIG1hcmtzIGFzIGxlc3MgdGhhbiBsb3NzLQ0KPiBlcXVpdmFsZW50DQo+ ID4+IGFyZSBvdXRzaWRlIHRoZWlyIGludGVuZGVkIG9wZXJhdGluZyBlbnZlbG9wZXMvcmVnaW9u cy4NCj4gPg0KPiA+IENsZWFybHkgaWYgdGhlIHF1ZXVlIGhhcyBiZWVuIGRyaXZlbiB0byBvdmVy Zmxvdywgc28gdGhhdCBwYWNrZXQgbG9zcyBpcw0KPiBvY2N1cnJpbmcsIHRoZW4gdGhlIEFRTSBp cyBvdXRzaWRlIGl0cyBpbnRlbmRlZCBvcGVyYXRpbmcgcmVnaW1lLiBJ4oCZbSBub3Qgc3VyZQ0K PiB3ZSBuZWVkIHRvIHB1c2ggaXQgc28gZmFyLCB0aG91Z2guIElzIHRoZXJlIG5vdCBhIHJlZ2lt ZSB3aGVyZSB0aGUgRUNOLUNFDQo+IG1hcmtpbmcgcmF0ZSBpbmRpY2F0ZXMgZXhjZXNzaXZlIGNv bmdlc3Rpb24sIGJlZm9yZSB0aGUgcXVldWUgb3ZlcmZsb3dzIGFuZA0KPiBkcm9wcyBwYWNrZXRz Pw0KPiANCj4gU2hvdWxkbuKAmXQgYSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIHJlYWN0 IHdlbGwgYmVmb3JlIHRoYXQ/DQo+IA0KPiBDaGVlcnMsDQo+IE1pY2hhZWwNCg0K From nobody Wed Jun 29 07:54:28 2016 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 14B9512DC29; Wed, 29 Jun 2016 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 l5Ym9gC2J5Vs; Wed, 29 Jun 2016 07:54:18 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F7112D08F; Wed, 29 Jun 2016 07:54:16 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bIGsW-0004NH-BT; Wed, 29 Jun 2016 16:54:12 +0200 Received: from 1x-193-157-240-251.uio.no ([193.157.240.251]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bIGsV-0005HQ-Pp; Wed, 29 Jun 2016 16:54:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Wed, 29 Jun 2016 16:54:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 3 sum rcpts/h 15 sum msgs/h 7 total rcpts 43824 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BEC1D3752D6DF3869DF476B59BD2B275000EA244 X-UiO-SPAM-Test: remote_host: 193.157.240.251 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 131 max/h 8 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "rtcweb@ietf.org" , Colin Perkins , IETF AVTCore WG , tsvwg Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:54:21 -0000 > On 29. jun. 2016, at 16.44, Black, David wrote: >=20 > I wrote:=20 >=20 >>> Another possible rationale for this mixing is that if drops start = occurring, then many of >>> the new and proposed uses of ECN that treat ECN-CE marks as less = than loss-equivalent >>> are outside their intended operating envelopes/regions. >=20 > Colin responded: >=20 >> Clearly if the queue has been driven to overflow, so that packet loss = is >> occurring, then the AQM is outside its intended operating regime. = I=E2=80=99m not sure >> we need to push it so far, though. Is there not a regime where the = ECN-CE >> marking rate indicates excessive congestion, before the queue = overflows and >> drops packets? >=20 > Yes, but that may not be relevant to this discussion. My hypothesis = for this discussion > is that actual drops will occur well before RTP is running at 10x the = TCP equivalent rate > (based on drops and ECN-CE marks), and that 10x factor is the trip = threshold for the > circuit breaker, which is the focus of this discussion.=20 >=20 > I would think that the "regime where the ECN-CE marking rate indicates = excessive > congestion, before the queue overflows and drops packets?" would not = extend as > far as RTP running at 10x the TCP equivalent rate, which is where the = RTP circuit > breaker trips. Seems reasonable to me=E2=80=A6. >=20 > This is all a thought exercise - I'm happy to be shown to be wrong = based on actual > data and experience with "running code" ... >=20 > To which Michael responded:=20 >=20 >> Shouldn=E2=80=99t a congestion control mechanism react well before = that? >=20 > Yes, if there is one ;-). This is RTP =E2=80=A6 Earlier, in the same conversation, so - I assume - the same context, = Colin wrote: "Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running=E2=80=9D Cheers, Michael From nobody Wed Jun 29 13:01:27 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FED12D5B4; Wed, 29 Jun 2016 13:01:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160629200126.30471.13573.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2016 13:01:26 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 20:01: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 of the IETF. Title : GRE-in-UDP Encapsulation Authors : Lucy Yong Edward Crabbe Xiaohu Xu Tom Herbert Filename : draft-ietf-tsvwg-gre-in-udp-encap-12.txt Pages : 24 Date : 2016-06-29 Abstract: This document specifies a method of encapsulating network protocol packet within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load balancing of GRE traffic in transit networks using existing ECMP mechanisms. This document also specifies GRE-in-UDP tunnel requirements for two applicability scenarios: (1) general Internet; (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-gre-in-udp-encap-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 29 13:08:06 2016 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 0467E12B05D; Wed, 29 Jun 2016 13:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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, RP_MATCHES_RCVD=-1.426, 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 JOAlnPHkzwV0; Wed, 29 Jun 2016 13:08:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEAE12B02E; Wed, 29 Jun 2016 13:07:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMX00782; Wed, 29 Jun 2016 20:07:55 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 29 Jun 2016 21:07:54 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Wed, 29 Jun 2016 13:07:49 -0700 From: Lucy yong To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-12.txt Thread-Index: AQHR0kEJdxNTnuBQ3UW1TUGzDwfh7KAA3alw Date: Wed, 29 Jun 2016 20:07:48 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572A7737@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57742A9C.00AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 24858d3f083490ed37f81b24aadf7b76 Archived-At: Cc: "draft-ietf-tsvwg-gre-in-udp-encap@ietf.org" Subject: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 20:08:05 -0000 RllJLiBUaGlzIHZlcnNpb24gYWRkcmVzc2VzIHRoZSBjb21tZW50cy9zdWdnZXN0aW9ucyBmcm9t IERvbmFsZCBFYXN0bGFrZSwgRWxpb3QgTGVhciwgDQphbmQgTWFydGluIFN0aWVtZXJsaW5nIGlu IFdHTEMgcHJvY2Vzcy4gSSBsaWtlIHRvIHRoYW5rIHRoZW0gZm9yIHRoZWlyIGRldGFpbCByZXZp ZXdzLg0KDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDM6MDEgUE0NClRvOiBMdWN5IHlvbmc7IFh1eGlh b2h1OyBFZHdhcmQgQ3JhYmJlOyBUb20gSGVyYmVydA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMTIudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNh cC0xMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTHVjeSBZb25nIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtdHN2 d2ctZ3JlLWluLXVkcC1lbmNhcA0KUmV2aXNpb246CTEyDQpUaXRsZToJCUdSRS1pbi1VRFAgRW5j YXBzdWxhdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wNi0yOQ0KR3JvdXA6CQl0c3Z3Zw0KUGFn ZXM6CQkyNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMTIudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1n cmUtaW4tdWRwLWVuY2FwLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXRzdndnLWdyZS1pbi11ZHAtZW5jYXAtMTINCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1ncmUt aW4tdWRwLWVuY2FwLTEyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMg YSBtZXRob2Qgb2YgZW5jYXBzdWxhdGluZyBuZXR3b3JrIHByb3RvY29sDQogICBwYWNrZXQgd2l0 aGluIEdSRSBhbmQgVURQIGhlYWRlcnMuIFRoaXMgR1JFLWluLVVEUCBlbmNhcHN1bGF0aW9uDQog ICBhbGxvd3MgdGhlIFVEUCBzb3VyY2UgcG9ydCBmaWVsZCB0byBiZSB1c2VkIGFzIGFuIGVudHJv cHkgZmllbGQuDQogICBUaGlzIG1heSBiZSB1c2VkIGZvciBsb2FkIGJhbGFuY2luZyBvZiBHUkUg dHJhZmZpYyBpbiB0cmFuc2l0DQogICBuZXR3b3JrcyB1c2luZyBleGlzdGluZyBFQ01QIG1lY2hh bmlzbXMuIFRoaXMgZG9jdW1lbnQgYWxzbw0KICAgc3BlY2lmaWVzIEdSRS1pbi1VRFAgdHVubmVs IHJlcXVpcmVtZW50cyBmb3IgdHdvIGFwcGxpY2FiaWxpdHkNCiAgIHNjZW5hcmlvczogKDEpIGdl bmVyYWwgSW50ZXJuZXQ7ICgyKSBhIHRyYWZmaWMtbWFuYWdlZCBjb250cm9sbGVkDQogICBlbnZp cm9ubWVudC4gVGhlIGNvbnRyb2xsZWQgZW52aXJvbm1lbnQgaGFzIGxlc3MgcmVzdHJpY3RpdmUN CiAgIHJlcXVpcmVtZW50cyB0aGFuIHRoZSBnZW5lcmFsIEludGVybmV0Lg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Jun 30 00:50:33 2016 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 CA3D712DA11 for ; Thu, 30 Jun 2016 00:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 OV1GXLIIYih9 for ; Thu, 30 Jun 2016 00:50:30 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D689612DA09 for ; Thu, 30 Jun 2016 00:50:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,550,1459839600"; d="asc'?scan'208";a="124097237" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 30 Jun 2016 00:45:27 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 30 Jun 2016 00:45:28 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Thu, 30 Jun 2016 00:45:28 -0700 From: "Eggert, Lars" To: "Black, David" Thread-Topic: [tsvwg] RFC 5405bis draft - non-congestion-controlled IP traffic Thread-Index: AdHSDr4yaUy437LrT6qIFydk7GP8rAAz0sKA Date: Thu, 30 Jun 2016 07:45:27 +0000 Message-ID: <6344F13E-F78C-428B-A383-F8AF932F3E1F@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_40D9075F-B985-4134-8E67-15B65CA93F91"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Martin Stiemerling , "tsvwg@ietf.org" Subject: Re: [tsvwg] RFC 5405bis draft - non-congestion-controlled IP traffic X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 07:50:32 -0000 --Apple-Mail=_40D9075F-B985-4134-8E67-15B65CA93F91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I made both of these changes in our working copy of -16. Will wait a = little while before submitting in case there are more change requests. Thanks, Lars On 2016-06-29, at 16:01, Black, David wrote: >=20 > A while back, in response to Martin Stiemerling's comments on the = GRE/UDP draft, > I wrote: >=20 >> [2] IP traffic congestion control assumptions. >>=20 >>> - I do disagree with "IP-traffic can be assumed to be >>> congestion-controlled.", even though it is stated in RFC 5405, as = there >>> is a lot of IP traffic that is not congestion controlled, such as >>> multicast traffic... >>> Section 4, even states that multicast and broadcast traffic can be >>> carried over GRE-UDP! None of both is in general congestion = controlled! >>=20 >> Well, this is actually an issue with the rfc5405bis draft, and this = issue needs >> to be fixed there, as RFC 5405 is (and the rfc5405bis draft will be) = the >> Transport Area's statement to the rest of the IETF on congestion = control >> guidelines and requirements for UDP usage. >=20 > This is indeed an issue with the 5405bis draft. In particular, Martin = has > effectively pointed out that this text in Section 3.1.11 is wrong = because > it encompasses multicast and broadcast traffic: >=20 > IP-based traffic is generally assumed to be congestion-controlled, > i.e., it is assumed that the transport protocols generating IP-based > traffic at the sender already employ mechanisms that are sufficient > to address congestion on the path. Consequently, a tunnel carrying > IP-based traffic should already interact appropriately with other > traffic sharing the path, and specific congestion control mechanisms > for the tunnel are not necessary. >=20 > Changing "IP-based traffic" to "IP-based unicast traffic" in three = places > in the above paragraph should correct this problem. >=20 > In addition, multicast needs to be called out as an exception in the = next > paragraph: >=20 > OLD > However, if the IP traffic in the tunnel is known to not be > congestion-controlled, additional measures are RECOMMENDED to limit > the impact of the tunneled traffic on other traffic sharing the = path. >=20 > The following guidelines define these possible cases in more detail: > NEW > However, if the IP traffic in the tunnel is known to not be > congestion-controlled, additional measures are RECOMMENDED to limit > the impact of the tunneled traffic on other traffic sharing the = path. For > the specific case of a tunnel that carries IP multicast traffic, see = section 4.1. >=20 > The following guidelines define these possible cases in more detail: >=20 > As a WG chair and draft shepherd, I think these changes are important, > as the original text has already been misread/misinterpreted by more > than one UDP tunnel designer. >=20 > Thanks, --David --Apple-Mail=_40D9075F-B985-4134-8E67-15B65CA93F91 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXdM4WAAoJEFS1wwm/cMFXDhwQALFb6aKN/Yy5wwMAqqudaQcV 4bK9W02Z4IXl+Rd6oI5kOzhBeAiUIitjp/2po42yuFxEryexsMClyRi97VJcBgHB ts1OHne6WO7DbPERhQCZC7HO6YE9oiYUy9GoCr+2KQSpPlJmjZns59qN8HmSSJVh 3/SDnpexEiP1P19YjDLuaaIGVgr7m1ury57KkRyLrcMcgb8lLC9+utVVI0etGmYM b+8GQHeS2jK3XkH+NbOoYevHPRl6BS0BtN3PYtZO6fcGt1DrVp8axbsb8adHgnmV +NI5CtIZum+zFOFY8McUcrr5BO9zbvH4rUKCYOVW0hV3VWRgI5KjXbmfW7Rl+LQO 3RPPCImihjlLdyeb8mY7F+Et2HZwcb4yq+tYFeOnay4P2V1TNfYL5jHQc+GYKfmn O6ZvUc6jJ/nNQYatN85I6PF1gRW06lEaE7yXZdVbTOBWbWbc8citc8yQ7SbU/uQL XP9uBb00U0UUGkcCHVDnBl8YBKVFPJZnu8M191ZrmbDfzf8Zi94F9hil1CQIWT8Z zx6+IRdG+EMzSUsFm851ge2n32E0R1ID3Lj1fflVneudgbOndopUC2f93T6LNwPO gocNL669LaZ4OlmMrJhfnSQvHerbpRoiUC0HXOPFYnTRQdKIRHZ6xt2jogjy+CDN T7PJsCpFMGWeHIxfpekx =IlE/ -----END PGP SIGNATURE----- --Apple-Mail=_40D9075F-B985-4134-8E67-15B65CA93F91-- From nobody Thu Jun 30 07:51:39 2016 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 717AD12D09B; Thu, 30 Jun 2016 07:51:34 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 Q0CKsTE6lqQi; Thu, 30 Jun 2016 07:51:32 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CBF12B054; Thu, 30 Jun 2016 07:51:32 -0700 (PDT) Received: from [130.209.247.112] (port=64642 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bIdJQ-0004W4-9v; Thu, 30 Jun 2016 15:51:29 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Thu, 30 Jun 2016 15:51:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B94C5D0-A473-44A4-B1BF-0D927DEBDD63@csperkins.org> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> To: Michael Welzl X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:51:34 -0000 > On 29 Jun 2016, at 15:54, Michael Welzl wrote: >> On 29. jun. 2016, at 16.44, Black, David wrote: >> I wrote:=20 >>=20 >>>> Another possible rationale for this mixing is that if drops start = occurring, then many of >>>> the new and proposed uses of ECN that treat ECN-CE marks as less = than loss-equivalent >>>> are outside their intended operating envelopes/regions. >>=20 >> Colin responded: >>=20 >>> Clearly if the queue has been driven to overflow, so that packet = loss is >>> occurring, then the AQM is outside its intended operating regime. = I=E2=80=99m not sure >>> we need to push it so far, though. Is there not a regime where the = ECN-CE >>> marking rate indicates excessive congestion, before the queue = overflows and >>> drops packets? >>=20 >> Yes, but that may not be relevant to this discussion. My hypothesis = for this discussion >> is that actual drops will occur well before RTP is running at 10x = the TCP equivalent rate >> (based on drops and ECN-CE marks), and that 10x factor is the trip = threshold for the >> circuit breaker, which is the focus of this discussion.=20 >>=20 >> I would think that the "regime where the ECN-CE marking rate = indicates excessive >> congestion, before the queue overflows and drops packets?" would not = extend as >> far as RTP running at 10x the TCP equivalent rate, which is where the = RTP circuit >> breaker trips. >=20 > Seems reasonable to me=E2=80=A6. Does anyone have data to let us find out either way?=20 >> This is all a thought exercise - I'm happy to be shown to be wrong = based on actual >> data and experience with "running code" ... >>=20 >> To which Michael responded:=20 >>=20 >>> Shouldn=E2=80=99t a congestion control mechanism react well before = that? >>=20 >> Yes, if there is one ;-). This is RTP =E2=80=A6 >=20 > Earlier, in the same conversation, so - I assume - the same context, = Colin wrote: > "Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running=E2=80=9D If the congestion control is working, then it should adapt the rate so = the circuit breaker never triggers. Yes, there should be a parallel = congestion control, but for the circuit breaker to be relevant, that = congestion control is either not working properly, or not implemented.=20= --=20 Colin Perkins https://csperkins.org/ From nobody Thu Jun 30 09:00:08 2016 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 9449F12D508; Thu, 30 Jun 2016 09:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 aQ2deBhBW38t; Thu, 30 Jun 2016 08:59:58 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F059112D113; Thu, 30 Jun 2016 08:59:57 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A149A96969B67; Thu, 30 Jun 2016 15:59:51 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5UFxsAG002113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2016 15:59:54 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5UFxrch016560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jun 2016 17:59:54 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 30 Jun 2016 17:58:43 +0200 From: "De Schepper, Koen (Nokia - BE)" To: "Black, David" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4Xv7l4815Xu02SCqscZNZxsp/tUDQAgABAKwCAABBvgIABAQmAgAOYcQCAADeCAIAK/Ekg///0AQCAAFzOEP//7voAgAAowpA= Date: Thu, 30 Jun 2016 15:58:42 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:00:06 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJsYWNrLCBEYXZpZCBbbWFp bHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+IFNlbnQ6IG1hYW5kYWcgMjcganVuaSAyMDE2IDIy OjEwDQo+IFRvOiBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRSkNCj4gQ2M6IHRzdndnOyBJ RVRGIEFWVENvcmUgV0c7IHJ0Y3dlYkBpZXRmLm9yZzsgQmxhY2ssIERhdmlkDQo+IFN1YmplY3Q6 IFJFOiBbdHN2d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczog ZHJhZnQtDQo+IGlldGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gPiBB cyBsb25nIGFzIGFuIEFRTSBpcyBtYXJraW5nIGF0IHRoZSBzYW1lIHJhdGUgYXMgZHJvcHBpbmcN Cj4gDQo+IFRoYXQncyBhbiBpbnRlcmVzdGluZyBhc3N1bXB0aW9uIC0gaXQgc2hvdWxkIGJlIHRy dWUgZm9yIEFRTXMgdmV0dGVkDQo+IGhlcmUgaW4gdGhlIHBhc3QsDQoNCkFuZCBJIGhvcGUgZm9y IGVjdCgwKSB0aGUgbmV0d29yayB3aWxsIGtlZXAgZG9pbmcgdGhpcyBpbiB0aGUgZnV0dXJlLCBh dCANCmxlYXN0IG5vdCB0byBkZXZpYXRlIHRvbyBmYXIgZnJvbSB0aGlzLg0KTDRTIHByb3Bvc2Vz IHRvIHVzZSBlY3QoMSkganVzdCBiZWNhdXNlIGl0IGRldmlhdGVzIHRvbyBtdWNoLCBzbyB0aGUg bmV0d29yayANCmNhbiBkZXRlY3QgdGhlIGRpZmZlcmVudCBlbmQtc3lzdGVtIGJlaGF2aW9yIGFu ZCBjYW4gY291cGxlIGl0IGNvcnJlY3RseSB0byANCndoYXQgaXQgaXMgZG9pbmcgZm9yIGRyb3Ag YW5kIGVjdCgwKS4NCg0KDQo+IGJ1dCB0aGVyZSBhcmUgZWFzeSB3YXlzIGZvciBpdCBub3QgdG8g aG9sZCAoZS5nLiwgaWYNCj4gZHJvcHBpbmcNCj4gb3IgbWFya2luZyBpcyBiYXNlZCBvbiBxdWV1 ZSBvY2N1cGFuY3ksIGl0IGlzIHBvc3NpYmxlIHRoYXQgZHJvcHBpbmcNCj4gcmVkdWNlcyBxdWV1 ZSBvY2N1cGFuY3kgaW4gYSBmYXNoaW9uIHRoYXQgbWFya2luZyBkb2VzIG5vdCkuDQoNCkRvIHlv dSBtZWFuIHRoYXQgdGhpcyByZXN1bHRzIGluIGRpZmZlcmVudCBtYXJrIGFuZCBkcm9wIHByb2Jh YmlsaXRpZXMgDQpmb3IgY29tcGV0aW5nIEVDTiBhbmQgbm9uLUVDTiBmbG93cz8NCg0KVGhlIGlt cGFjdCBvbiB0aGUgZHJvcHBpbmcvbWFya2luZyBwcm9iYWJpbGl0eSAqdmFsdWUqIGFwcGxpZWQg YnkgYW4gQVFNIGNhbiBjaGFuZ2UgDQpkdWUgdG8gcHJlc2VuY2Ugb2YgRUNOIGZsb3dzLCBidXQg SSBkb24ndCB0aGluayB0aGlzIHJlc3VsdHMgaW4gYSBkaWZmZXJlbnQgDQpkcm9wIGNvbXBhcmVk IHRvIG1hcmsgcHJvYmFiaWxpdHkuIFVwIHRvIG5vdyBhbGwgY2xhc3NpYyBBUU1zIHNtb290aCB0 aGVpciBwIA0Kb3ZlciBzdWZmaWNpZW50IGxvbmcgdGltZSB0byByZW1vdmUgc2hvcnQgZmx1Y3R1 YXRpb25zIGluIHF1ZXVlIHNpemVzLiANCg0KRnJvbSBhbiBlbmQgc3lzdGVtIEkgdGhpbmsgZm9y IGNsYXNzaWMgRUNOIGl0IGlzIHNhZmUgdG8gYXNzdW1lIHRoYXQgaWYgeW91IA0KZGV0ZWN0IGhp Z2ggbGV2ZWxzIG9mIGRyb3AsIGl0IG1lYW5zIHRoZXJlIGlzIGEgaGlnaCBsZXZlbCBvZiANCmNv bmdlc3Rpb24gQU5EIHRoZSBuZXR3b3JrIHRha2VzIGNhcmUgb2YgaXQuIElmIHlvdSBkZXRlY3Qg YSBoaWdoIGxldmVsDQpvZiBtYXJraW5nLCBpdCBtZWFucyBsb3RzIG9mIGNvbmdlc3Rpb24gYW5k IG5vYm9keSBpcyBjdXJyZW50bHkgdGFraW5nIGNhcmUgDQpvZiBpdC4gRXZlcnlib2R5IGlzIGxv b2tpbmcgYXQgeW91IGFzIGEgc2VuZGVyIHRvIHRha2UgY2FyZSBvZiBpdC4gVGhhdCdzIHdoeQ0K SSB0aGluayB5b3Ugc2hvdWxkIG5vdCB1c2UgRUNOIGlmIHlvdSBkb24ndCB1c2UgY29uZ2VzdGlv biBjb250cm9sLg0KDQpJdCBhbHNvIG1lYW5zIHRoYXQgdGhlIGNvbXBldGluZyBkcm9wIGZsb3dz IGFyZSBoYXZpbmcgYSBoaWdoIGxldmVsIG9mIG1hdGNoaW5nDQpkcm9wLiBUaGF0J3Mgd2h5IEkg dGhpbmsgYSBjbGFzc2ljIGNpcmN1aXQgYnJlYWtlciBzaG91bGQgYWxzbyB0cmVhdCBkcm9wIGFu ZCANCmNsYXNzaWMgbWFya2luZyBzaW1pbGFyLg0KDQpJIHVuZGVyc3Rvb2QgQUJFIHRyaWVzIHRv IG1vZGlmeSB0aGUgZW5kIHN5c3RlbSBiZWhhdmlvciBzbGlnaHRseSBmb3IgRUNOLiBJZiANCnRo aXMgY2FuIGJlIGRvbmUgc2FmZWx5IHdpdGggYmVuZWZpdHMgdGhhdCBvdXR3ZWlnaHMgdGhlIGRp c2FkdmFudGFnZXMsIA0KdGhhbiB0aGF0J3Mgbm8gcHJvYmxlbSwgYnV0IEkgdGhpbmsgbm9ib2R5 IGlzIGluIGZhdm9yIHRvIG1vZGlmeSB0aGUgQVFNIA0KYmVoYXZpb3IgdG8gZWN0KDApLg0KDQpC YXNlZCBvbiBEdWFsUSBjb21wYXRpYmlsaXR5IGV4cGVyaW1lbnRzIHdpdGggY2xhc3NpYyBFQ04s IEkgYWxzbyBiZWxpZXZlIA0KdGhhdCwgaWYgd2Ugd2FudCB0byBmdXJ0aGVyIHByb21vdGUgY2xh c3NpYyBFQ04gdG9vLCB3ZSBuZWVkIHNvbWUgZXh0cmEgDQpzYWZldHkgbWVhc3VyZXMgZm9yIGNs YXNzaWMgQVFNcyB1c2luZyBFQ04gdG8gYXZvaWQgaGlnaCBDRSBtYXJraW5nIGxldmVscywgDQp3 aGVyZSBlY3QoMCkgZmxvd3Mgc3RhcnQgdG8gcHVzaCBhd2F5IHRvbyBtdWNoIHRoZSBub24tZWN0 IGZsb3dzLiBGb3IgDQppbnN0YW5jZSBQSUUgaGFzIChmb3IgZ29vZCByZWFzb25zKSBhIG1heCBv ZiAxMCUgbWFya2luZywgYW5kIHRoZW4gc3dpdGNoZXMgDQp0byBkcm9wLiBBcyBmYXIgYXMgSSBr bm93IHN1Y2ggbWVhc3VyZXMgYXJlIG5vdCBtYW5kYXRvcnkgaW4gb3RoZXIgRUNOL0FRTSANCnJl bGF0ZWQgZHJhZnRzLCBpcyBpdD8NCg0KS29lbi4NCg0KPiANCj4gRm9yIEVDTiAiY2xhc3NpYyIg KGkuZS4sIHNlZSBSRkMgMzE2OCkgd2hlcmUgRUNOLUNFIG1hcmtpbmdzIGFyZSB0cmVhdGVkDQo+ IGFzIGRyb3AtZXF1aXZhbGVudCwgdGhhdCBpcyBmb3IgY29uZ2VzdGlvbiBjb250cm9sIHB1cnBv c2VzLCB3aGljaCBpcw0KPiBzaW1pbGFyDQo+IHRvLCAoYnV0IG5vdCB0aGUgc2FtZSBhcykgdGhl IHRocm91Z2hwdXQgZXN0aW1hdGlvbiB1c2FnZSBmb3IgdGhlIFJUUA0KPiBjaXJjdWl0DQo+IGJy ZWFrZXIuICAgIEknbGwgbm90ZSB0aGF0IEVDTiAiY2xhc3NpYyIgd2FzIGRlc2lnbmVkIGNvbmdl c3Rpb24gY29udHJvbA0KPiBhbGdvcml0aG1zIGZvciByZWFjdCB0byBFQ04tQ0UgbWFya3Mgb25j ZSBwZXIgUlRULCBpbmRlcGVuZGVudCBvZiBob3cNCj4gbWFueSBFQ04tQ0UgbWFya3MgYXJlIG9i c2VydmVkIGluIGFuIFJUVC4NCj4gDQo+IEdvcnJ5IHdyb3RlOg0KPiANCj4gPiA+IGluIHRoaXMg Y29udGV4dCB3ZSBzaG91bGQgdXNlIEVDTiB0byBkcml2ZSBhIENDIGFsZ29yaXRobSBhbmQgd2UN Cj4gc2hvdWxkIGJlDQo+ID4gPiBjYXV0aW91cyB0byBhdm9pZCByZXF1aXJpbmcgaXRzIHVzZSB3 aXRoaW4gYSBDaXJjdWl0IEJyZWFrZXIgLQ0KPiBvcHRpb25hbA0KPiA+ID4gdXNlLCBpZiB5b3Ug dW5kZXJzdGFuZCBob3cgdG8gaW50ZXJwcmV0IGEgcmVhY3Rpb24gdG8gbWFueSBDRS1tYXJrcw0K PiBhcw0KPiA+ID4gZXhjZXNzaXZlIGNvbmdlc3Rpb24sIGFyZSBwZXJtaXR0ZWQuDQo+IA0KPiBT b21ldGhpbmcgbGlrZSB0aGF0IG1heSBiZSB3b3JrYWJsZSwgc3RhcnRpbmcgd2l0aCBhIGNsZWFy IGRpc3RpbmN0aW9uDQo+IGJldHdlZW4NCj4gdGhlIHVzZSBvZiBFQ04gYnkgQ0MgKHJvdXRpbmUs IGFjdGl2ZSBhdCBhbGwgdGltZXMpIGFuZCBFQ04gYnkgYSBjaXJjdWl0DQo+IGJyZWFrZXIgKG1v bml0b3JzIGZvciBldmlkZW5jZSB0aGF0IHRoaW5ncyBoYXZlIGdvdHRlbiBiYWQsIG9ubHkNCj4g YWN0aXZhdGVkDQo+IHdoZW4gdGhpbmdzIGdldCBiYWQpLiAgIFRoaXMgd291bGQgYmFzZWxpbmUg dGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgb24NCj4gZHJvcHMNCj4gYW5kIGFsbG93IHVzZSBvZiBF Q04gYXMgYWRkaXRpb25hbCBldmlkZW5jZSBvZiBwcm9ibGVtcywgaW4gY29udHJhc3QgdG8NCj4g Y29uZ2VzdGlvbiBjb250cm9sIHdoZXJlIEVDTi1DRSBpcyBlZmZlY3RpdmVseSB0cmVhdGVkIGFz IGRyb3AtDQo+IGVxdWl2YWxlbnQuDQo+IA0KPiBJJ20gbm90IHF1aXRlIHN1cmUgaG93IHRvIHNw ZWNpZnkgInVzZSBvZiBFQ04gYXMgYWRkaXRpb25hbCBldmlkZW5jZSIgb2YNCj4gImV4Y2Vzc2l2 ZSBjb25nZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxlbmNlIGlzIGFib3V0IHRoZSBiZXN0IHdlIGhh dmUNCj4gZm9yIGN1cnJlbnQgZ3VpZGFuY2UuDQo+IA0KPiBUaGFua3MsIC0tRGF2aWQNCj4gDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBEZSBTY2hlcHBlciwgS29l biAoTm9raWEgLSBCRSkgW21haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLQ0KPiBiZWxsLQ0K PiA+IGxhYnMuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVuZSAyNywgMjAxNiAzOjEzIFBNDQo+ ID4gVG86IGdvcnJ5QGVyZy5hYmRuLmFjLnVrDQo+ID4gQ2M6IE1pY2hhZWwgV2Vsemw7IEJsYWNr LCBEYXZpZDsgTWFnbnVzIFdlc3Rlcmx1bmQ7IHRzdndnOyBJRVRGDQo+IEFWVENvcmUgV0c7DQo+ ID4gcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+ID4gU3ViamVjdDogUkU6IFt0c3Z3 Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0KPiBkcmFmdC1p ZXRmLQ0KPiA+IGF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYNCj4gPg0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogZ29ycnlAZXJnLmFiZG4u YWMudWsgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gPiA+IFNlbnQ6IG1hYW5kYWcg MjcganVuaSAyMDE2IDE3OjM4DQo+ID4gPiBUbzogRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0g QkUpDQo+ID4gPiBDYzogTWljaGFlbCBXZWx6bDsgQmxhY2ssIERhdmlkOyBnb3JyeUBlcmcuYWJk bi5hYy51azsgTWFnbnVzDQo+ID4gPiBXZXN0ZXJsdW5kOyB0c3Z3ZzsgSUVURiBBVlRDb3JlIFdH OyBydGN3ZWJAaWV0Zi5vcmc7IENvbGluIFBlcmtpbnMNCj4gPiA+IFN1YmplY3Q6IFJlOiBbdHN2 d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczoNCj4gZHJhZnQt DQo+ID4gPiBpZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYNCj4gPiA+DQo+ID4g PiBJIHRoaW5rIHRoaW5raW5nIG9mIEw0UyBpcyBtYXliZSBvZmYgYXQgYSB0YW5nZW50LiBUaGUg cXVlc3Rpb24NCj4gcmVhbGx5DQo+ID4gPiBpcw0KPiA+ID4gYWJvdXQgdGhlIGludGVycHJldGF0 aW9uIG9mIGxvc3MgYW5kIENFLW1hcmsgYXMgZXF1aXZhbGVudC4gSSBhcmd1ZWQNCj4gPiA+IHRo YXQNCj4gPiA+IGVhY2ggRUNOLUNFIG1hcmsgc2hvdWxkIG5vdCBiZSBjb3VudGVkIGFzIGVxdWl2 YWxlbnQgdG8gYSBsb3N0DQo+IHNlZ21lbnQgLQ0KPiA+DQo+ID4gV2h5IG5vdD8gQXMgbG9uZyBh cyBhbiBBUU0gaXMgbWFya2luZyBhdCB0aGUgc2FtZSByYXRlIGFzIGRyb3BwaW5nLCBhDQo+ID4g MTAwJSBtYXJraW5nIG1lYW5zIHRoYXQgbm9uLWVjbiBmbG93cyBhcmUgYmVpbmcgZHJvcHBlZCBh dCBhIDEwMCUsDQo+IG5vdD8NCj4gPg0KPiA+IEtvZW4uDQo+ID4NCj4gPg0KPiA+ID4gaW4gdGhp cyBjb250ZXh0IHdlIHNob3VsZCB1c2UgRUNOIHRvIGRyaXZlIGEgQ0MgYWxnb3JpdGhtIGFuZCB3 ZQ0KPiBzaG91bGQNCj4gPiA+IGJlDQo+ID4gPiBjYXV0aW91cyB0byBhdm9pZCByZXF1aXJpbmcg aXRzIHVzZSB3aXRoaW4gYSBDaXJjdWl0IEJyZWFrZXIgLQ0KPiBvcHRpb25hbA0KPiA+ID4gdXNl LCBpZiB5b3UgdW5kZXJzdGFuZCBob3cgdG8gaW50ZXJwcmV0IGEgcmVhY3Rpb24gdG8gbWFueSBD RS1tYXJrcw0KPiBhcw0KPiA+ID4gZXhjZXNzaXZlIGNvbmdlc3Rpb24sIGFyZSBwZXJtaXR0ZWQu DQo+ID4gPg0KPiA+ID4gR29ycnkNCj4gPiA+DQo+ID4gPiA+IEFzIGZhciBhcyBJIHVuZGVyc3Rh bmQsIHRoaXMgZHJhZnQgaXMgcmVsYXRlZCB0byBjaXJjdWl0IGJyZWFrZXJzDQo+IGluDQo+ID4g PiA+IGVuZC1zeXN0ZW1zLCByaWdodD8NCj4gPiA+ID4NCj4gPiA+ID4gSXQgaXMgdGhlIGVuZCBz eXN0ZW0gdGhhdCBkZXRlcm1pbmVzIHRoZSB1c2Ugb2YgRUNOIChjdXJyZW50bHkNCj4gbWFya2lu Zw0KPiA+ID4gPiBub24tZWN0IGZvciBkcm9wIGFuZCBlY3QoMCkgZm9yIENsYXNzaWMgRUNOKS4N Cj4gPiA+ID4NCj4gPiA+ID4gSW4gTDRTIHdlIGRvbid0IHBsYW4gdG8gY2hhbmdlIHRoZSBiZWhh dmlvciBvZiBDbGFzc2ljIEVDTiwgYW5kDQo+IEFCRSdzDQo+ID4gPiA+IGJlaGF2aW9yIHNob3Vs ZCBiZSBjbG9zZSB0byBub24tQUJFIEVDTi4gU28gSSBndWVzcyB0aGVyZSBpcyBubw0KPiA+ID4g cHJvYmxlbSBvZg0KPiA+ID4gPiBkZXNjcmliaW5nIHRoZSBiZWhhdmlvciBvZiBob3cgYSBDbGFz c2ljIEVDTiBiYXNlZCBzZW5kZXIgd291bGQNCj4gPiA+IHJlc3BvbmQNCj4gPiA+ID4gdG9kYXku DQo+ID4gPiA+DQo+ID4gPiA+IEFzIHdlIG9ubHkgd2FudCB0byBzaWduaWZpY2FudGx5IGNoYW5n ZSB0aGUgbmV0d29yayBiZWhhdmlvciBvZg0KPiBlY3QoMSkNCj4gPiA+ID4gbWFya2luZywgY2Fu IHdlIHNvbHZlIHRoaXMgaXNzdWUgYnkgcmVjb21tZW5kaW5nIChvciBldmVuDQo+IHJlcXVpcmlu ZykNCj4gPiA+ID4gc2VuZGVycyB0byBtYXJrIG9ubHkgZWN0KDApIGFuZCBkZXNjcmliaW5nIHRo ZSBjbGFzc2ljIEVDTiBjaXJjdWl0DQo+ID4gPiA+IGJyZWFrZXI/IFdoZW4gTDRTIGdldHMgZGVm aW5lZCwgYWxzbyBhbiBMNFMgYmFzZWQgY2lyY3VpdCBicmVha2VyDQo+ID4gPiA+IGV4dGVuc2lv biBjYW4gYmUgZGVmaW5lZCBmb3Igc2VuZGVycyB0aGF0IHdhbnQgdG8gdXNlIHRoZSBMNFMNCj4g c2VydmljZQ0KPiA+ID4gPiAod2hlbiBzZW5kZXJzIHNlbmQgZWN0KDEpIHBhY2tldHMpLg0KPiA+ ID4gPg0KPiA+ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiBLb2VuLg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+IEZyb206IHRzdndn IFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4g PiA+IFdlbHpsDQo+ID4gPiA+PiBTZW50OiBtYWFuZGFnIDIwIGp1bmkgMjAxNiAxODozNg0KPiA+ ID4gPj4gVG86IEJsYWNrLCBEYXZpZA0KPiA+ID4gPj4gQ2M6IDxnb3JyeUBlcmcuYWJkbi5hYy51 az4gRmFpcmh1cnN0OyBNYWdudXMgV2VzdGVybHVuZDsgdHN2d2c7DQo+IElFVEYNCj4gPiA+ID4+ IEFWVENvcmUgV0c7IHJ0Y3dlYkBpZXRmLm9yZzsgQ29saW4gUGVya2lucw0KPiA+ID4gPj4gU3Vi amVjdDogUmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFu Z2VzOg0KPiA+ID4gZHJhZnQtDQo+ID4gPiA+PiBpZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJl YWtlcnMtMTYNCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4gPiBPbiAyMC4ganVuLiAyMDE2 LCBhdCAxNS4xNiwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPg0KPiA+ID4gd3Jv dGU6DQo+ID4gPiA+PiA+DQo+ID4gPiA+PiA+Pj4gQnV0IEnDouKCrOKEom0gbGVzcyBjb25jZXJu ZWQgdGhhbiBEYXZpZCBhYm91dCBldmVudHVhbGx5IGlnbm9yaW5nDQo+IGl0DQo+ID4gPiA+PiBm b3INCj4gPiA+ID4+IGNpcmN1aXQNCj4gPiA+ID4+ID4+IGJyZWFrZXIuDQo+ID4gPiA+PiA+Pj4N Cj4gPiA+ID4+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFzdXJlbWVudCB0aGF0IGEgQ0IgTVVT VCByZXNwb25kIHRvLg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiBNdW1ibGUuICAgSSB3b3VsZCBi ZSBvayB3aXRoIGEgY2xlYXIgZGlzY291cmFnZW1lbnQgZm9yIHVzZSBvZg0KPiBFQ04tDQo+ID4g PiBDRQ0KPiA+ID4gPj4gbWFya3MsIGFjY29tcGFuaWVkIGJ5IHRoZSBzb3J0IG9mIGRlc2lnbiBy YXRpb25hbGUgaGVyZSwgb3IgZXZlbg0KPiA+ID4gPj4gYmV0dGVyLA0KPiA+ID4gPj4gYSBjbGVh ciBzdGF0ZW1lbnQgdGhhdCBsb3N0IHBhY2tldHMgZm9yIHRoZSBwdXJwb3NlIG9mIHRoZSBSVFAN Cj4gPiA+IGNpcmN1aXQNCj4gPiA+ID4+IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1YWxseSBsb3N0 IHdpdGhvdXQgZ2V0dGluZyBpbnRvIHdoZXRoZXIgb3INCj4gbm90DQo+ID4gPiA+PiBFQ04tQ0Ug bWFya3MgYXJlIGludm9sdmVkIC1pLmUuLCB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBpcw0KPiBz cGVjaWZpZWQNCj4gPiA+ID4+IGFnYWluc3QgYWN0dWFsIGRyb3BzIGFzIGEgbmV0d29yayBwcm90 ZWN0aW9uIGJhY2tzdG9wLg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiBBIHJlbGF0ZWQgY29uY2Vy biBpcyB0aGF0IEVDTiBtYXJrcyBtYXkgb3ZlcnN0YXRlIGVxdWl2YWxlbnQNCj4gbG9zcw0KPiA+ ID4gPj4gYmVoYXZpb3IgLSBhIHNpbXBsaXN0aWMgcXVldWUgbWFuYWdlbWVudCBkaXNjaXBsaW5l IHRoYXQgbWFya3MNCj4gZXZlcnkNCj4gPiA+ID4+IHBhY2tldCB3aGVuIHRoZSBxdWV1ZSBpcyBv dmVyIGEgdGhyZXNob2xkIChOQjogdGhpcyBjbGFzcyBvZg0KPiBtYXJraW5nDQo+ID4gPiA+PiBi ZWhhdmlvciBpcyBOT1QgUkVDT01NRU5ERUQgLSBhIHJlYWwgQVFNIFNIT1VMRCBiZSB1c2VkKSBj b3VsZA0KPiB5aWVsZA0KPiA+ID4gYQ0KPiA+ID4gPj4gcnVuIG9mIEVDTi1DRSBtYXJrcyB0aGF0 IHdvdWxkIG5vdCBjYXVzZSBhIGNvcnJlc3BvbmRpbmcgd2l0aCBhDQo+IHJ1bg0KPiA+ID4gb2YN Cj4gPiA+ID4+IHBhY2tldCBkcm9wcy4gICBUaGlzIGlzIGFtb25nIHRoZSByZWFzb25zIHRoYXQg VENQIHJlYWN0cyB0byBFQ04tDQo+IENFDQo+ID4gPiA+PiBtYXJrcyBvbmx5IG9uY2UgcGVyIFJU VCwgYW5kIG1pZ2h0IGJlIGEgcmVhc29uIHRvIHRyZWF0IG11bHRpcGxlDQo+IEVDTi0NCj4gPiA+ IENFDQo+ID4gPiA+PiBtYXJrcyBpbiBhbiBSVFQgaW50ZXJ2YWwgYXMgbm90IHJlcHJlc2VudGlu ZyBkcm9wcyBvZiBhbGwgcGFja2V0cw0KPiBmb3INCj4gPiA+ID4+IHRoZSBSVFAgY2lyY3VpdCBi cmVha2VyJ3MgVENQLWVxdWl2YWxlbnQgdGhyb3VnaHB1dCBjYWxjdWxhdGlvbi4NCj4gPiA+ID4+ DQo+ID4gPiA+PiBJw6LigqzihKJtIG5vdCBzdXJlIHdlIG5lZWQgc3VjaCBjb21wbGljYXRlZCBs b2dpYyB0byBmaW5kIGEgY2FzZQ0KPiB3aGVyZQ0KPiA+ID4gRUNODQo+ID4gPiA+PiBtYXJrcyBh cmUgZGlmZmVyZW50IGZyb20gcGFja2V0IGRyb3BzOg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJhc2lj YWxseSwgdGhleSBzaW1wbHkgYXJlbsOi4oKs4oSidCAtIGV2ZW4gw6LigqzFk3JlYWzDouKCrMKd IEFRTXMgbWFya2luZw0KPiA+ID4gaXNuw6LigqzihKJ0DQo+ID4gPiA+PiBleGFjdGx5DQo+ID4g PiA+PiB0aGUgc2FtZSBhcyBhIHBhY2tldCBkcm9wOiB0aGUgbWFya3MgdGhlbXNlbHZlcyBpbmZv cm0geW91IHRoYXQNCj4gYW4NCj4gPiA+IEFRTQ0KPiA+ID4gPj4gZGlkIGl0cyBqb2IsIGFuZCB3 aXRoIG1vZGVybiBBUU1zIGxpa2UgQ29EZWwgLyBQSUUgZXRjLiwgeW91w6LigqzihKJyZQ0KPiA+ ID4gPj4gcHJvYmFibHkNCj4gPiA+ID4+IGdldHRpbmcgdGhpcyBmcm9tIGEgc2hhbGxvdyBxdWV1 ZS4gQ2hhbmNlcyBhcmUgdGhhdCB0aGlzIGlzIGxlc3MNCj4gdGhhbg0KPiA+ID4gYQ0KPiA+ID4g Pj4gQkRQIHdvcnRoIG9mIHF1ZXVpbmcsIHdoaWNoIGlzIG91ciBqdXN0aWZpY2F0aW9uIGZvciBy ZWNvbW1lbmRpbmcNCj4gYQ0KPiA+ID4gPj4gZGlmZmVyZW50IGJhY2stb2ZmIGJlaGF2aW9yIGlu IGRyYWZ0LWtoYWRlbWktdHN2d2ctZWNuLXJlc3BvbnNlLQ0KPiAwMA0KPiA+ID4gYW5kDQo+ID4g PiA+PiBkcmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbi0wMA0KPiA+ID4g Pj4NCj4gPiA+ID4+IFNvIHRoZSBwb2ludCBpcyBub3QgdGhhdCBBUU1zIHdvdWxkIHRyZWF0IEVD TiBtYXJraW5nIGFuZA0KPiBkcm9wcGluZw0KPiA+ID4gPj4gZGlmZmVyZW50bHkgLSBpdMOi4oKs 4oSicyB0aGF0IEVDTiBpbmRpY2F0ZXMgYW4gQVFNLCBhbmQgaGVuY2UNCj4gcHJvYmFibHkgYQ0K PiA+ID4gPj4gc2hhbGxvdyBxdWV1ZS4gV2l0aCBhIGRyb3AsIHlvdSBqdXN0IGRvbsOi4oKs4oSi dCBrbm93Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJhY2sgdG8gdGhlIENCLCBJIHRoaW5rIGFuIEFR TSBtYXJraW5nIGF0IGEgc2hhbGxvdyBxdWV1ZSAobGlrZQ0KPiBlLmcuDQo+ID4gPiA+PiBDb0Rl bCkgaXMgaW5kZWVkIHF1aXRlIGRpZmZlcmVudCBmcm9tIGEgw6LigqzFk2Jyb2tlbiBjb25uZWN0 aW9uw6LigqzCnS4NCj4gPiA+ID4+DQo+ID4gPiA+PiBDaGVlcnMsDQo+ID4gPiA+PiBNaWNoYWVs DQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gVGhhbmtzLCAtLURh dmlkDQo+ID4gPiA+PiA+DQo+ID4gPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4gPj4gPj4gRnJvbTogR29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 a10NCj4gPiA+ID4+ID4+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDE4LCAyMDE2IDI6MjMgQU0NCj4g PiA+ID4+ID4+IFRvOiBNaXJqYSBLw4PCvGhsZXdpbmQNCj4gPiA+ID4+ID4+IENjOiBCbGFjaywg RGF2aWQ7IE1hZ251cyBXZXN0ZXJsdW5kOyBDb2xpbiBQZXJraW5zOw0KPiA+ID4gcnRjd2ViQGll dGYub3JnOw0KPiA+ID4gPj4gSUVURg0KPiA+ID4gPj4gPj4gQVZUQ29yZSBXRzsgdHN2d2cNCj4g PiA+ID4+ID4+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0 IENhbGwgb24NCj4gY2hhbmdlczoNCj4gPiA+ID4+IGRyYWZ0LWlldGYtDQo+ID4gPiA+PiA+PiBh dnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2DQo+ID4gPiA+PiA+Pg0KPiA+ID4gPj4gPj4g SSB0aGluayB3ZSBTSE9VTEQgTk9UIHJlY29tbWVuZCB0byB1c2UgRUNOIG1hcmtzIGFzIGlucHV0 cyB0bw0KPiBhDQo+ID4gPiBDQi4NCj4gPiA+ID4+IFNlZQ0KPiA+ID4gPj4gPj4gYmVsb3c6DQo+ ID4gPiA+PiA+Pg0KPiA+ID4gPj4gPj4+IE9uIDE3IEp1biAyMDE2LCBhdCAxNjowMiwgTWlyamEg S8ODwrxobGV3aW5kDQo+ID4gPiA+PiA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4N Cj4gPiA+ID4+ID4+IHdyb3RlOg0KPiA+ID4gPj4gPj4+DQo+ID4gPiA+PiA+Pj4gKzEgdG8gbm90 IHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaGVyZS4NCj4gPiA+ID4+ID4+Pg0KPiA+ID4gPj4gPj4+ IEhvd2V2ZXIsIHBsZWFzZSBub3RlIHRoYXQgaGF2aW5nIGEgaGlnaCBsZXZlbCBvZiBFQ04tQ0Ug bWFya3MNCj4gPiA+ID4+ICh3aXRob3V0IGFueQ0KPiA+ID4gPj4gPj4gbG9zc2VzKSBtZWFucyB0 aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVjdGx5LiBUaGlzDQo+ID4gPiA+PiBz aXR1YXRpb24gY2FuIGV2ZW4NCj4gPiA+ID4+ID4+IG9jY3VycyB3aXRob3V0IGhpZ2ggZGVsYXlz IChkZXBlbmRpbmcgb24gdGhlIEFRTSB1c2VkKSwgd2hpY2gNCj4gPiA+IHdvdWxkDQo+ID4gPiA+ PiBqdXN0DQo+ID4gPiA+PiA+PiBtZWFuIHRoZSBzZXJ2aWNlcyB3b3JrcyBwZXJmZWN0bHkuIFRo ZXJlZm9yZSBmb3IgbWUgQ0UgbWFya3MNCj4gYXJlIGENCj4gPiA+ID4+IHBlcmZlY3QgaW5wdXQN Cj4gPiA+ID4+ID4+IHNpZ25hbCBmb3IgYSBjb25nZXN0aW9uIGNvbnRyb2wgbG9vcCAod2hlcmUg dGhlIEFRTSB0ZWxsIHRoZQ0KPiA+ID4gc2VuZGVyDQo+ID4gPiA+PiB0byB0YWtlIGFjdGlvbg0K PiA+ID4gPj4gPj4gLSB3aGF0ZXZlciB0aGF0IG1lYW5zKS4NCj4gPiA+ID4+ID4+DQo+ID4gPiA+ PiA+PiBXZSBtYXkgaW4gZnV0dXJlIGZpZ3VyZSBvdXQgd2F5cyB0byBkbyB0aGlzIHRvIGRldGVj dA0KPiBzaWduaWZpY2FudA0KPiA+ID4gPj4gZmFpbHVyZSB1c2luZyBhDQo+ID4gPiA+PiA+PiBy YXRlIGFkYXB0aXZlIHRyYW5zcG9ydCBhbmQgRUNOIGUuZy4gIE9ic2VydmluZyAxMDAlIENFIG1h cmtzDQo+IG9yDQo+ID4gPiA+PiBzb21ldGhpbmcsIGZvcg0KPiA+ID4gPj4gPj4gYW4gUlRQIGZs b3cgdGhhdCBpcyB0cnlpbmcgdG8gc2VuZCB3ZWxsIGJlbG93IGl0cyBwZWFrIHJhdGUNCj4gPiA+ IGRlY2lkZWQNCj4gPiA+ID4+IGJ5IENDIC0tIGJ1dCBJDQo+ID4gPiA+PiA+PiB0aGluayB0aGlz IGlzIHNwZWN1bGF0aW5nIGF0IGFuIGFsZ29yaXRobSBhbmQgYWRkaW5nIGRldGFpbHMNCj4gaGVy ZQ0KPiA+ID4gaXMNCj4gPiA+ID4+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPiA+ID4+ID4+IEVzcGVj aWFsbHkgYXMgQVFNIGNvbnRpbnVlcyB0byBldm9sdmUuDQo+ID4gPiA+PiA+Pg0KPiA+ID4gPj4g Pj4+IEJ1dCBJw6LigqzihKJtIGxlc3MgY29uY2VybmVkIHRoYW4gRGF2aWQgYWJvdXQgZXZlbnR1 YWxseSBpZ25vcmluZw0KPiBpdA0KPiA+ID4gPj4gZm9yDQo+ID4gPiA+PiBjaXJjdWl0DQo+ID4g PiA+PiA+PiBicmVha2VyLg0KPiA+ID4gPj4gPj4+DQo+ID4gPiA+PiA+PiBBZ3JlZS4gTG9zcyBp cyB0aGUgbWVhc3VyZW1lbnQgdGhhdCBhIENCIE1VU1QgcmVzcG9uZCB0by4NCj4gPiA+ID4+ID4+ DQo+ID4gPiA+PiA+Pj4gSW4gYWRkaXRpb24gb25lIHBvaW50IG9uIHNvbWV0aGluZyBNYWdudXMg d3JvdGUgZWFybGllcjoNCj4gPiA+ID4+ID4+PiAiSWYgdGhlIGltcGxlbWVudGF0aW9uIG9ubHkg aGF2ZSBjaXJjdWl0IGJyZWFrZXIsIGkuZS4gbm8NCj4gZnVsbA0KPiA+ID4gPj4gZmxlZGdlZCBj b25nZXN0aW9uDQo+ID4gPiA+PiA+PiBjb250cm9sbGVyIGFuZCB1c2VzIEVDTiwgdGhleSBjYW4g aW4gd29yc3QgY2FzZSBkcml2ZSB0aGUNCj4gYnVmZmVyDQo+ID4gPiA+PiBpbnRvDQo+ID4gPiA+ PiB0aGUgb3ZlcmxvYWQNCj4gPiA+ID4+ID4+IHJlZ2ltZSB3aGVyZSBpdCBzdGFydHMgZHJvcHBp bmcgcGFja2V0cy4gw6LigqzFvg0KPiA+ID4gPj4gPj4+DQo+ID4gPiA+PiA+Pj4gScOi4oKs4oSi bSBub3Qgc3VyZSBhYm91dCB0aGlzIGNhc2UuIEVDTiBpcyBhbiBpbnB1dCBzaWduYWwgZm9yDQo+ ID4gPiA+PiBjb25nZXN0aW9uDQo+ID4gPiA+PiBjb250cm9sLiBJZiB5b3UNCj4gPiA+ID4+ID4+ IGRvbsOi4oKs4oSidCB1c2UgY29uZ2VzdGlvbiBjb250cm9sIGJ1dCBvbmx5IGEgY2lyY3VpdCBi cmVha2VyLCB5b3UNCj4gPiA+ID4+IHNob3VsZA0KPiA+ID4gPj4gcHJvYmFibHkgbm90DQo+ID4g PiA+PiA+PiBlbmFibGUgRUNOLiBBdCBsZWFzdCBpdCBub3QgY2xlYXIgdG8gbWUgd2h5IHlvdSB3 b3VsZCBlbmFibGUNCj4gaXQsDQo+ID4gPiBhbmQNCj4gPiA+ID4+IGl0J3MgZGVmaW5pdGVseQ0K PiA+ID4gPj4gPj4gbm90IGNvbmZvcm0gdG8gdGhlIEVDTiBzcGVjLiBQcm9iYWJseSB3ZSBzaG91 bGQgc2F5IHNvbWV0aGluZw0KPiA+ID4gYWJvdXQNCj4gPiA+ID4+IHRoaXMgaW4gdGhlDQo+ID4g PiA+PiA+PiBkcmFmdC4uLj8NCj4gPiA+ID4+ID4+Pg0KPiA+ID4gPj4gPj4gQWdyZWUsIGVuYWJs aW5nIEVDTiB3aXRob3V0IGEgcmVzcG9uc2l2ZSBDQyBpcyBnb2luZyB0byBsZWFkDQo+IHRvDQo+ ID4gPiA+PiB0cm91YmxlLg0KPiA+ID4gPj4gPj4NCj4gPiA+ID4+ID4+PiBNaXJqYQ0KPiA+ID4g Pj4gPj4+DQo+ID4gPiA+PiA+PiBHb3JyeQ0KPiA+ID4gPj4gPj4NCj4gPiA+ID4+ID4+Pj4gQW0g MTcuMDYuMjAxNiB1bSAxNjowMyBzY2hyaWViIEJsYWNrLCBEYXZpZA0KPiA+ID4gPGRhdmlkLmJs YWNrQGVtYy5jb20+Og0KPiA+ID4gPj4gPj4+Pg0KPiA+ID4gPj4gPj4+PiBDb2xpbiwNCj4gPiA+ ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBh cyBwcm92aWRpbmcgaW1wbGVtZW50ZXJzDQo+IHdpdGgNCj4gPiA+IHRvbw0KPiA+ID4gPj4gbXVj aA0KPiA+ID4gPj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIChlLmcu LCBiZWNhdXNlIGFuDQo+IGltcGxlbWVudGVyDQo+ID4gPiA+PiBkb2Vzbid0DQo+ID4gPiA+PiA+ Pj4+Pj4+IHdhbnQgdG8gdGhpbmsgYWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJz dA0KPiBwbGFjZSkuDQo+ID4gPiA+PiA+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0 IHRoZSBhcmd1bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bA0KPiB0aGFuDQo+ ID4gPiA+PiBkZXBsb3lpbmcgYQ0KPiA+ID4gPj4gPj4gY2lyY3VpdA0KPiA+ID4gPj4gPj4+Pj4g YnJlYWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2VkLg0KPiA+ID4g Pj4gPj4+Pj4NCj4gPiA+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRo aXMgYXJndW1lbnQsIHRob3VnaCwgc2luY2UgaXQNCj4gc2VlbXMNCj4gPiA+ID4+IHRoYXQNCj4g PiA+ID4+IGFueSBuZXcNCj4gPiA+ID4+ID4+IEFRTQ0KPiA+ID4gPj4gPj4+Pj4gdGhhdCBhcHBs aWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gPiA+ IGhhdmUNCj4gPiA+ID4+IHRvDQo+ID4gPiA+PiA+PiBjb25zaWRlcg0KPiA+ID4gPj4gPj4+Pj4g YmFja3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdvcmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4s DQo+ID4gPiBkcmFmdC0NCj4gPiA+ID4+IGJyaXNjb2UtDQo+ID4gPiA+PiA+PiB0c3Z3Zy0NCj4g PiA+ID4+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEg c2lnbmFsIHRvIHVzZQ0KPiB0aGUNCj4gPiA+IG5ldw0KPiA+ID4gPj4gbWFya2luZywNCj4gPiA+ ID4+ID4+Pj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhl c2UNCj4gY29tcGF0aWJpbGl0eQ0KPiA+ID4gPj4gbWVjaGFuaXNtcw0KPiA+ID4gPj4gPj4+Pj4g d291bGQgc2VlbSB0byBwcmV2ZW50IHRoZSBpc3N1ZXMgd2l0aCB0aGUgY2lyY3VpdCBicmVha2Vy DQo+IHRvby4NCj4gPiA+ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNo ZXMgbXkgbGluZSBvZiB0aGlua2luZywgYW5kIEknbGwgb2JzZXJ2ZQ0KPiB0aGF0DQo+ID4gPiA+ PiB0aGUNCj4gPiA+ID4+IG9yaWdpbmFsDQo+ID4gPiA+PiA+PiBEQ1RDUA0KPiA+ID4gPj4gPj4+ PiBwcm90b2NvbCBkZXNpZ24gdGhhdCB1c2VkIG1vcmUgYWdncmVzc2l2ZSBFQ04tQ0UgbWFya2lu ZyB3YXMNCj4gPiA+IG9ubHkNCj4gPiA+ID4+IHNhZmUgZm9yDQo+ID4gPiA+PiA+Pj4+IENvbnRy b2xsZWQgRW52aXJvbm1lbnQgZGVwbG95bWVudHMuICAgU2VlIHRoZSBUU1ZXRw0KPiByZmM1NDA1 YmlzDQo+ID4gPiA+PiBkcmFmdCBmb3INCj4gPiA+ID4+ID4+IHRoZQ0KPiA+ID4gPj4gPj4+PiBk ZWZpbml0aW9uIG9mIENvbnRyb2xsZWQgRW52aXJvbm1lbnQsIGFuZCBpZ25vcmUgdGhlIGZhY3QN Cj4gdGhhdA0KPiA+ID4gdGhlDQo+ID4gPiA+PiByZmM1NDA1YmlzDQo+ID4gPiA+PiA+Pj4+IGRy YWZ0IGlzIGEgVURQIGRyYWZ0IC0gdGhpcyBkZWZpbml0aW9uIGlzIG1vcmUgYnJvYWRseQ0KPiA+ ID4gYXBwbGljYWJsZS4NCj4gPiA+ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4gR29pbmcgYmFjayBv dmVyIFNlY3Rpb24gNyBpbiB0aGlzIGF2dGNvcmUgZHJhZnQsIG15IHZpZXdzDQo+IGFyZToNCj4g PiA+ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4gW0FdIE5vbmUgb2YgdGhlc2UgZHJhZnRzIGp1c3Rp ZnkgYSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8NCj4gRUNOLQ0KPiA+ID4gQ0UNCj4gPiA+ID4+ IG1hcmtzOg0KPiA+ID4gPj4gPj4+PiAgIC0gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZl YmFja29mZi1lY24NCj4gPiA+ID4+ID4+Pj4gICAtIGRyYWZ0LWlldGYtcm1jYXQtbmFkYQ0KPiA+ ID4gPj4gPj4+PiAgIC0gZHJhZnQtaWV0Zi1ybWNhdC1zY3JlYW0tY2MNCj4gPiA+ID4+ID4+Pj4N Cj4gPiA+ID4+ID4+Pj4gW0JdIEluIGxpbmUgd2l0aCBDb2xpbidzIGNvbW1lbnQgb24gdGhlIEw0 UyBkcmFmdCwgSSB0aGluaw0KPiBpdCdzDQo+ID4gPiA+PiBpbmN1bWJlbnQgb24NCj4gPiA+ID4+ ID4+Pj4gdGhlIGF1dGhvcnMgb2YgZHJhZnQtYnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBm aWd1cmUgb3V0DQo+IGhvdw0KPiA+ID4gPj4gdGhhdCB3aWxsDQo+ID4gPiA+PiA+Pj4+IGNvZXhp c3QgKG9yIGF2b2lkKSBkZXBsb3llZCBUQ1AsIGFuZCB0aGlzIGF2dGNvcmUgZHJhZnQNCj4gb3Vn aHQNCj4gPiA+IG5vdA0KPiA+ID4gPj4gdG8gYmUNCj4gPiA+ID4+ID4+Pj4gdHJ5aW5nIHRvIHBy ZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KPiA+ID4gPj4gPj4+Pg0KPiA+ID4gPj4g Pj4+PiBTbywgSSBkb24ndCB0aGluayB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gNyBoYXMN Cj4ganVzdGlmaWVkDQo+ID4gPiB0aGUNCj4gPiA+ID4+IHVuZmV0dGVyZWQNCj4gPiA+ID4+ID4+ Pj4gImltcGxlbWVudGF0aW9ucyBNQVkgaWdub3JlIEVDTi1DRSBtYXJrcyIgdGV4dCwgYXMgaWdu b3JpbmcNCj4gPiA+IHRob3NlDQo+ID4gPiA+PiBtYXJrcw0KPiA+ID4gPj4gPj4+PiBpcyBub3Qg Y29uc2lzdGVudCB3aXRoIGFueSBvZiB0aGUgZm91ciBjaXRlZCBkcmFmdHMuDQo+ID4gPiA+PiA+ Pj4+DQo+ID4gPiA+PiA+Pj4+IEluIG1vcmUgZGV0YWlsLCBJIHRoaW5rIG1ha2luZyBjaGFuZ2Vz IHRvIG5vcm1hdGl2ZQ0KPiByZXF1aXJlbWVudHMNCj4gPiA+ID4+IGhlcmUgYmFzZWQNCj4gPiA+ ID4+ID4+Pj4gb24gW0JdIGlzIHByZW1hdHVyZSwgYW5kIEkgd291bGQgaG9wZSB0aGF0IHRoZSBy bWNhdCBXRw0KPiBjb3VsZCBiZQ0KPiA+ID4gPj4gPj4gZW5jb3VyYWdlZA0KPiA+ID4gPj4gPj4+ PiB0byBjb25zaWRlciB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBpbiBpdHMgY29uZ2VzdGlvbg0K PiBjb250cm9sDQo+ID4gPiA+PiBkcmFmdHMsIGFzIHRob3NlIENDDQo+ID4gPiA+PiA+Pj4+IG1l Y2hhbmlzbXMgYXJlIHJlbGF0ZWQgdG8gdGhlIGNpcmN1aXQgYnJlYWtlciBtZWNoYW5pc20sDQo+ IGhlbmNlDQo+ID4gPiA+PiBsaWtlbHkNCj4gPiA+ID4+ID4+Pj4gdG8gYmUgaW4gcmVsYXRlZCBh cmVhcyBvZiBhbiBSVFAgaW1wbGVtZW50YXRpb24uDQo+ID4gPiA+PiA+Pj4+DQo+ID4gPiA+PiA+ Pj4+IFRoYXQgbGVhdmVzIGRyYWZ0LWtoYWRlbWktdGNwbS1hbHRlcm5hdGl2ZWJhY2tvZmYtZWNu LCB3aGljaA0KPiA+ID4gVFNWV0cNCj4gPiA+ID4+ID4+Pj4gd2lsbCBiZSBsb29raW5nIGF0IGlu IEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudA0KPiBhYm91dA0KPiA+ID4gRUNOLQ0K PiA+ID4gPj4gQ0UgcmVhY3Rpb24NCj4gPiA+ID4+ID4+Pj4gaXMgZ29pbmcgdG8gcmVzdCBvbiB0 aGF0IGRyYWZ0LCB0aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdA0KPiBkcmFmdA0KPiA+ID4gPj4g c2hvdWxkIGJlDQo+ID4gPiA+PiA+Pj4+IG5vcm1hdGl2ZS4gIFNvbWV0aGluZyBhYm91dCBkb2lu ZyB0aGF0IHN0cmlrZXMgbWUgYXMNCj4gcHJlbWF0dXJlDQo+ID4gPiAuLi4NCj4gPiA+ID4+ID4+ Pj4NCj4gPiA+ID4+ID4+Pj4gSSByZWFsaXplIHRoYXQgd2UncmUgdHJ5aW5nIHRvIHByZWRpY3Qg YW5kIGFjY29tbW9kYXRlIHRoZQ0KPiA+ID4gZnV0dXJlLA0KPiA+ID4gPj4gd2hpY2gNCj4gPiA+ ID4+ID4+Pj4gaXMgYW4gaW1wcmVjaXNlIHVuZGVydGFraW5nIGF0IGJlc3QuICAgQXMgYW4gYWx0 ZXJuYXRpdmUgdG8NCj4gdGhlDQo+ID4gPiA+PiBjdXJyZW50IHRleHQsDQo+ID4gPiA+PiA+Pj4+ IHdvdWxkIGl0IGJlIHJlYXNvbmFibGUgdG8gc2F5ICh3aXRob3V0IGFueSBSRkMgMjExOQ0KPiBr ZXl3b3JkcykNCj4gPiA+IHRoYXQNCj4gPiA+ID4+IHRoZQ0KPiA+ID4gPj4gPj4+PiBiZXN0IGN1 cnJlbnQgZ3VpZGFuY2UgaXMgc3RpbGwgdG8gdHJlYXQgRUNOLUNFIG1hcmtzIGFzDQo+ID4gPiBp bmRpY2F0aW5nDQo+ID4gPiA+PiBkcm9wcywNCj4gPiA+ID4+ID4+Pj4gd2l0aCBhIHdhcm5pbmcg dGhhdCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkgb2YgdGhpcw0KPiBjaGFuZ2luZw0KPiA+ ID4gPj4gaW4NCj4gPiA+ID4+IHRoZQ0KPiA+ID4gPj4gPj4+PiBuZWFyIGZ1dHVyZSBkdWUgdG8g YWxsIG9mIHRoZSB3b3JrIGluIHByb2dyZXNzIGNpdGVkIGluDQo+IFNlY3Rpb24NCj4gPiA+IDc/ DQo+ID4gPiA+PiA+Pj4+DQo+ID4gPiA+PiA+Pj4+IFRoYW5rcywgLS1EYXZpZA0KPiA+ID4gPj4g Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+ ID4+Pj4+IEZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4g PiA+ID4+ID4+Pj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAxNiA2OjE0IEFNDQo+ID4gPiA+ PiA+Pj4+PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+ID4gPj4gPj4+Pj4gQ2M6 IHJ0Y3dlYkBpZXRmLm9yZzsgSUVURiBBVlRDb3JlIFdHOyB0c3Z3Zw0KPiA+ID4gPj4gPj4+Pj4g U3ViamVjdDogUmU6IFtydGN3ZWJdIFtBVlRDT1JFXSBbdHN2d2ddIFdHIExhc3QgQ2FsbCBvbg0K PiA+ID4gY2hhbmdlczoNCj4gPiA+ID4+IGRyYWZ0LWlldGYtDQo+ID4gPiA+PiA+Pj4+PiBhdnRj b3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2DQo+ID4gPiA+PiA+Pj4+Pg0KPiA+ID4gPj4gPj4+ Pj4NCj4gPiA+ID4+ID4+Pj4+PiBPbiAxNiBKdW4gMjAxNiwgYXQgMjM6MjUsIEpvaG4gTGVzbGll IDxqb2huQGpsYy5uZXQ+DQo+IHdyb3RlOg0KPiA+ID4gPj4gPj4+Pj4+DQo+ID4gPiA+PiA+Pj4+ Pj4gQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPiB3cm90ZToNCj4gPiA+ID4+ID4+ Pj4+Pj4NCj4gPiA+ID4+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBw cm92aWRpbmcgaW1wbGVtZW50ZXJzDQo+IHdpdGgNCj4gPiA+IHRvbw0KPiA+ID4gPj4gbXVjaA0K PiA+ID4gPj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIChlLmcuLCBi ZWNhdXNlIGFuDQo+IGltcGxlbWVudGVyDQo+ID4gPiA+PiBkb2Vzbid0DQo+ID4gPiA+PiA+Pj4+ Pj4+IHdhbnQgdG8gdGhpbmsgYWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJzdA0K PiBwbGFjZSkuDQo+ID4gPiA+PiA+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0IHRo ZSBhcmd1bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bA0KPiB0aGFuDQo+ID4g PiA+PiBkZXBsb3lpbmcgYQ0KPiA+ID4gPj4gPj4gY2lyY3VpdA0KPiA+ID4gPj4gPj4+Pj4gYnJl YWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2VkLg0KPiA+ID4gPj4g Pj4+Pj4NCj4gPiA+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMg YXJndW1lbnQsIHRob3VnaCwgc2luY2UgaXQNCj4gc2VlbXMNCj4gPiA+ID4+IHRoYXQNCj4gPiA+ ID4+IGFueSBuZXcNCj4gPiA+ID4+ID4+IEFRTQ0KPiA+ID4gPj4gPj4+Pj4gdGhhdCBhcHBsaWVz IEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gPiA+IGhh dmUNCj4gPiA+ID4+IHRvDQo+ID4gPiA+PiA+PiBjb25zaWRlcg0KPiA+ID4gPj4gPj4+Pj4gYmFj a3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdvcmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sDQo+ ID4gPiBkcmFmdC0NCj4gPiA+ID4+IGJyaXNjb2UtDQo+ID4gPiA+PiA+PiB0c3Z3Zy0NCj4gPiA+ ID4+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEgc2ln bmFsIHRvIHVzZQ0KPiB0aGUNCj4gPiA+IG5ldw0KPiA+ID4gPj4gbWFya2luZywNCj4gPiA+ID4+ ID4+Pj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UN Cj4gY29tcGF0aWJpbGl0eQ0KPiA+ID4gPj4gbWVjaGFuaXNtcw0KPiA+ID4gPj4gPj4+Pj4gd291 bGQgc2VlbSB0byBwcmV2ZW50IHRoZSBpc3N1ZXMgd2l0aCB0aGUgY2lyY3VpdCBicmVha2VyDQo+ IHRvby4NCj4gPiA+ID4+ID4+Pj4+DQo+ID4gPiA+PiA+Pj4+Pj4gVW5kZXJzdGFuZCwgd2UgaGF2 ZSBhdCBsZWFzdCB0d28gcHJvcG9zYWxzIHRvIG1ha2UgRUNOLUNFDQo+IG1vcmUNCj4gPiA+ID4+ ID4+IGZyZXF1ZW50DQo+ID4gPiA+PiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3VsZCBiZSBm b3Igbm9uLUVDTiBwYWNrZXRzOiBwb3NzaWJseQ0KPiA+ID4gPj4gc3Vic3RhbnRpYWxseQ0KPiA+ ID4gPj4gPj4+Pj4+IG1vcmUgZnJlcXVlbnQuIFVubGVzcyBib3RoIGFyZSBraWxsZWQgb2ZmLCBF Q04tQ0Ugd2lsbA0KPiBzaG93IHVwDQo+ID4gPiA+PiBmcmVxdWVudGx5DQo+ID4gPiA+PiA+Pj4+ Pj4gZW5vdWdoIHRoYXQgY2xvc2luZyB0aGUgZmxvdyBvbiBFQ04tQ0Ugd291bGQga2lsbCB0b28g bWFueQ0KPiA+ID4gPj4gY29ubmVjdGlvbnMuDQo+ID4gPiA+PiA+Pj4+Pj4NCj4gPiA+ID4+ID4+ Pj4+PiBJZiB5b3Ugd2FudCBjaXJjdWl0LWJyZWFraW5nIG9uIHN1Y2ggY29ubmVjdGlvbnMsIHRo ZXJlDQo+IGFyZQ0KPiA+ID4gdHdvDQo+ID4gPiA+PiB3YXlzOg0KPiA+ID4gPj4gPj4+Pj4+IDEu IGNvbnZpbmNlIHRoZSBmb3J3YXJkaW5nIG5vZGVzIHRvIGRyb3AgcGFja2V0cyBpZiB0aGVpcg0K PiA+ID4gcXVldWUNCj4gPiA+ID4+IGV4Y2VlZHMNCj4gPiA+ID4+ID4+Pj4+PiBkZXNpZ24gY2Fw YWNpdHk7IG9yDQo+ID4gPiA+PiA+Pj4+Pj4gMi4gcmVxdWlyZSB0aGUgc2VuZGVyIHRvIHNlbmQg ZW5vdWdoIG5vdC1FQ04tY2FwYWJsZQ0KPiBwYWNrZXRzDQo+ID4gPiBzbw0KPiA+ID4gPj4gdGhh dCBvdXINCj4gPiA+ID4+ID4+Pj4+PiByZWNlaXZlciB3aWxsIHNlZSBlbm91Z2ggcGFja2V0LWRy b3BzIHdoZW4gYSBjaXJjdWl0LQ0KPiBicmVha2VyDQo+ID4gPiA+PiBzaG91bGQNCj4gPiA+ID4+ ID4+Pj4+PiBhY3RpdmF0ZS4NCj4gPiA+ID4+ID4+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4+IChJIHBy ZWZlciB0aGUgZmlyc3Qgb3B0aW9uOyBidXQgSSB3b3VsZG4ndCBvYmplY3QgdG8gdGhlDQo+ID4g PiA+PiBzZWNvbmQuKQ0KPiA+ID4gPj4gPj4+Pj4+DQo+ID4gPiA+PiA+Pj4+Pj4gVGhlcmUgcmVh bGx5IGlzbid0IGFueSB3YXkgZm9yIG91ciBjaXJjdWl0LWJyZWFrZXIgdG8ga25vdw0KPiA+ID4g Pj4gX2hvd19tdWNoXw0KPiA+ID4gPj4gPj4+Pj4+IG1vcmUgZnJlcXVlbnQgdGhlIEVDTi1DRSBt YXJrcyBtYXkgYmUuIDpeKA0KPiA+ID4gPj4gPj4+Pj4NCj4gPiA+ID4+ID4+Pj4+IFRoaXMgaXMg YSBwcm9ibGVtLCBib3RoIGZvciB0aGUgY2lyY3VpdCBicmVha2VyLCBhbmQgZm9yDQo+IHRoZQ0K PiA+ID4gPj4gYWxnb3JpdGhtcyBiZWluZw0KPiA+ID4gPj4gPj4+Pj4gZGVmaW5lZCBpbiBSTUNB VC4gV2UgZG8gbmVlZCBzb21lIHVuZGVyc3RhbmRpbmcgd2hhdCB0aGUNCj4gPiA+IGV4cGVjdGVk DQo+ID4gPiA+PiA+PiBtYXJraW5nDQo+ID4gPiA+PiA+Pj4+PiByYXRlcyBhcmUgbGlrZWx5IHRv IGJlLCBzbyBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIGNpcmN1aXQNCj4gPiA+ID4+IGJyZWFrZXJz DQo+ID4gPiA+PiBjYW4gYmUNCj4gPiA+ID4+ID4+IGRlZmluZWQuDQo+ID4gPiA+PiA+Pj4+Pg0K PiA+ID4gPj4gPj4+Pj4+IFdlIF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+ID4gPj4gPj4+Pj4+ IGFsbG90IHRoZSBzYW1lIGZyZXF1ZW5jeSBvZiBDRSBwYWNrZXRzIGFzIHBhY2tldC1kcm9wcyB0 bw0KPiA+ID4gPj4gdHJpZ2dlcg0KPiA+ID4gPj4gdGhlDQo+ID4gPiA+PiA+Pj4+Pj4gY2lyY3Vp dC1icmVha2VyLg0KPiA+ID4gPj4gPj4+Pj4+DQo+ID4gPiA+PiA+Pj4+Pj4+IENvdWxkIHNvbWVv bmUgcHJvcG9zZSBpbml0aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZQ0KPiBjdXJyZW50DQo+ID4g PiA+PiAiTUFZDQo+ID4gPiA+PiBpZ25vcmUiDQo+ID4gPiA+PiA+Pj4+Pj4+IHN0YXRlbWVudD8N Cj4gPiA+ID4+ID4+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4+IEVzc2VudGlhbGx5LCBmb3IgdGhlIHNl Y29uZCBvcHRpb24sIHlvdSBtaWdodCBwcm9wb3NlIHRleHQNCj4gdG8NCj4gPiA+ID4+IHRoZQ0K PiA+ID4gPj4gPj4+Pj4+IGVmZmVjdCBvZjoNCj4gPiA+ID4+ID4+Pj4+PiBdDQo+ID4gPiA+PiA+ Pj4+Pj4gXSBJZiB0b28gbWFueSBFQ04tQ0UgcGFja2V0cyBhcmUgcmVjZWl2ZWQsIHRoZSBzZW5k ZXINCj4gU0hPVUxEDQo+ID4gPiA+PiBzZW5kDQo+ID4gPiA+PiBzb21lDQo+ID4gPiA+PiA+Pj4+ Pj4gXSBub3QtRUNOLWNhcGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUgd2hldGhlciBlbm91Z2gN Cj4gcGFja2V0cw0KPiA+ID4gPj4gYWxvbmcgdGhlDQo+ID4gPiA+PiA+Pj4+Pj4gXSBwYXRoIGFy ZSBiZWluZyBkcm9wcGVkIHRvIGp1c3RpZnkgYWN0aXZhdGluZyBvdXINCj4gY2lyY3VpdC0NCj4g PiA+ID4+IGJyZWFrZXIuDQo+ID4gPiA+PiA+Pj4+Pj4NCj4gPiA+ID4+ID4+Pj4+PiBJw6Ligqzi hKJtIG5vdCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3VsZA0KPiBy ZXNvbHZlDQo+ID4gPiA+PiB0aGUNCj4gPiA+ID4+IGlzc3VlLg0KPiA+ID4gPj4gPj4+Pj4NCj4g PiA+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IGNvbnZpbmNlZCB0aGlzIHdvdWxkIHdvcmsuIFRo ZSBjaXJjdWl0IGJyZWFrZXIgaXMNCj4gPiA+ID4+IGxvb2tpbmcNCj4gPiA+ID4+IGF0IGxvbmcg dGVybQ0KPiA+ID4gPj4gPj4+Pj4gdHJlbmRzLCBhbmQgaW4gb3JkZXIgdG8gaGF2ZSBlbm91Z2gg bm90LUVDVCBwYWNrZXRzIHRvDQo+ID4gPiBkZXRlcm1pbmUNCj4gPiA+ID4+IGlmIGl0DQo+ID4g PiA+PiA+PiBzaG91bGQNCj4gPiA+ID4+ID4+Pj4+IHRyaWdnZXIsIHlvdcOi4oKs4oSiZCBlc3Nl bnRpYWxseSBoYXZlIHRvIHJ1biB3aXRob3V0IEVDTiBmb3INCj4gc29tZQ0KPiA+ID4gPj4gc2Vj b25kcy4NCj4gPiA+ID4+ID4+Pj4+DQo+ID4gPiA+PiA+Pj4+PiAtLQ0KPiA+ID4gPj4gPj4+Pj4g Q29saW4gUGVya2lucw0KPiA+ID4gPj4gPj4+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiA+ ID4gPj4gPj4+Pg0KPiA+ID4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPj4gPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4g PiA+PiA+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+ID4gPj4gPj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+ID4gPj4gPg0KPiA+ID4gPg0KPiA+ID4g Pg0KDQo= From nobody Thu Jun 30 09:28:34 2016 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 0FD9412D16D; Thu, 30 Jun 2016 09:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 v9FLU2j5cM5w; Thu, 30 Jun 2016 09:28:22 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 D306512D113; Thu, 30 Jun 2016 09:28:21 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bIep8-0005uh-1O; Thu, 30 Jun 2016 18:28:18 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bIep7-0007mS-8a; Thu, 30 Jun 2016 18:28:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Thu, 30 Jun 2016 18:28:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> To: "De Schepper, Koen (Nokia - BE)" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 10 sum msgs/h 4 total rcpts 43919 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5AE02707A5F73F64E8158E2EEAD77F4720030D04 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1481 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:28:25 -0000 Hi, > On 30. jun. 2016, at 17.58, De Schepper, Koen (Nokia - BE) = wrote: >=20 >=20 >> -----Original Message----- >> From: Black, David [mailto:david.black@emc.com] >> Sent: maandag 27 juni 2016 22:10 >> To: De Schepper, Koen (Nokia - BE) >> Cc: tsvwg; IETF AVTCore WG; rtcweb@ietf.org; Black, David >> Subject: RE: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: = draft- >> ietf-avtcore-rtp-circuit-breakers-16 >>=20 >>> As long as an AQM is marking at the same rate as dropping >>=20 >> That's an interesting assumption - it should be true for AQMs vetted >> here in the past, >=20 > And I hope for ect(0) the network will keep doing this in the future, = at=20 > least not to deviate too far from this. > L4S proposes to use ect(1) just because it deviates too much, so the = network=20 > can detect the different end-system behavior and can couple it = correctly to=20 > what it is doing for drop and ect(0). >=20 >=20 >> but there are easy ways for it not to hold (e.g., if >> dropping >> or marking is based on queue occupancy, it is possible that dropping >> reduces queue occupancy in a fashion that marking does not). >=20 > Do you mean that this results in different mark and drop probabilities=20= > for competing ECN and non-ECN flows? >=20 > The impact on the dropping/marking probability *value* applied by an = AQM can change=20 > due to presence of ECN flows, but I don't think this results in a = different=20 > drop compared to mark probability. Up to now all classic AQMs smooth = their p=20 > over sufficient long time to remove short fluctuations in queue sizes.=20= >=20 > =46rom an end system I think for classic ECN it is safe to assume that = if you=20 > detect high levels of drop, it means there is a high level of=20 > congestion AND the network takes care of it. If you detect a high = level > of marking, it means lots of congestion and nobody is currently taking = care=20 > of it. Everybody is looking at you as a sender to take care of it. = That's why > I think you should not use ECN if you don't use congestion control. >=20 > It also means that the competing drop flows are having a high level of = matching > drop. That's why I think a classic circuit breaker should also treat = drop and=20 > classic marking similar. >=20 > I understood ABE tries to modify the end system behavior slightly for = ECN. If=20 > this can be done safely with benefits that outweighs the = disadvantages,=20 > than that's no problem, but I think nobody is in favor to modify the = AQM=20 > behavior to ect(0). I pretty much agree with everything here=E2=80=A6 > Based on DualQ compatibility experiments with classic ECN, I also = believe=20 > that, if we want to further promote classic ECN too, we need some = extra=20 > safety measures for classic AQMs using ECN to avoid high CE marking = levels,=20 > where ect(0) flows start to push away too much the non-ect flows. For=20= > instance PIE has (for good reasons) a max of 10% marking, and then = switches=20 > to drop. As far as I know such measures are not mandatory in other = ECN/AQM=20 > related drafts, is it? =E2=80=A6 but here I=E2=80=99d like to put a note of warning: see the = appendix here: http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf here, we found that this behavior is detrimental (the 10% threshold was = too small). =3D> I agree with the general notion of such a threshold, but the = threshold shouldn=E2=80=99t be too low (it can eliminate ECN=E2=80=99s = benefits). Cheers, Michael