From nobody Thu Jun 2 03:11:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DDE12D6CC for ; Thu, 2 Jun 2016 03:11:39 -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 uJbcwaETsLMv for ; Thu, 2 Jun 2016 03:11:37 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F1E9512D6C8 for ; Thu, 2 Jun 2016 03:11:36 -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 9B7BD1A0B37; Thu, 2 Jun 2016 12:11:35 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ED294A14-E424-4315-AEBB-FDD776295338"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 2 Jun 2016 12:11:34 +0200 Message-Id: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 10:11:39 -0000 --Apple-Mail=_ED294A14-E424-4315-AEBB-FDD776295338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Mark, Thanks for raising this. Seeing no reply... I've taken a look at 5405-bis with this question in mind. While it = *really* isn't written with the idea of using UDP as a substrate for a = transport protocol, one can read it replacing "application" with = "transport". So my answer to (a) is yes. Since an application using UDP is really an application that has decided = to take the responsibilities of the transport layer into its own hands, = 5405bis can also be seen as a set of guidelines for building = Internet-deployable transport protocols written with application = developers in mind. IMO, looking at the current state of the charter and = the current draft protocol, QUIC seems already to meet the applicable = guidelines, with the exception of the following in Section 3: " ...the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol..." which is kind of circular in QUIC's case, and I'm sure not the intent of = the document (on which see a late last-call comment, to be posted = shortly...) Cheers, Brian > On 31 May 2016, at 04:54, Mark Nottingham wrote: >=20 > Apologies if I missed discussion about this. >=20 > If this is to be a BCP, is it safe to assume that a) it will apply to = QUIC if chartered, and b) that folks here are comfortable with its = requirements? >=20 > Cheers, >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: The IESG >> Subject: Last Call: (UDP Usage = Guidelines) to Best Current Practice >> Date: 18 May 2016 at 10:17:06 AM AEST >> To: "IETF-Announce" >> Cc: draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, = tsvwg@ietf.org >> Reply-To: ietf@ietf.org >> Archived-At: = >>=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 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_ED294A14-E424-4315-AEBB-FDD776295338 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 iQIcBAEBCgAGBQJXUAZXAAoJEIoSt78L6kajBFUP/2+c4aS4gx/MHFE0TP1rd7n6 c9UR4SKVVi+lmqioIzLlJ0K1wQHggGZvbWxz9uoOrTcWteuebwViejUYUFy0/0/x mH3GiSngL55NzSPo/mYJfI47bOHNuUyLtP7JUnad9oQtxK9+Itd+7niHBJcq1dvp rFpXnzK32lOB7H9N/1ROqJ3IwjOr79cpU80AisrY//vauHM9anL2VQzBvGHplGYd t7sqX8axqt4E/Koj5De1pvnH9hryB2X4GXdvYnvA01YjgZ2AC4C+mDbiYFkYtNj2 S4E1jguJBVlyadb1PXDSTbCOLlEzSsJTUmkX5NuUwTiCtxH+avGSqOiXBHi0WCvD hzDSQ1+llaMDPGKkKyJvabn6Tm6DDHF2nNmA6kRhwVFgubQ6reHi3Cm0jUnWzhH5 7OeEfzRu9pTNIcqY8fK9fZU72drq6Ug63t++czs+C8EBZ0VhkrAob9eauTmx1Jjg gMSp2l7RuABuR7WZcWkQ1EOjnZdli18U3QhJrUhxBYPkHV0hCR/avQ6DoGon8vP1 jisJxal54VDbJHnzu4BpuW7jF1nPDUXJRbJkeKbMkqXsy0WEibAROx1bPk6HmKpd fvh2jeL0AxCjUIpGJl3bk9UI8SJZ4B/9T9p9jOb6sNlAAeRq+GylYLQcJ8JMNdG3 UUcc+a4jQjWKX81+eSTU =AaKH -----END PGP SIGNATURE----- --Apple-Mail=_ED294A14-E424-4315-AEBB-FDD776295338-- From nobody Thu Jun 2 03:12:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@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: [QUIC] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization 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 Fri Jun 3 08:17:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@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: X-Mailman-Approved-At: Fri, 03 Jun 2016 08:17:30 -0700 Cc: tsvwg WG , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , "quic@ietf.org" , "ietf@ietf.org" Subject: Re: [QUIC] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization 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:29:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@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: X-Mailman-Approved-At: Fri, 03 Jun 2016 08:29:17 -0700 Cc: "ietf@ietf.org" , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Brian Trammell , "quic@ietf.org" , tsvwg WG Subject: Re: [QUIC] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Mailing list to discuss QUIC standardization 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 10:09:12 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B79412D579 for ; Fri, 3 Jun 2016 10:09:10 -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 eAKKtPq7n1Bs for ; Fri, 3 Jun 2016 10:09:09 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE58E12D542 for ; Fri, 3 Jun 2016 10:09:08 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id e72so136593433oib.1 for ; Fri, 03 Jun 2016 10:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=B+J28FW6eo4RV93TccYlXjlFQAz64j9Dtt51rrM3+8I=; b=Lw3jCfM3TZ/Epgwmw/cPG22T+y40aG8as3M2ixhox4KFSzRIKtLeYzdYCBpG+5idBp U+vHPNY0xffEq4u7MfgpjD1h3xa6ScNt1XrSDkYNyhBNq7ZhsiHUKIG0l0EMwfroF0z3 i33G8F5yRyY+ePmuYV/0kxaSqCk2OEk7fuRdDDYwy6bj957Y/uIrd1+p/QYHHBjXlC45 TGSV2138TEkLywKUJIDj9pV6APLL75Po7DwlBSIifrOMJEQiig5/9pqcoP/PbWc27v0N kHheHMHam6DZtmMsE7ELwv6kiOyW+dfj+lIg5QI1Jbcb4aE4mGld10u5MC8HhIDR6o6j K/rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=B+J28FW6eo4RV93TccYlXjlFQAz64j9Dtt51rrM3+8I=; b=X6br8R0C+Bs/fbMdjn43A/LR7LtrFiGTVUfJWTNNBrOSRSzZSnKHVuYvydu1tL8Vmp d3KYUhI94Nl4hGkowjkd/NKFmd7XGlryRfXzE9t3fdNVgsaeil9QJs5QgIAg2C3GR9L0 oL/7gX61bOWIdB4m3yj0OoGVt3IdMo02xKKwt8uJ5Hnu1cKcb5f3N+ICqmvnVzatyL1Q w6gfoHgmMZLOuvowJLrNxsOTMOFERl6pK9ZyLfS3Rf/Eh4oFCCnXRRHI1L10P5imeAAv 01+42RUg2TTfvJxZHLRjPZzouCanLU+GDQQ9OBOZK/3xl9W9ennsXIkm+57Z0Azrs5Uo Mh1A== X-Gm-Message-State: ALyK8tK1lz8zOVnCO0P3uzOs/QqR4Yf4HJ6Sm/sG9va3CghUq9YsEjKiYVwFljPNivdRi56m7PFOL+KlC7/DVA== X-Received: by 10.157.58.68 with SMTP id j62mr2618885otc.118.1464973748191; Fri, 03 Jun 2016 10:09:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.195.137 with HTTP; Fri, 3 Jun 2016 10:08:48 -0700 (PDT) From: Ted Hardie Date: Fri, 3 Jun 2016 10:08:48 -0700 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114929e6ddcca6053462c7cc Archived-At: Subject: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:09:10 -0000 --001a114929e6ddcca6053462c7cc Content-Type: text/plain; charset=UTF-8 Howdy, The ADs asked the proponents a questions about the values of N associated with the various places in the charter where we have a chartering + N line in the milestones. Here's a strawman set of values; comments on whether it is the right order are probably stage one. They are a bit aggressive, but then we're an optimistic bunch around here, right? Ted ## Milestones * Chartering + 3 Months: Working group adoption of Core Protocol document * Chartering + 3 Months: Working group adoption of Loss detection and Congestion Control document * Chartering + 3 Months: Working group adoption of TLS 1.3 mapping document * Chartering + 6 Months: Working group adoption of HTTP/2 mapping document * Chartering + 6 Months: Working group adoption of Multipath extension document * Chartering + 12 Months: Core Protocol document to IESG * Chartering + 12 Months: Loss detection and Congestion Control document to IESG * Chartering + 12 Months: TLS 1.3 Mapping document to IESG * Chartering + 18 Months: HTTP/2 mapping document to IESG * Chartering + 18 Months: Multipath extension document to IESG * Rechartering + 3 Months: Working group adoption of FEC extension document * Rechartering + 12 Months: FEC extension document to IESG --001a114929e6ddcca6053462c7cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

The ADs asked the proponents= a questions about the values of N associated with the various places in th= e charter where we have a chartering + N line in the milestones.=C2=A0 Here= 's a strawman set of values; comments on whether it is the right order = are probably stage one.=C2=A0 They are a bit aggressive, but then we're= an optimistic bunch around here, right?

Ted

## Milesto= nes

* Chartering + 3 Months: Working group adoption of Core Protocol= document
* Chartering + 3 Months: Working group adoption of Loss detect= ion and Congestion Control document
* Chartering + 3 Months: Working gro= up adoption of TLS 1.3 mapping document
* Chartering + 6 Months: Working= group adoption of HTTP/2 mapping document
* Chartering + 6 Months: Work= ing group adoption of Multipath extension document
* Chartering + 12 Mon= ths: Core Protocol document to IESG
* Chartering + 12 Months: Loss detec= tion and Congestion Control document to IESG
* Chartering + 12 Months: T= LS 1.3 Mapping document to IESG
* Chartering + 18 Months: HTTP/2 mapping= document to IESG
* Chartering + 18 Months: Multipath extension document= to IESG
* Rechartering + 3 Months: Working group adoption of FEC extens= ion document
* Rechartering + 12 Months: FEC extension document to IESG<= br>
--001a114929e6ddcca6053462c7cc-- From nobody Fri Jun 3 10:56:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49E312D793 for ; Fri, 3 Jun 2016 10:56:00 -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 R6ONN4M93tDI for ; Fri, 3 Jun 2016 10:55:59 -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 D649212D0A7 for ; Fri, 3 Jun 2016 10:55:58 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-47-5751c4ad98aa Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.47.12926.DA4C1575; Fri, 3 Jun 2016 19:55:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 19:55:56 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Ted Hardie , "quic@ietf.org" Thread-Topic: [QUIC] Charter dates Thread-Index: AQHRvbqnsCgxosvZnE+SI63MeLPRl5/YBuKA Date: Fri, 3 Jun 2016 17:55:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7ou7aI4HhBn13BSx6FnBbNM61c2Dy 2DnrLrvHkiU/mQKYorhsUlJzMstSi/TtErgy2jt+MBbM4qg4dGcJUwPjGbYuRk4OCQETie5v 31kgbDGJC/fWA8W5OIQEjjBKXLt9ggnCWcwocWdDMytIFZuAt8S0FWfBbBEBF4kp8/4B2Rwc wgKKEvf3e0OElSQ2bbjBCGEbSfy/voMRpIRFQEVi6RUhkDCvgLXEpd61YCVCAgESWz5PALuB UyBQYtHkR2A2o4CsxP3v98BsZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/YNeICuhJfLk3jxEi riSxYvslRohePYkbU6ewgZzADLT3xoEIiLC2xLKFr5khzhGUODnzCcsERvFZSLbNQtI9C6F7 FpLuWUi6FzCyrmIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjLKDW36r7mC8/MbxEKMAB6MS D2/CmoBwIdbEsuLK3EOMEhzMSiK887YHhgvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4k kJ5YkpqdmlqQWgSTZeLglGpgNH/x7+yGA6K/j9bP3nOyfO/0VkaBslUTJfnW2s9miPrKWb9q 3aEwsa9CH/amHefrfnBblHPetdpcZynx3L2rX/hvvWy0QTShgXGDn5/cE/OTh5VaWg+2bGEN aVb+9W0O261jzxbelXKTNjY7I/O+4YuPedrdvMP3L0/01kzNZ828e23dcp7O/UosxRmJhlrM RcWJAPhCQG+uAgAA Archived-At: Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:56:00 -0000 > > >Ted > >## Milestones > >* Chartering + 3 Months: Working group adoption of Core Protocol document >* Chartering + 3 Months: Working group adoption of Loss detection and >Congestion Control document >* Chartering + 3 Months: Working group adoption of TLS 1.3 mapping >document >* Chartering + 6 Months: Working group adoption of HTTP/2 mapping document >* Chartering + 6 Months: Working group adoption of Multipath extension >document Hi ted, Which document addresses HTTP/2 mapping on Multipath? or is that out-of-scope? Regards G=F6ran >* Chartering + 12 Months: Core Protocol document to IESG >* Chartering + 12 Months: Loss detection and Congestion Control document >to IESG >* Chartering + 12 Months: TLS 1.3 Mapping document to IESG >* Chartering + 18 Months: HTTP/2 mapping document to IESG >* Chartering + 18 Months: Multipath extension document to IESG >* Rechartering + 3 Months: Working group adoption of FEC extension >document >* Rechartering + 12 Months: FEC extension document to IESG > > From nobody Fri Jun 3 13:26:54 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37212D986 for ; Fri, 3 Jun 2016 13:26:51 -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 RneOa4w9IehD for ; Fri, 3 Jun 2016 13:26:49 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A2A12D983 for ; Fri, 3 Jun 2016 13:26:49 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id e72so144528468oib.1 for ; Fri, 03 Jun 2016 13:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uv01cWFVkr8WJnh0y+h9LF4WgLvodoH1wui/6I2t/ig=; b=TxUQbyjtyS5Zs6aLs/usc5tbUyic2+q2/l4anGhxZD2hB3tVP8ydFmOR8Z1ZxQ7IVd i6bnXqYDrdBSi2Ysb9m4W0n56sej9ZNl8LrqQ1XFCP5eEQsj/8259RXbEjI9O5v/+iq2 DWh9fkonS28nSAhrsKEeq2BpomSm1252kxWgNmj+IhD9lpScbDRBkRI4I1HGUQYCoaog nhxoLonz/NiBKJcRN/tStpeVTa4mWo985EyODmXPjKCTz2q/w0bxKyZRRa5Rz4xwJ6Ek J8sX3FDsycYr7t+u8hnSB1etpZAD2x4OmGvncDKmJdRTgraZY6ATRga+kjYc/FEKAoif jTwQ== 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=uv01cWFVkr8WJnh0y+h9LF4WgLvodoH1wui/6I2t/ig=; b=YmUGznTNPtDL7Loql+kxdg0S3hGGwltHPpwPqCZcqNwIkTfLPJfKvQVM7fMHV0yOo5 VZYYla3SSCqHHYLGTGiLVAycpy7gB6nXdlChQlEWeUK4zX4JHLZtYbNhBInvhvRF0Owx GQnvD94a5MFjpXJox3o4gTFyVQJ7vCMlcFXSL2zwiw+31ZQ+YPMgBT6161nI9M7kFUmo t2B2UxEx+Xr2jSo6PZc81vixzI6xJ3J9liix0KGBot0meD83u8CPSuXZloIgGLhh5lVl IDReJ5otGUnyBFM3v2Qxz4C1xg1poBzbKhwVKUqecpVeveWlAPk+/zwZ3zB9yhZznGvu 6yNw== X-Gm-Message-State: ALyK8tJIBvahoKaX/lkb2dPDcrRYxrHmo6DTwikTm4YbrkzLj94b256Zq+CFowlwBeRPdXMmu1DiHSYLxspF0Q== X-Received: by 10.157.61.197 with SMTP id l63mr3244448otc.48.1464985608907; Fri, 03 Jun 2016 13:26:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.195.137 with HTTP; Fri, 3 Jun 2016 13:26:29 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Fri, 3 Jun 2016 13:26:29 -0700 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= Content-Type: multipart/alternative; boundary=001a1149299cd20c060534658a64 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 20:26:51 -0000 --001a1149299cd20c060534658a64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi G=C3=B6ran, On Fri, Jun 3, 2016 at 10:55 AM, G=C3=B6ran Eriksson AP < goran.ap.eriksson@ericsson.com> wrote: > > > > > > >Ted > > > >## Milestones > > > >* Chartering + 3 Months: Working group adoption of Core Protocol documen= t > >* Chartering + 3 Months: Working group adoption of Loss detection and > >Congestion Control document > >* Chartering + 3 Months: Working group adoption of TLS 1.3 mapping > >document > >* Chartering + 6 Months: Working group adoption of HTTP/2 mapping docume= nt > >* Chartering + 6 Months: Working group adoption of Multipath extension > >document > > Hi ted, > > Which document addresses HTTP/2 mapping on Multipath? or is that > out-of-scope? > > I think that it is in scope, since we want a demonstration that the multipath extension was useful. The reliability/mobility aspects of multipath I would expect to be covered in the extensions document. If there were load-sharing optimizations that related to a specific application, I would expect them to be the application's mapping doc. I could see adding a third doc, if the considerations got particularly large, but I don't see a reason for that at the moment. That's just my take on it, by the way, and if you have a different split in mind, please feel free to bring it forward, regards, Ted > Regards > G=C3=B6ran > > >* Chartering + 12 Months: Core Protocol document to IESG > >* Chartering + 12 Months: Loss detection and Congestion Control document > >to IESG > >* Chartering + 12 Months: TLS 1.3 Mapping document to IESG > >* Chartering + 18 Months: HTTP/2 mapping document to IESG > >* Chartering + 18 Months: Multipath extension document to IESG > >* Rechartering + 3 Months: Working group adoption of FEC extension > >document > >* Rechartering + 12 Months: FEC extension document to IESG > > > > > > --001a1149299cd20c060534658a64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi G=C3=B6ran,

On Fri, Jun 3, = 2016 at 10:55 AM, G=C3=B6ran Eriksson AP <goran.ap.eriksson@e= ricsson.com> wrote:
>

>
>Ted
>
>## Milestones
>
>* Chartering + 3 Months: Working group adoption of Core Protocol docume= nt
>* Chartering + 3 Months: Working group adoption of Loss detection and >Congestion Control document
>* Chartering + 3 Months: Working group adoption of TLS 1.3 mapping
>document
>* Chartering + 6 Months: Working group adoption of HTTP/2 mapping docum= ent
>* Chartering + 6 Months: Working group adoption of Multipath extension<= br> >document

Hi ted,

Which document addresses HTTP/2 mapping on Multipath? or is that
out-of-scope?

I think that it is in scope, since we want a demonstr= ation that the multipath extension was useful. The reliability/mobility asp= ects of multipath I would expect to be covered in the extensions document.= =C2=A0 If there were load-sharing optimizations that related to a specific = application, I would expect them to be the application's mapping doc.= =C2=A0 I could see adding a third doc, if the considerations got particular= ly large, but I don't see a reason for that at the moment.

That's just my take on it, by the way, and if you have a differen= t split in mind, please feel free to bring it forward,

re= gards,

Ted

=C2=A0
Regards
G=C3=B6ran

>* Chartering + 12 Months: Core Protocol document to IESG
>* Chartering + 12 Months: Loss detection and Congestion Control documen= t
>to IESG
>* Chartering + 12 Months: TLS 1.3 Mapping document to IESG
>* Chartering + 18 Months: HTTP/2 mapping document to IESG
>* Chartering + 18 Months: Multipath extension document to IESG
>* Rechartering + 3 Months: Working group adoption of FEC extension
>document
>* Rechartering + 12 Months: FEC extension document to IESG
>
>


--001a1149299cd20c060534658a64-- From nobody Fri Jun 3 14:16:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAB112D9CE for ; Fri, 3 Jun 2016 14:16:31 -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 c83eW_cENT-L for ; Fri, 3 Jun 2016 14:16:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D1612D9BC for ; Fri, 3 Jun 2016 14:16:29 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-3d-5751f3aa8fda Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 17.1E.12516.AA3F1575; Fri, 3 Jun 2016 23:16:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 23:16:25 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Ted Hardie Thread-Topic: [QUIC] Charter dates Thread-Index: AQHRvbqnsCgxosvZnE+SI63MeLPRl5/YBuKAgAAIjICAAC94gA== Date: Fri, 3 Jun 2016 21:16:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <02843C2741C03D49AAC7B4F3A199784F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7ge6qz4HhBvcuyFj0LOC2aJxr58Dk sXPWXXaPJUt+MgUwRXHZpKTmZJalFunbJXBlnNx+ka3ghFDF3+kf2RoY7/F1MXJySAiYSEx9 cpUFwhaTuHBvPVsXIxeHkMARRontu48yQjiLGSW2LmlkBKliE/CWmLbiLCuILSKgLLH3yg42 EJsZyJ5yugEozsEhLKAocX+/N0SJksSmDTcYIWwnic1vfoKVswioSBy784sJxOYVsJb4eP4k C8Suk4wSF9d+BZvPKRAo8eLQVrAiRgFZifvf77FA7BKXuPVkPhPE1QISS/acZ4awRSVePv4H 1isqoCfx5d48Roi4ksSi25+ZIHr1JG5MnQJ1s7XE52fNUDO1JZYtfM0McZCgxMmZT1gmMErM QrJuFpL2WUjaZyFpn4WkfQEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwCg8uOW37g7G 1a8dDzEKcDAq8fAmrAkIF2JNLCuuzD3EKMHBrCTCm/I6MFyINyWxsiq1KD++qDQntfgQozQH i5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDI6eL1eeZFkfVNHa0BJ6Oib2+SnxW232xuUzZ B469vO196/vqDI9Y9n9Shye84zx6e6KDFeMVNZ8wF/agH1E3Fjz/LnxNeALH5DeP7STV5Ms3 x3x9fLEixCLz56Opr7I5Hudzbt+zMM5daT7722sbL1sq/4jLti7hn1A2cV+v3KtDxeryGeuP flRiKc5INNRiLipOBAB7IruGvgIAAA== Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 21:16:32 -0000 Hi Ted, Inlne regards G=F6ran On 03/06/16 22:26, "Ted Hardie" wrote: >Hi G=F6ran, > > >>* Chartering + 6 Months: Working group adoption of HTTP/2 mapping >>document >>* Chartering + 6 Months: Working group adoption of Multipath extension >>document > >Hi ted, > >Which document addresses HTTP/2 mapping on Multipath? or is that >out-of-scope? > >I think that it is in scope, since we want a demonstration that the >multipath extension was useful. The reliability/mobility aspects of >multipath I would expect to be covered in the extensions document. I interpret this to mean that reliability/mobility aspects of multi path has no impact on HTTP/2 mapping. It would seem to me as if you have a particular realization of multipath reliability/mobility in mind. I have not reached that point yet. I could for instance see how the newly proposed HTTP extension Client Hints, e.g. DL (Downlink rate/network quality), could be used to convey client side information useful for sender side selection of path (but that is just an example). >If there were load-sharing optimizations that related > to a specific application, I would expect them to be the application's >mapping doc. I could see adding a third doc, if the considerations got >particularly large, but I don't see a reason for that at the moment. > > >That's just my take on it, by the way, and if you have a different split >in mind, please feel free to bring it forward, Thanks. Having read your thinking I believe this is a good start. The discussion until and at Berlin will I am sure clarify if there are considerations enough, such as need for new or changed HTTP extensions, for a specific HTTP/2 on multipath quic doc. Best Regards G=F6ran > > >regards, > > > >Ted > > >=20 > >Regards >G=F6ran > >>* Chartering + 12 Months: Core Protocol document to IESG >>* Chartering + 12 Months: Loss detection and Congestion Control document >>to IESG >>* Chartering + 12 Months: TLS 1.3 Mapping document to IESG >>* Chartering + 18 Months: HTTP/2 mapping document to IESG >>* Chartering + 18 Months: Multipath extension document to IESG >>* Rechartering + 3 Months: Working group adoption of FEC extension >>document >>* Rechartering + 12 Months: FEC extension document to IESG >> >> > > > > > > > > > > From nobody Fri Jun 3 14:58:10 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE7312D56D for ; Fri, 3 Jun 2016 14:58:09 -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 A61mnMeIAVPD for ; Fri, 3 Jun 2016 14:58:07 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 2323312D115 for ; Fri, 3 Jun 2016 14:58:07 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id c127so92933462ywb.1 for ; Fri, 03 Jun 2016 14:58:07 -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=KCwr4IvMVGz1RMSGnkrR0oXvHzp5LA9c3ELL0EXKfGo=; b=Mp3if4y/brhUrWtHWlMB/cfwMHrveCMsx6/FDRj1KcVi/ST/ymBZlIIYC6aVzoqEyx s/kD3y9Cv5jDGxBU1VbFZ8xgAnzyZqwF/eWZS1S8qprzLM4Pw3bM+yw7cUE7x8V8p2hs 4NpMxVuCeqjAmm70KqaHqKpiCWXek/75EBN54yamfEWPHuaUv3UJR/OC76zrj+fUDO98 PaXuGqLKg3YtR734UAU4EfPlps0L5VOh+PPUvnmcBLjQ1gIHyVjSAElyP8iV4hjw6D/h FdNTou8WXERJHuGKIKGTrIFUu+9i9t2mCEVZB+tyGbLugcyiWRCNhj4v1XxxbyO4r+t9 Po6w== 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=KCwr4IvMVGz1RMSGnkrR0oXvHzp5LA9c3ELL0EXKfGo=; b=hYMUx5VXgnE5urcKJI+oDeuR8cPRU0G7Zr2QkKTjXV0Ln/+9VnOgSgSERvdpA1+HJa 6r721KmBmnZwMrv9RSFMMGRa9RgVMn+xrOR9Y5GB/smKKMezzToROrWS7Uvx+hdLVlt1 l6wqhqgCxRVvQQzFNW6PME+n73xATrstq/CcL565VkdeE7Gms8pcD/xRc+2t/JMqho8u kK2CmAkJmUKR3JgZYroSoWNjUY4jhJxYMW6ZOrhCu+7iIUlftdgbbibwzcTErtXA/BH6 qqqdAoRLfrpgvp9J1Q7k44u4cVb6b6DlFNaZHBi9p5uzr9BEOktPdHK1HME3g18YncWq A8qQ== X-Gm-Message-State: ALyK8tLsXPK2ooN3A6UJKb3Gp2zg8FuzAy7Iu/QfExTgCp0sKufHe9dpu55r0gUmhU7AwZywaFt0RB63/f0BU/pZ X-Received: by 10.13.237.1 with SMTP id w1mr3991368ywe.62.1464991086345; Fri, 03 Jun 2016 14:58:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Fri, 3 Jun 2016 14:58:05 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Fri, 3 Jun 2016 14:58:05 -0700 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= Content-Type: multipart/alternative; boundary=94eb2c0864a84d6636053466d10c Archived-At: Cc: Ted Hardie , "quic@ietf.org" Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 21:58:09 -0000 --94eb2c0864a84d6636053466d10c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable G=C3=B6ran, I interpret this to mean that reliability/mobility aspects of multi path > has no impact on HTTP/2 mapping. It would seem to me as if you have a > particular realization of multipath reliability/mobility in mind. I have not reached that point yet. I could for instance see how the newly > proposed HTTP extension Client Hints, e.g. DL (Downlink rate/network > quality), could be used to convey client side information useful for > sender side selection of path (but that is just an example). This extension is about defining the transport mechanisms necessary for multipath in QUIC, which is entirely independent of path selection or scheduling mechanisms. This is the equivalent of MPTCP's or SCTP's definition of multipath; both of these describe protocol mechanisms to enable use of multiple paths, but do not specify a path selection or scheduling mechanism. >If there were load-sharing optimizations that related > > to a specific application, I would expect them to be the application's > >mapping doc. I could see adding a third doc, if the considerations got > >particularly large, but I don't see a reason for that at the moment. > > > > > >That's just my take on it, by the way, and if you have a different split > >in mind, please feel free to bring it forward, > > Thanks. Having read your thinking I believe this is a good start. The > discussion until and at Berlin will I am sure clarify if there are > considerations enough, such as need for new or changed HTTP extensions, > for a specific HTTP/2 on multipath quic doc. > Right -- an HTTP/2 on QUIC multipath could be, in theory, an addition to the QUIC multipath extension. I would argue against adding it now for the early work, but that's just my thinking. - jana > Best Regards > G=C3=B6ran > > > > > > >regards, > > > > > > > >Ted > > > > > > > > > >Regards > >G=C3=B6ran > > > >>* Chartering + 12 Months: Core Protocol document to IESG > >>* Chartering + 12 Months: Loss detection and Congestion Control documen= t > >>to IESG > >>* Chartering + 12 Months: TLS 1.3 Mapping document to IESG > >>* Chartering + 18 Months: HTTP/2 mapping document to IESG > >>* Chartering + 18 Months: Multipath extension document to IESG > >>* Rechartering + 3 Months: Working group adoption of FEC extension > >>document > >>* Rechartering + 12 Months: FEC extension document to IESG > >> > >> > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --94eb2c0864a84d6636053466d10c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
G=C3=B6ran,

=
I interpret this to mean that r= eliability/mobility aspects of multi path
has no impact on HTTP/2 mapping. It would seem to me as if you have a
particular realization of multipath reliability/mobility in mind. I have=C2= =A0
not reached that point yet. I could for in= stance see how the newly
proposed HTTP extension Client Hints, e.g. DL (Downlink rate/network
quality), could be used to convey client side information useful for
sender side selection of path (but that is just an example).

This extension is about defining the transport mecha= nisms necessary for multipath in QUIC, which is entirely independent of pat= h selection or scheduling mechanisms. This is the equivalent of MPTCP's= or SCTP's definition of multipath; both of these describe protocol mec= hanisms to enable use of multiple paths, but do not specify a path selectio= n or scheduling mechanism.

>If there were load-sharing optimizations that related
> to a specific application, I would expect them to be the application&#= 39;s
>mapping doc.=C2=A0 I could see adding a third doc, if the consideration= s got
>particularly large, but I don't see a reason for that at the moment= .
>
>
>That's just my take on it, by the way, and if you have a different = split
>in mind, please feel free to bring it forward,

Thanks. Having read your thinking I believe this is a good start. Th= e
discussion until and at Berlin will I am sure clarify if there are
considerations enough, such as need for new or changed HTTP extensions,
for a specific HTTP/2 on multipath quic doc.

Right -- an HTTP/2 on QUIC multipath could be, in theory, an addition= to the QUIC multipath extension. I would argue against adding it now for t= he early work, but that's just my thinking.

- = jana

=C2=A0
Best Regards
G=C3=B6ran

>
>
>regards,
>
>
>
>Ted
>
>
>
>
>Regards
>G=C3=B6ran
>
>>* Chartering + 12 Months: Core Protocol document to IESG
>>* Chartering + 12 Months: Loss detection and Congestion Control doc= ument
>>to IESG
>>* Chartering + 12 Months: TLS 1.3 Mapping document to IESG
>>* Chartering + 18 Months: HTTP/2 mapping document to IESG
>>* Chartering + 18 Months: Multipath extension document to IESG
>>* Rechartering + 3 Months: Working group adoption of FEC extension<= br> >>document
>>* Rechartering + 12 Months: FEC extension document to IESG
>>
>>
>
>
>
>
>
>
>
>
>
>

________________= _______________________________
QUIC mailing list
QUIC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/quic

--94eb2c0864a84d6636053466d10c-- From nobody Fri Jun 3 23:43:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D4D12D0CB for ; Fri, 3 Jun 2016 23:43: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 qRKdVxsuQsmz for ; Fri, 3 Jun 2016 23:43:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EBD12D0BD for ; Fri, 3 Jun 2016 23:43:45 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-10-5752789ee947 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 23.4C.18043.E9872575; Sat, 4 Jun 2016 08:43:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Sat, 4 Jun 2016 08:43:42 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Jana Iyengar Thread-Topic: [QUIC] Charter dates Thread-Index: AQHRvbqnsCgxosvZnE+SI63MeLPRl5/YBuKAgAAIjICAAC94gP//6iCAgAC0X4A= Date: Sat, 4 Jun 2016 06:43:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <54FBE6F74C1ADC49AD3C174CC6140816@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2J7uO68iqBwg9ZDZhaTji5ksehZwG3R ONfOgdlj56y77B4LNpV6LFnykymAOYrLJiU1J7MstUjfLoErY8uT3awFe1grtm7eyd7AuIyl i5GTQ0LARKLj7Ad2CFtM4sK99WxdjFwcQgJHGCUerj3ICJIQEljMKHGzJxvEZhPwlpi24iwr iC0ioCjx9OdXsGZmAReJ1i9bgIZycAgDxe/v94YoUZLYtOEGI4TtJ9F27AxYK4uAikTfjq1g cV4Ba4mp3deh9h5ikmg+eZkNJMEpECjRMWkR2KGMArIS97/fY4HYJS5x68l8JoijBSSW7DnP DGGLSrx8/A9sgaiAnsSXe/MYIeJKEotuf2aC6NWTuDF1ChuEbS1x/OMsqLi2xLKFr5khDhKU ODnzCcsERolZSNbNQtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokR GJUHt/y22sF48LnjIUYBDkYlHt4HfwPDhVgTy4orcw8xSnAwK4nw7i0OChfiTUmsrEotyo8v Ks1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUgtQgmy8TBKQWM3sfVUiYZ1g260avENL6cWc2s y3D9U3FNd+Am7aYju55aPl303ZKr0tQ7Ny5bzGlHz67D812TeeP1ag35BSMMVmeqaDteWGst KnBUN+0w468DV213akT07O2Xu/plnvTf7bvmTdsoFimvfi455XZQXED3C7nZLnLvPgX9E3op 8u73wj+Fz88rsRRnJBpqMRcVJwIA1SHbn8YCAAA= Archived-At: Cc: Ted Hardie , "quic@ietf.org" Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 06:43:47 -0000 Hi Jana, On 03/06/16 23:58, "Jana Iyengar" wrote: >Right -- an HTTP/2 on QUIC multipath could be, in theory, an addition to >the QUIC multipath extension. I would argue against adding it now for the >early work, but that's just my thinking. Yes, still too early to decide. And it may be that 3rd doc that is needed. 1 HTTP/2 on QUIC 2 QUIC Multipath extensions 3 HTTP/2 and MPQUIC extension I think the HTTPBis group has some thinking to do here about the impact of multipath, just as other =B3application=B2 groups and I guess(!) that will be/is ongoing in parallel to the QUIC work, :-). I am good for now and look forward to Berlin! Regards G=F6ran From nobody Sat Jun 4 02:33:51 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3A712D11F for ; Sat, 4 Jun 2016 02:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xQ7RpTQiLcEQ for ; Sat, 4 Jun 2016 02:33:47 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 31206128B44 for ; Sat, 4 Jun 2016 02:33:47 -0700 (PDT) Received: from [192.168.1.109] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8DBCD22E1F3; Sat, 4 Jun 2016 05:33:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: Date: Sat, 4 Jun 2016 19:33:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> References: To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 09:33:50 -0000 My .02 - Do people really believe that the core document can be done in 9 months? = H2 took two years, and that was a pretty aggressive schedule.=20 I think it's important to have a set of deadlines that people can agree = to as goals. If the milestones are widely viewed as unrealistic, there = effectively isn't any pressure to finish, and it can easily blow out to = endless discussion and iteration.=20 OTOH if the WG can get consensus to meet its milestones, that can be = effective in moving things forward; this is how we did H2. But, it = requires achievable milestones. Also, why "Chartering + 3 months" for adoption of the starting = documents? What will the WG be doing for those three months? Lastly for now, what are peoples' expectations for Interim meetings? = Again drawing on the experience with H2, we held them pretty often (by = IETF standards); seven of them in those two years. IMHO meeting an = aggressive schedule like this requires a high frequency of F2F meeting = (and I note the new IESG statements on this topic with a bit of = concern). Cheers, > On 4 Jun 2016, at 3:08 AM, Ted Hardie wrote: >=20 > Howdy, >=20 > The ADs asked the proponents a questions about the values of N = associated with the various places in the charter where we have a = chartering + N line in the milestones. Here's a strawman set of values; = comments on whether it is the right order are probably stage one. They = are a bit aggressive, but then we're an optimistic bunch around here, = right? >=20 > Ted >=20 > ## Milestones >=20 > * Chartering + 3 Months: Working group adoption of Core Protocol = document > * Chartering + 3 Months: Working group adoption of Loss detection and = Congestion Control document > * Chartering + 3 Months: Working group adoption of TLS 1.3 mapping = document > * Chartering + 6 Months: Working group adoption of HTTP/2 mapping = document > * Chartering + 6 Months: Working group adoption of Multipath extension = document > * Chartering + 12 Months: Core Protocol document to IESG > * Chartering + 12 Months: Loss detection and Congestion Control = document to IESG > * Chartering + 12 Months: TLS 1.3 Mapping document to IESG > * Chartering + 18 Months: HTTP/2 mapping document to IESG > * Chartering + 18 Months: Multipath extension document to IESG > * Rechartering + 3 Months: Working group adoption of FEC extension = document > * Rechartering + 12 Months: FEC extension document to IESG >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jun 4 05:04:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212F412D55D for ; Sat, 4 Jun 2016 05:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 vNhhMMHrNanW for ; Sat, 4 Jun 2016 05:04:13 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1819612D55F for ; Sat, 4 Jun 2016 05:04:12 -0700 (PDT) Received: from [192.168.1.100] (p508F17E0.dip0.t-ipconnect.de [80.143.23.224]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id E6A82721E281E; Sat, 4 Jun 2016 14:04:08 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> Date: Sat, 4 Jun 2016 14:04:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ted Hardie , quic@ietf.org Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 12:04:16 -0000 > On 04 Jun 2016, at 11:33, Mark Nottingham wrote: >=20 > My .02 - >=20 > Do people really believe that the core document can be done in 9 = months? H2 took two years, and that was a pretty aggressive schedule.=20 Just another data pointer. When SIGTRAN developed SCTP, the first WG = document was submitted on February 1, 1999: https://tools.ietf.org/html/draft-ietf-sigtran-mdtp-00 It substantially changed to https://tools.ietf.org/html/draft-ietf-sigtran-sctp-00 in September 23, 1999 The final ID was submitted on July 11th, 2000 https://tools.ietf.org/html/draft-ietf-sigtran-sctp-13 and it became an RFC in October 2000. Please note that the protocol changed completely within this process. If = you just consider the time from September 1999 to July 2000, you might and up in the 9 month = order. However, this means that you don't expect substantial protocol changes. >=20 > I think it's important to have a set of deadlines that people can = agree to as goals. If the milestones are widely viewed as unrealistic, = there effectively isn't any pressure to finish, and it can easily blow = out to endless discussion and iteration.=20 >=20 > OTOH if the WG can get consensus to meet its milestones, that can be = effective in moving things forward; this is how we did H2. But, it = requires achievable milestones. >=20 > Also, why "Chartering + 3 months" for adoption of the starting = documents? What will the WG be doing for those three months? You either want to start with the existing QUIC ID, in which case you = don't need 3 month, or you want to pick a candidate from a pool. Then you might need some time doing so, = based on some requirements you have. This was done in the SIGTRAN case by looking at requirements = first. Best regards Michael >=20 > Lastly for now, what are peoples' expectations for Interim meetings? = Again drawing on the experience with H2, we held them pretty often (by = IETF standards); seven of them in those two years. IMHO meeting an = aggressive schedule like this requires a high frequency of F2F meeting = (and I note the new IESG statements on this topic with a bit of = concern). >=20 > Cheers, >=20 >=20 >> On 4 Jun 2016, at 3:08 AM, Ted Hardie wrote: >>=20 >> Howdy, >>=20 >> The ADs asked the proponents a questions about the values of N = associated with the various places in the charter where we have a = chartering + N line in the milestones. Here's a strawman set of values; = comments on whether it is the right order are probably stage one. They = are a bit aggressive, but then we're an optimistic bunch around here, = right? >>=20 >> Ted >>=20 >> ## Milestones >>=20 >> * Chartering + 3 Months: Working group adoption of Core Protocol = document >> * Chartering + 3 Months: Working group adoption of Loss detection and = Congestion Control document >> * Chartering + 3 Months: Working group adoption of TLS 1.3 mapping = document >> * Chartering + 6 Months: Working group adoption of HTTP/2 mapping = document >> * Chartering + 6 Months: Working group adoption of Multipath = extension document >> * Chartering + 12 Months: Core Protocol document to IESG >> * Chartering + 12 Months: Loss detection and Congestion Control = document to IESG >> * Chartering + 12 Months: TLS 1.3 Mapping document to IESG >> * Chartering + 18 Months: HTTP/2 mapping document to IESG >> * Chartering + 18 Months: Multipath extension document to IESG >> * Rechartering + 3 Months: Working group adoption of FEC extension = document >> * Rechartering + 12 Months: FEC extension document to IESG >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Sat Jun 4 21:53:20 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B487412D624 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 MceGB1ak4FKr for ; Sat, 4 Jun 2016 17:25:45 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DB812D5A7 for ; Sat, 4 Jun 2016 17:25:40 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f67so17531516ith.1 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=SdcaiXloHWbYxDFohnzc//Czb+Yzjg7WTVarA8uwlbnvzS0hQi4imGARMEOiMomrk0 1fWgkU8rIQxhYvl1B+W7dydln8INKeLmVpHUB6n2rqyGsh3+1zTEklf+7SBi0afROlCl 2efp1SMEK8EtD+x+ovvcu5kN5IPLSbh8f/TUXcPtwwaJvvw3Q35tuMoqaTsembpM3M9V beLl4zWK5N2NWUED+dPgL5cd25Kq0YCt0etARjOH9k6JFRH1KXHmXV57NI7HD4mjSiNu 6DG+B78zOHZAgHOlNmBDkBXrPBPpugeK1joYhEwyWUTrEFhRMJFZDso6/kvEa+08kEF4 Vfcg== X-Gm-Message-State: ALyK8tLcKtOv5zu6crJT1pZdnDqI4aT98fwceuWmA4V9kMo7aLuAef99wmEZ8ZvkgfoZctocv32AKJDY77blcA== 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: X-Mailman-Approved-At: Sat, 04 Jun 2016 21:53:20 -0700 Cc: tsvwg WG , draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, spud , quic@ietf.org, ietf@ietf.org Subject: Re: [QUIC] [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 00:25:47 -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:38 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@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 , Brian Trammell , quic@ietf.org, ietf@ietf.org Subject: Re: [QUIC] [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization 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 00:44:56 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CF312D1B3 for ; Mon, 6 Jun 2016 00:44:54 -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 39oiGCIOU8iM for ; Mon, 6 Jun 2016 00:44:52 -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 D1E2512B055 for ; Mon, 6 Jun 2016 00:44:51 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b9pDM-0003hb-My for quic@ietf.org; Mon, 06 Jun 2016 09:44:48 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b9pDM-0007gu-5h for quic@ietf.org; Mon, 06 Jun 2016 09:44:48 +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: Date: Mon, 6 Jun 2016 09:44:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: quic@ietf.org X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 42624 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: B2EADC2EF26723D67678498A298807D03FB22F27 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10228 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 07:44:55 -0000 Hi, I narrow down the recipient list to QUIC only and change the subject, = because I don't think this is about making a recommendation for the text = in the RFC5405bis draft anymore: > On 06 Jun 2016, at 07:18, Jim Roskind wrote: >=20 >=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).=20 > 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). "never" isn't true. We recently did measurements where about half of TCP = connection attempts succeeded when the protocol didn't really claim to = be TCP at all but we used an unknown protocol number. This wasn't a huge = measurement campaign, just approx. 100 different Internet paths. Still, = "never" just ain't true; the question is really if the other protocol = deployment attempts that you mention used (efficient) fallbacks. > 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 You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP - but this would require some intelligence in how to do this fall back, = e.g. with a useful caching strategy. Of course, the question is if this = is really worth the effort. Cheers, Michael From nobody Mon Jun 6 00:54:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA3012B024 for ; Mon, 6 Jun 2016 00:54: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 lTcnjIYqhKkE for ; Mon, 6 Jun 2016 00:54:11 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 62DE912B017 for ; Mon, 6 Jun 2016 00:54:11 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:2960:d96:96b2:e1] (unknown [IPv6:2001:470:26:9c2:2960:d96:96b2:e1]) by trammell.ch (Postfix) with ESMTPSA id 2C6251A1442; Mon, 6 Jun 2016 09:54:10 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_72DBB174-D23B-4D3A-B236-AF171706AF0D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Mon, 6 Jun 2016 09:54:17 +0200 Message-Id: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 07:54:13 -0000 --Apple-Mail=_72DBB174-D23B-4D3A-B236-AF171706AF0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Michael, > On 06 Jun 2016, at 09:44, Michael Welzl wrote: >=20 > Hi, >=20 > I narrow down the recipient list to QUIC only and change the subject, = because I don't think this is about making a recommendation for the text = in the RFC5405bis draft anymore: >=20 >=20 >> On 06 Jun 2016, at 07:18, Jim Roskind wrote: >>=20 >>=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, >>>=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 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). >=20 > "never" isn't true. We recently did measurements where about half of = TCP connection attempts succeeded when the protocol didn't really claim = to be TCP at all but we used an unknown protocol number. This wasn't a = huge measurement campaign, just approx. 100 different Internet paths. = Still, "never" just ain't true; the question is really if the other = protocol deployment attempts that you mention used (efficient) = fallbacks. Interesting; I would actually have expected more than half to succeed, = but I suppose this is entirely a function of how present (and clueful) = the NAT boxes along your chosen path are. We're planning on doing a = larger-scale study of exactly this question soon, both on the open = Internet and in the lab on a set of captive middleboxes. >> 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 > You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP >=20 > - but this would require some intelligence in how to do this fall = back, e.g. with a useful caching strategy. Of course, the question is if = this is really worth the effort. At least in our (ongoing, under submission) work on UDP impairment (see = BA maprg talk), it appears that the *vast* majority of cases are = access-network linked. So each peer can cache its "UDP works" bit on a = per-interface or per-connection-profile basis (and servers, of course, = can have it configured as a matter of policy). I suspect the picture = with other protocol numbers is similar (but need to see data to believe = it). Cheers, Brian --Apple-Mail=_72DBB174-D23B-4D3A-B236-AF171706AF0D 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 iQIcBAEBCgAGBQJXVSwpAAoJEIoSt78L6kajPBwQAMflb7BkhH9Fp/YkIuJpS4n0 WN1Cymwvw8FQ8GFmNUbPPaT84T3Njoq5/Omj2Amn6ixhhrrwoAsBKtMoU9rZDmTz fwA/U8+R0Rw7jf0pDhiiAwjTf6g3m1xqfISGIdwZod9bPMYnAnAXf5vKOp3xhTCx p7MwAz4V4Y86W0nXTg2oi4uxv7eknKtwXrQoLeut2aD5srnA2dgaDgaLbGmr0eXL mJsOYZ4SiUZmCQZD5jzXLUBJP7/7cQGAYfmF1VEVM80Y3+ZO9QJ/GD9GV2nlb/1X s08CUlVBw7pA7IEp85grZP1q1f0TUx9c5cMSLyooUa6ncNPb5tLwdOXbB3XqQYBf Salhu3dA+cSALKHe9QHYYU/k9vRSKrPWzlmgEpiqWC8XY0iajdhK2RjJ128eU+au IKFgVBBLMDl+ZIyr2tFJt4xa1OhUbAXZqiw9WAUG62k24Si0Hw8lpO3BC1342IPo LaaRMt77ja38ZGdeKlwspa1ygDtIFLsNT/aR1VP8hLduxNC3xN/FDIPHB/wmvAqF QB7RkbEn7FnMX6tqGt9Y8xQPbghBt6N9wTaBrw/4Xk7a7dTKLWaS3nrZ/EAEtyLK 31vu32fuwthOkzPDQKb5bEFtKwOIPvCSpio7Flhcz2Vh4/9xCH1FiHA984uM754T OOVcbyQh9o/jDlBHtR7w =7hHp -----END PGP SIGNATURE----- --Apple-Mail=_72DBB174-D23B-4D3A-B236-AF171706AF0D-- From nobody Mon Jun 6 02:18:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276BB12D09F for ; Mon, 6 Jun 2016 02:18:45 -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 vfcMGpI4Y6Xn for ; Mon, 6 Jun 2016 02:18:43 -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 7099D12D650 for ; Mon, 6 Jun 2016 02:18:42 -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 1b9qgC-0007K9-BK; Mon, 06 Jun 2016 11:18:40 +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 1b9qgB-0007wE-LU; Mon, 06 Jun 2016 11:18:40 +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: Date: Mon, 6 Jun 2016 11:18:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 15 sum msgs/h 8 total rcpts 42647 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: 6141D7EEBAB436B03C5B5FA83E96831843A131C3 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 10240 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 09:18:45 -0000 > On 06 Jun 2016, at 09:54, Brian Trammell wrote: >=20 > hi Michael, >=20 >> On 06 Jun 2016, at 09:44, Michael Welzl wrote: >>=20 >> Hi, >>=20 >> I narrow down the recipient list to QUIC only and change the subject, = because I don't think this is about making a recommendation for the text = in the RFC5405bis draft anymore: >>=20 >>=20 >>> On 06 Jun 2016, at 07:18, Jim Roskind wrote: >>>=20 >>>=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, >>>>=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 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). >>=20 >> "never" isn't true. We recently did measurements where about half of = TCP connection attempts succeeded when the protocol didn't really claim = to be TCP at all but we used an unknown protocol number. This wasn't a = huge measurement campaign, just approx. 100 different Internet paths. = Still, "never" just ain't true; the question is really if the other = protocol deployment attempts that you mention used (efficient) = fallbacks. >=20 > Interesting; I would actually have expected more than half to succeed, = but I suppose this is entirely a function of how present (and clueful) = the NAT boxes along your chosen path are. We're planning on doing a = larger-scale study of exactly this question soon, both on the open = Internet and in the lab on a set of captive middleboxes. Cool! >>> 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 >> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP >>=20 >> - but this would require some intelligence in how to do this fall = back, e.g. with a useful caching strategy. Of course, the question is if = this is really worth the effort. >=20 > At least in our (ongoing, under submission) work on UDP impairment = (see BA maprg talk), it appears that the *vast* majority of cases are = access-network linked. We saw something similar. > So each peer can cache its "UDP works" bit on a per-interface or = per-connection-profile basis (and servers, of course, can have it = configured as a matter of policy). I suspect the picture with other = protocol numbers is similar (but need to see data to believe it). Well ... maybe ? Interesting thought anyway! Cheers, Michael From nobody Mon Jun 6 07:35:28 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1212D5BE for ; Mon, 6 Jun 2016 07:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 P3maunBB-Hp2 for ; Mon, 6 Jun 2016 07:35:21 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 465C412B006 for ; Mon, 6 Jun 2016 07:27:18 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id n126so12001160itd.1 for ; Mon, 06 Jun 2016 07:27:18 -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=ab3ufuH1P/7AK1YTCa7iyW99sGemOQIPyq1tPCKEdQQ=; b=flO6pt4ZcF5c4RSmp5dwHFQw3pfMc1EvEDOhtKTIThgq3UOiIdddKjgre5BeTsaoiu rxouYDu/Zp+n77Wt/NzVFpB5iq28ZnhoPTg1XJkD4h+xAlOgZz4uOWaqb2chBpd5N9ui psnGGTkxN6fDC4lGyRd4njXsYCfJ45m9u0giDvuEncausNGqTenF6P+5puKFKsZb3YGr uw69CAwSI03BEXkwzaBCin+NnzvyTSK3lXgmqHiTkycGu/cc687gfW/3x9Mlr3fHOgk+ r8yG2TEcAbwYQ601JSEEFRKH4OW/bBhhgcpJ4jC0KqHgxQLG+htStcDFD656W5zgK8Am Ccjw== 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=ab3ufuH1P/7AK1YTCa7iyW99sGemOQIPyq1tPCKEdQQ=; b=FQl/fIH9iyZ/ZH63GNDPi8ShlCxoe2+flYE//H2FV0istPa9o0AOysiOeCMkh2Mh3Y wq4+02T2dAqSl51kHE5pSabo9WZ1+pSbngpra7uGeYU+WmHCuzbVwJU4f9uLSPX6X1q0 O6rT8ocWnncDg6TNU0mFtCPXm6FV5ZKVJbzDhU54PjKqM6CoKVFzwURxR5ymm6j0hpCE OoO2HGmItyYJ6at+NMhR4XDLIpF5hQVNZzJgf+29+UQrKko9SCFtUsP5YGLgz08ILGha yb7nVCt26FtzxjeNzHL/x0uhGI7mrDYRlTtShi7nn2Ij4jAqtmaD0tQNWW+G979OBHHB iqgw== X-Gm-Message-State: ALyK8tJPUuawvB15q4Plx/j9dNhFIOil53ITjXUDZrNrSs44OLQIKfaWJfO59iEpVj/jqdXRJ3rU3PVg9G8WcZxD X-Received: by 10.36.14.71 with SMTP id 68mr16751863ite.98.1465223237313; Mon, 06 Jun 2016 07:27:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.227 with HTTP; Mon, 6 Jun 2016 07:26:57 -0700 (PDT) In-Reply-To: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> From: Ian Swett Date: Mon, 6 Jun 2016 10:26:57 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=001a1143ac6c941b6a05349cde3c Archived-At: Cc: Brian Trammell , quic@ietf.org Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 14:35:23 -0000 --001a1143ac6c941b6a05349cde3c Content-Type: text/plain; charset=UTF-8 On Mon, Jun 6, 2016 at 5:18 AM, Michael Welzl wrote: > > > On 06 Jun 2016, at 09:54, Brian Trammell wrote: > > > > hi Michael, > > > >> On 06 Jun 2016, at 09:44, Michael Welzl wrote: > >> > >> Hi, > >> > >> I narrow down the recipient list to QUIC only and change the subject, > because I don't think this is about making a recommendation for the text in > the RFC5405bis draft anymore: > >> > >> > >>> On 06 Jun 2016, at 07:18, 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). > >> > >> "never" isn't true. We recently did measurements where about half of > TCP connection attempts succeeded when the protocol didn't really claim to > be TCP at all but we used an unknown protocol number. This wasn't a huge > measurement campaign, just approx. 100 different Internet paths. Still, > "never" just ain't true; the question is really if the other protocol > deployment attempts that you mention used (efficient) fallbacks. > > > > Interesting; I would actually have expected more than half to succeed, > but I suppose this is entirely a function of how present (and clueful) the > NAT boxes along your chosen path are. We're planning on doing a > larger-scale study of exactly this question soon, both on the open Internet > and in the lab on a set of captive middleboxes. > > Cool! > > > >>> 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, > >> > >> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP > >> > But Chrome his privileges to write QUIC over a dedicated protocol number on ~0% of the clients it's running on, which further increases the barrier beyond the complexity of a 3-way race. A 2-way race with v4/v6 happy eyeballs is quite complex and difficult to get right. > >> - but this would require some intelligence in how to do this fall back, > e.g. with a useful caching strategy. Of course, the question is if this is > really worth the effort. > > > > At least in our (ongoing, under submission) work on UDP impairment (see > BA maprg talk), it appears that the *vast* majority of cases are > access-network linked. > > We saw something similar. > We've seen something similar, though sometimes there are other issues(server config issues, network config issues, etc) that come up and effect one server or set of servers but not others. Chrome tries to handle this by marking some as broken and not others, but this logic has proven hard to get exactly right. > > So each peer can cache its "UDP works" bit on a per-interface or > per-connection-profile basis (and servers, of course, can have it > configured as a matter of policy). I suspect the picture with other > protocol numbers is similar (but need to see data to believe it). > > Well ... maybe ? Interesting thought anyway! > > Cheers, > Michael > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a1143ac6c941b6a05349cde3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 6, 2016 at 5:18 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

> On 06 Jun 2016, at 09:54, Brian Trammell <ietf@trammell.ch> wrote:
>
> hi Michael,
>
>> On 06 Jun 2016, at 09:44, Michael Welzl <michawe@ifi.uio.no> wrote:
>>
>> Hi,
>>
>> I narrow down the recipient list to QUIC only and change the subje= ct, because I don't think this is about making a recommendation for the= text in the RFC5405bis draft anymore:
>>
>>
>>> On 06 Jun 2016, at 07:18, Jim Roskind <JimRoskind@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,= relatively minor. I hope it's still useful.
>>>>
>>>> I understand that Section 3 was written to encourage appli= cation 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 writ= ten it would seem to discourage transport innovation atop UDP (e.g. QUIC, t= he RTCWEB data channel, anything-over-PLUS), which I very much hope was not= the intent. The problematic recommendation is in the second paragraph:
>>>>
>>>>=C2=A0 These mechanisms are difficult to implement correctl= y.=C2=A0 For most
>>>>=C2=A0 applications, the use of one of the existing IETF tr= ansport protocols
>>>>=C2=A0 is the simplest method of acquiring the required mec= hanisms.=C2=A0 Doing
>>>>=C2=A0 so also avoids issues that protocols using a new IP = protocol number
>>>>=C2=A0 face when being deployed over the Internet, where mi= ddleboxes that
>>>>=C2=A0 only support TCP and UDP are not rare.=C2=A0 Consequ= ently, the RECOMMENDED
>>>>=C2=A0 alternative to the UDP usage described in the remain= der of this
>>>>=C2=A0 section is the use of an IETF transport protocol suc= h as TCP
>>>>=C2=A0 [RFC0793], Stream Control Transmission Protocol (SCT= P) [RFC4960], and
>>>>=C2=A0 SCTP Partial Reliability Extension (SCTP-PR) [RFC375= 8], or Datagram
>>>>=C2=A0 Congestion Control Protocol (DCCP) [RFC4340] with it= s different
>>>>=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 thi= s is a minor point and probably not worth a late edit. Second, I'm conc= erned this recommendation could be taken as broader than intended, against = the definition of any new transport protocol encapsulated within UDP that p= erforms substantially the same function as the listed protocols.
>>>>
>>> I would agree, this paragraph also seems a little self
>>> contradictory.There is an acknowledgment that "middleboxe= s that only
>>> support TCP and UDP are not rare", but then the next sent= ence
>>> recommends the use of several other protocols besides UDP and = TCP. If
>>> I put these two together, the only congested controlled protoc= ol that
>>> is recommended and expected to work on the Internet is TCP. >>>
>>> +1=C2=A0 =C2=A0TCP (implemented in kernel space) can't pos= sibly evolve congestion avoidance as fast as the Internet has changed, or w= ill change (example: good handling of middle boxes that use "policers&= quot; 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).
>>
>> "never" isn't true. We recently did measurements whe= re about half of TCP connection attempts succeeded when the protocol didn&#= 39;t really claim to be TCP at all but we used an unknown protocol number. = This wasn't a huge measurement campaign, just approx. 100 different Int= ernet paths. Still, "never" just ain't true; the question is = really if the other protocol deployment attempts that you mention used (eff= icient) fallbacks.
>
> Interesting; I would actually have expected more than half to succeed,= but I suppose this is entirely a function of how present (and clueful) the= NAT boxes along your chosen path are. We're planning on doing a larger= -scale study of exactly this question soon, both on the open Internet and i= n the lab on a set of captive middleboxes.

Cool!


>>> It turns out that even UDP is partially blocked (as recently a= s 2011) by paths to 5-7% of all chrome clients, which lead to the "aut= omated fallback" elements of QUIC,
>>
>> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP
>>

But Chrome his privileg= es to write QUIC over a dedicated protocol number on ~0% of the clients it&= #39;s running on, which further increases the barrier beyond the complexity= of a 3-way race.=C2=A0 A 2-way race with =C2=A0v4/v6 happy eyeballs is qui= te complex and difficult to get right.
=C2=A0
>> - but this would require some intelligence in how to do this fall = back, e.g. with a useful caching strategy. Of course, the question is if th= is is really worth the effort.
>
> At least in our (ongoing, under submission) work on UDP impairment (se= e BA maprg talk), it appears that the *vast* majority of cases are access-n= etwork linked.

We saw something similar.
=C2=A0
We&#= 39;ve seen something similar, though sometimes there are other issues(serve= r config issues, network config issues, etc) that come up and effect one se= rver or set of servers but not others.=C2=A0 Chrome tries to handle this by= marking some as broken and not others, but this logic has proven hard to g= et exactly right.


> So each peer can cache its "UDP works" bit on a per-interfac= e or per-connection-profile basis (and servers, of course, can have it conf= igured as a matter of policy). I suspect the picture with other protocol nu= mbers is similar (but need to see data to believe it).

Well ...=C2=A0 =C2=A0maybe ?=C2=A0 =C2=A0Interesting thought anyway!=

Cheers,
Michael

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

--001a1143ac6c941b6a05349cde3c-- From nobody Mon Jun 6 13:22:51 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6153612D906 for ; Mon, 6 Jun 2016 13:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 JjVKEpRl8YoI for ; Mon, 6 Jun 2016 13:22: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 CC72D12D904 for ; Mon, 6 Jun 2016 13:22:45 -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 1bA12o-0002A3-Sb; Mon, 06 Jun 2016 22:22:42 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.102]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bA12n-0003TG-Ec; Mon, 06 Jun 2016 22:22:42 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E0ADA72-5419-4811-8FD6-398898B28B73" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 6 Jun 2016 22:22:40 +0200 Message-Id: <50315345-0384-4938-BC96-84C029FFA025@ifi.uio.no> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: Ian Swett X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 8 sum msgs/h 5 total rcpts 42692 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D4D5DC0CEF4C8DDDFF29C47942E7487D1C39FFFB X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1233 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , quic@ietf.org Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:22:49 -0000 --Apple-Mail=_6E0ADA72-5419-4811-8FD6-398898B28B73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6. jun. 2016, at 16.26, Ian Swett wrote: >=20 > On Mon, Jun 6, 2016 at 5:18 AM, Michael Welzl > wrote: >=20 > > On 06 Jun 2016, at 09:54, Brian Trammell > wrote: > > > > hi Michael, > > > >> On 06 Jun 2016, at 09:44, Michael Welzl > wrote: > >> > >> Hi, > >> > >> I narrow down the recipient list to QUIC only and change the = subject, because I don't think this is about making a recommendation for = the text in the RFC5405bis draft anymore: > >> > >> > >>> On 06 Jun 2016, at 07:18, 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). > >> > >> "never" isn't true. We recently did measurements where about half = of TCP connection attempts succeeded when the protocol didn't really = claim to be TCP at all but we used an unknown protocol number. This = wasn't a huge measurement campaign, just approx. 100 different Internet = paths. Still, "never" just ain't true; the question is really if the = other protocol deployment attempts that you mention used (efficient) = fallbacks. > > > > Interesting; I would actually have expected more than half to = succeed, but I suppose this is entirely a function of how present (and = clueful) the NAT boxes along your chosen path are. We're planning on = doing a larger-scale study of exactly this question soon, both on the = open Internet and in the lab on a set of captive middleboxes. >=20 > Cool! >=20 >=20 > >>> 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, > >> > >> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP > >> >=20 > But Chrome his privileges to write QUIC over a dedicated protocol = number on ~0% of the clients it's running on, which further increases = the barrier beyond the complexity of a 3-way race. A 2-way race with = v4/v6 happy eyeballs is quite complex and difficult to get right. Of course; I=E2=80=99m not complaining about the choice made by QUIC, = just pointing out that in principle, such a thing could be done (and I = think it should be provided by some layer below, in the OS - but this is = just wishful thinking). Sorry for saying =E2=80=9Cyou could=E2=80=9D - I = know you couldn=E2=80=99t. Plus I agree about the complexity and I=E2=80=99= m not sure this would be worth the effort; again I=E2=80=99m dreaming of = some magic thing in the OS that does that for you... Cheers, Michael > =20 > >> - but this would require some intelligence in how to do this fall = back, e.g. with a useful caching strategy. Of course, the question is if = this is really worth the effort. > > > > At least in our (ongoing, under submission) work on UDP impairment = (see BA maprg talk), it appears that the *vast* majority of cases are = access-network linked. >=20 > We saw something similar. > =20 > We've seen something similar, though sometimes there are other = issues(server config issues, network config issues, etc) that come up = and effect one server or set of servers but not others. Chrome tries to = handle this by marking some as broken and not others, but this logic has = proven hard to get exactly right. >=20 >=20 > > So each peer can cache its "UDP works" bit on a per-interface or = per-connection-profile basis (and servers, of course, can have it = configured as a matter of policy). I suspect the picture with other = protocol numbers is similar (but need to see data to believe it). >=20 > Well ... maybe ? Interesting thought anyway! >=20 > Cheers, > Michael >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic = >=20 --Apple-Mail=_6E0ADA72-5419-4811-8FD6-398898B28B73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 6. jun. 2016, at 16.26, Ian Swett <ianswett@google.com>= wrote:

On Mon, Jun 6, 2016 at 5:18 AM, Michael Welzl = <michawe@ifi.uio.no> wrote:

> On 06 Jun 2016, at 09:54, Brian Trammell <ietf@trammell.ch> = wrote:
>
> hi Michael,
>
>> On 06 Jun 2016, at 09:44, Michael Welzl <michawe@ifi.uio.no> = wrote:
>>
>> Hi,
>>
>> I narrow down the recipient list to QUIC only and change the = subject, because I don't think this is about making a recommendation for = the text in the RFC5405bis draft anymore:
>>
>>
>>> On 06 Jun 2016, at 07:18, Jim Roskind <JimRoskind@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, 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).
>>
>> "never" isn't true. We recently did measurements where about = half of TCP connection attempts succeeded when the protocol didn't = really claim to be TCP at all but we used an unknown protocol number. = This wasn't a huge measurement campaign, just approx. 100 different = Internet paths. Still, "never" just ain't true; the question is really = if the other protocol deployment attempts that you mention used = (efficient) fallbacks.
>
> Interesting; I would actually have expected more than half to = succeed, but I suppose this is entirely a function of how present (and = clueful) the NAT boxes along your chosen path are. We're planning on = doing a larger-scale study of exactly this question soon, both on the = open Internet and in the lab on a set of captive middleboxes.

Cool!


>>> 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,
>>
>> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP
>>

But Chrome his privileges to write QUIC = over a dedicated protocol number on ~0% of the clients it's running on, = which further increases the barrier beyond the complexity of a 3-way = race.  A 2-way race with  v4/v6 happy eyeballs is quite = complex and difficult to get = right.

Of course; I=E2=80=99m not complaining about the choice = made by QUIC, just pointing out that in principle, such a thing could be = done  (and I think it should be provided by some layer below, in = the OS - but this is just wishful thinking). Sorry for saying =E2=80=9Cyou= could=E2=80=9D - I know you couldn=E2=80=99t.  Plus I agree about = the complexity and I=E2=80=99m not sure this would be worth the effort; = again I=E2=80=99m dreaming of some magic thing in the OS that does that = for you...

Cheers,
Michael



 
>> - but this would require some intelligence in how to do this = fall back, e.g. with a useful caching strategy. Of course, the question = is if this is really worth the effort.
>
> At least in our (ongoing, under submission) work on UDP impairment = (see BA maprg talk), it appears that the *vast* majority of cases are = access-network linked.

We saw something similar.
 
We've seen something similar, = though sometimes there are other issues(server config issues, network = config issues, etc) that come up and effect one server or set of servers = but not others.  Chrome tries to handle this by marking some as = broken and not others, but this logic has proven hard to get exactly = right.


> So each peer can cache its "UDP works" bit on a per-interface or = per-connection-profile basis (and servers, of course, can have it = configured as a matter of policy). I suspect the picture with other = protocol numbers is similar (but need to see data to believe it).

Well ...   maybe ?   Interesting thought = anyway!

Cheers,
Michael

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


= --Apple-Mail=_6E0ADA72-5419-4811-8FD6-398898B28B73-- From nobody Mon Jun 6 13:24:16 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F9112D904 for ; Mon, 6 Jun 2016 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.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 t2n3Ke9fBp7n for ; Mon, 6 Jun 2016 13:24:11 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A71E612D74D for ; Mon, 6 Jun 2016 13:24:11 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B6F2B200084; Mon, 6 Jun 2016 20:24:10 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id A05FB200085; Mon, 6 Jun 2016 20:24:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1465244650; bh=woZo3raK4CEg+rw3v17rHDIJf7Bz2hFStpbo8Y3fdjw=; l=586; h=From:To:CC:Date:References:In-Reply-To:From; b=Gt3fcQRu6M/XeuHE577/qmLRka3HC8Cd0vD6/CksKa/CiSdRGcfG7/mS92SmBVKVj WVZlr6QTBRyVtj+1LVjQi6Wk/RRfF84YfUUwmRLPuJuG3ZVjaxYaVk7/zLMnMqz8Bw tEA5Pbyo2CpKnF2JzpEzPEQeaJDqivDty9HXTO1E= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 851221E07C; Mon, 6 Jun 2016 20:24:10 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 6 Jun 2016 13:24:09 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 6 Jun 2016 16:24:09 -0400 From: "Salz, Rich" To: Mark Nottingham , Ted Hardie Thread-Topic: [QUIC] Charter dates Thread-Index: AQHRvbqpkZ4EeNRsJE+7qKeRdvnGY5/ZT/YAgAOWvwA= Date: Mon, 6 Jun 2016 20:24:09 +0000 Message-ID: References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> In-Reply-To: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> 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: [172.19.43.117] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:24:13 -0000 Mark brings up an interesting point that I had not realized: > If the milestones are widely viewed as unrealistic, there effectively > isn't any pressure to finish, and it can easily blow out to endless discu= ssion > and iteration. If you try to be *too* aggressive it's worse than not putting any pressure = at all. That's counter-intuitive. Call it the "freakonomics" insight on m= ilestones. I'd like to see some revisions based on that, and other parts of his feedba= ck too. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Mon Jun 6 15:17:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3A12D953 for ; Mon, 6 Jun 2016 15:17:43 -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 LnBeaYw13pDn for ; Mon, 6 Jun 2016 15:17:40 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF84C12D95D for ; Mon, 6 Jun 2016 15:17:39 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id p204so53259522oih.3 for ; Mon, 06 Jun 2016 15:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lkRdzKeWP9uY4chxi/FCVahp/GwtwjtUMFYrhUIwlOk=; b=owcWsz18sPHuQ4n0HbMotIU3IzKRXjcsoRNweHFWc055KH0v0R7rk3X1PJoakWRBty sg664KlkS2GGYF1dZzGAW4X4S2uOYmzVcfvQV2VlaH1XJ3L4TuvxCnFAUdBXzVlfMnkA E08ovIeKdSZy/IfpaDmEhFFR+m32OR4pui0/1Y7yiFWhN0RWNFbpPO17hMfiGT2P2+lE 1PJD/yN5kAN0rCQESqAh7sv21CkFfi75kK1cH0R9pYu3S6UTer0/K6pr0/lX1P+sRwtY qCoLq4AmrmeWce6pmq7xGlAImWA2Vocl30yRhImjHsVIYPmugNrNhoR9f76Bw9gTylne vO4A== 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=lkRdzKeWP9uY4chxi/FCVahp/GwtwjtUMFYrhUIwlOk=; b=OboL8ivzMmLHHWZxIobNsSzCecoznlC3KQLKqNQ2v09n5ERTx922getESelmcLZyCU Qa9XBEf9gHRFoBskMTaMRDwWGlvOSSJ1KoRjWzvSFFgBd1e3bnb5r3Zj9vx0en84XyOx gRk+fHnYkt1huoiHYrC6pdGVWoIP/Umvl2kFk61tvk7ntGZ44y53l30FgMpZIcEbpF+W 6YhqCkaPF61Oo7ONzXZiByoM2hLmgaT3GIxNnoIlJaUeugPJbCqqOSWjs8/Kw+MeWzpW LUb+HQbHd2LaDrBlCejzR6m5B56E9od+jF8W7StKhB4hDJQ7a43QlUW76H/MfseLzjDl KnZg== X-Gm-Message-State: ALyK8tKj0ZKHZQAWwjevchYgoUjilp1TWQEE6fsrev1kJ1+fv3COsvPmpgc9ol1PTxnUYlLVGI0xvcH5/ORKLw== X-Received: by 10.202.48.139 with SMTP id w133mr8012990oiw.61.1465251459255; Mon, 06 Jun 2016 15:17:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Mon, 6 Jun 2016 15:17:19 -0700 (PDT) In-Reply-To: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> From: Ted Hardie Date: Mon, 6 Jun 2016 15:17:19 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113ceffebc53720534a37026 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 22:17:43 -0000 --001a113ceffebc53720534a37026 Content-Type: text/plain; charset=UTF-8 A couple of replies, just my own opinion. On Sat, Jun 4, 2016 at 2:33 AM, Mark Nottingham wrote: > My .02 - > > Do people really believe that the core document can be done in 9 months? > H2 took two years, and that was a pretty aggressive schedule. > > I think it's important to have a set of deadlines that people can agree to > as goals. If the milestones are widely viewed as unrealistic, there > effectively isn't any pressure to finish, and it can easily blow out to > endless discussion and iteration. > > OTOH if the WG can get consensus to meet its milestones, that can be > effective in moving things forward; this is how we did H2. But, it requires > achievable milestones. > > If I can ask you to focus on the H2 mapping document, if we were starting from the current doc, what do you think an achievable milestone would be from adoption of a split document to IESG submission? > Also, why "Chartering + 3 months" for adoption of the starting documents? > What will the WG be doing for those three months? > > Personally, I'm assuming that there will be some discussion of the starting documents when they are still draft-individual-xx; that would occur on the mailing list during/just after the IESG activity for chartering. I'd assume that folding any changes that come up during that section of time would occur before the adoption of them as draft-ietf-wg-xx. Obviously, you could run this the other way and adopt draft-individual as-is and republish as a draft-wg before the substantive changes start; prior to the "replaces" function in the tracker, I would have suggested that. Having a three-month window allows you to do it either way, but this is definitely one I see as "no later than". > Lastly for now, what are peoples' expectations for Interim meetings? Again drawing on the experience with H2, we held them pretty often (by IETF > standards); seven of them in those two years. IMHO meeting an aggressive > schedule like this requires a high frequency of F2F meeting (and I note the > new IESG statements on this topic with a bit of concern). > > I think it requires a high frequency of interim meetings, but I personally fall more on the "many virtuals, some F2F" side of the spectrum. So it might run to 7 in a single year, but only 1 additional face to face. A lot really depends on where the controversies lie and what needs to be done to reach consensus; I don't think any one map is always right. As I said, just my thinking, Ted > Cheers, > > > > On 4 Jun 2016, at 3:08 AM, Ted Hardie wrote: > > > > Howdy, > > > > The ADs asked the proponents a questions about the values of N > associated with the various places in the charter where we have a > chartering + N line in the milestones. Here's a strawman set of values; > comments on whether it is the right order are probably stage one. They are > a bit aggressive, but then we're an optimistic bunch around here, right? > > > > Ted > > > > ## Milestones > > > > * Chartering + 3 Months: Working group adoption of Core Protocol document > > * Chartering + 3 Months: Working group adoption of Loss detection and > Congestion Control document > > * Chartering + 3 Months: Working group adoption of TLS 1.3 mapping > document > > * Chartering + 6 Months: Working group adoption of HTTP/2 mapping > document > > * Chartering + 6 Months: Working group adoption of Multipath extension > document > > * Chartering + 12 Months: Core Protocol document to IESG > > * Chartering + 12 Months: Loss detection and Congestion Control document > to IESG > > * Chartering + 12 Months: TLS 1.3 Mapping document to IESG > > * Chartering + 18 Months: HTTP/2 mapping document to IESG > > * Chartering + 18 Months: Multipath extension document to IESG > > * Rechartering + 3 Months: Working group adoption of FEC extension > document > > * Rechartering + 12 Months: FEC extension document to IESG > > > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic > > -- > Mark Nottingham https://www.mnot.net/ > > > > > --001a113ceffebc53720534a37026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A couple of replies, just my own opinion.

On Sat, Jun 4, 2016 at 2:33 AM= , Mark Nottingham <mnot@mnot.net> wrote:
My .02 -

Do people really believe that the core document can be done in 9 months? H2= took two years, and that was a pretty aggressive schedule.

I think it's important to have a set of deadlines that people can agree= to as goals. If the milestones are widely viewed as unrealistic, there eff= ectively isn't any pressure to finish, and it can easily blow out to en= dless discussion and iteration.

OTOH if the WG can get consensus to meet its milestones, that can be effect= ive in moving things forward; this is how we did H2. But, it requires achie= vable milestones.


If I can ask you to focus on the H2 ma= pping document, if we were starting from the current doc, what do you think= an achievable milestone would be from adoption of a split document to IESG= submission?=C2=A0
=C2=A0
Lastly for now, what are peoples' expectations for Interim meetings?
Again drawing on the experience wi= th H2, we held them pretty often (by IETF standards); seven of them in thos= e two years. IMHO meeting an aggressive schedule like this requires a high = frequency of F2F meeting (and I note the new IESG statements on this topic = with a bit of concern).

I think it requires a high frequency of interim meeti= ngs, but I personally fall more on the "many virtuals, some F2F" = side of the spectrum.=C2=A0 So it might run to 7 in a single year, but only= 1 additional face to face.=C2=A0 A lot really depends on where the controv= ersies lie and what needs to be done to reach consensus; I don't think = any one map is always right.

As I said, just my thinking,=

Ted

=C2=A0
Cheers,


> On 4 Jun 2016, at 3:08 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Howdy,
>
> The ADs asked the proponents a questions about the values of N associa= ted with the various places in the charter where we have a chartering + N l= ine in the milestones.=C2=A0 Here's a strawman set of values; comments = on whether it is the right order are probably stage one.=C2=A0 They are a b= it aggressive, but then we're an optimistic bunch around here, right? >
> Ted
>
> ## Milestones
>
> * Chartering + 3 Months: Working group adoption of Core Protocol docum= ent
> * Chartering + 3 Months: Working group adoption of Loss detection and = Congestion Control document
> * Chartering + 3 Months: Working group adoption of TLS 1.3 mapping doc= ument
> * Chartering + 6 Months: Working group adoption of HTTP/2 mapping docu= ment
> * Chartering + 6 Months: Working group adoption of Multipath extension= document
> * Chartering + 12 Months: Core Protocol document to IESG
> * Chartering + 12 Months: Loss detection and Congestion Control docume= nt to IESG
> * Chartering + 12 Months: TLS 1.3 Mapping document to IESG
> * Chartering + 18 Months: HTTP/2 mapping document to IESG
> * Chartering + 18 Months: Multipath extension document to IESG
> * Rechartering + 3 Months: Working group adoption of FEC extension doc= ument
> * Rechartering + 12 Months: FEC extension document to IESG
>
> _________________________________________= ______
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/





--001a113ceffebc53720534a37026-- From nobody Mon Jun 6 19:03:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB8012D7D3 for ; Mon, 6 Jun 2016 19:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 GsnJFk76QdHY for ; Mon, 6 Jun 2016 19:03:00 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 E988C12D745 for ; Mon, 6 Jun 2016 19:02:59 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1C74522E257; Mon, 6 Jun 2016 22:02:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: Date: Tue, 7 Jun 2016 12:02:55 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1B9BEB09-ED28-42D5-8904-52C2A74CFB66@mnot.net> References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 02:03:02 -0000 > On 7 Jun 2016, at 8:17 AM, Ted Hardie wrote: >=20 [...] > Personally, I'm assuming that there will be some discussion of the = starting documents when they are still draft-individual-xx; that would = occur on the mailing list during/just after the IESG activity for = chartering. I'd assume that folding any changes that come up during = that section of time would occur before the adoption of them as = draft-ietf-wg-xx. Obviously, you could run this the other way and adopt = draft-individual as-is and republish as a draft-wg before the = substantive changes start; prior to the "replaces" function in the = tracker, I would have suggested that. Having a three-month window = allows you to do it either way, but this is definitely one I see as "no = later than". OK. Personally, if the charter nominated a specific set of documents as = a starting point, I'd make -00 a carbon copy of them on day 1, and = immediately start gathering issues on them. I don't think "replaces" = changes things that much. [...] > I think it requires a high frequency of interim meetings, but I = personally fall more on the "many virtuals, some F2F" side of the = spectrum. So it might run to 7 in a single year, but only 1 additional = face to face. A lot really depends on where the controversies lie and = what needs to be done to reach consensus; I don't think any one map is = always right. Generally agreed. Personally -- and I want to emphasise that -- I think = that having good F2F meetings early in the process is critical when = there are diverse communities and opposing viewpoints, because it helps = socialise people and their perspectives. They need to be F2F and it's = vastly preferable that they're interim, since IETF weeks have so many = other distractions. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 6 19:13:57 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD6912D97E for ; Mon, 6 Jun 2016 19:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 18W_RuKlHvaw for ; Mon, 6 Jun 2016 19:13:53 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 D468812D97C for ; Mon, 6 Jun 2016 19:13:52 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id s187so5291645itd.0 for ; Mon, 06 Jun 2016 19:13:52 -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=ZqYjgV/JzAn26wgG1+6QThp61dLWHLU8qlk2HVe7xiw=; b=oAfMPYZHcCH6ihMgQMZqYYDpvkDF0sYiYS9YUT9uj9jq+zY6QH+496xFl1rB4+SfUk UaKXn1Qxt2ewnbJ+vGgirSoy35/QsNZCqrMDYJoA47MrXQqUgDG5P+laZcWFl9ykHO6m vxNj0KY62CrE9fofki/iO/ZYFGH25iYR3Yt6cDJFXasbI5tNVIde2lm9e5FZCw1zm6zp 3FIJIe2hezuPGRUy++b0RZhMKNk9MiPXsW6qBmNhv43l15MI4kz3RNUjvzizydFxBa38 CCn1SOWoFuig4Zo3yoW0g9GsKx32MRydF0j8dodUuij+gh8GnPQu3dFjEjb+G4Z3mJ/q 4o1Q== 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=ZqYjgV/JzAn26wgG1+6QThp61dLWHLU8qlk2HVe7xiw=; b=lYZ5VRvZ71uivsa8Y3geZoyZdqO0eWbd/O+AZb+Fd/rL7mHcFEpqFZCRYBUuban5li rOYibiX7x81YNjQWOep5GFLhRTYFICdpgbLozARnHTV7rq7NTRO4IhFE5ll8rweArKFh mdLH9uzXPihHPz/WxWyp7Wr04NwtFozeHXz/UAumxdVcbzbkqPkodl988AAALOv30zX6 pcU1o1dB3yqZGbIAZlV/akHPVbKZUsW7sW1e+0/mz0KGsIu7Saf6GPSh3WOU7hmGe6NP /qlxchYuIonaHkVU+r0wg14Xgn76k7TqmXfxKAB4gE9ftPsDQpSgKJkSEae8vwO5/Oxi FCZw== X-Gm-Message-State: ALyK8tKIK+4cSWU2vAjipkQmybxjQ2zgWzJKhZDoCST0wLKWT2EP5RWvDYJyD2knTKrbahgmeOvWZDfLavohnywN X-Received: by 10.107.185.67 with SMTP id j64mr807580iof.32.1465265632078; Mon, 06 Jun 2016 19:13:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.227 with HTTP; Mon, 6 Jun 2016 19:13:32 -0700 (PDT) In-Reply-To: <1B9BEB09-ED28-42D5-8904-52C2A74CFB66@mnot.net> References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> <1B9BEB09-ED28-42D5-8904-52C2A74CFB66@mnot.net> From: Ian Swett Date: Mon, 6 Jun 2016 22:13:32 -0400 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=94eb2c06d0c280d8c50534a6bd0a Archived-At: Cc: Ted Hardie , quic@ietf.org Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 02:13:55 -0000 --94eb2c06d0c280d8c50534a6bd0a Content-Type: text/plain; charset=UTF-8 Thanks Mark, I support both of your suggestions and would be willing to attend as many F2F meetings as we can organize. On Mon, Jun 6, 2016 at 10:02 PM, Mark Nottingham wrote: > > > On 7 Jun 2016, at 8:17 AM, Ted Hardie wrote: > > > [...] > > > Personally, I'm assuming that there will be some discussion of the > starting documents when they are still draft-individual-xx; that would > occur on the mailing list during/just after the IESG activity for > chartering. I'd assume that folding any changes that come up during that > section of time would occur before the adoption of them as > draft-ietf-wg-xx. Obviously, you could run this the other way and adopt > draft-individual as-is and republish as a draft-wg before the substantive > changes start; prior to the "replaces" function in the tracker, I would > have suggested that. Having a three-month window allows you to do it > either way, but this is definitely one I see as "no later than". > > OK. Personally, if the charter nominated a specific set of documents as a > starting point, I'd make -00 a carbon copy of them on day 1, and > immediately start gathering issues on them. I don't think "replaces" > changes things that much. > > [...] > > > I think it requires a high frequency of interim meetings, but I > personally fall more on the "many virtuals, some F2F" side of the > spectrum. So it might run to 7 in a single year, but only 1 additional > face to face. A lot really depends on where the controversies lie and what > needs to be done to reach consensus; I don't think any one map is always > right. > > Generally agreed. Personally -- and I want to emphasise that -- I think > that having good F2F meetings early in the process is critical when there > are diverse communities and opposing viewpoints, because it helps socialise > people and their perspectives. They need to be F2F and it's vastly > preferable that they're interim, since IETF weeks have so many other > distractions. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --94eb2c06d0c280d8c50534a6bd0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Mark, I support both of your suggestions and would = be willing to attend as many F2F meetings as we can organize.

On Mon, Jun 6, 2016 at 10= :02 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 7 Jun 2016, at 8:17 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
[...]

> Personally, I'm assuming that there will be some discussion of the= starting documents when they are still draft-individual-xx; that would occ= ur on the mailing list during/just after the IESG activity for chartering.= =C2=A0 I'd assume that folding any changes that come up during that sec= tion of time would occur before the adoption of them as draft-ietf-wg-xx.= =C2=A0 Obviously, you could run this the other way and adopt draft-individu= al as-is and republish as a draft-wg before the substantive changes start; = prior to the "replaces" function in the tracker, I would have sug= gested that.=C2=A0 Having a three-month window allows you to do it either w= ay, but this is definitely one I see as "no later than".

OK. Personally, if the charter nominated a specific set of documents= as a starting point, I'd make -00 a carbon copy of them on day 1, and = immediately start gathering issues on them. I don't think "replace= s" changes things that much.

[...]

> I think it requires a high frequency of interim meetings, but I person= ally fall more on the "many virtuals, some F2F" side of the spect= rum.=C2=A0 So it might run to 7 in a single year, but only 1 additional fac= e to face.=C2=A0 A lot really depends on where the controversies lie and wh= at needs to be done to reach consensus; I don't think any one map is al= ways right.

Generally agreed. Personally -- and I want to emphasise that -- I th= ink that having good F2F meetings early in the process is critical when the= re are diverse communities and opposing viewpoints, because it helps social= ise people and their perspectives. They need to be F2F and it's vastly = preferable that they're interim, since IETF weeks have so many other di= stractions.

Cheers,


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

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

--94eb2c06d0c280d8c50534a6bd0a-- From nobody Mon Jun 6 23:59:09 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF1312D1AF for ; Mon, 6 Jun 2016 23:59:07 -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 4ZBKcpa2ts1L for ; Mon, 6 Jun 2016 23:59:05 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 4CA3812B056 for ; Mon, 6 Jun 2016 23:59:05 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id c127so161564588ywb.1 for ; Mon, 06 Jun 2016 23:59: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=J+B4TZImUqXH94z3TjDbTLGsPIw/7O3EX+BnykO0Tss=; b=NkIb/ldq2I5CUVA/x7HbPOi0coGk7fYx8hTr4MwaUsN/yrYAjebcTDRST2WBl4RgAj wivLvG6GfXaAY3npgL5L0Ksbm9eT7ZWhgyJ1r1QpYFZqgWJa79rThtVUAAN/POt7lciv TzAa2mYyyrhNYyNXEwgYKbV9r+tARNwgiALlvWQ4+Z2gvX+qE7MuWUG10b4ch/3qM2fi Ord53lq6WOJrVP7jaT6n/M8fDK4rAgZ9N8fqFq739+LUyWrnQowM1VWHHWcXK1+dWZGc xYqlBtX6+4VySQQ2eZr4LOdEz9ttVXSCjLT1mnTKHWjljV49rTfqnWr6dQs2ckUHnM+T BaNg== 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=J+B4TZImUqXH94z3TjDbTLGsPIw/7O3EX+BnykO0Tss=; b=VU/pd7p44NU66lh1xbdpirX7rpQTC2VY8jy2qUDIyFx/qI7r4yP9DmWbDv6ic29+MB XIDx68NG7jympML3s/75a44MPxjWa5+ZjhRyhG3z0Sz9CJE3/3as8g+V1hCnm9Wvs222 3X7p/JPScvyXL5ZtvYCtkDCmv7F/poRZioM/BeOyICNJOv9q2t79HBvssavLlABBaGzH bOb6dFK7G0doyOJvC0Uvs34qaSHykeGM6etgKT3yYOC7jVKi8q0NvvSQd3YQEIkSUx02 m14O+evInDAdjQtsXMuYGxRH5sRzqNpTSpfU9NT56X8iWaMukKdZFDdi24DbwCHI1Vaf Ai3w== X-Gm-Message-State: ALyK8tKaPU0FLYVgMSs3vDCG/rMNULwroZQ2U5pAOT9Ehmm2hhfZJwZiByWmutKv+iqwG+qm6DSjM+IH4Y18BjaZ X-Received: by 10.13.249.129 with SMTP id j123mr14287567ywf.188.1465282744108; Mon, 06 Jun 2016 23:59:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Mon, 6 Jun 2016 23:59:03 -0700 (PDT) In-Reply-To: References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> <1B9BEB09-ED28-42D5-8904-52C2A74CFB66@mnot.net> From: Jana Iyengar Date: Mon, 6 Jun 2016 23:59:03 -0700 Message-ID: To: Ian Swett Content-Type: multipart/alternative; boundary=94eb2c0827ba75b47a0534aab9ea Archived-At: Cc: Mark Nottingham , quic@ietf.org, Ted Hardie Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 06:59:08 -0000 --94eb2c0827ba75b47a0534aab9ea Content-Type: text/plain; charset=UTF-8 A few thoughts, as I catch up on this thread: - I do not have a strong opinion on the Charter + 3 months on adoption of -00 documents. I can see that having a 3-month window allows for any delays, just in case there is discussion, but if we adopt the feeder individual documents as -00 on day 1, then we just met the deadline early. I see the work on the documents as having starter as soon as the Charter is adopted anyways. - IMO, the document deadlines are a bit too aggressive. I'd love to get the core documents done within 1 year, but going by our track-record with HTTP/2, which took 2 years, and MPTCP, which took 5 years, the current deadlines seem too aggressive. - I'd like to suggest that we push the beginning of the multipath work to later in the cycle, to allow for the core documents to make progress before we add another document in the mix. Based on these thoughts, I'll suggest the following changes: * Chartering + 12 Months: Working group adoption of Multipath extension document * Chartering + 18 Months: Core Protocol document to IESG * Chartering + 18 Months: Loss detection and Congestion Control document to IESG * Chartering + 18 Months: TLS 1.3 Mapping document to IESG * Chartering + 24 Months: HTTP/2 mapping document to IESG * Chartering + 30 Months: Multipath extension document to IESG I agree that we should have more interims especially in the first year. I also agree with Mark's sentiment that we should try to do more F2F meetings in the first year as well. - jana On Mon, Jun 6, 2016 at 7:13 PM, Ian Swett wrote: > Thanks Mark, I support both of your suggestions and would be willing to > attend as many F2F meetings as we can organize. > > On Mon, Jun 6, 2016 at 10:02 PM, Mark Nottingham wrote: > >> >> > On 7 Jun 2016, at 8:17 AM, Ted Hardie wrote: >> > >> [...] >> >> > Personally, I'm assuming that there will be some discussion of the >> starting documents when they are still draft-individual-xx; that would >> occur on the mailing list during/just after the IESG activity for >> chartering. I'd assume that folding any changes that come up during that >> section of time would occur before the adoption of them as >> draft-ietf-wg-xx. Obviously, you could run this the other way and adopt >> draft-individual as-is and republish as a draft-wg before the substantive >> changes start; prior to the "replaces" function in the tracker, I would >> have suggested that. Having a three-month window allows you to do it >> either way, but this is definitely one I see as "no later than". >> >> OK. Personally, if the charter nominated a specific set of documents as a >> starting point, I'd make -00 a carbon copy of them on day 1, and >> immediately start gathering issues on them. I don't think "replaces" >> changes things that much. >> >> [...] >> >> > I think it requires a high frequency of interim meetings, but I >> personally fall more on the "many virtuals, some F2F" side of the >> spectrum. So it might run to 7 in a single year, but only 1 additional >> face to face. A lot really depends on where the controversies lie and what >> needs to be done to reach consensus; I don't think any one map is always >> right. >> >> Generally agreed. Personally -- and I want to emphasise that -- I think >> that having good F2F meetings early in the process is critical when there >> are diverse communities and opposing viewpoints, because it helps socialise >> people and their perspectives. They need to be F2F and it's vastly >> preferable that they're interim, since IETF weeks have so many other >> distractions. >> >> Cheers, >> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >> > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --94eb2c0827ba75b47a0534aab9ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A few thoughts, as I catch up on this thread:

- I do not have a strong opinion on the Charter + 3 months on adopti= on of -00 documents. I can see that having a 3-month window allows for any = delays, just in case there is discussion, but if we adopt the feeder indivi= dual documents as -00 on day 1, then we just met the deadline early. I see = the work on the documents as having starter as soon as the Charter is adopt= ed anyways.

- IMO, the document deadlines are a bi= t too aggressive. I'd love to get the core documents done within 1 year= , but going by our track-record with HTTP/2, which took 2 years, and MPTCP,= which took 5 years, the current deadlines seem too aggressive.
<= br>
- I'd like to suggest that we push the beginning of the m= ultipath work to later in the cycle, to allow for the core documents to mak= e progress before we add another document in the mix.=C2=A0

<= /div>
Based on these thoughts, I'll suggest the following changes:<= /div>
* Chartering + 12 Months: Working group adoption of Multipat= h extension document
* Chartering + 18 Months: Core Protocol docu= ment to IESG
* Chartering + 18 Months: Loss detection and Congest= ion Control document to IESG
* Chartering + 18 Months: TLS 1.3 Ma= pping document to IESG
* Chartering + 24 Months: HTTP/2 mapping d= ocument to IESG
* Chartering + 30 Months: Multipath extension doc= ument to IESG

I agree that we should have mo= re interims especially in the first year. I also agree with Mark's sent= iment that we should try to do more F2F meetings in the first year as well.=

- jana


<= div class=3D"gmail_extra">
On Mon, Jun 6, 201= 6 at 7:13 PM, Ian Swett <ianswett@google.com> wrote:
Thanks Mark, I support both o= f your suggestions and would be willing to attend as many F2F meetings as w= e can organize.

On Mon, Jun 6, 2016 at 10:02 PM= , Mark Nottingham <mnot@mnot.net> wrote:

> On 7 Jun 2016, at 8:17 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
[...]

> Personally, I'm assuming that there will be some discussion of the= starting documents when they are still draft-individual-xx; that would occ= ur on the mailing list during/just after the IESG activity for chartering.= =C2=A0 I'd assume that folding any changes that come up during that sec= tion of time would occur before the adoption of them as draft-ietf-wg-xx.= =C2=A0 Obviously, you could run this the other way and adopt draft-individu= al as-is and republish as a draft-wg before the substantive changes start; = prior to the "replaces" function in the tracker, I would have sug= gested that.=C2=A0 Having a three-month window allows you to do it either w= ay, but this is definitely one I see as "no later than".

OK. Personally, if the charter nominated a specific set of documents= as a starting point, I'd make -00 a carbon copy of them on day 1, and = immediately start gathering issues on them. I don't think "replace= s" changes things that much.

[...]

> I think it requires a high frequency of interim meetings, but I person= ally fall more on the "many virtuals, some F2F" side of the spect= rum.=C2=A0 So it might run to 7 in a single year, but only 1 additional fac= e to face.=C2=A0 A lot really depends on where the controversies lie and wh= at needs to be done to reach consensus; I don't think any one map is al= ways right.

Generally agreed. Personally -- and I want to emphasise that -- I th= ink that having good F2F meetings early in the process is critical when the= re are diverse communities and opposing viewpoints, because it helps social= ise people and their perspectives. They need to be F2F and it's vastly = preferable that they're interim, since IETF weeks have so many other di= stractions.

Cheers,


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

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


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


--94eb2c0827ba75b47a0534aab9ea-- From nobody Tue Jun 7 01:23:20 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46012B030 for ; Tue, 7 Jun 2016 01:23:18 -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 56fxp5oevT8O for ; Tue, 7 Jun 2016 01:23:15 -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 6358112B011 for ; Tue, 7 Jun 2016 01:23:15 -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 1bACI4-0006YO-L9; Tue, 07 Jun 2016 10:23:12 +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 1bACI4-0003I8-6b; Tue, 07 Jun 2016 10:23:12 +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: Date: Tue, 7 Jun 2016 10:23:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: Ian Swett X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 10 sum msgs/h 5 total rcpts 42711 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: 92A6D70C8E3F4C3267D7EAE52DC3C75325C42783 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 10267 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , quic@ietf.org Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 08:23:18 -0000 Actually - now I have more questions, below; I'm just curious about = these things - (snip) > >>> 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, > >> > >> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP > >> >=20 > But Chrome his privileges to write QUIC over a dedicated protocol = number on ~0% of the clients it's running on, which further increases = the barrier beyond the complexity of a 3-way race. A 2-way race with = v4/v6 happy eyeballs is quite complex and difficult to get right. So Chrome can't even be a root process on Android? I know almost nothing = about Android but I find that strange - Google develops an OS and its = own browser is then so limited in it? And a thought about the "3-way race": I understand that you're working = hard to get QUIC to operate ASAP, which explains the complexity of your = 2-way race. However, if you were to try QUIC/native too, this could have = a much lower priority - you could send an occasional SYN-type packet = much later, and cache a positive result if you get one. Surely this = cache will be valid for some time, and surely browsers open many = connections to the same site, not only all in one go but also with delay = (e.g.: I go to Google, I type in a search, I click on a result - 3 = consecutive interactions with the same server, all with delay in = between). Cheers, Michael From nobody Tue Jun 7 02:15:38 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A97F12D531 for ; Tue, 7 Jun 2016 02:15: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 7WP-PPVtRZ_C for ; Tue, 7 Jun 2016 02:15:34 -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 CA5B412D533 for ; Tue, 7 Jun 2016 02:15:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0F2C9D9304; Tue, 7 Jun 2016 11:15:31 +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 2xtcvw2Lgc0N; Tue, 7 Jun 2016 11:15:30 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2B24.dip0.t-ipconnect.de [93.236.43.36]) (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 99A3FD9302; Tue, 7 Jun 2016 11:15:30 +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: Tue, 7 Jun 2016 11:15:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49703677-6135-4CDC-A60E-CAFBFEA701B8@tik.ee.ethz.ch> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , Ian Swett , quic@ietf.org Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 09:15:36 -0000 Hi Michael, I don=E2=80=99t even really see your point in using e.g. quic natively. = I mean sure that was the original idea, but all that UDP gives is you is = port numbers, at a well defined position in the header. Given that a = bunch of things operate on a 4- or 5-tuple, you need port numbers anyway = and they are basically not really end-to-end anymore. Mirja > Am 07.06.2016 um 10:23 schrieb Michael Welzl : >=20 > Actually - now I have more questions, below; I'm just curious about = these things - >=20 > (snip) >=20 >=20 >>>>> 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 >>>> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP >>>>=20 >>=20 >> But Chrome his privileges to write QUIC over a dedicated protocol = number on ~0% of the clients it's running on, which further increases = the barrier beyond the complexity of a 3-way race. A 2-way race with = v4/v6 happy eyeballs is quite complex and difficult to get right. >=20 > So Chrome can't even be a root process on Android? I know almost = nothing about Android but I find that strange - Google develops an OS = and its own browser is then so limited in it? >=20 > And a thought about the "3-way race": I understand that you're working = hard to get QUIC to operate ASAP, which explains the complexity of your = 2-way race. However, if you were to try QUIC/native too, this could have = a much lower priority - you could send an occasional SYN-type packet = much later, and cache a positive result if you get one. Surely this = cache will be valid for some time, and surely browsers open many = connections to the same site, not only all in one go but also with delay = (e.g.: I go to Google, I type in a search, I click on a result - 3 = consecutive interactions with the same server, all with delay in = between). >=20 > Cheers, > Michael >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Tue Jun 7 03:03:44 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2E12D606 for ; Tue, 7 Jun 2016 03:03: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 gXwlh58RsGow for ; Tue, 7 Jun 2016 03:03: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 2C2D112D614 for ; Tue, 7 Jun 2016 03:03:40 -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 1bADrF-0007Fj-Ir; Tue, 07 Jun 2016 12:03:37 +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 1bADrE-00007N-W5; Tue, 07 Jun 2016 12:03:37 +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: <49703677-6135-4CDC-A60E-CAFBFEA701B8@tik.ee.ethz.ch> Date: Tue, 7 Jun 2016 12:03:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <749ECC25-C46B-43BE-95F0-EFC53106A0E0@ifi.uio.no> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> <49703677-6135-4CDC-A60E-CAFBFEA701B8@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 11 sum msgs/h 5 total rcpts 42726 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: 452FB3237762BF2A156FC866B328150BC89BC3C9 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 10275 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , Ian Swett , quic@ietf.org Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 10:03:43 -0000 ACK that - just talking about possibilities but maybe it's a waste of = time to even talk about it - I was just curious, that's why I asked my = questions below. But I don't have an issue with using UDP and agree with you. > On 07 Jun 2016, at 11:15, Mirja K=C3=BChlewind = wrote: >=20 > Hi Michael, >=20 > I don=E2=80=99t even really see your point in using e.g. quic = natively. I mean sure that was the original idea, but all that UDP gives = is you is port numbers, at a well defined position in the header. Given = that a bunch of things operate on a 4- or 5-tuple, you need port numbers = anyway and they are basically not really end-to-end anymore. >=20 > Mirja >=20 >=20 >> Am 07.06.2016 um 10:23 schrieb Michael Welzl : >>=20 >> Actually - now I have more questions, below; I'm just curious about = these things - >>=20 >> (snip) >>=20 >>=20 >>>>>> 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 >>>>> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP >>>>>=20 >>>=20 >>> But Chrome his privileges to write QUIC over a dedicated protocol = number on ~0% of the clients it's running on, which further increases = the barrier beyond the complexity of a 3-way race. A 2-way race with = v4/v6 happy eyeballs is quite complex and difficult to get right. >>=20 >> So Chrome can't even be a root process on Android? I know almost = nothing about Android but I find that strange - Google develops an OS = and its own browser is then so limited in it? >>=20 >> And a thought about the "3-way race": I understand that you're = working hard to get QUIC to operate ASAP, which explains the complexity = of your 2-way race. However, if you were to try QUIC/native too, this = could have a much lower priority - you could send an occasional SYN-type = packet much later, and cache a positive result if you get one. Surely = this cache will be valid for some time, and surely browsers open many = connections to the same site, not only all in one go but also with delay = (e.g.: I go to Google, I type in a search, I click on a result - 3 = consecutive interactions with the same server, all with delay in = between). >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >=20 From nobody Tue Jun 7 06:46:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F122812D0DC for ; Tue, 7 Jun 2016 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZfQO22MVCMtU for ; Tue, 7 Jun 2016 06:45:59 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 CE38D12B03A for ; Tue, 7 Jun 2016 06:45:58 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h62so25370422itb.1 for ; Tue, 07 Jun 2016 06:45:58 -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=L8p7u3LnLSahMMFlSKG65o9cL7zmXcLyYZVEXNHMkEM=; b=AhcPYDHuotVLHjL4T5CO6iPKaytCVLhgjuFhr6vq5a54Csl1jtclm1dHrNysvjY1FB AjsYx+zaxO0IL5V23og3srP+8gCNMU8foSKjHBeT4486id+663q7d+HSkrnpcHCs6QGg 2/VOVdYtvYeIchydKFoZblNnq8beRhYEmUFUbI04zlR1nKQt2FYYni79pTgD+f7p49uU c3L1/DBgL7GU2gDbjOQoX1kAwebRgNEJE3OnuQkBff2UQ47NUvaKqUPv4RNBDgjhbpMZ 7aaQBcyvZN99GJbEr/eMO3fSw6af1KBCDje367dllbip/lBAlDoJp78ubauPU4doEcOZ cGHw== 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=L8p7u3LnLSahMMFlSKG65o9cL7zmXcLyYZVEXNHMkEM=; b=V3OigYatE8nOaUWf5eRucqNll0Y6d9NUuxfZfxkDng5McACesKR8KBt8SpU0qG1yZ8 Kdtk3wbvcKaB1k2SOh735LfSm7ArlF/R0v/V1r2Uq24lgFPmI/I+55LNXzR/fR5zBjM5 fizJsi1nfCJ8OpmZRXguuJqLNmmMcx248+fJ0tEX8XtH7PRnCflsjTiiZetjYneKvvQr UJlTvkT/jJPn3AEuE95NVnages4QZrWkCjZY5sSlzSVKby35mUEt7ct9SNpOAcqwAjZP 3rXg5kxET9M+aSWNhSZLKGQ/KDzFg0dIzqGqvmICYItliS2qgrLM1EXQT899H1W9PwzN Uw3w== X-Gm-Message-State: ALyK8tKc/RSbhULcyn0kmypLAgbuVco8p58sYb5YIfoVT7A1SKMeOM6A1ZAKtP0cwZ6w/IyhzVeyAQkzahk4Civx X-Received: by 10.36.0.207 with SMTP id 198mr625751ita.30.1465307157310; Tue, 07 Jun 2016 06:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.227 with HTTP; Tue, 7 Jun 2016 06:45:37 -0700 (PDT) In-Reply-To: <749ECC25-C46B-43BE-95F0-EFC53106A0E0@ifi.uio.no> References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com> <035AC810-E5E4-45E2-A4F8-05C9F31A7F3D@trammell.ch> <49703677-6135-4CDC-A60E-CAFBFEA701B8@tik.ee.ethz.ch> <749ECC25-C46B-43BE-95F0-EFC53106A0E0@ifi.uio.no> From: Ian Swett Date: Tue, 7 Jun 2016 09:45:37 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c1418e9981e60534b068e2 Archived-At: Cc: Brian Trammell , quic@ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [QUIC] Blocking, falling back X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 13:46:01 -0000 --001a11c1418e9981e60534b068e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 7, 2016 at 6:03 AM, Michael Welzl wrote: > ACK that - just talking about possibilities but maybe it's a waste of tim= e > to even talk about it - I was just curious, that's why I asked my questio= ns > below. > But I don't have an issue with using UDP and agree with you. > > > > On 07 Jun 2016, at 11:15, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > > > Hi Michael, > > > > I don=E2=80=99t even really see your point in using e.g. quic natively.= I mean > sure that was the original idea, but all that UDP gives is you is port > numbers, at a well defined position in the header. Given that a bunch of > things operate on a 4- or 5-tuple, you need port numbers anyway and they > are basically not really end-to-end anymore. > > > > Mirja > > > > > >> Am 07.06.2016 um 10:23 schrieb Michael Welzl : > >> > >> Actually - now I have more questions, below; I'm just curious about > these things - > >> > >> (snip) > >> > >> > >>>>>> 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 "automate= d > fallback" elements of QUIC, > >>>>> > >>>>> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP > >>>>> > >>> > >>> But Chrome his privileges to write QUIC over a dedicated protocol > number on ~0% of the clients it's running on, which further increases the > barrier beyond the complexity of a 3-way race. A 2-way race with v4/v6 > happy eyeballs is quite complex and difficult to get right. > >> > >> So Chrome can't even be a root process on Android? I know almost > nothing about Android but I find that strange - Google develops an OS and > its own browser is then so limited in it? > >> > I don't believe so. Chrome is just a normal app. If it was root, I think that would increase the chances of cross-app security issues. > >> And a thought about the "3-way race": I understand that you're working > hard to get QUIC to operate ASAP, which explains the complexity of your > 2-way race. However, if you were to try QUIC/native too, this could have = a > much lower priority - you could send an occasional SYN-type packet much > later, and cache a positive result if you get one. Surely this cache will > be valid for some time, and surely browsers open many connections to the > same site, not only all in one go but also with delay (e.g.: I go to > Google, I type in a search, I click on a result - 3 consecutive > interactions with the same server, all with delay in between). > On a desktop, today this likely works ok because one's connectivity rarely changes. On a laptop, it's probably not terrible, though you may change a few times a day. On a phone, it's much harder, because phones change IPs and networks all the time. > >> > >> Cheers, > >> Michael > >> > >> _______________________________________________ > >> QUIC mailing list > >> QUIC@ietf.org > >> https://www.ietf.org/mailman/listinfo/quic > > > > --001a11c1418e9981e60534b068e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 7, 2016 at 6:03 AM, Michael Welzl <michawe@ifi.uio.no> wrote:=
ACK that - just talking about possibilities but maybe = it's a waste of time to even talk about it - I was just curious, that&#= 39;s why I asked my questions below.
But I don't have an issue with using UDP and agree with you.


> On 07 Jun 2016, at 11:15, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wro= te:
>
> Hi Michael,
>
> I don=E2=80=99t even really see your point in using e.g. quic natively= . I mean sure that was the original idea, but all that UDP gives is you is = port numbers, at a well defined position in the header. Given that a bunch = of things operate on a 4- or 5-tuple, you need port numbers anyway and they= are basically not really end-to-end anymore.
>
> Mirja
>
>
>> Am 07.06.2016 um 10:23 schrieb Michael Welzl <michawe@ifi.uio.no>:
>>
>> Actually - now I have more questions, below; I'm just curious = about these things -
>>
>> (snip)
>>
>>
>>>>>> It turns out that even UDP is partially blocked (a= s recently as 2011) by paths to 5-7% of all chrome clients, which lead to t= he "automated fallback" elements of QUIC,
>>>>>
>>>>> You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TC= P
>>>>>
>>>
>>> But Chrome his privileges to write QUIC over a dedicated proto= col number on ~0% of the clients it's running on, which further increas= es the barrier beyond the complexity of a 3-way race.=C2=A0 A 2-way race wi= th=C2=A0 v4/v6 happy eyeballs is quite complex and difficult to get right.<= br> >>
>> So Chrome can't even be a root process on Android? I know almo= st nothing about Android but I find that strange - Google develops an OS an= d its own browser is then so limited in it?
>>

I don't believ= e so.=C2=A0 Chrome is just a normal app.=C2=A0 If it was root, I think that= would increase the chances of cross-app security issues.
=C2=A0<= /div>
>> And a thought about the "3-way race": I understand that = you're working hard to get QUIC to operate ASAP, which explains the com= plexity of your 2-way race. However, if you were to try QUIC/native too, th= is could have a much lower priority - you could send an occasional SYN-type= packet much later, and cache a positive result if you get one. Surely this= cache will be valid for some time, and surely browsers open many connectio= ns to the same site, not only all in one go but also with delay (e.g.: I go= to Google, I type in a search, I click on a result - 3 consecutive interac= tions with the same server, all with delay in between).

On a desktop, today this likely works ok becau= se one's connectivity rarely changes.=C2=A0 On a laptop, it's proba= bly not terrible, though you may change a few times a day.=C2=A0 On a phone= , it's much harder, because phones change IPs and networks all the time= . =C2=A0
=C2=A0
>>
>> Cheers,
>> Michael
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>


<= /div> --001a11c1418e9981e60534b068e2-- From nobody Tue Jun 7 09:42:27 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D6312D7CD for ; Tue, 7 Jun 2016 09:42:24 -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 z6Lo3KlOGFF2 for ; Tue, 7 Jun 2016 09:42:22 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 AC5DD12D7C3 for ; Tue, 7 Jun 2016 09:42:22 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id e72so285815804oib.1 for ; Tue, 07 Jun 2016 09:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oe3gRdoyZ8CcKJGNIE3UTFW/lOKHhbBNvZmlmXWj/zI=; b=xMVoCBEgUotDWZN8+PEC7QczqsKQQsPhlnEVHxpVUL4Iq5zLkRL1MWhhSz9ULnBcw6 BfN3eOOTEM2nu7GjLpO/4L3Mw2RsWZROGnfotpH5/7PmCLaU3UFEN5R/17lfQjMVgVeQ 4tHK5e4IsfkuRJzdz9Ec6BSuBeJ9CjbK7TDjY5mPSW33HJQpQTOt3jHlsl+UeSWDNefV bE73tNiHfyOoHJGnRpnBW/CC7leBeuLQvGWdQQYqAT/EL+/rf22NlhLIRXjP1T2PTMoR DgySxIJqpJ/siS4RtHSHN2D43NfLcCdb4YDaSusSzi3RRpQ8oqV7nQjHscbcjlAMgvjC ckGA== 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=oe3gRdoyZ8CcKJGNIE3UTFW/lOKHhbBNvZmlmXWj/zI=; b=ID5Y0M4CmOQwGjyZDyppxts9pJc7lmHExRx43qUO2SagmcOxWzssspTDEfb3leiVV6 EI2BCGUjewLqPH+O916K30rCVJqmv2R1wOWs+Szl88vKj/831T0g3JM294wA8UIqbu5s rfaZS8mblYSOEhHGT+t5pAhiYnnAaiif4DKLYZXAWfFaXE6M1oNRfLWDCz6onfuDmx0r 5v5KHOKfFXoaX/PKJbDk8NY2sa6cEy9nfuhHLnD4mUZg0dHdWCT2KZlkLWViY+Cj0lsQ 9QuqvG6y9f863H8+oBhprBRO2EukbVwkOHVrjzh8ruq8J/P4wa0p5v2zgj9gGTcsd5j9 SpNw== X-Gm-Message-State: ALyK8tLBQFI02qnhl/xnnjq7zuLb4omQu9mJYKLseZIqSyaMrPtKcvOKknri4gCq5SKkKiYVaUrhnK9iP4K6hg== X-Received: by 10.202.48.18 with SMTP id w18mr211904oiw.61.1465317741935; Tue, 07 Jun 2016 09:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Tue, 7 Jun 2016 09:42:02 -0700 (PDT) In-Reply-To: References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> <1B9BEB09-ED28-42D5-8904-52C2A74CFB66@mnot.net> From: Ted Hardie Date: Tue, 7 Jun 2016 09:42:02 -0700 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a113cd59c7dc4970534b2dff9 Archived-At: Cc: Ian Swett , quic@ietf.org, Mark Nottingham Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:42:25 -0000 --001a113cd59c7dc4970534b2dff9 Content-Type: text/plain; charset=UTF-8 Jana, do you want to put this in a PR, so we can track this suggestion against the current text? I'd like to get a sense of what update to make prior to the BoF call on Friday. My current sense is that, while there is some discussion of the chartering + 3 milestones, the basic conclusion is that this is more-or-less a style issue. I propose we leave the resolution to the ADs, and adopt either approach they prefer. For the other milestones, there are two basic suggestions: move the dates out in the strawman PR https://github.com/IETF-QUIC/Charter/pull/6/files by 6 to 12 months (but leave the ordering); re-order so that multipath shifts later (as per Jana's message above). It also seems like there is general agreement that virtual meetings will be needed to make this pace work. I think we should probably say that in the charter, with something like "In order to achieve the milestones set out below, the group expects to make extensive use of interim meetings, especially in its first year". Would that make sense to people, inserted just above the milestones? Ted On Mon, Jun 6, 2016 at 11:59 PM, Jana Iyengar wrote: > A few thoughts, as I catch up on this thread: > > - I do not have a strong opinion on the Charter + 3 months on adoption of > -00 documents. I can see that having a 3-month window allows for any > delays, just in case there is discussion, but if we adopt the feeder > individual documents as -00 on day 1, then we just met the deadline early. > I see the work on the documents as having starter as soon as the Charter is > adopted anyways. > > - IMO, the document deadlines are a bit too aggressive. I'd love to get > the core documents done within 1 year, but going by our track-record with > HTTP/2, which took 2 years, and MPTCP, which took 5 years, the current > deadlines seem too aggressive. > > - I'd like to suggest that we push the beginning of the multipath work to > later in the cycle, to allow for the core documents to make progress before > we add another document in the mix. > > Based on these thoughts, I'll suggest the following changes: > * Chartering + 12 Months: Working group adoption of Multipath extension > document > * Chartering + 18 Months: Core Protocol document to IESG > * Chartering + 18 Months: Loss detection and Congestion Control document > to IESG > * Chartering + 18 Months: TLS 1.3 Mapping document to IESG > * Chartering + 24 Months: HTTP/2 mapping document to IESG > * Chartering + 30 Months: Multipath extension document to IESG > > I agree that we should have more interims especially in the first year. I > also agree with Mark's sentiment that we should try to do more F2F meetings > in the first year as well. > > - jana > > > > On Mon, Jun 6, 2016 at 7:13 PM, Ian Swett wrote: > >> Thanks Mark, I support both of your suggestions and would be willing to >> attend as many F2F meetings as we can organize. >> >> On Mon, Jun 6, 2016 at 10:02 PM, Mark Nottingham wrote: >> >>> >>> > On 7 Jun 2016, at 8:17 AM, Ted Hardie wrote: >>> > >>> [...] >>> >>> > Personally, I'm assuming that there will be some discussion of the >>> starting documents when they are still draft-individual-xx; that would >>> occur on the mailing list during/just after the IESG activity for >>> chartering. I'd assume that folding any changes that come up during that >>> section of time would occur before the adoption of them as >>> draft-ietf-wg-xx. Obviously, you could run this the other way and adopt >>> draft-individual as-is and republish as a draft-wg before the substantive >>> changes start; prior to the "replaces" function in the tracker, I would >>> have suggested that. Having a three-month window allows you to do it >>> either way, but this is definitely one I see as "no later than". >>> >>> OK. Personally, if the charter nominated a specific set of documents as >>> a starting point, I'd make -00 a carbon copy of them on day 1, and >>> immediately start gathering issues on them. I don't think "replaces" >>> changes things that much. >>> >>> [...] >>> >>> > I think it requires a high frequency of interim meetings, but I >>> personally fall more on the "many virtuals, some F2F" side of the >>> spectrum. So it might run to 7 in a single year, but only 1 additional >>> face to face. A lot really depends on where the controversies lie and what >>> needs to be done to reach consensus; I don't think any one map is always >>> right. >>> >>> Generally agreed. Personally -- and I want to emphasise that -- I think >>> that having good F2F meetings early in the process is critical when there >>> are diverse communities and opposing viewpoints, because it helps socialise >>> people and their perspectives. They need to be F2F and it's vastly >>> preferable that they're interim, since IETF weeks have so many other >>> distractions. >>> >>> Cheers, >>> >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> _______________________________________________ >>> QUIC mailing list >>> QUIC@ietf.org >>> https://www.ietf.org/mailman/listinfo/quic >>> >> >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >> >> > --001a113cd59c7dc4970534b2dff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jana, do you want to put this in a PR,= so we can track this suggestion against the current text?

I&#= 39;d like to get a sense of what update to make prior to the BoF call on Fr= iday.=C2=A0 My current sense is that, while there is some discussion of the= chartering + 3 milestones, the basic conclusion is that this is more-or-le= ss a style issue.=C2=A0 I propose we leave the resolution to the ADs, and a= dopt either approach they prefer.

For the other milestones, th= ere are two basic suggestions:=C2=A0 move the dates out in the strawman PR = https://githu= b.com/IETF-QUIC/Charter/pull/6/files by 6 to 12 months (but leave the o= rdering); re-order so that multipath shifts later (as per Jana's messag= e above).

It also seems like there is general agreement that v= irtual meetings will be needed to make this pace work.=C2=A0 I think we sho= uld probably say that in the charter, with something like "In order to= achieve the milestones set out below, the group expects to make extensive = use of interim meetings, especially in its first year".=C2=A0 Would th= at make sense to people, inserted just above the milestones?

T= ed


On Mon, Jun 6, 2016 at 11:59 PM, Jana Iyengar <jri@google= .com> wrote:
A few thoughts, as I catch up on this thread:
- I do not have a strong opinion on the Charter + 3 months on a= doption of -00 documents. I can see that having a 3-month window allows for= any delays, just in case there is discussion, but if we adopt the feeder i= ndividual documents as -00 on day 1, then we just met the deadline early. I= see the work on the documents as having starter as soon as the Charter is = adopted anyways.

- IMO, the document deadlines are= a bit too aggressive. I'd love to get the core documents done within 1= year, but going by our track-record with HTTP/2, which took 2 years, and M= PTCP, which took 5 years, the current deadlines seem too aggressive.
<= div>
- I'd like to suggest that we push the beginning of = the multipath work to later in the cycle, to allow for the core documents t= o make progress before we add another document in the mix.=C2=A0
=
Based on these thoughts, I'll suggest the following chan= ges:
* Chartering + 12 Months: Working group adoption of Mul= tipath extension document
* Chartering + 18 Months: Core Protocol= document to IESG
* Chartering + 18 Months: Loss detection and Co= ngestion Control document to IESG
* Chartering + 18 Months: TLS 1= .3 Mapping document to IESG
* Chartering + 24 Months: HTTP/2 mapp= ing document to IESG
* Chartering + 30 Months: Multipath extensio= n document to IESG

I agree that we should ha= ve more interims especially in the first year. I also agree with Mark's= sentiment that we should try to do more F2F meetings in the first year as = well.

- j= ana


=

On Mon, Jun 6, 2016 at 7:13 PM, Ian Swett <ianswett@google.com><= /span> wrote:
Thanks Mark, I support both of your suggestions and would be willi= ng to attend as many F2F meetings as we can organize.

On Mon, Jun 6, 2016 at = 10:02 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 7 Jun 2016, at 8:17 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
[...]

> Personally, I'm assuming that there will be some discussion of the= starting documents when they are still draft-individual-xx; that would occ= ur on the mailing list during/just after the IESG activity for chartering.= =C2=A0 I'd assume that folding any changes that come up during that sec= tion of time would occur before the adoption of them as draft-ietf-wg-xx.= =C2=A0 Obviously, you could run this the other way and adopt draft-individu= al as-is and republish as a draft-wg before the substantive changes start; = prior to the "replaces" function in the tracker, I would have sug= gested that.=C2=A0 Having a three-month window allows you to do it either w= ay, but this is definitely one I see as "no later than".

OK. Personally, if the charter nominated a specific set of documents= as a starting point, I'd make -00 a carbon copy of them on day 1, and = immediately start gathering issues on them. I don't think "replace= s" changes things that much.

[...]

> I think it requires a high frequency of interim meetings, but I person= ally fall more on the "many virtuals, some F2F" side of the spect= rum.=C2=A0 So it might run to 7 in a single year, but only 1 additional fac= e to face.=C2=A0 A lot really depends on where the controversies lie and wh= at needs to be done to reach consensus; I don't think any one map is al= ways right.

Generally agreed. Personally -- and I want to emphasise that -- I th= ink that having good F2F meetings early in the process is critical when the= re are diverse communities and opposing viewpoints, because it helps social= ise people and their perspectives. They need to be F2F and it's vastly = preferable that they're interim, since IETF weeks have so many other di= stractions.

Cheers,


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

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


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



--001a113cd59c7dc4970534b2dff9-- From nobody Tue Jun 7 10:32:48 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F2012D73B for ; Tue, 7 Jun 2016 10:32:35 -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 ejsQO92B0QRk for ; Tue, 7 Jun 2016 10:32:31 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B5812D5CE for ; Tue, 7 Jun 2016 10:32:31 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id o16so176685542ywd.2 for ; Tue, 07 Jun 2016 10:32:31 -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=DDFTlGf+pxXSAskpQSpNb73mDdEZ4gpJeBOkA1kzV6U=; b=iJLWHDA0cnJxvPBaEIw3YD1KHI3mPr9e9+t56ccZSYqnfvVN6XAxXlISrlnLG9G6Oc qrNu3kZGH9PsgzpJJqi00XT72N7EiAvVwLEWMK7Z3L1EiEzaBgR9PE5jGXwkQkj9eVPu JY49Gq3H4ARB5K7Y4TaRiQ/esl4N91fD6bBROX+cWsvDxhGwdtsLnzMNPs86HlXOwn5P GiMcfPH4IiouFDzXLnIVytzyoN3tN6nsvFRy25V8mQxltk+anXAylBrNCED0cZoAnxCk 3tfdhNVHtXtanmX51/AWOKYHxWBmXjNRqZNPCIrWWLQWrUhdqWq67DOgZwbIvl1/tF1Q xXAg== 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=DDFTlGf+pxXSAskpQSpNb73mDdEZ4gpJeBOkA1kzV6U=; b=Qm6zwsegNoQRePfr+TWEJBeqDfVyf/cBq8oVKXXrf9CvPLDGJCPrJV1Q1Q93XN68uK w/CBakX5rcHVvThJmsrddHLgAMJ6PgalXCtZhmUK2aS1LrLndaygNEOdhSsOVtJ3E2I0 vRQuC67i8AWxE3vTeLqp7EGlb72sLQ1lzbHX3uVkLKtxXLIXHGGisGhJ714nVEKCVrnk kaFDgWhOJDXy8SfZ+vt+jSqYAf4o/s3Gfo+FsCXdYxZ1I/AGRfJX3zsnwtEOK0sOZT73 s2YWhLIw/zHWk1TyOGD7tqs3HRCYTod3SYrEUgpXzRFml1KkEc8CQxDzyahcjgQB6jKe IEBQ== X-Gm-Message-State: ALyK8tK1cK6jjYyp/z/wYYj/hzUL+3zxoONaxDpfHHh3zb3+Lg2uoV2yf6P/ELxzC2tMnoyPvBRtQuuRz1GBvdJS X-Received: by 10.13.249.129 with SMTP id j123mr377069ywf.188.1465320750855; Tue, 07 Jun 2016 10:32:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Tue, 7 Jun 2016 10:32:30 -0700 (PDT) In-Reply-To: References: <13A4C467-0803-43E7-99D9-9FFE47CA9FB4@mnot.net> <1B9BEB09-ED28-42D5-8904-52C2A74CFB66@mnot.net> From: Jana Iyengar Date: Tue, 7 Jun 2016 10:32:30 -0700 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=94eb2c0827bad6ab310534b3929a Archived-At: Cc: Ian Swett , quic@ietf.org, Mark Nottingham Subject: Re: [QUIC] Charter dates X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 17:32:35 -0000 --94eb2c0827bad6ab310534b3929a Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 9:42 AM, Ted Hardie wrote: > Jana, do you want to put this in a PR, so we can track this suggestion > against the current text? > Done. (https://github.com/IETF-QUIC/Charter/pull/7) > I'd like to get a sense of what update to make prior to the BoF call on > Friday. My current sense is that, while there is some discussion of the > chartering + 3 milestones, the basic conclusion is that this is > more-or-less a style issue. I propose we leave the resolution to the ADs, > and adopt either approach they prefer. > > For the other milestones, there are two basic suggestions: move the dates > out in the strawman PR https://github.com/IETF-QUIC/Charter/pull/6/files > by 6 to 12 months (but leave the ordering); re-order so that multipath > shifts later (as per Jana's message above). > > It also seems like there is general agreement that virtual meetings will > be needed to make this pace work. I think we should probably say that in > the charter, with something like "In order to achieve the milestones set > out below, the group expects to make extensive use of interim meetings, > especially in its first year". Would that make sense to people, inserted > just above the milestones? > Sounds good to me. - jana > > Ted > > > > On Mon, Jun 6, 2016 at 11:59 PM, Jana Iyengar wrote: > >> A few thoughts, as I catch up on this thread: >> >> - I do not have a strong opinion on the Charter + 3 months on adoption of >> -00 documents. I can see that having a 3-month window allows for any >> delays, just in case there is discussion, but if we adopt the feeder >> individual documents as -00 on day 1, then we just met the deadline early. >> I see the work on the documents as having starter as soon as the Charter is >> adopted anyways. >> >> - IMO, the document deadlines are a bit too aggressive. I'd love to get >> the core documents done within 1 year, but going by our track-record with >> HTTP/2, which took 2 years, and MPTCP, which took 5 years, the current >> deadlines seem too aggressive. >> >> - I'd like to suggest that we push the beginning of the multipath work to >> later in the cycle, to allow for the core documents to make progress before >> we add another document in the mix. >> >> Based on these thoughts, I'll suggest the following changes: >> * Chartering + 12 Months: Working group adoption of Multipath extension >> document >> * Chartering + 18 Months: Core Protocol document to IESG >> * Chartering + 18 Months: Loss detection and Congestion Control document >> to IESG >> * Chartering + 18 Months: TLS 1.3 Mapping document to IESG >> * Chartering + 24 Months: HTTP/2 mapping document to IESG >> * Chartering + 30 Months: Multipath extension document to IESG >> >> I agree that we should have more interims especially in the first year. I >> also agree with Mark's sentiment that we should try to do more F2F meetings >> in the first year as well. >> >> - jana >> >> >> >> On Mon, Jun 6, 2016 at 7:13 PM, Ian Swett wrote: >> >>> Thanks Mark, I support both of your suggestions and would be willing to >>> attend as many F2F meetings as we can organize. >>> >>> On Mon, Jun 6, 2016 at 10:02 PM, Mark Nottingham wrote: >>> >>>> >>>> > On 7 Jun 2016, at 8:17 AM, Ted Hardie wrote: >>>> > >>>> [...] >>>> >>>> > Personally, I'm assuming that there will be some discussion of the >>>> starting documents when they are still draft-individual-xx; that would >>>> occur on the mailing list during/just after the IESG activity for >>>> chartering. I'd assume that folding any changes that come up during that >>>> section of time would occur before the adoption of them as >>>> draft-ietf-wg-xx. Obviously, you could run this the other way and adopt >>>> draft-individual as-is and republish as a draft-wg before the substantive >>>> changes start; prior to the "replaces" function in the tracker, I would >>>> have suggested that. Having a three-month window allows you to do it >>>> either way, but this is definitely one I see as "no later than". >>>> >>>> OK. Personally, if the charter nominated a specific set of documents as >>>> a starting point, I'd make -00 a carbon copy of them on day 1, and >>>> immediately start gathering issues on them. I don't think "replaces" >>>> changes things that much. >>>> >>>> [...] >>>> >>>> > I think it requires a high frequency of interim meetings, but I >>>> personally fall more on the "many virtuals, some F2F" side of the >>>> spectrum. So it might run to 7 in a single year, but only 1 additional >>>> face to face. A lot really depends on where the controversies lie and what >>>> needs to be done to reach consensus; I don't think any one map is always >>>> right. >>>> >>>> Generally agreed. Personally -- and I want to emphasise that -- I think >>>> that having good F2F meetings early in the process is critical when there >>>> are diverse communities and opposing viewpoints, because it helps socialise >>>> people and their perspectives. They need to be F2F and it's vastly >>>> preferable that they're interim, since IETF weeks have so many other >>>> distractions. >>>> >>>> Cheers, >>>> >>>> >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >>>> >>>> _______________________________________________ >>>> QUIC mailing list >>>> QUIC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/quic >>>> >>> >>> >>> _______________________________________________ >>> QUIC mailing list >>> QUIC@ietf.org >>> https://www.ietf.org/mailman/listinfo/quic >>> >>> >> > --94eb2c0827bad6ab310534b3929a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 7, 2016 at 9:42 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
Jana, do you want to put thi= s in a PR, so we can track this suggestion against the current text?

=C2=A0
I'd like to get a sense of what update to= make prior to the BoF call on Friday.=C2=A0 My current sense is that, whil= e there is some discussion of the chartering + 3 milestones, the basic conc= lusion is that this is more-or-less a style issue.=C2=A0 I propose we leave= the resolution to the ADs, and adopt either approach they prefer.

<= /div>For the other milestones, there are two basic suggestions:=C2=A0 move = the dates out in the strawman PR https://github.com/IETF-QUIC/Charter/pull/6/files b= y 6 to 12 months (but leave the ordering); re-order so that multipath shift= s later (as per Jana's message above).

It also seems like = there is general agreement that virtual meetings will be needed to make thi= s pace work.=C2=A0 I think we should probably say that in the charter, with= something like "In order to achieve the milestones set out below, the= group expects to make extensive use of interim meetings, especially in its= first year".=C2=A0 Would that make sense to people, inserted just abo= ve the milestones?

Sounds good = to me.

- jana
=C2=A0

Ted


<= div>

On Mon, = Jun 6, 2016 at 11:59 PM, Jana Iyengar <jri@google.com> wrote:
A few thoughts, as I catch up on this thread:

- I do not have a strong opinion on the Charter + 3 months on adopt= ion of -00 documents. I can see that having a 3-month window allows for any= delays, just in case there is discussion, but if we adopt the feeder indiv= idual documents as -00 on day 1, then we just met the deadline early. I see= the work on the documents as having starter as soon as the Charter is adop= ted anyways.

- IMO, the document deadlines are a b= it too aggressive. I'd love to get the core documents done within 1 yea= r, but going by our track-record with HTTP/2, which took 2 years, and MPTCP= , which took 5 years, the current deadlines seem too aggressive.
=
- I'd like to suggest that we push the beginning of the = multipath work to later in the cycle, to allow for the core documents to ma= ke progress before we add another document in the mix.=C2=A0

=
Based on these thoughts, I'll suggest the following changes:=
* Chartering + 12 Months: Working group adoption of Multipa= th extension document
* Chartering + 18 Months: Core Protocol doc= ument to IESG
* Chartering + 18 Months: Loss detection and Conges= tion Control document to IESG
* Chartering + 18 Months: TLS 1.3 M= apping document to IESG
* Chartering + 24 Months: HTTP/2 mapping = document to IESG
* Chartering + 30 Months: Multipath extension do= cument to IESG

I agree that we should have m= ore interims especially in the first year. I also agree with Mark's sen= timent that we should try to do more F2F meetings in the first year as well= .

- jana
<= br>


On Mon, Jun 6, 2016 at 7:13 PM, Ian Sw= ett <ianswett@g= oogle.com> wrote:
Thank= s Mark, I support both of your suggestions and would be willing to attend a= s many F2F meetings as we can organize.

On Mon, Jun 6, 2016 at 10:02 PM, Mark= Nottingham <mnot@mno= t.net> wrote:

> On 7 Jun 2016, at 8:17 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
[...]

> Personally, I'm assuming that there will be some discussion of the= starting documents when they are still draft-individual-xx; that would occ= ur on the mailing list during/just after the IESG activity for chartering.= =C2=A0 I'd assume that folding any changes that come up during that sec= tion of time would occur before the adoption of them as draft-ietf-wg-xx.= =C2=A0 Obviously, you could run this the other way and adopt draft-individu= al as-is and republish as a draft-wg before the substantive changes start; = prior to the "replaces" function in the tracker, I would have sug= gested that.=C2=A0 Having a three-month window allows you to do it either w= ay, but this is definitely one I see as "no later than".

OK. Personally, if the charter nominated a specific set of documents= as a starting point, I'd make -00 a carbon copy of them on day 1, and = immediately start gathering issues on them. I don't think "replace= s" changes things that much.

[...]

> I think it requires a high frequency of interim meetings, but I person= ally fall more on the "many virtuals, some F2F" side of the spect= rum.=C2=A0 So it might run to 7 in a single year, but only 1 additional fac= e to face.=C2=A0 A lot really depends on where the controversies lie and wh= at needs to be done to reach consensus; I don't think any one map is al= ways right.

Generally agreed. Personally -- and I want to emphasise that -- I th= ink that having good F2F meetings early in the process is critical when the= re are diverse communities and opposing viewpoints, because it helps social= ise people and their perspectives. They need to be F2F and it's vastly = preferable that they're interim, since IETF weeks have so many other di= stractions.

Cheers,


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
QUIC mailing list
QUIC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/quic


_______________________________________________
QUIC mailing list
QUIC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/quic




--94eb2c0827bad6ab310534b3929a-- From nobody Tue Jun 7 22:59:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A38C12D77F for ; Tue, 7 Jun 2016 22:59:23 -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 0nhAxckogPgR for ; Tue, 7 Jun 2016 22:59:22 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 A168A12D77C for ; Tue, 7 Jun 2016 22:59:20 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id x189so190981482ywe.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=Ql3QVgCvh2ZYK82T4UJk1AdY4HRRARoRxE6JL8/rYiMPDcf1JpX4/eBUD8QjbpF5aA U5a4jFG1RWBOWbhU9VPcSWpWd9n3X0APaa4EUvLj7wb6XAX3DWTrWfQj4zsfm5ssM0Rd 5vZG8bskR11h/5Tg8eCvAAi8egEh87gOldUAbXWAgOOGCDR+jb9N57Ovly/ugZHLiybm 4cZHhM3MjYKfsj3Pzm5PCgT/z0X3C4EQmg6H0U2H7udVUr+849XG6zvnW2L0eBSNJera c+bIbnj5WDOwpWLnjOYAiLSxyFJZKtm94FUoaM5N8nLscSGh0aYfAS3kb7N3HI8Cil/w Vxog== X-Gm-Message-State: ALyK8tIOgravbJ5My4dEktpuGujYNPJzC37Yjbqvk4I6zuNM8PtUTZ9M+FhwxHyY+FkmPKR6pO8qPuz49hNqyJXb 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 , Brian Trammell , quic@ietf.org, ietf@ietf.org Subject: Re: [QUIC] [Spud] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 05:59:23 -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 Tue Jun 7 23:14:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4F712D7F1 for ; Tue, 7 Jun 2016 23:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, 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 l30EAotjngmU for ; Tue, 7 Jun 2016 23:14:45 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6A612D7F3 for ; Tue, 7 Jun 2016 23:14:45 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id o16so191377012ywd.2 for ; Tue, 07 Jun 2016 23:14:45 -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=m3Dbusems6SPcXVcec9U7z/CiCg6v0NKx/Sfar124uM=; b=iWEeDvrrJiVy2ruIkqVMd10f59gwHhgaQUcZMHzsb1NC4rtvKNpvrZ4VecHLZeBsiV m6UTQim9TU+MUP2L9w5eLQkeQdpOhmIc3HSTRvLX9AafYKO/T68d/3+9ToNyjSZPpAu1 OkM6oesFN+gVfj2/OuTAq8/Se62f07QjRk6SpkfNYpufbk8tDmyRdqG7jefg5jSkKS5n UNdRJHkMLQtrTeBTLrYXqUPqpK2ABkX8DT2ffg+cvLPrSwoBetdzzMmxEt/m3zci1hl0 nEqxHozuDm60GaSsCAG91tFqNsgWm/ysRVf7vYOMEO5GChsWWxbaxzchcyO9itxQPyLy GhJQ== 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=m3Dbusems6SPcXVcec9U7z/CiCg6v0NKx/Sfar124uM=; b=kqyCagaPdT3cRy0Cf639DnyqSBBk9MmVaTGamW7HLUPTyeNC98KEcZvqSym7AV0hpt ZvAdbZnGJ54VBsj8iyHeym9xsRliHLdO6mhRVZV8QivapHDKAD1AcuwH+BE1gUK8K7VA ljbR/O5XTMc20FEVCgHb+XlJn3uwSScBOVgrYlEUWRGiUONugSf8cvISLX1+pX41l3qJ Ej8J/E7o1HwHblrdPzX1HM5mCG4IZJ8yqiVM0CpeLfAmU5VNpohe7oVZhYOttiDxfGXl JaGqIR5Jbn4cdhmO0g6/1lirl+t0f+ca24NBtNO5yZQpt/+VPTS7rPWieb0B1ZRaQvFh Ed1w== X-Gm-Message-State: ALyK8tLvBYXBlRDhy3auZrzcf3ugsoi7okdoQQ4Du+VtW08CXzURWOdYXkQP4StMnu8bDbcTguZQ7ygazH/fzzlB X-Received: by 10.37.96.130 with SMTP id u124mr1637900ybb.81.1465366484133; Tue, 07 Jun 2016 23:14:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Tue, 7 Jun 2016 23:14:43 -0700 (PDT) In-Reply-To: <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> From: Jana Iyengar Date: Tue, 7 Jun 2016 23:14:43 -0700 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=001a1143e930c121700534be3856 Archived-At: Cc: quic@ietf.org, Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 06:14:46 -0000 --001a1143e930c121700534be3856 Content-Type: text/plain; charset=UTF-8 Michael, > Perhaps a list of features that can be added to TCP can be discussed on > TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on those > threads. > I'm currently trying to figure out how such a list might look like. > I think the list you have is a fairly good one to start with. I would add Versioning and Version Negotiation to the list -- this is fundamental to be able to evolve the wire format. - jana --001a1143e930c121700534be3856 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,=C2=A0

>= ; Perhaps a list of features that can be added to TCP can be discussed on T= CPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on those = threads.
I'm currently trying to figure out how such a list might look li= ke.

I think the list you have is a fair= ly good one to start with. I would add Versioning and Version Negotiation t= o the list -- this is fundamental to be able to evolve the wire format.

- jana=C2=A0
--001a1143e930c121700534be3856-- From nobody Wed Jun 8 00:08:14 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C582F128874 for ; Wed, 8 Jun 2016 00:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, 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 hn7XBij94YuR for ; Wed, 8 Jun 2016 00:08:11 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1CE12D815 for ; Wed, 8 Jun 2016 00:08:11 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id c72so11307377ywb.1 for ; Wed, 08 Jun 2016 00:08:11 -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=43ndb/QeWrJPoJyaO3aodSYh7QzR3oJHicOvs6ZW1/U=; b=kT1m7G+DW+VsI47EP/k2bN9zjn6PX2CMAZ/0WK1dCcOA0wgwYTaqy+39VD0sVyaLCh gRjIucJ1ILuiEPewO2G99zACoeO4K3qoTm0lG8rZY6HzSy+uhmwoZHOGkM4TN11AzabU aC0IIypWEsKmYaSV1qOnCCCjm50Ru4okhiEF3vcXe+YULX3g5UgPObWiX0XH5nvocjj2 NYtuy0fDssIiGjbei3HRcVhQaq4gMUo2PbrilLOXswqStojQ3X07U/gIGNlHCAmkzS76 Y4TMqcecc52yDnh9anQU/LRo9Pozjr9FAlWj4KowHuiB39UebqgOveajSZWilE7WK5PZ GSsw== 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=43ndb/QeWrJPoJyaO3aodSYh7QzR3oJHicOvs6ZW1/U=; b=VlyOFMTZCxsRfkgg17seOXBtx/FS8FUNreLL2PGtf1J5BEmLO5noIWd0B7DQQwJD2b z4Bbar/6gfH5k2Sdh5knHkeS3zEo9QT7IvDSW7WQ7xx5VSo71BAjuwvfwHTAwSvHzbZo Q+EwxiOnpo+g0o0fa4w2qHSX4eQPP5MMm6+dh3IatywTeoC5IBNDBQFDds+XZrUSA3ex NnFvXaeJ/GoHOpReh6es617oVlUVB97K5V1EMpmZtraj75YQC9Ybr+LwktP80wh3ioqu UuYe1JOe+ENU6qgzL5B1bgOGpCPIiEf8oVwaSmRVe6u8vL8BbuZKocAcI4/BPmiyxXTf sEUg== X-Gm-Message-State: ALyK8tLOr3eiQ0/vzbc8hfVnN7OVsWiilrE19FuzURMtAs+u1VIxhpcF3uOc91rKtkoODYjQ/lezasy7x7WpYs4N X-Received: by 10.13.237.1 with SMTP id w1mr1782773ywe.62.1465369690354; Wed, 08 Jun 2016 00:08:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Wed, 8 Jun 2016 00:08:09 -0700 (PDT) In-Reply-To: <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> From: Jana Iyengar Date: Wed, 8 Jun 2016 00:08:09 -0700 Message-ID: To: Randall Stewart Content-Type: multipart/alternative; boundary=94eb2c0864a8dc1b0a0534bef7b2 Archived-At: Cc: =?UTF-8?Q?Michael_T=C3=BCxen?= , quic@ietf.org Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:08:13 -0000 --94eb2c0864a8dc1b0a0534bef7b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Randy, Is this activity to: > > (a) document what Google as done and produce an RFC showing here is =E2= =80=9CQuic" > > (b) solving a specific problem > > If it is (b) it would make sense to figure out what the problem is and ho= w > it could be solved most easily. In this case one could consider evolving > TCP (or even > SCTP =E2=80=A6 but hey I do TCP right now :D). In case of (a) then this i= s not > even something > we need to discuss.. > I think it's somewhere in between the two. IMO, the goal is to solve the specific problem of developing a transport that minimizes latency for applications; specifically, HTTP. QUIC was built expressly for this purpose, and there is fairly extensive deployment experience with using QUIC for HTTP. The BoF's charter is not clean-slate design -- QUIC exists, it is being used to solve precisely the problem of being a low-latency HTTP transport, and the charter says as much that the proposed goal is to start with QUIC's current design as the initial seed and generalize it. There's active interest from various entities in building and using QUIC, which is the primary motivation for this standardization effort. There's also the additional opportunity to jumpstart a next-generation transport for modern applications, which should be a close second motivation for this work at the IETF. We can usually find rough translations from one transport to another, if we are willing to squint hard enough and live with the resulting complexity. Ryan Bickhart's work on mapping TCP semantics onto SCTP and my work with Bryan Ford on mapping SCTP-like semantics onto TCP are both examples of how with enough work it is feasible to retrofit a transport on top of or inside another. That said, a clean-slate design has substantial benefits if the costs of building and deploying it can be balanced out. QUIC shows an initial deployable (and deployed) clean-slate design, and arguably, the costs of building and deploying it have been considered reasonable by folks, at Google and elsewhere, currently working on developing and deploying QUIC. - jana --94eb2c0864a8dc1b0a0534bef7b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Randy,

Is this activity to:

(a) document what Goo= gle as done and produce an RFC showing here is =E2=80=9CQuic"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<or>
(b) solving a spec= ific problem

If it is (b) it would make sense to f= igure out what the problem is and how
it could be solved most eas= ily. In this case one could consider evolving TCP (or even
SCTP = =E2=80=A6 but hey I do TCP right now :D). In case of (a) then this is not e= ven something
we need to discuss..
<= br>
I think it's somewhere in between the two. IMO, the goal = is to solve the specific problem of developing a transport that minimizes l= atency for applications; specifically, HTTP. QUIC was built expressly for t= his purpose, and there is fairly extensive deployment experience with using= QUIC for HTTP. The BoF's charter is not clean-slate design -- QUIC exi= sts, it is being used to solve precisely the problem of being a low-latency= HTTP transport, and the charter says as much that the proposed goal is to = start with QUIC's current design as the initial seed and generalize it.= There's active interest from various entities in building and using QU= IC, which is the primary motivation for this standardization effort.=C2=A0<= /div>

There's also the additional opportunity to jum= pstart a next-generation transport for modern applications, which should be= a close second motivation for this work at the IETF. We can usually find r= ough translations from one transport to another, if we are willing to squin= t hard enough and live with the resulting complexity. Ryan Bickhart's w= ork on mapping TCP semantics onto SCTP and my work with Bryan Ford on mappi= ng SCTP-like semantics onto TCP are both examples of how with enough work i= t is feasible to retrofit a transport on top of or inside another. That sai= d, a clean-slate design has substantial benefits if the costs of building a= nd deploying it can be balanced out. QUIC shows an initial deployable (and = deployed) clean-slate design, and arguably, the costs of building and deplo= ying it have been considered reasonable by folks, at Google and elsewhere, = currently working on developing and deploying QUIC.

- jana


=C2=A0
--94eb2c0864a8dc1b0a0534bef7b2-- From nobody Wed Jun 8 00:12:06 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D67312D849 for ; Wed, 8 Jun 2016 00:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, 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 DIHN1UkaqLZa for ; Wed, 8 Jun 2016 00:12:02 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9B212D815 for ; Wed, 8 Jun 2016 00:12:02 -0700 (PDT) Received: from [172.17.186.217] (unknown [147.67.241.226]) by trammell.ch (Postfix) with ESMTPSA id 503151A0302; Wed, 8 Jun 2016 09:11:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_709815C1-D5C2-4ABE-ABD2-7BF75438DA59"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Wed, 8 Jun 2016 09:11:30 +0200 Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Tuexen , quic@ietf.org, Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:12:04 -0000 --Apple-Mail=_709815C1-D5C2-4ABE-ABD2-7BF75438DA59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, all, > On 08 Jun 2016, at 08:14, Jana Iyengar wrote: >=20 > Michael, >=20 > > Perhaps a list of features that can be added to TCP can be discussed = on TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on = those threads. > I'm currently trying to figure out how such a list might look like. >=20 > I think the list you have is a fairly good one to start with. I would = add Versioning and Version Negotiation to the list -- this is = fundamental to be able to evolve the wire format. +1. (It is of course tricky to add versioning to a protocol that doesn't = have it yet. But that doesn't make it not a requirement. :) ) Cheers, Brian > - jana > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_709815C1-D5C2-4ABE-ABD2-7BF75438DA59 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 iQIcBAEBCgAGBQJXV8UiAAoJEIoSt78L6kajhCkQAIO8JkDXu6DcZ2sOwDxc4WaZ j8NPnta3S/2MJudhWg7YvfSlZgaPG0LxA5HzD2gxS8CYYI5hYkLNw0AnwPu7qTC/ IStpGDbvdsu4CP1La2Q3OHwaRTAhuodaVJqaS+fLWFIMrFPq/sFEP1wCeZ/NCO4u PRjvdznqOagE6FkSkXzr0Le1guLXh999f7SGyC2H0fnGDPZj3JRXvfVp6qGUHlwo vw9m6a+9soV8GWt6/PkIahahm1gtPrd3wWdLDRhYXyOJCgMb7cligsNKr6rR2G5+ +E39RqHart8UoFVs6cwE7QwdVMCx5ZT8uxMbhbtK4OEr2d2xRUHYcFIM8mgYc4I1 UE9ywhPGeV7lGF3gMmDd1lNBlrKqZxGclM0WHWyhfXOOGLJsFOhwIjiXMAiQ4Obm XFmjlRvDCqpncyPRPAFK+wE04XI9aokHIPhOt5v3ToemoMmKln9ysJBEDtQ1d6xg I8qhjEKJARK4FzpJXabJ8FZDgO9isY6Qkv1RW+AT1UKt7FmBQmdlC7ZvS4qAdlhF qZHfjr6EaUh4GsYycxUQtL4r1gdzO/A6KjS6VsVqiqpEcxdt9p4vEjzrrN4x+sbm r5jY0pHjQ2dUeg4PkLS3lOj30DN/OCNXj9EbUKo1fHfoHJkMXswjyu4mEkEDOSHf cL2QZRPoROtGT76amAn9 =LbUQ -----END PGP SIGNATURE----- --Apple-Mail=_709815C1-D5C2-4ABE-ABD2-7BF75438DA59-- From nobody Wed Jun 8 00:30:11 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595AD12D145 for ; Wed, 8 Jun 2016 00:30:06 -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 DMhx0zwBmBVu for ; Wed, 8 Jun 2016 00:30:04 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696A412D10B for ; Wed, 8 Jun 2016 00:30:04 -0700 (PDT) Received: from mfilter39-d.gandi.net (mfilter39-d.gandi.net [217.70.178.170]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 72AE8C5A6C; Wed, 8 Jun 2016 09:30:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter39-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter39-d.gandi.net (mfilter39-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id D1rnGxPrvMHe; Wed, 8 Jun 2016 09:30:01 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 749E4C5A79; Wed, 8 Jun 2016 09:29:58 +0200 (CEST) Message-ID: <5757C974.6010703@tzi.org> Date: Wed, 08 Jun 2016 09:29:56 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jana Iyengar References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Michael Tuexen , quic@ietf.org, Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:30:07 -0000 Versioning is almost always the wrong way to hand evolution. (One recent article that made this point in passing: https://www.imperialviolet.org/2016/05/16/agility.html ) In any case, the requirement is not for versioning, but for supporting evolution. Grüße, Carsten Jana Iyengar wrote: > I would add Versioning and Version Negotiation to the list -- this is > fundamental to be able to evolve the wire format. From nobody Wed Jun 8 00:41:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6303212D1AA for ; Wed, 8 Jun 2016 00:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, 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 7bFPo1D__yBK for ; Wed, 8 Jun 2016 00:41:26 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2412D0A1 for ; Wed, 8 Jun 2016 00:41:26 -0700 (PDT) Received: from [172.17.186.217] (unknown [147.67.241.226]) by trammell.ch (Postfix) with ESMTPSA id CFB1F1A083A; Wed, 8 Jun 2016 09:41:24 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_04EB933E-A043-49BA-9655-5C287CE1242B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <5757C974.6010703@tzi.org> Date: Wed, 8 Jun 2016 09:41:23 +0200 Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> <5757C974.6010703@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , quic@ietf.org, Randall Stewart , Michael Tuexen Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:41:28 -0000 --Apple-Mail=_04EB933E-A043-49BA-9655-5C287CE1242B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Carsten, > On 08 Jun 2016, at 09:29, Carsten Bormann wrote: >=20 > Versioning is almost always the wrong way to hand evolution. >=20 > (One recent article that made this point in passing: >=20 > https://www.imperialviolet.org/2016/05/16/agility.html > ) >=20 > In any case, the requirement is not for versioning, but for supporting > evolution. Better put. Fully flexible capability exposure and negotiation is the other end of = this continuum, and can turn into a somewhat different nightmare than = that described if not carefully managed. To stretch the article's = central metaphor, it is very difficult to fully oil a joint that has = degrees of freedom in dimensions you can't see. I think we agree on the end goal, though, and perhaps phrasing it as = "support evolution of the protocol, including stable and interoperable = coexistence of protocol instances at different phases of this evolution" = captures the goal without bias toward one or another end of this = continuum of possible designs. Cheers, Brian > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Jana Iyengar wrote: >> I would add Versioning and Version Negotiation to the list -- this is >> fundamental to be able to evolve the wire format. >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_04EB933E-A043-49BA-9655-5C287CE1242B 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 iQIcBAEBCgAGBQJXV8wkAAoJEIoSt78L6kaj0v4P/02wZR00PPBKrrEow2jfZeG5 Xiv6VsPRPBBUBFRsFer+Zm1Gc3ecgTNpSsSGFVJ3sE7sBkFakQOXDhsKDc7sJeuF FLrgvqttUo874rDxYnPiZB/1JbGzUTwjSJUnOreIT5X//Bg4MPvxIWU/lrXMfu2v TMCDmk5UFyE9BRIKk1OFAzWOlkw4mcL79A0Am0zJ13bL/qceEMhKBB2yW6mzf+I2 54n/mfnyn6xLCgTtIIyHdLq+MGGhLNl406SwSYwcGmAZiT4yfROz8NbLAxp6IC8j B0PoxC/BkAcEw2MVZfqLOmBwzVrjq17U7nfEC1rE0ywXyhw5diEzi403CgQJM2I7 JQGf4I7I0wxoIJj1w6kykmmjNhhGkcrN/Ppc+ST+0xF3ghjvlywO7Ym/LLAGChIC eSphO0nbByBouZMCW6M6tJMPtzsWImAFxK3eGJSX88en5g29kv79kTBt552j/SvG uuMKqXzYaP81aPEuYpgWcm+fGeS3UuTb0T4k0xkjpgK+gYxOWwjE8p/sRekqLoMC f6kowajp94mKGYaGPse6EhS8DbAouPAFaAc/o88ujJ88xGuHieIf2iGyiINTeBUW GFIwpbL1t7MJh/Wn2+hJ5gPl9NP/SuRzBC/a+yD2K11X+Da4iLAenifQ8VEzcTLC IMJa8u7/2O++6uZ+c4Oi =fRHj -----END PGP SIGNATURE----- --Apple-Mail=_04EB933E-A043-49BA-9655-5C287CE1242B-- From nobody Wed Jun 8 00:46:59 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC68C12D871 for ; Wed, 8 Jun 2016 00:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 KIbrd4JX_cw3 for ; Wed, 8 Jun 2016 00:46:54 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B582512D86E for ; Wed, 8 Jun 2016 00:46:54 -0700 (PDT) Received: from [10.13.44.231] (unknown [89.27.138.50]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 660DB721E281C; Wed, 8 Jun 2016 09:46:51 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: Date: Wed, 8 Jun 2016 09:46:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <26940943-82C2-4589-8265-5D45EC49B6A7@lurchi.franken.de> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org, Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:46:58 -0000 > On 08 Jun 2016, at 08:14, Jana Iyengar wrote: >=20 > Michael,=20 >=20 > > Perhaps a list of features that can be added to TCP can be discussed = on TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on = those threads. > I'm currently trying to figure out how such a list might look like. >=20 > I think the list you have is a fairly good one to start with. I would = add Versioning and Version Negotiation to the list -- this is = fundamental to be able to evolve the wire format. I think we agree, that the protocol must provide a way to evolve it. Using version numbers and version negotiation is one way. Negotiating features is another one. That would allow for a backwards compatible way of evolution. Best regards Michael >=20 > - jana=20 From nobody Wed Jun 8 01:59:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED23712D86E for ; Wed, 8 Jun 2016 01:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 2Bb9F-zheKEy for ; Wed, 8 Jun 2016 01:59:43 -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 4BEFD12D0A0 for ; Wed, 8 Jun 2016 01:59:42 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 34A7B3109B706; Wed, 8 Jun 2016 08:59:37 +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 u588xdmQ012675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 08:59:40 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 u588ucS0010980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2016 10:59:37 +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; Wed, 8 Jun 2016 10:57:16 +0200 From: "Scharf, Michael (Nokia - DE)" To: Jana Iyengar , Randall Stewart Thread-Topic: [QUIC] Requirements Thread-Index: AQHRuIjf1g82qhC+F0C0JHCI/xZN8J/N4CYAgACFmICAAYUQAIABVPAAgAAZTgCAAAEKgIABFZeAgACdeQCADAlHgIAAPA5Q Date: Wed, 8 Jun 2016 08:57:15 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> In-Reply-To: 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: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D488BD814FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= , "quic@ietf.org" Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 08:59:45 -0000 --_000_655C07320163294895BBADA28372AF5D488BD814FR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2l2ZW4gd2hhdCBpcyB3cml0dGVuIGJlbG93LCBJIHdvdWxkIHByZWZlciB0aGF0IGFuIElFVEYg cHJvdG9jb2wgZG9lcyBub3QgdXNlIHRoZSBuYW1lIG9mIGEgcHJvcHJpZXRhcnkgcHJvdG9jb2wu DQoNCkFsc28sIGdpdmVuIHRoYXQgbm90IGV2ZXJ5Ym9keSBzZWVtcyB0byBiZSBhYmxlIHRvIHJl cHJvZHVjZSB0aGUgY2xhaW1lZCBwZXJmb3JtYW5jZSBiZW5lZml0cywgZ2l2ZW4gdGhlIGxhY2sg b2YgaGFyZHdhcmUgc2VnbWVudGF0aW9uIG9mZmxvYWQgZXRjLiwgSSBmZWFyIHRoYXQgdGhlIHBy b3Bvc2VkIEJvRiBuYW1lIGNvdWxkIHJhaXNlIHdyb25nIGV4cGVjdGF0aW9ucy4NCg0KSG93ZXZl ciwgZ2l2ZW4gdGhhdCB0aGVyZSBpcyBydW5uaW5nIGNvZGUsIEkgY291bGQgaW1hZ2luZSB0byB1 c2UgZS5nLiDigJxx4oCdIGluIGFuIGFjcm9ueW0gb2YgdGhlIElFVEYgdmVyc2lvbiBvZiBhIHBy b3RvY29sLg0KDQpNaWNoYWVsDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbmEgSXllbmdhcg0KU2VudDogV2VkbmVzZGF5LCBKdW5l IDA4LCAyMDE2IDk6MDggQU0NClRvOiBSYW5kYWxsIFN0ZXdhcnQNCkNjOiBNaWNoYWVsIFTDvHhl bjsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtRVUlDXSBSZXF1aXJlbWVudHMNCg0KUmFu ZHksDQoNCklzIHRoaXMgYWN0aXZpdHkgdG86DQoNCihhKSBkb2N1bWVudCB3aGF0IEdvb2dsZSBh cyBkb25lIGFuZCBwcm9kdWNlIGFuIFJGQyBzaG93aW5nIGhlcmUgaXMg4oCcUXVpYyINCiAgICAg ICAgIDxvcj4NCihiKSBzb2x2aW5nIGEgc3BlY2lmaWMgcHJvYmxlbQ0KDQpJZiBpdCBpcyAoYikg aXQgd291bGQgbWFrZSBzZW5zZSB0byBmaWd1cmUgb3V0IHdoYXQgdGhlIHByb2JsZW0gaXMgYW5k IGhvdw0KaXQgY291bGQgYmUgc29sdmVkIG1vc3QgZWFzaWx5LiBJbiB0aGlzIGNhc2Ugb25lIGNv dWxkIGNvbnNpZGVyIGV2b2x2aW5nIFRDUCAob3IgZXZlbg0KU0NUUCDigKYgYnV0IGhleSBJIGRv IFRDUCByaWdodCBub3cgOkQpLiBJbiBjYXNlIG9mIChhKSB0aGVuIHRoaXMgaXMgbm90IGV2ZW4g c29tZXRoaW5nDQp3ZSBuZWVkIHRvIGRpc2N1c3MuLg0KDQpJIHRoaW5rIGl0J3Mgc29tZXdoZXJl IGluIGJldHdlZW4gdGhlIHR3by4gSU1PLCB0aGUgZ29hbCBpcyB0byBzb2x2ZSB0aGUgc3BlY2lm aWMgcHJvYmxlbSBvZiBkZXZlbG9waW5nIGEgdHJhbnNwb3J0IHRoYXQgbWluaW1pemVzIGxhdGVu Y3kgZm9yIGFwcGxpY2F0aW9uczsgc3BlY2lmaWNhbGx5LCBIVFRQLiBRVUlDIHdhcyBidWlsdCBl eHByZXNzbHkgZm9yIHRoaXMgcHVycG9zZSwgYW5kIHRoZXJlIGlzIGZhaXJseSBleHRlbnNpdmUg ZGVwbG95bWVudCBleHBlcmllbmNlIHdpdGggdXNpbmcgUVVJQyBmb3IgSFRUUC4gVGhlIEJvRidz IGNoYXJ0ZXIgaXMgbm90IGNsZWFuLXNsYXRlIGRlc2lnbiAtLSBRVUlDIGV4aXN0cywgaXQgaXMg YmVpbmcgdXNlZCB0byBzb2x2ZSBwcmVjaXNlbHkgdGhlIHByb2JsZW0gb2YgYmVpbmcgYSBsb3ct bGF0ZW5jeSBIVFRQIHRyYW5zcG9ydCwgYW5kIHRoZSBjaGFydGVyIHNheXMgYXMgbXVjaCB0aGF0 IHRoZSBwcm9wb3NlZCBnb2FsIGlzIHRvIHN0YXJ0IHdpdGggUVVJQydzIGN1cnJlbnQgZGVzaWdu IGFzIHRoZSBpbml0aWFsIHNlZWQgYW5kIGdlbmVyYWxpemUgaXQuIFRoZXJlJ3MgYWN0aXZlIGlu dGVyZXN0IGZyb20gdmFyaW91cyBlbnRpdGllcyBpbiBidWlsZGluZyBhbmQgdXNpbmcgUVVJQywg d2hpY2ggaXMgdGhlIHByaW1hcnkgbW90aXZhdGlvbiBmb3IgdGhpcyBzdGFuZGFyZGl6YXRpb24g ZWZmb3J0Lg0KDQpUaGVyZSdzIGFsc28gdGhlIGFkZGl0aW9uYWwgb3Bwb3J0dW5pdHkgdG8ganVt cHN0YXJ0IGEgbmV4dC1nZW5lcmF0aW9uIHRyYW5zcG9ydCBmb3IgbW9kZXJuIGFwcGxpY2F0aW9u cywgd2hpY2ggc2hvdWxkIGJlIGEgY2xvc2Ugc2Vjb25kIG1vdGl2YXRpb24gZm9yIHRoaXMgd29y ayBhdCB0aGUgSUVURi4gV2UgY2FuIHVzdWFsbHkgZmluZCByb3VnaCB0cmFuc2xhdGlvbnMgZnJv bSBvbmUgdHJhbnNwb3J0IHRvIGFub3RoZXIsIGlmIHdlIGFyZSB3aWxsaW5nIHRvIHNxdWludCBo YXJkIGVub3VnaCBhbmQgbGl2ZSB3aXRoIHRoZSByZXN1bHRpbmcgY29tcGxleGl0eS4gUnlhbiBC aWNraGFydCdzIHdvcmsgb24gbWFwcGluZyBUQ1Agc2VtYW50aWNzIG9udG8gU0NUUCBhbmQgbXkg d29yayB3aXRoIEJyeWFuIEZvcmQgb24gbWFwcGluZyBTQ1RQLWxpa2Ugc2VtYW50aWNzIG9udG8g VENQIGFyZSBib3RoIGV4YW1wbGVzIG9mIGhvdyB3aXRoIGVub3VnaCB3b3JrIGl0IGlzIGZlYXNp YmxlIHRvIHJldHJvZml0IGEgdHJhbnNwb3J0IG9uIHRvcCBvZiBvciBpbnNpZGUgYW5vdGhlci4g VGhhdCBzYWlkLCBhIGNsZWFuLXNsYXRlIGRlc2lnbiBoYXMgc3Vic3RhbnRpYWwgYmVuZWZpdHMg aWYgdGhlIGNvc3RzIG9mIGJ1aWxkaW5nIGFuZCBkZXBsb3lpbmcgaXQgY2FuIGJlIGJhbGFuY2Vk IG91dC4gUVVJQyBzaG93cyBhbiBpbml0aWFsIGRlcGxveWFibGUgKGFuZCBkZXBsb3llZCkgY2xl YW4tc2xhdGUgZGVzaWduLCBhbmQgYXJndWFibHksIHRoZSBjb3N0cyBvZiBidWlsZGluZyBhbmQg ZGVwbG95aW5nIGl0IGhhdmUgYmVlbiBjb25zaWRlcmVkIHJlYXNvbmFibGUgYnkgZm9sa3MsIGF0 IEdvb2dsZSBhbmQgZWxzZXdoZXJlLCBjdXJyZW50bHkgd29ya2luZyBvbiBkZXZlbG9waW5nIGFu ZCBkZXBsb3lpbmcgUVVJQy4NCg0KLSBqYW5hDQoNCg0KDQo= --_000_655C07320163294895BBADA28372AF5D488BD814FR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2l2ZW4gd2hhdCBpcyB3cml0dGVuIGJlbG93 LCBJIHdvdWxkIHByZWZlciB0aGF0IGFuIElFVEYgcHJvdG9jb2wgZG9lcyBub3QgdXNlIHRoZSBu YW1lIG9mIGEgcHJvcHJpZXRhcnkgcHJvdG9jb2wuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvLCBnaXZlbiB0aGF0 IG5vdCBldmVyeWJvZHkgc2VlbXMgdG8gYmUgYWJsZSB0byByZXByb2R1Y2UgdGhlIGNsYWltZWQg cGVyZm9ybWFuY2UgYmVuZWZpdHMsIGdpdmVuIHRoZSBsYWNrIG9mIGhhcmR3YXJlIHNlZ21lbnRh dGlvbiBvZmZsb2FkIGV0Yy4sIEkgZmVhcg0KIHRoYXQgdGhlIHByb3Bvc2VkIEJvRiBuYW1lIGNv dWxkIHJhaXNlIHdyb25nIGV4cGVjdGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGdpdmVuIHRo YXQgdGhlcmUgaXMgcnVubmluZyBjb2RlLCBJIGNvdWxkIGltYWdpbmUgdG8gdXNlIGUuZy4g4oCc ceKAnSBpbiBhbiBhY3JvbnltIG9mIHRoZSBJRVRGIHZlcnNpb24gb2YgYSBwcm90b2NvbC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5KYW5hIEl5ZW5nYXI8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDA4 LCAyMDE2IDk6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IFJhbmRhbGwgU3Rld2FydDxicj4NCjxiPkNj OjwvYj4gTWljaGFlbCBUw7x4ZW47IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtRVUlDXSBSZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlJhbmR5LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGlzIGFjdGl2aXR5IHRvOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYSkg ZG9jdW1lbnQgd2hhdCBHb29nbGUgYXMgZG9uZSBhbmQgcHJvZHVjZSBhbiBSRkMgc2hvd2luZyBo ZXJlIGlzIOKAnFF1aWMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7b3Im Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o Yikgc29sdmluZyBhIHNwZWNpZmljIHByb2JsZW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgaXQgaXMgKGIpIGl0IHdvdWxkIG1ha2Ugc2Vu c2UgdG8gZmlndXJlIG91dCB3aGF0IHRoZSBwcm9ibGVtIGlzIGFuZCBob3c8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPml0IGNvdWxkIGJlIHNvbHZl ZCBtb3N0IGVhc2lseS4gSW4gdGhpcyBjYXNlIG9uZSBjb3VsZCBjb25zaWRlciBldm9sdmluZyBU Q1AgKG9yIGV2ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNDVFAg4oCmIGJ1dCBoZXkgSSBkbyBUQ1AgcmlnaHQgbm93IDpEKS4gSW4gY2FzZSBv ZiAoYSkgdGhlbiB0aGlzIGlzIG5vdCBldmVuIHNvbWV0aGluZzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2UgbmVlZCB0byBkaXNjdXNzLi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0J3Mgc29tZXdoZXJlIGluIGJldHdlZW4gdGhlIHR3 by4gSU1PLCB0aGUgZ29hbCBpcyB0byBzb2x2ZSB0aGUgc3BlY2lmaWMgcHJvYmxlbSBvZiBkZXZl bG9waW5nIGEgdHJhbnNwb3J0IHRoYXQgbWluaW1pemVzIGxhdGVuY3kgZm9yIGFwcGxpY2F0aW9u czsgc3BlY2lmaWNhbGx5LCBIVFRQLiBRVUlDIHdhcyBidWlsdCBleHByZXNzbHkgZm9yIHRoaXMg cHVycG9zZSwgYW5kIHRoZXJlIGlzIGZhaXJseQ0KIGV4dGVuc2l2ZSBkZXBsb3ltZW50IGV4cGVy aWVuY2Ugd2l0aCB1c2luZyBRVUlDIGZvciBIVFRQLiBUaGUgQm9GJ3MgY2hhcnRlciBpcyBub3Qg Y2xlYW4tc2xhdGUgZGVzaWduIC0tIFFVSUMgZXhpc3RzLCBpdCBpcyBiZWluZyB1c2VkIHRvIHNv bHZlIHByZWNpc2VseSB0aGUgcHJvYmxlbSBvZiBiZWluZyBhIGxvdy1sYXRlbmN5IEhUVFAgdHJh bnNwb3J0LCBhbmQgdGhlIGNoYXJ0ZXIgc2F5cyBhcyBtdWNoIHRoYXQgdGhlIHByb3Bvc2VkIGdv YWwNCiBpcyB0byBzdGFydCB3aXRoIFFVSUMncyBjdXJyZW50IGRlc2lnbiBhcyB0aGUgaW5pdGlh bCBzZWVkIGFuZCBnZW5lcmFsaXplIGl0LiBUaGVyZSdzIGFjdGl2ZSBpbnRlcmVzdCBmcm9tIHZh cmlvdXMgZW50aXRpZXMgaW4gYnVpbGRpbmcgYW5kIHVzaW5nIFFVSUMsIHdoaWNoIGlzIHRoZSBw cmltYXJ5IG1vdGl2YXRpb24gZm9yIHRoaXMgc3RhbmRhcmRpemF0aW9uIGVmZm9ydC4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl cmUncyBhbHNvIHRoZSBhZGRpdGlvbmFsIG9wcG9ydHVuaXR5IHRvIGp1bXBzdGFydCBhIG5leHQt Z2VuZXJhdGlvbiB0cmFuc3BvcnQgZm9yIG1vZGVybiBhcHBsaWNhdGlvbnMsIHdoaWNoIHNob3Vs ZCBiZSBhIGNsb3NlIHNlY29uZCBtb3RpdmF0aW9uIGZvciB0aGlzIHdvcmsgYXQgdGhlIElFVEYu IFdlIGNhbiB1c3VhbGx5IGZpbmQgcm91Z2ggdHJhbnNsYXRpb25zIGZyb20gb25lIHRyYW5zcG9y dCB0bw0KIGFub3RoZXIsIGlmIHdlIGFyZSB3aWxsaW5nIHRvIHNxdWludCBoYXJkIGVub3VnaCBh bmQgbGl2ZSB3aXRoIHRoZSByZXN1bHRpbmcgY29tcGxleGl0eS4gUnlhbiBCaWNraGFydCdzIHdv cmsgb24gbWFwcGluZyBUQ1Agc2VtYW50aWNzIG9udG8gU0NUUCBhbmQgbXkgd29yayB3aXRoIEJy eWFuIEZvcmQgb24gbWFwcGluZyBTQ1RQLWxpa2Ugc2VtYW50aWNzIG9udG8gVENQIGFyZSBib3Ro IGV4YW1wbGVzIG9mIGhvdyB3aXRoIGVub3VnaCB3b3JrIGl0DQogaXMgZmVhc2libGUgdG8gcmV0 cm9maXQgYSB0cmFuc3BvcnQgb24gdG9wIG9mIG9yIGluc2lkZSBhbm90aGVyLiBUaGF0IHNhaWQs IGEgY2xlYW4tc2xhdGUgZGVzaWduIGhhcyBzdWJzdGFudGlhbCBiZW5lZml0cyBpZiB0aGUgY29z dHMgb2YgYnVpbGRpbmcgYW5kIGRlcGxveWluZyBpdCBjYW4gYmUgYmFsYW5jZWQgb3V0LiBRVUlD IHNob3dzIGFuIGluaXRpYWwgZGVwbG95YWJsZSAoYW5kIGRlcGxveWVkKSBjbGVhbi1zbGF0ZSBk ZXNpZ24sIGFuZA0KIGFyZ3VhYmx5LCB0aGUgY29zdHMgb2YgYnVpbGRpbmcgYW5kIGRlcGxveWlu ZyBpdCBoYXZlIGJlZW4gY29uc2lkZXJlZCByZWFzb25hYmxlIGJ5IGZvbGtzLCBhdCBHb29nbGUg YW5kIGVsc2V3aGVyZSwgY3VycmVudGx5IHdvcmtpbmcgb24gZGV2ZWxvcGluZyBhbmQgZGVwbG95 aW5nIFFVSUMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_655C07320163294895BBADA28372AF5D488BD814FR712WXCHMBA15z_-- From nobody Wed Jun 8 02:05:54 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A1E12D893 for ; Wed, 8 Jun 2016 02:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, 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 snQJYyvNMqsK for ; Wed, 8 Jun 2016 02:05:51 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id ECB7612D87C for ; Wed, 8 Jun 2016 02:05:50 -0700 (PDT) Received: from [172.17.186.217] (unknown [147.67.241.226]) by trammell.ch (Postfix) with ESMTPSA id 095741A0F5B; Wed, 8 Jun 2016 11:05:49 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F7ED0259-B058-466F-83C9-AD1AE55E8150"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 8 Jun 2016 11:05:49 +0200 Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Nokia - DE)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , "quic@ietf.org" , Randall Stewart , =?utf-8?Q?Michael_T=C3=BCxen?= Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 09:05:53 -0000 --Apple-Mail=_F7ED0259-B058-466F-83C9-AD1AE55E8150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The obvious candidate is QUAC: QUIC-based UDP Application-focused = Connection-oriented transport (or similar) Cheers, Brian > On 08 Jun 2016, at 10:57, Scharf, Michael (Nokia - DE) = wrote: >=20 > Given what is written below, I would prefer that an IETF protocol does = not use the name of a proprietary protocol. >=20 > Also, given that not everybody seems to be able to reproduce the = claimed performance benefits, given the lack of hardware segmentation = offload etc., I fear that the proposed BoF name could raise wrong = expectations. >=20 > However, given that there is running code, I could imagine to use e.g. = =E2=80=9Cq=E2=80=9D in an acronym of the IETF version of a protocol. >=20 > Michael >=20 >=20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar > Sent: Wednesday, June 08, 2016 9:08 AM > To: Randall Stewart > Cc: Michael T=C3=BCxen; quic@ietf.org > Subject: Re: [QUIC] Requirements >=20 > Randy, >=20 > Is this activity to: >=20 > (a) document what Google as done and produce an RFC showing here is = =E2=80=9CQuic" > > (b) solving a specific problem >=20 > If it is (b) it would make sense to figure out what the problem is and = how > it could be solved most easily. In this case one could consider = evolving TCP (or even > SCTP =E2=80=A6 but hey I do TCP right now :D). In case of (a) then = this is not even something > we need to discuss.. >=20 > I think it's somewhere in between the two. IMO, the goal is to solve = the specific problem of developing a transport that minimizes latency = for applications; specifically, HTTP. QUIC was built expressly for this = purpose, and there is fairly extensive deployment experience with using = QUIC for HTTP. The BoF's charter is not clean-slate design -- QUIC = exists, it is being used to solve precisely the problem of being a = low-latency HTTP transport, and the charter says as much that the = proposed goal is to start with QUIC's current design as the initial seed = and generalize it. There's active interest from various entities in = building and using QUIC, which is the primary motivation for this = standardization effort. >=20 > There's also the additional opportunity to jumpstart a next-generation = transport for modern applications, which should be a close second = motivation for this work at the IETF. We can usually find rough = translations from one transport to another, if we are willing to squint = hard enough and live with the resulting complexity. Ryan Bickhart's work = on mapping TCP semantics onto SCTP and my work with Bryan Ford on = mapping SCTP-like semantics onto TCP are both examples of how with = enough work it is feasible to retrofit a transport on top of or inside = another. That said, a clean-slate design has substantial benefits if the = costs of building and deploying it can be balanced out. QUIC shows an = initial deployable (and deployed) clean-slate design, and arguably, the = costs of building and deploying it have been considered reasonable by = folks, at Google and elsewhere, currently working on developing and = deploying QUIC. >=20 > - jana >=20 >=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_F7ED0259-B058-466F-83C9-AD1AE55E8150 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 iQIcBAEBCgAGBQJXV9/tAAoJEIoSt78L6kajxAcQAMibPjNKR5w9ZfameUYwFECh X+Iv800nKxL4qaTj+hHN9nbg3nKb1vH3Jio4PDR/mSTlzDl+nbfW0qp6Y4DskpOQ poseatk8uNS/2SKPdeIQ63GlqVQ1JQpPleUkK892p3uSgnCegXz6vQwCrSUgnq52 P3dWU/8vRs1KtckXzCcZ/ORUdOmBOSRBMCyEE9g81SO3anioUsBEdCqUn4QE24kC S8RjGs682WJgCHrgyX7YJNXZExYPrEfFbuggZNO0H0orRj/FoDypzqsuNt7hfPoQ x7KLqxTEx6N/TYhRhOaB1BRcVJ2ybs/kHVJ1Fc/t4rKTxQ8KLidQKbkpJhHMiFj/ 3CWhaKsUIqKekmbInIhj6iu9RFGaa2VghWAn+lqqB2pqcsmOppyaT2PtvEXVOVpd jk9MCGysh+vkAZCHy0RObVaH2fJKSL6ORzbXBr28q4914niXeo33HABOdNBtgeIE jOPu26rcdoSJ1ALzpsEBXGzLOcWu6r0hbwYZHCc2+hXWP/HvNeP+nLnWxsxUMAVa IqZ2TJIT8mg9uDVIoYhoyO+bcGtru9dW48J/1a9sVTez7mtkqFmHA/XRWXd8MwM1 94H5OH6i4glmnaVUg/sN6nBBudUrMJZEanI76t598MlwJ489sjGbwMM5El/Dc/NK rlaGL62i1Uvpl32nmxgM =OKfR -----END PGP SIGNATURE----- --Apple-Mail=_F7ED0259-B058-466F-83C9-AD1AE55E8150-- From nobody Wed Jun 8 02:09:58 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB812D86E for ; Wed, 8 Jun 2016 02:09:56 -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 hG8LpnBW66Yh for ; Wed, 8 Jun 2016 02:09:54 -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 4CEA712D596 for ; Wed, 8 Jun 2016 02:09:54 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 87D148ABDA00B; Wed, 8 Jun 2016 09:09:49 +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 u5899q9J024419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 09:09:52 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 u5899nEl004534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2016 11:09:52 +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; Wed, 8 Jun 2016 11:07:15 +0200 From: "Scharf, Michael (Nokia - DE)" To: Brian Trammell Thread-Topic: [QUIC] Requirements Thread-Index: AQHRuIjf1g82qhC+F0C0JHCI/xZN8J/N4CYAgACFmICAAYUQAIABVPAAgAAZTgCAAAEKgIABFZeAgACdeQCADAlHgIAAPA5Q///k0oCAACHMcA== Date: Wed, 8 Jun 2016 09:07:14 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488BD8A4@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: 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: Jana Iyengar , "quic@ietf.org" , Randall Stewart , =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 09:09:56 -0000 UXVpY2sgVXNlciBEYXRhIFByb3RlY3Rpb24NCg0KTWljaGFlbA0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQnJpYW4gVHJhbW1lbGwNClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwOCwgMjAx NiAxMTowNiBBTQ0KVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNCkNjOiBKYW5hIEl5 ZW5nYXI7IHF1aWNAaWV0Zi5vcmc7IFJhbmRhbGwgU3Rld2FydDsgTWljaGFlbCBUw7x4ZW4NClN1 YmplY3Q6IFJlOiBbUVVJQ10gUmVxdWlyZW1lbnRzDQoNClRoZSBvYnZpb3VzIGNhbmRpZGF0ZSBp cyBRVUFDOiBRVUlDLWJhc2VkIFVEUCBBcHBsaWNhdGlvbi1mb2N1c2VkIENvbm5lY3Rpb24tb3Jp ZW50ZWQgdHJhbnNwb3J0IChvciBzaW1pbGFyKQ0KDQpDaGVlcnMsDQoNCkJyaWFuDQoNCj4gT24g MDggSnVuIDIwMTYsIGF0IDEwOjU3LCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxtaWNo YWVsLnNjaGFyZkBub2tpYS5jb20+IHdyb3RlOg0KPiANCj4gR2l2ZW4gd2hhdCBpcyB3cml0dGVu IGJlbG93LCBJIHdvdWxkIHByZWZlciB0aGF0IGFuIElFVEYgcHJvdG9jb2wgZG9lcyBub3QgdXNl IHRoZSBuYW1lIG9mIGEgcHJvcHJpZXRhcnkgcHJvdG9jb2wuDQo+IA0KPiBBbHNvLCBnaXZlbiB0 aGF0IG5vdCBldmVyeWJvZHkgc2VlbXMgdG8gYmUgYWJsZSB0byByZXByb2R1Y2UgdGhlIGNsYWlt ZWQgcGVyZm9ybWFuY2UgYmVuZWZpdHMsIGdpdmVuIHRoZSBsYWNrIG9mIGhhcmR3YXJlIHNlZ21l bnRhdGlvbiBvZmZsb2FkIGV0Yy4sIEkgZmVhciB0aGF0IHRoZSBwcm9wb3NlZCBCb0YgbmFtZSBj b3VsZCByYWlzZSB3cm9uZyBleHBlY3RhdGlvbnMuDQo+IA0KPiBIb3dldmVyLCBnaXZlbiB0aGF0 IHRoZXJlIGlzIHJ1bm5pbmcgY29kZSwgSSBjb3VsZCBpbWFnaW5lIHRvIHVzZSBlLmcuIOKAnHHi gJ0gaW4gYW4gYWNyb255bSBvZiB0aGUgSUVURiB2ZXJzaW9uIG9mIGEgcHJvdG9jb2wuDQo+IA0K PiBNaWNoYWVsDQo+IA0KPiANCj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEphbmEgSXllbmdhcg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUg MDgsIDIwMTYgOTowOCBBTQ0KPiBUbzogUmFuZGFsbCBTdGV3YXJ0DQo+IENjOiBNaWNoYWVsIFTD vHhlbjsgcXVpY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1FVSUNdIFJlcXVpcmVtZW50cw0K PiANCj4gUmFuZHksDQo+IA0KPiBJcyB0aGlzIGFjdGl2aXR5IHRvOg0KPiANCj4gKGEpIGRvY3Vt ZW50IHdoYXQgR29vZ2xlIGFzIGRvbmUgYW5kIHByb2R1Y2UgYW4gUkZDIHNob3dpbmcgaGVyZSBp cyDigJxRdWljIg0KPiAgICAgICAgICA8b3I+DQo+IChiKSBzb2x2aW5nIGEgc3BlY2lmaWMgcHJv YmxlbQ0KPiANCj4gSWYgaXQgaXMgKGIpIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gZmlndXJlIG91 dCB3aGF0IHRoZSBwcm9ibGVtIGlzIGFuZCANCj4gaG93IGl0IGNvdWxkIGJlIHNvbHZlZCBtb3N0 IGVhc2lseS4gSW4gdGhpcyBjYXNlIG9uZSBjb3VsZCBjb25zaWRlciANCj4gZXZvbHZpbmcgVENQ IChvciBldmVuIFNDVFAg4oCmIGJ1dCBoZXkgSSBkbyBUQ1AgcmlnaHQgbm93IDpEKS4gSW4gY2Fz ZSANCj4gb2YgKGEpIHRoZW4gdGhpcyBpcyBub3QgZXZlbiBzb21ldGhpbmcgd2UgbmVlZCB0byBk aXNjdXNzLi4NCj4gDQo+IEkgdGhpbmsgaXQncyBzb21ld2hlcmUgaW4gYmV0d2VlbiB0aGUgdHdv LiBJTU8sIHRoZSBnb2FsIGlzIHRvIHNvbHZlIHRoZSBzcGVjaWZpYyBwcm9ibGVtIG9mIGRldmVs b3BpbmcgYSB0cmFuc3BvcnQgdGhhdCBtaW5pbWl6ZXMgbGF0ZW5jeSBmb3IgYXBwbGljYXRpb25z OyBzcGVjaWZpY2FsbHksIEhUVFAuIFFVSUMgd2FzIGJ1aWx0IGV4cHJlc3NseSBmb3IgdGhpcyBw dXJwb3NlLCBhbmQgdGhlcmUgaXMgZmFpcmx5IGV4dGVuc2l2ZSBkZXBsb3ltZW50IGV4cGVyaWVu Y2Ugd2l0aCB1c2luZyBRVUlDIGZvciBIVFRQLiBUaGUgQm9GJ3MgY2hhcnRlciBpcyBub3QgY2xl YW4tc2xhdGUgZGVzaWduIC0tIFFVSUMgZXhpc3RzLCBpdCBpcyBiZWluZyB1c2VkIHRvIHNvbHZl IHByZWNpc2VseSB0aGUgcHJvYmxlbSBvZiBiZWluZyBhIGxvdy1sYXRlbmN5IEhUVFAgdHJhbnNw b3J0LCBhbmQgdGhlIGNoYXJ0ZXIgc2F5cyBhcyBtdWNoIHRoYXQgdGhlIHByb3Bvc2VkIGdvYWwg aXMgdG8gc3RhcnQgd2l0aCBRVUlDJ3MgY3VycmVudCBkZXNpZ24gYXMgdGhlIGluaXRpYWwgc2Vl ZCBhbmQgZ2VuZXJhbGl6ZSBpdC4gVGhlcmUncyBhY3RpdmUgaW50ZXJlc3QgZnJvbSB2YXJpb3Vz IGVudGl0aWVzIGluIGJ1aWxkaW5nIGFuZCB1c2luZyBRVUlDLCB3aGljaCBpcyB0aGUgcHJpbWFy eSBtb3RpdmF0aW9uIGZvciB0aGlzIHN0YW5kYXJkaXphdGlvbiBlZmZvcnQuDQo+IA0KPiBUaGVy ZSdzIGFsc28gdGhlIGFkZGl0aW9uYWwgb3Bwb3J0dW5pdHkgdG8ganVtcHN0YXJ0IGEgbmV4dC1n ZW5lcmF0aW9uIHRyYW5zcG9ydCBmb3IgbW9kZXJuIGFwcGxpY2F0aW9ucywgd2hpY2ggc2hvdWxk IGJlIGEgY2xvc2Ugc2Vjb25kIG1vdGl2YXRpb24gZm9yIHRoaXMgd29yayBhdCB0aGUgSUVURi4g V2UgY2FuIHVzdWFsbHkgZmluZCByb3VnaCB0cmFuc2xhdGlvbnMgZnJvbSBvbmUgdHJhbnNwb3J0 IHRvIGFub3RoZXIsIGlmIHdlIGFyZSB3aWxsaW5nIHRvIHNxdWludCBoYXJkIGVub3VnaCBhbmQg bGl2ZSB3aXRoIHRoZSByZXN1bHRpbmcgY29tcGxleGl0eS4gUnlhbiBCaWNraGFydCdzIHdvcmsg b24gbWFwcGluZyBUQ1Agc2VtYW50aWNzIG9udG8gU0NUUCBhbmQgbXkgd29yayB3aXRoIEJyeWFu IEZvcmQgb24gbWFwcGluZyBTQ1RQLWxpa2Ugc2VtYW50aWNzIG9udG8gVENQIGFyZSBib3RoIGV4 YW1wbGVzIG9mIGhvdyB3aXRoIGVub3VnaCB3b3JrIGl0IGlzIGZlYXNpYmxlIHRvIHJldHJvZml0 IGEgdHJhbnNwb3J0IG9uIHRvcCBvZiBvciBpbnNpZGUgYW5vdGhlci4gVGhhdCBzYWlkLCBhIGNs ZWFuLXNsYXRlIGRlc2lnbiBoYXMgc3Vic3RhbnRpYWwgYmVuZWZpdHMgaWYgdGhlIGNvc3RzIG9m IGJ1aWxkaW5nIGFuZCBkZXBsb3lpbmcgaXQgY2FuIGJlIGJhbGFuY2VkIG91dC4gUVVJQyBzaG93 cyBhbiBpbml0aWFsIGRlcGxveWFibGUgKGFuZCBkZXBsb3llZCkgY2xlYW4tc2xhdGUgZGVzaWdu LCBhbmQgYXJndWFibHksIHRoZSBjb3N0cyBvZiBidWlsZGluZyBhbmQgZGVwbG95aW5nIGl0IGhh dmUgYmVlbiBjb25zaWRlcmVkIHJlYXNvbmFibGUgYnkgZm9sa3MsIGF0IEdvb2dsZSBhbmQgZWxz ZXdoZXJlLCBjdXJyZW50bHkgd29ya2luZyBvbiBkZXZlbG9waW5nIGFuZCBkZXBsb3lpbmcgUVVJ Qy4NCj4gDQo+IC0gamFuYQ0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBRVUlDIG1haWxpbmcgbGlzdA0KPiBRVUlDQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYw0KDQo= From nobody Wed Jun 8 07:03:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F0012D99A for ; Wed, 8 Jun 2016 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 qZRfXHp-KpcF for ; Wed, 8 Jun 2016 07:03:09 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83A012D97A for ; Wed, 8 Jun 2016 07:01:42 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p22so4445064qka.2 for ; Wed, 08 Jun 2016 07:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nEwf5CbJVtsmfZBmY45/tcyo+uiszMrqJID6wrobpUw=; b=okd/g9dgBrPlQ2kcPPd8Y2RDsZ2ImCeCAM/46tAFmcxcUUdFM5bQ2hMFMYFr4QkEuf ymFCrsI0QmZv0wNzeZ8L3NXYZBJCBOeOjPG8PLmdHedsENGF1pq0yr+H5JOhbfWJB9p3 e9A/XTeykOYvetKq+K8pZkw00MgGIvv54Oxwg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nEwf5CbJVtsmfZBmY45/tcyo+uiszMrqJID6wrobpUw=; b=Z7E8hpY9I30TNylfCcL2xD11tLEwDpCuABHHNX0CNC4p3iDJbQJPx3pHQV0XdRKja7 ON4egcv7ulqD8DGb6RCsLyt3kEtTjEpmMhiPhylQORljPC1b3RQ8CnjgTXostFShsUUs tVDDugj2yehcOXWE2IXggipXsNqchkYyfXdIiV76LyPR8hQQkUHqXVkz3BoxwmcIVcm6 wXEBmFkWx2T8MfGufwukKhaZ2U6kAFOP8X8CwTe8U4Y58UfYflGtT7eRmWk+GCYl7BE/ ub6a4Omr7q1RH73kfcRrkiav3j/cwCYMFhJya8S0bohrRrCDLKibu8CC8q/IdHVwk2wD SpCg== X-Gm-Message-State: ALyK8tKjUKlKNCVnUjucQyjJAfOoannif2C8BY2MoD16pAdE7sZENf+AwZnPE9QY9KyYuNZY X-Received: by 10.55.17.84 with SMTP id b81mr4865365qkh.104.1465394499317; Wed, 08 Jun 2016 07:01:39 -0700 (PDT) Received: from [100.127.83.61] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id a35sm329493qgf.27.2016.06.08.07.01.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 07:01:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: <5757C974.6010703@tzi.org> Date: Wed, 8 Jun 2016 10:01:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8535F9E2-8E10-4417-8BAE-135EE8542E52@netflix.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> <5757C974.6010703@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , quic@ietf.org, =?utf-8?Q?Michael_T=C3=BCxen?= Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:03:20 -0000 Carsten: +1 on the idea its transport evolution not necessarily versioning. A side note to your weblink on TLS, I can say the same thing with = experience in SCTP=E2=80=99s compatibility bits.. in all of the many SCTP interop=E2=80=99s the proper application = of the upper two bits in chunks and parameters was always a sore point that was done wrong. It never failed = to cause us issues.. hopefully most implementations of SCTP have it right now (but I doubt it :-D) R > On Jun 8, 2016, at 3:29 AM, Carsten Bormann wrote: >=20 > Versioning is almost always the wrong way to hand evolution. >=20 > (One recent article that made this point in passing: >=20 > https://www.imperialviolet.org/2016/05/16/agility.html > ) >=20 > In any case, the requirement is not for versioning, but for supporting > evolution. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Jana Iyengar wrote: >> I would add Versioning and Version Negotiation to the list -- this is >> fundamental to be able to evolve the wire format. -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Wed Jun 8 07:46:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2080712D5AE for ; Wed, 8 Jun 2016 07:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 CkpDk_QjUWZl for ; Wed, 8 Jun 2016 07:46:14 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC76012D969 for ; Wed, 8 Jun 2016 07:46:04 -0700 (PDT) Received: from [10.13.44.231] (unknown [89.27.138.50]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 1664A721E281C; Wed, 8 Jun 2016 16:46:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <8535F9E2-8E10-4417-8BAE-135EE8542E52@netflix.com> Date: Wed, 8 Jun 2016 16:46:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41736E45-03B2-441D-B84C-F39447467E58@lurchi.franken.de> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> <5757C974.6010703@tzi.org> <8535F9E2-8E10-4417-8BAE-135EE8542E52@netflix.com> To: Randall Stewart X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , Carsten Bormann , quic@ietf.org Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:46:16 -0000 > On 08 Jun 2016, at 16:01, Randall Stewart wrote: >=20 > Carsten: >=20 > +1 on the idea its transport evolution not necessarily versioning. >=20 > A side note to your weblink on TLS, I can say the same thing with = experience in SCTP=E2=80=99s compatibility > bits.. in all of the many SCTP interop=E2=80=99s the proper = application of the upper two bits in chunks and > parameters was always a sore point that was done wrong. It never = failed to cause us issues.. hopefully > most implementations of SCTP have it right now (but I doubt it :-D) My experience with testing shows that implementations have it right = now... Both on the chunk and parameter level. Part of the confusion was about a copy and paste error in RFC 2960. = After this got fixed in the Implementor's Guide, things got better. Best regards Michael >=20 > R >> On Jun 8, 2016, at 3:29 AM, Carsten Bormann wrote: >>=20 >> Versioning is almost always the wrong way to hand evolution. >>=20 >> (One recent article that made this point in passing: >>=20 >> https://www.imperialviolet.org/2016/05/16/agility.html >> ) >>=20 >> In any case, the requirement is not for versioning, but for = supporting >> evolution. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> Jana Iyengar wrote: >>> I would add Versioning and Version Negotiation to the list -- this = is >>> fundamental to be able to evolve the wire format. >=20 > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 From nobody Wed Jun 8 08:29:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8970012D9DC for ; Wed, 8 Jun 2016 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 YbMtssT9jh3Y for ; Wed, 8 Jun 2016 08:28:59 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 BB7AD12D941 for ; Wed, 8 Jun 2016 08:28:59 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id l44so4570617qgd.0 for ; Wed, 08 Jun 2016 08:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8NNg6dOgO9q1HmEr54bNqakc33pTZo6vzgMndlrB7ME=; b=Zzg6if8LWHTHEQ4dRndElKLzqJ7T3rPWg7qoE/dEXDQvHSiHS5bJmR2RH34ShzCycC 8BLoBDbTIqqLunCcXXfgTluHuTQJeLYiH+cTRlZVtIX5uOojFOOG83fcLoDhUazWG70I SQvZL5DVF2L6j+WADsZlXkIY9lYefDM7lRo+w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8NNg6dOgO9q1HmEr54bNqakc33pTZo6vzgMndlrB7ME=; b=F0y0wITO5THSxraZUIEKSaJfjJMvCkNMXap8qzU7Pd7CYH1GXqZNs6g/nZOsq2RAvh 2k0i2qeZlBKJOtKY6VEswR7BvppEjx4hKsFk0Ls61/3i+Ju07bbOoUCKZu1ZX2CKnlhq I2eo6qfqf50Yn7lcnpUCmMG2gzPS16eqBiDXR4O6RIHld/tbT4uawnESSZzfrV4gHrV1 YpKL8JCXihqM9fYufUJqhgh5f3QZJtyWcgx7EX5IoUlXMuwnkuSFvhbOD9eNinQcOV/p IBfENaqnWt2XQq3lHca1SCFJi1PLflNSn+4CJJ2FcDoXc5eWOcQ4J4D1joomEX5rPDCe oXiQ== X-Gm-Message-State: ALyK8tIYr/Uz4qkv95eDZ8tgCoxjnL78IB7M9ZSp1tcF1p/DjxF8pJA2F8nup0CEDjsPGYYJ X-Received: by 10.140.251.195 with SMTP id w186mr5325287qhc.57.1465399738647; Wed, 08 Jun 2016 08:28:58 -0700 (PDT) Received: from [100.127.83.66] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id s17sm331906qhb.2.2016.06.08.08.28.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 08:28:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: <41736E45-03B2-441D-B84C-F39447467E58@lurchi.franken.de> Date: Wed, 8 Jun 2016 11:28:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99D92D6A-7CBF-4BB2-A858-5D8A08ACF93C@netflix.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> <5757C974.6010703@tzi.org> <8535F9E2-8E10-4417-8BAE-135EE8542E52@netflix.com> <41736E45-03B2-441D-B84C-F39447467E58@lurchi.franken.de> To: =?utf-8?Q?Michael_T=C3=BCxen?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , Carsten Bormann , quic@ietf.org Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:29:01 -0000 > On Jun 8, 2016, at 10:46 AM, Michael Tuexen = wrote: >=20 >> On 08 Jun 2016, at 16:01, Randall Stewart wrote: >>=20 >> Carsten: >>=20 >> +1 on the idea its transport evolution not necessarily versioning. >>=20 >> A side note to your weblink on TLS, I can say the same thing with = experience in SCTP=E2=80=99s compatibility >> bits.. in all of the many SCTP interop=E2=80=99s the proper = application of the upper two bits in chunks and >> parameters was always a sore point that was done wrong. It never = failed to cause us issues.. hopefully >> most implementations of SCTP have it right now (but I doubt it :-D) > My experience with testing shows that implementations have it right = now... Both on the chunk and > parameter level. Michael: I agree that.. all we have seen the last few interop=E2=80=99s confirm = that.. but my =E2=80=9Cdoubt/:-D=E2=80=9D above was that if someone builds a new implementation of SCT there would be = problems.. since that did tend to be one of the principle problem spots that early interop=E2=80= =99s saw :) >=20 > Part of the confusion was about a copy and paste error in RFC 2960. = After this got fixed in the > Implementor's Guide, things got better. Maybe you are right and its all due to the mis-wordings in RFC 2960, or = could it be just be time, experience and inter-ops :-) R >=20 > Best regards > Michael >>=20 >> R >>> On Jun 8, 2016, at 3:29 AM, Carsten Bormann wrote: >>>=20 >>> Versioning is almost always the wrong way to hand evolution. >>>=20 >>> (One recent article that made this point in passing: >>>=20 >>> https://www.imperialviolet.org/2016/05/16/agility.html >>> ) >>>=20 >>> In any case, the requirement is not for versioning, but for = supporting >>> evolution. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>> Jana Iyengar wrote: >>>> I would add Versioning and Version Negotiation to the list -- this = is >>>> fundamental to be able to evolve the wire format. >>=20 >> -------- >> Randall Stewart >> rrs@netflix.com >> 803-317-4952 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Wed Jun 8 08:46:50 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@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: X-Mailman-Approved-At: Wed, 08 Jun 2016 08:46:48 -0700 Cc: tsvwg WG , Tom Herbert , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Brian Trammell , "quic@ietf.org" , "ietf@ietf.org" Subject: [QUIC] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization 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:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@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 , Tom Herbert , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Jim Roskind , "quic@ietf.org" Subject: Re: [QUIC] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization 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 14:57:12 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8CB12D5AA for ; Wed, 8 Jun 2016 14:57:11 -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 NTc9lBjXT3Ol for ; Wed, 8 Jun 2016 14:57:09 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96FAB12D508 for ; Wed, 8 Jun 2016 14:57:09 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id c72so20825933ywb.1 for ; Wed, 08 Jun 2016 14:57:09 -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=BivfAhva5satpOA/2GIH1xEFiJoJlo6uGI3AKw3mHKU=; b=nvkeuCdS3m/bjOOU2oLoFM4BY2WdaF3wFiItkYpBZCLbRMOwPKDGIaMgtjhOJNNyzy u83Lwk1wM9QD91vShsqZDo0qmi851MXlyhcExeblikqsHU4RJVxmB6hBpfkIRoDBHUzw RtzBJeFhZOKqORGNWO0z7C6oQxvziIyPOAT4TOK3TFyC0CzCDJRnOk9g7mSSWLi6O1dI Vmqs/J8NkVUXTXagX7Nvfj6FOBpTBC3+Dn4mrtzNilj1g9+YbIKnI2ydLcBi+OeRXgNR 8e8ZxNjwhkUOSfdcgm70+SwdP7L5BgPOLJ4OXB7NV9nT32UbYuh8HFYgax/l5+RJmbn4 CFxA== 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=BivfAhva5satpOA/2GIH1xEFiJoJlo6uGI3AKw3mHKU=; b=WmQEtJ0ix/b+64+z1SNY37Pr3CqfdsfI/QUUvKR8A3PzYy86RqZ93XHCklquksN4qg Q0cEUtrRar/aFr6KDMJKXggWe7KWte2dw3n71pk/O1yhWtu/jqKEhgCoIlVoGzH/zBqW ygk+eaASj5wOwGfQgIwSWO71YUhKG54QsnaKz4NJbEXW2v419olfNbfSFiqkn37i7kGJ n8zi76vqmiiPPsjJNnHQMpGqwYK/1aLAoxhmNKSNDYC41SgNQxsgROetvw9GMMMgF0lZ RpzFyPNTmj2d5cVPzq6zH2nv3Bzs9HcHKPDCZIQqrSGOzCIiTIrdt63rYLaQHsjF5fzB lM8Q== X-Gm-Message-State: ALyK8tKDOfDC5jwgNEXLNWmfhWQibhSODBJkFyzCFXqQFwjMlftOMjJhPNDyUNWXx0JSlTzPmz9q0aogGgKViqqd X-Received: by 10.13.218.65 with SMTP id c62mr4087555ywe.36.1465423028734; Wed, 08 Jun 2016 14:57:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Wed, 8 Jun 2016 14:57:07 -0700 (PDT) In-Reply-To: <26940943-82C2-4589-8265-5D45EC49B6A7@lurchi.franken.de> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> <26940943-82C2-4589-8265-5D45EC49B6A7@lurchi.franken.de> From: Jana Iyengar Date: Wed, 8 Jun 2016 14:57:07 -0700 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=94eb2c08050813339c0534cb63f6 Archived-At: Cc: quic@ietf.org, Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 21:57:11 -0000 --94eb2c08050813339c0534cb63f6 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 8, 2016 at 12:46 AM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > > On 08 Jun 2016, at 08:14, Jana Iyengar wrote: > > > > Michael, > > > > > Perhaps a list of features that can be added to TCP can be discussed > on TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on those > threads. > > I'm currently trying to figure out how such a list might look like. > > > > I think the list you have is a fairly good one to start with. I would > add Versioning and Version Negotiation to the list -- this is fundamental > to be able to evolve the wire format. > I think we agree, that the protocol must provide a way to evolve it. > Using version numbers and version negotiation is one way. Negotiating > features is another one. That would allow for a backwards compatible > way of evolution. Yup, agreed. --94eb2c08050813339c0534cb63f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 8, 2016 at 12:46 AM, Michael Tuexen <Michael.Tuex= en@lurchi.franken.de> wrote:
> On 08 Jun 2016, at 08:14, Jana Iyengar <jri@google.com> wrote:
>
> Michael,
>
> > Perhaps a list of features that can be added to TCP can be discus= sed on TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in o= n those threads.
> I'm currently trying to figure out how such a list might look like= .
>
> I think the list you have is a fairly good one to start with. I would = add Versioning and Version Negotiation to the list -- this is fundamental t= o be able to evolve the wire format.
I think we agree, that the protocol must provide a way to evolve it.=
Using version numbers and version negotiation is one way. Negotiating
features is another one. That would allow for a backwards compatible
way of evolution.

Yup, agreed.
--94eb2c08050813339c0534cb63f6-- From nobody Wed Jun 8 15:26:55 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B15612D790 for ; Wed, 8 Jun 2016 15:26:54 -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 b1ZLfpTTI8Jg for ; Wed, 8 Jun 2016 15:26:53 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF34612D10F for ; Wed, 8 Jun 2016 15:26:52 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id c72so21433600ywb.1 for ; Wed, 08 Jun 2016 15:26:52 -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=RcpbrZl9OcpKHX2YfirGt4z3M2gQ8LfVlR7ZKwxGdL8=; b=mt/2JJiko9rse3gzQ+00NIcUmr6uBwgoyjXFPNdReq8f6sGASYyQ+IuoG88PChZIZQ dSNPeGy09sqr1Nie+zfGVgHKloxvgjiHfPVOXXvZRNh0HPF5+B5j6Ep7wR/jkMPwzUQJ cjBuYxNAteDkTXGwHNFu3ZdVXeQR54IM3eC0cDvlbwcODTCbITarFBTm7AtDKTIagteh wggAPDjsT+fdlrOQkRUp0o+tAjXPemol752pZRA7UPEnCW7ZHVE1HOrUSmEaO3PqcKIi Obyy12KiHoIIKP9jJGEKbRrK8GFv08v+VHwMV02hSEY8n5eA0xCJ9RTMmgNjs3Iju/7a tGmQ== 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=RcpbrZl9OcpKHX2YfirGt4z3M2gQ8LfVlR7ZKwxGdL8=; b=NH0lqy3SXbOFOxewL2iBiBHIGz/0CrUsQpUMOn1jdf1+dEoLytnbGGQo69GF/EVCQU kyfUeHzQ9zDJD4tbEjwX7s1zxVQuv7zGusT/SVETir+oYV6nFLFq1bDudbCga56+QJGR LkPcH7ltf/vEysLNBbo7Zwik6X7uOVjNs8/o2yC7uwpeWJPF7ZgDUoqekHyuv/qbioD8 7h9VX9aTnC/QDqt1ooe2sBNAIsDEvbrzKnsRRJ05eURAX7qoVnhbVBl1IOlkELLKJJSc IBvYVKI06OgushytNSFgBh839QKUqV9ne7PdnzUg1ro5JBHU6fv3TGePoEcOBCKX+YLp 1niQ== X-Gm-Message-State: ALyK8tLp8QZh0nASfDVXVXU190fkMistRLzMQfgx2Z7y8bwA2Jcxc6koQTTzljLVs6atuvdjY4Udv8T8ITdIGfN8 X-Received: by 10.37.96.130 with SMTP id u124mr3911597ybb.81.1465424811923; Wed, 08 Jun 2016 15:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.221.193 with HTTP; Wed, 8 Jun 2016 15:26:50 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Jana Iyengar Date: Wed, 8 Jun 2016 15:26:50 -0700 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a1143e9305ca3980534cbcd22 Archived-At: Cc: =?UTF-8?Q?Michael_T=C3=BCxen?= , "quic@ietf.org" , Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 22:26:54 -0000 --001a1143e9305ca3980534cbcd22 Content-Type: text/plain; charset=UTF-8 Michael, On Wed, Jun 8, 2016 at 1:57 AM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Given what is written below, I would prefer that an IETF protocol does not > use the name of a proprietary protocol > Also, given that not everybody seems to be able to reproduce the claimed > performance benefits, given the lack of hardware segmentation offload etc., > I fear that the proposed BoF name could raise wrong expectations. > Unless it's miscommunication, you seem to be suggesting that others have tried and failed to realize some/any of the claimed benefits of QUIC. I'm not aware of any such work. I also don't understand what you mean by "lack of hardware segmentation offload". Can you clarify? I don't understand what wrong expectations the BoF name raises. To be clear, there may well be, and if there are any such, I think we definitely ought to at least clarify them in the charter text. Can you be more specific about the wrong expectations you see? - jana --001a1143e9305ca3980534cbcd22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mich= ael,

O= n Wed, Jun 8, 2016 at 1:57 AM, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com= > wrote:

Given what is written below, I would p= refer that an IETF protocol does not use the name of a proprietary protocol= =C2=A0

Also, given that not everybody see= ms to be able to reproduce the claimed performance benefits, given the lack= of hardware segmentation offload etc., I fear that the proposed BoF name could raise wrong expectations.

Unless it's miscommunication, you seem to be suggest= ing that others have tried and failed to realize some/any of the claimed be= nefits of QUIC. I'm not aware of any such work. I also don't unders= tand what you mean by "lack of hardware segmentation offload". Ca= n you clarify?

I don't understand what wrong e= xpectations the BoF name raises. To be clear, there may well be, and if the= re are any such, I think we definitely ought to at least clarify them in th= e charter text. Can you be more specific about the wrong expectations you s= ee?

- jana
--001a1143e9305ca3980534cbcd22-- From nobody Thu Jun 9 01:03:57 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9212D12D1B9 for ; Thu, 9 Jun 2016 01:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CQVPv460DeZC for ; Thu, 9 Jun 2016 01:03: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 20F9512D1AA for ; Thu, 9 Jun 2016 01:03:52 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 49C74C3F91C41; Thu, 9 Jun 2016 08:03:49 +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 u5983omT004038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2016 08:03:50 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 u5983hOL012994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jun 2016 10:03:50 +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; Thu, 9 Jun 2016 10:03:47 +0200 From: "Scharf, Michael (Nokia - DE)" To: Jana Iyengar Thread-Topic: [QUIC] Requirements Thread-Index: AQHRuIjf1g82qhC+F0C0JHCI/xZN8J/N4CYAgACFmICAAYUQAIABVPAAgAAZTgCAAAEKgIABFZeAgACdeQCADAlHgIAAPA5QgADEnwCAAK5bMA== Date: Thu, 9 Jun 2016 08:03:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D488C9873FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Cc: =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= , "quic@ietf.org" , Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 08:03:55 -0000 --_000_655C07320163294895BBADA28372AF5D488C9873FR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgY29uY2VybiBpcyB0aGF0IHRoZSBjdXJyZW50IGNoYXJ0ZXIgc3VnZ2VzdGlvbiBtYXJrZXRz IHRoZSBwcm90b2NvbCBieSDigJxtaW5pbWl6aW5nICjigKYpIG92ZXJhbGwgdHJhbnNwb3J0IGxh dGVuY3kgZm9yIGFwcGxpY2F0aW9uc+KAnS4gSU1ITyB0aGlzIGNhbiBoYXZlIHJlYm91bmQgZWZm ZWN0cy4NCg0KSGVyZSBpcyB3aGF0IEkgbWVhbiBieSB3cm9uZyBleHBlY3RhdGlvbnM6IFdoZXRo ZXIgYSBwcm90b2NvbCBpcyBpbmRlZWQgZmFzdCBvciBub3QgZGVwZW5kcyBvbiBtYW55IHBhcmFt ZXRlcnMgaW5jbHVkaW5nIGFzcGVjdHMgc3VjaCBhcyBoYXJkd2FyZSBhY2NlbGVyYXRpb24vb2Zm bG9hZCAod2hpY2ggbWF0dGVycyBhdCAxMEcvNDBHIGxpbmUgc3BlZWQsIHRvIHRoZSBiZXN0IG9m IG15IGtub3dsZWRnZSkuIFNvbWUgb2YgdGhlc2UgZWZmZWN0cyBvZiBhcHBsaWNhdGlvbiBsYXRl bmN5IGFyZSBlbnRpcmVseSBpbmRlcGVuZGVudCBvZiB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlv bi4gQnV0IGlmIHRoZSBJRVRGIGNyZWF0ZXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgc3BlZWQgaXMg dGhlIG1haW4gZGlmZmVyZW50aWF0b3Igb2YgYSBwcm90b2NvbCwgdGhpcyBjb3VsZCBoYXZlIGVm ZmVjdHMgc3VjaCBhcyBlbmNvdXJhZ2luZyBhcHAgZGV2ZWxvcGVycyB0byBkaXNhYmxlIG9yIOKA nHR1bmXigJ0gdGhlIGNvbmdlc3Rpb24gY29udHJvbCBsb2dpYywgdG8gYWN0dWFsbHkgZ2V0IHRo ZSDigJxwcm9taXNlZOKAnSBtaW5pbXVtIGxhdGVuY3kuLi4gQW5kIGlmIGEgcHJvdG9jb2wgdGFy Z2V0cyB0aGUgV2ViLCBpdCB3aWxsIHByb2JhYmx5IGJlIHVzZWQgYnkgZGl2ZXJzZSB1c2VyIGNv bW11bml0aWVzLCBhbmQgbm90IGV2ZXJ5Ym9keSBtYXkgaGF2ZSB0aGUgc2FtZSB1bmRlcnN0YW5k aW5nIG9mIHdoYXQg4oCcY29uZ2VzdGlvbiBjb250cm9sIGFnaWxpdHnigJ0gbWVhbnMgdG8gaGlt Li4uDQoNCk9idmlvdXNseSwgdGhlcmUgaXMgbm90IG11Y2ggdGhlIElFVEYgY2FuIGRvIHRvIHBy ZXZlbnQgdXNlcnMgZnJvbSBkaXNhYmxpbmcgb3IgbWVzc2luZyB1cCBjb25nZXN0aW9uIGNvbnRy b2wsIGFuZCBJIGFtIGZpbmUgd2l0aCBleGNsdWRpbmcgY29uZ2VzdGlvbiBjb250cm9sIGluIHRo ZSBjaGFydGVyLg0KDQpCdXQgSSBiZWxpZXZlIHRoZSBJRVRGIGNvdWxkIHBpY2sgYSBwcm90b2Nv bCBhY3JvbnltIGFuZCB1c2UgY2hhcnRlciB3b3JkaW5nIHRoYXQgZm9jdXNlcyBtb3JlIG9uIHRo ZSBmdW5jdGlvbmFsIHByb3BlcnRpZXMgb2YgcHJvdG9jb2wsIHRvIG1ha2UgY2xlYXIgdGhhdCBp biB0aGUgSW50ZXJuZXQgbm90IGV2ZXJ5IHRyYW5zZmVyIGNhbiBiZSBxdWljay4NCg0KTWljaGFl bA0KDQoNCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQpTZW50 OiBUaHVyc2RheSwgSnVuZSAwOSwgMjAxNiAxMjoyNyBBTQ0KVG86IFNjaGFyZiwgTWljaGFlbCAo Tm9raWEgLSBERSkNCkNjOiBSYW5kYWxsIFN0ZXdhcnQ7IE1pY2hhZWwgVMO8eGVuOyBxdWljQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW1FVSUNdIFJlcXVpcmVtZW50cw0KDQpNaWNoYWVsLA0KDQpP biBXZWQsIEp1biA4LCAyMDE2IGF0IDE6NTcgQU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBE RSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEu Y29tPj4gd3JvdGU6DQoNCkdpdmVuIHdoYXQgaXMgd3JpdHRlbiBiZWxvdywgSSB3b3VsZCBwcmVm ZXIgdGhhdCBhbiBJRVRGIHByb3RvY29sIGRvZXMgbm90IHVzZSB0aGUgbmFtZSBvZiBhIHByb3By aWV0YXJ5IHByb3RvY29sDQoNCkFsc28sIGdpdmVuIHRoYXQgbm90IGV2ZXJ5Ym9keSBzZWVtcyB0 byBiZSBhYmxlIHRvIHJlcHJvZHVjZSB0aGUgY2xhaW1lZCBwZXJmb3JtYW5jZSBiZW5lZml0cywg Z2l2ZW4gdGhlIGxhY2sgb2YgaGFyZHdhcmUgc2VnbWVudGF0aW9uIG9mZmxvYWQgZXRjLiwgSSBm ZWFyIHRoYXQgdGhlIHByb3Bvc2VkIEJvRiBuYW1lIGNvdWxkIHJhaXNlIHdyb25nIGV4cGVjdGF0 aW9ucy4NClVubGVzcyBpdCdzIG1pc2NvbW11bmljYXRpb24sIHlvdSBzZWVtIHRvIGJlIHN1Z2dl c3RpbmcgdGhhdCBvdGhlcnMgaGF2ZSB0cmllZCBhbmQgZmFpbGVkIHRvIHJlYWxpemUgc29tZS9h bnkgb2YgdGhlIGNsYWltZWQgYmVuZWZpdHMgb2YgUVVJQy4gSSdtIG5vdCBhd2FyZSBvZiBhbnkg c3VjaCB3b3JrLiBJIGFsc28gZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGJ5ICJsYWNr IG9mIGhhcmR3YXJlIHNlZ21lbnRhdGlvbiBvZmZsb2FkIi4gQ2FuIHlvdSBjbGFyaWZ5Pw0KDQpJ IGRvbid0IHVuZGVyc3RhbmQgd2hhdCB3cm9uZyBleHBlY3RhdGlvbnMgdGhlIEJvRiBuYW1lIHJh aXNlcy4gVG8gYmUgY2xlYXIsIHRoZXJlIG1heSB3ZWxsIGJlLCBhbmQgaWYgdGhlcmUgYXJlIGFu eSBzdWNoLCBJIHRoaW5rIHdlIGRlZmluaXRlbHkgb3VnaHQgdG8gYXQgbGVhc3QgY2xhcmlmeSB0 aGVtIGluIHRoZSBjaGFydGVyIHRleHQuIENhbiB5b3UgYmUgbW9yZSBzcGVjaWZpYyBhYm91dCB0 aGUgd3JvbmcgZXhwZWN0YXRpb25zIHlvdSBzZWU/DQoNCi0gamFuYQ0K --_000_655C07320163294895BBADA28372AF5D488C9873FR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuZ21h aWwtbXNvbm9ybWFsLCBsaS5nbWFpbC1tc29ub3JtYWwsIGRpdi5nbWFpbC1tc29ub3JtYWwNCgl7 bXNvLXN0eWxlLW5hbWU6Z21haWwtbXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15 IGNvbmNlcm4gaXMgdGhhdCB0aGUgY3VycmVudCBjaGFydGVyIHN1Z2dlc3Rpb24gbWFya2V0cyB0 aGUgcHJvdG9jb2wgYnkg4oCcbWluaW1pemluZyAo4oCmKSBvdmVyYWxsIHRyYW5zcG9ydCBsYXRl bmN5IGZvciBhcHBsaWNhdGlvbnPigJ0uIElNSE8gdGhpcyBjYW4gaGF2ZSByZWJvdW5kDQogZWZm ZWN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhlcmUgaXMgd2hhdCBJIG1lYW4gYnkgd3JvbmcgZXhwZWN0YXRpb25z OiBXaGV0aGVyIGEgcHJvdG9jb2wgaXMgaW5kZWVkIGZhc3Qgb3Igbm90IGRlcGVuZHMgb24gbWFu eSBwYXJhbWV0ZXJzIGluY2x1ZGluZyBhc3BlY3RzIHN1Y2ggYXMgaGFyZHdhcmUgYWNjZWxlcmF0 aW9uL29mZmxvYWQNCiAod2hpY2ggbWF0dGVycyBhdCAxMEcvNDBHIGxpbmUgc3BlZWQsIHRvIHRo ZSBiZXN0IG9mIG15IGtub3dsZWRnZSkuIFNvbWUgb2YgdGhlc2UgZWZmZWN0cyBvZiBhcHBsaWNh dGlvbiBsYXRlbmN5IGFyZSBlbnRpcmVseSBpbmRlcGVuZGVudCBvZiB0aGUgcHJvdG9jb2wgc3Bl Y2lmaWNhdGlvbi4gQnV0IGlmIHRoZSBJRVRGIGNyZWF0ZXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQg c3BlZWQgaXMgdGhlIG1haW4gZGlmZmVyZW50aWF0b3Igb2YgYSBwcm90b2NvbCwNCiB0aGlzIGNv dWxkIGhhdmUgZWZmZWN0cyBzdWNoIGFzIGVuY291cmFnaW5nIGFwcCBkZXZlbG9wZXJzIHRvIGRp c2FibGUgb3Ig4oCcdHVuZeKAnSB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGxvZ2ljLCB0byBhY3R1 YWxseSBnZXQgdGhlIOKAnHByb21pc2Vk4oCdIG1pbmltdW0gbGF0ZW5jeS4uLiBBbmQgaWYgYSBw cm90b2NvbCB0YXJnZXRzIHRoZSBXZWIsIGl0IHdpbGwgcHJvYmFibHkgYmUgdXNlZCBieSBkaXZl cnNlIHVzZXIgY29tbXVuaXRpZXMsIGFuZCBub3QNCiBldmVyeWJvZHkgbWF5IGhhdmUgdGhlIHNh bWUgdW5kZXJzdGFuZGluZyBvZiB3aGF0IOKAnGNvbmdlc3Rpb24gY29udHJvbCBhZ2lsaXR54oCd IG1lYW5zIHRvIGhpbS4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T2J2aW91c2x5LCB0aGVyZSBpcyBub3QgbXVjaCB0 aGUgSUVURiBjYW4gZG8gdG8gcHJldmVudCB1c2VycyBmcm9tIGRpc2FibGluZyBvciBtZXNzaW5n IHVwIGNvbmdlc3Rpb24gY29udHJvbCwgYW5kIEkgYW0gZmluZSB3aXRoIGV4Y2x1ZGluZyBjb25n ZXN0aW9uIGNvbnRyb2wNCiBpbiB0aGUgY2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGJlbGlldmUg dGhlIElFVEYgY291bGQgcGljayBhIHByb3RvY29sIGFjcm9ueW0gYW5kIHVzZSBjaGFydGVyIHdv cmRpbmcgdGhhdCBmb2N1c2VzIG1vcmUgb24gdGhlIGZ1bmN0aW9uYWwgcHJvcGVydGllcyBvZiBw cm90b2NvbCwgdG8gbWFrZSBjbGVhciB0aGF0DQogaW4gdGhlIEludGVybmV0IG5vdCBldmVyeSB0 cmFuc2ZlciBjYW4gYmUgcXVpY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEphbmEgSXllbmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDA5LCAyMDE2IDEyOjI3IEFNPGJyPg0KPGI+VG86 PC9iPiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpPGJyPg0KPGI+Q2M6PC9iPiBSYW5kYWxs IFN0ZXdhcnQ7IE1pY2hhZWwgVMO8eGVuOyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbUVVJQ10gUmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWwsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVuIDgsIDIwMTYg YXQgMTo1NyBBTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSI+bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFp bC1tc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5H aXZlbiB3aGF0IGlzIHdyaXR0ZW4gYmVsb3csIEkgd291bGQgcHJlZmVyIHRoYXQgYW4gSUVURiBw cm90b2NvbCBkb2VzIG5vdCB1c2UgdGhlIG5hbWUgb2YgYSBwcm9wcmlldGFyeSBwcm90b2NvbDwv c3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxwIGNsYXNzPSJnbWFpbC1tc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbHNvLCBnaXZlbiB0aGF0IG5vdCBldmVyeWJvZHkgc2VlbXMg dG8gYmUgYWJsZSB0byByZXByb2R1Y2UgdGhlIGNsYWltZWQgcGVyZm9ybWFuY2UgYmVuZWZpdHMs IGdpdmVuIHRoZSBsYWNrIG9mIGhhcmR3YXJlIHNlZ21lbnRhdGlvbiBvZmZsb2FkIGV0Yy4sIEkN CiBmZWFyIHRoYXQgdGhlIHByb3Bvc2VkIEJvRiBuYW1lIGNvdWxkIHJhaXNlIHdyb25nIGV4cGVj dGF0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vbmxlc3MgaXQncyBtaXNjb21tdW5pY2F0aW9uLCB5 b3Ugc2VlbSB0byBiZSBzdWdnZXN0aW5nIHRoYXQgb3RoZXJzIGhhdmUgdHJpZWQgYW5kIGZhaWxl ZCB0byByZWFsaXplIHNvbWUvYW55IG9mIHRoZSBjbGFpbWVkIGJlbmVmaXRzIG9mIFFVSUMuIEkn bSBub3QgYXdhcmUgb2YgYW55IHN1Y2ggd29yay4gSSBhbHNvIGRvbid0IHVuZGVyc3RhbmQgd2hh dCB5b3UgbWVhbiBieSAmcXVvdDtsYWNrIG9mIGhhcmR3YXJlIHNlZ21lbnRhdGlvbg0KIG9mZmxv YWQmcXVvdDsuIENhbiB5b3UgY2xhcmlmeT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgd3JvbmcgZXhw ZWN0YXRpb25zIHRoZSBCb0YgbmFtZSByYWlzZXMuIFRvIGJlIGNsZWFyLCB0aGVyZSBtYXkgd2Vs bCBiZSwgYW5kIGlmIHRoZXJlIGFyZSBhbnkgc3VjaCwgSSB0aGluayB3ZSBkZWZpbml0ZWx5IG91 Z2h0IHRvIGF0IGxlYXN0IGNsYXJpZnkgdGhlbSBpbiB0aGUgY2hhcnRlciB0ZXh0LiBDYW4geW91 IGJlIG1vcmUgc3BlY2lmaWMgYWJvdXQgdGhlIHdyb25nDQogZXhwZWN0YXRpb25zIHlvdSBzZWU/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g amFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_655C07320163294895BBADA28372AF5D488C9873FR712WXCHMBA15z_-- From nobody Thu Jun 9 02:06:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0F412D0A3 for ; Thu, 9 Jun 2016 02:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 2bECLg2-Db-I for ; Thu, 9 Jun 2016 02:06:17 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A9712D0D9 for ; Thu, 9 Jun 2016 02:06:16 -0700 (PDT) Received: from [192.168.1.7] (p4FE301FE.dip0.t-ipconnect.de [79.227.1.254]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8CB94721E281C; Thu, 9 Jun 2016 11:06:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 9 Jun 2016 11:06:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Nokia - DE)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , "quic@ietf.org" , Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 09:06:19 -0000 > On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) = wrote: >=20 > My concern is that the current charter suggestion markets the protocol = by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency for = applications=E2=80=9D. IMHO this can have rebound effects. > =20 > Here is what I mean by wrong expectations: Whether a protocol is = indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to = the best of my knowledge). Some of these effects of=20 I think this refers to high throughput. For TCP, offloading TCP = processing to a NIC improves performance of the TCP processing. I'm not sure if this still helps if = encryption/decryption comes into the game. > application latency are entirely independent of the protocol = specification. But if the IETF creates the expectation that speed is the = main differentiator of a protocol, this could have effects such as = encouraging app developers to disable or =E2=80=9Ctune=E2=80=9D the I think term speed is too generic. Depending on whom you talk this can = mean: * high bandwidth * low latency * something else. So I do think the term "minimising the transport latency" is more = precisely. Best regards Michael > congestion control logic, to actually get the =E2=80=9Cpromised=E2=80=9D= minimum latency... And if a protocol targets the Web, it will probably = be used by diverse user communities, and not everybody may have the same = understanding of what =E2=80=9Ccongestion control agility=E2=80=9D means = to him... > =20 > Obviously, there is not much the IETF can do to prevent users from = disabling or messing up congestion control, and I am fine with excluding = congestion control in the charter. > =20 > But I believe the IETF could pick a protocol acronym and use charter = wording that focuses more on the functional properties of protocol, to = make clear that in the Internet not every transfer can be quick. > =20 > Michael > =20 > =20 > =20 > From: Jana Iyengar [mailto:jri@google.com]=20 > Sent: Thursday, June 09, 2016 12:27 AM > To: Scharf, Michael (Nokia - DE) > Cc: Randall Stewart; Michael T=C3=BCxen; quic@ietf.org > Subject: Re: [QUIC] Requirements > =20 > Michael, > =20 > On Wed, Jun 8, 2016 at 1:57 AM, Scharf, Michael (Nokia - DE) = wrote: > Given what is written below, I would prefer that an IETF protocol does = not use the name of a proprietary protocol=20 >=20 > Also, given that not everybody seems to be able to reproduce the = claimed performance benefits, given the lack of hardware segmentation = offload etc., I fear that the proposed BoF name could raise wrong = expectations. >=20 > Unless it's miscommunication, you seem to be suggesting that others = have tried and failed to realize some/any of the claimed benefits of = QUIC. I'm not aware of any such work. I also don't understand what you = mean by "lack of hardware segmentation offload". Can you clarify? > =20 > I don't understand what wrong expectations the BoF name raises. To be = clear, there may well be, and if there are any such, I think we = definitely ought to at least clarify them in the charter text. Can you = be more specific about the wrong expectations you see? > =20 > - jana From nobody Thu Jun 9 02:08:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE1712D10B for ; Thu, 9 Jun 2016 02:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 2a5aQeXhfIRV for ; Thu, 9 Jun 2016 02:08:43 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5536812D0A3 for ; Thu, 9 Jun 2016 02:08:43 -0700 (PDT) Received: from [192.168.1.7] (p4FE301FE.dip0.t-ipconnect.de [79.227.1.254]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 02F26721E281C; Thu, 9 Jun 2016 11:08:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <99D92D6A-7CBF-4BB2-A858-5D8A08ACF93C@netflix.com> Date: Thu, 9 Jun 2016 11:08:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de> <5757C974.6010703@tzi.org> <8535F9E2-8E10-4417-8BAE-135EE8542E52@netflix.com> <41736E45-03B2-441D-B84C-F39447467E58@lurchi.franken.de> <99D92D6A-7CBF-4BB2-A858-5D8A08ACF93C@netflix.com> To: Randall Stewart X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , Carsten Bormann , quic@ietf.org Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 09:08:45 -0000 > On 08 Jun 2016, at 17:28, Randall Stewart wrote: >=20 >=20 >> On Jun 8, 2016, at 10:46 AM, Michael Tuexen = wrote: >>=20 >>> On 08 Jun 2016, at 16:01, Randall Stewart wrote: >>>=20 >>> Carsten: >>>=20 >>> +1 on the idea its transport evolution not necessarily versioning. >>>=20 >>> A side note to your weblink on TLS, I can say the same thing with = experience in SCTP=E2=80=99s compatibility >>> bits.. in all of the many SCTP interop=E2=80=99s the proper = application of the upper two bits in chunks and >>> parameters was always a sore point that was done wrong. It never = failed to cause us issues.. hopefully >>> most implementations of SCTP have it right now (but I doubt it :-D) >> My experience with testing shows that implementations have it right = now... Both on the chunk and >> parameter level. >=20 > Michael: >=20 > I agree that.. all we have seen the last few interop=E2=80=99s confirm = that.. but my =E2=80=9Cdoubt/:-D=E2=80=9D above was > that if someone builds a new implementation of SCT there would be = problems.. since that > did tend to be one of the principle problem spots that early = interop=E2=80=99s saw :) The point you are referring to is the handling of unknown chunk / = parameters. Newer SCTP extensions use the SUPPORTED_CHUNK_TYPES parameter to do the = "feature negotiation". This works pretty well and I haven't seen problems with that. It allow a = pretty fine granular negotiation. Best regards Michael >=20 >>=20 >> Part of the confusion was about a copy and paste error in RFC 2960. = After this got fixed in the >> Implementor's Guide, things got better. >=20 > Maybe you are right and its all due to the mis-wordings in RFC 2960, = or could it be just > be time, experience and inter-ops :-) >=20 > R >=20 >>=20 >> Best regards >> Michael >>>=20 >>> R >>>> On Jun 8, 2016, at 3:29 AM, Carsten Bormann wrote: >>>>=20 >>>> Versioning is almost always the wrong way to hand evolution. >>>>=20 >>>> (One recent article that made this point in passing: >>>>=20 >>>> https://www.imperialviolet.org/2016/05/16/agility.html >>>> ) >>>>=20 >>>> In any case, the requirement is not for versioning, but for = supporting >>>> evolution. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>>=20 >>>> Jana Iyengar wrote: >>>>> I would add Versioning and Version Negotiation to the list -- this = is >>>>> fundamental to be able to evolve the wire format. >>>=20 >>> -------- >>> Randall Stewart >>> rrs@netflix.com >>> 803-317-4952 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 From nobody Thu Jun 9 02:32:25 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C309A12D1E0 for ; Thu, 9 Jun 2016 02:32:24 -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 Z_M9LxVj_5IL for ; Thu, 9 Jun 2016 02:32:22 -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 0BCAB12D0D9 for ; Thu, 9 Jun 2016 02:32:21 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 048EF47140855; Thu, 9 Jun 2016 09:32:18 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u599WJrM030710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2016 09:32:19 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 u599WIoH001205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jun 2016 11:32:19 +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; Thu, 9 Jun 2016 11:32:18 +0200 From: "Scharf, Michael (Nokia - DE)" To: Michael Tuexen Thread-Topic: [QUIC] Requirements Thread-Index: AQHRuIjf1g82qhC+F0C0JHCI/xZN8J/N4CYAgACFmICAAYUQAIABVPAAgAAZTgCAAAEKgIABFZeAgACdeQCADAlHgIAAPA5QgADEnwCAAK5bMIAABEKAgAAijEA= Date: Thu, 9 Jun 2016 09:32:18 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488C9E77@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> In-Reply-To: <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jana Iyengar , "quic@ietf.org" , Randall Stewart Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 09:32:25 -0000 V2hldGhlciAidHJhbnNwb3J0IGxhdGVuY3kiIGlzIGRvbWluYXRlIGJ5IHRocm91Z2hwdXQgb3Ig YnkgcHJvdG9jb2wgaGFuZHNoYWtlcyBtYXkgZGVwZW5kIG9uIHRoZSB1c2UgY2FzZS4gVGhlIEhU VFAgY29tbXVuaWNhdGlvbiBwYXR0ZXJuIG9mIGEgV2ViIGJyb3dzZXIgYXQgYSByZXNpZGVudGlh bCBJbnRlcm5ldCB1c2VyIG1heSBiZSBkaWZmZXJlbnQgdG8sIHNheSwgdGhlIEhUVFAgY29tbXVu aWNhdGlvbiBwYXR0ZXJuIG9mIGEgcmVhbC10aW1lIGJpZyBkYXRhIGFuYWx5dGljcyBhcHBsaWNh dGlvbiBpbnNpZGUgYSBkYXRhIGNlbnRlci4NCg0KQW5kLCBmb3Igd2hhdCBpdCBpcyB3b3J0aCwg SSBiZWxpZXZlIHRoYXQgcGVvcGxlIHdobyByZWFsbHkgY2FyZSBhYm91dCBsYXRlbmN5LCBidXQg bm90IGFib3V0IHRocm91Z2hwdXQsIGN1cnJlbnRseSBlLmcuIHRlcm1pbmF0ZSBUQ1AgaW5zaWRl IEZQR0FzIGRpcmVjdGx5IG9uIHRoZSBOSUMuIEluIHRoYXQgdXNlIGNhc2UsIEkgaGF2ZSBoZWFy ZCB0aGF0IHRoZSBlbmQtdG8tZW5kIGFwcGxpY2F0aW9uICJ0cmFuc3BvcnQgbGF0ZW5jeSIsIG92 ZXIgYSBXQU4sIHRhcmdldHMgYXQgMTAgbWljcm9zZWNvbmRzLiAoRGlzY2xhaW1lcjogSSBkb24n dCBrbm93IHdoZXRoZXIgVExTIGFuZCBIVFRQIGlzIHVzZWQgaW4gdGhpcyB1c2UgY2FzZSkuDQoN CiJUcmFuc3BvcnQgbGF0ZW5jeSIgY2FuIG1lYW4gcXVpdGUgZGlmZmVyZW50IHRoaW5ncyB0byBk aWZmZXJlbnQgcGVvcGxlLiBJbiB0aGUgY3VycmVudCBjaGFydGVyIHdvcmRpbmcgSSBkb24ndCBm aW5kIHN0YXRlbWVudHMgdG8gbGltaXQgdGhlIHNjb3BlIHRvIFdlYiBicm93c2luZyBmb3IgdXNl cnMgd2l0aCAobmFycm93LWJhbmQpIEludGVybmV0IGFjY2Vzcy4NCg0KTWljaGFlbA0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwgVHVleGVuDQo+IFNlbnQ6IFRodXJz ZGF5LCBKdW5lIDA5LCAyMDE2IDExOjA2IEFNDQo+IFRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lh IC0gREUpDQo+IENjOiBKYW5hIEl5ZW5nYXI7IHF1aWNAaWV0Zi5vcmc7IFJhbmRhbGwgU3Rld2Fy dA0KPiBTdWJqZWN0OiBSZTogW1FVSUNdIFJlcXVpcmVtZW50cw0KPiANCj4gDQo+ID4gT24gMDkg SnVuIDIwMTYsIGF0IDEwOjAzLCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpDQo+IDxtaWNo YWVsLnNjaGFyZkBub2tpYS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gTXkgY29uY2VybiBpcyB0aGF0 IHRoZSBjdXJyZW50IGNoYXJ0ZXIgc3VnZ2VzdGlvbiBtYXJrZXRzIHRoZQ0KPiBwcm90b2NvbCBi eSDigJxtaW5pbWl6aW5nICjigKYpIG92ZXJhbGwgdHJhbnNwb3J0IGxhdGVuY3kgZm9yDQo+IGFw cGxpY2F0aW9uc+KAnS4gSU1ITyB0aGlzIGNhbiBoYXZlIHJlYm91bmQgZWZmZWN0cy4NCj4gPg0K PiA+IEhlcmUgaXMgd2hhdCBJIG1lYW4gYnkgd3JvbmcgZXhwZWN0YXRpb25zOiBXaGV0aGVyIGEg cHJvdG9jb2wgaXMNCj4gaW5kZWVkIGZhc3Qgb3Igbm90IGRlcGVuZHMgb24gbWFueSBwYXJhbWV0 ZXJzIGluY2x1ZGluZyBhc3BlY3RzIHN1Y2ggYXMNCj4gaGFyZHdhcmUgYWNjZWxlcmF0aW9uL29m ZmxvYWQgKHdoaWNoIG1hdHRlcnMgYXQgMTBHLzQwRyBsaW5lIHNwZWVkLCB0bw0KPiB0aGUgYmVz dCBvZiBteSBrbm93bGVkZ2UpLiBTb21lIG9mIHRoZXNlIGVmZmVjdHMgb2YNCj4gSSB0aGluayB0 aGlzIHJlZmVycyB0byBoaWdoIHRocm91Z2hwdXQuIEZvciBUQ1AsIG9mZmxvYWRpbmcgVENQDQo+ IHByb2Nlc3NpbmcgdG8gYSBOSUMgaW1wcm92ZXMgcGVyZm9ybWFuY2UNCj4gb2YgdGhlIFRDUCBw cm9jZXNzaW5nLiBJJ20gbm90IHN1cmUgaWYgdGhpcyBzdGlsbCBoZWxwcyBpZg0KPiBlbmNyeXB0 aW9uL2RlY3J5cHRpb24gY29tZXMgaW50byB0aGUgZ2FtZS4NCj4gPiBhcHBsaWNhdGlvbiBsYXRl bmN5IGFyZSBlbnRpcmVseSBpbmRlcGVuZGVudCBvZiB0aGUgcHJvdG9jb2wNCj4gc3BlY2lmaWNh dGlvbi4gQnV0IGlmIHRoZSBJRVRGIGNyZWF0ZXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgc3BlZWQg aXMNCj4gdGhlIG1haW4gZGlmZmVyZW50aWF0b3Igb2YgYSBwcm90b2NvbCwgdGhpcyBjb3VsZCBo YXZlIGVmZmVjdHMgc3VjaCBhcw0KPiBlbmNvdXJhZ2luZyBhcHAgZGV2ZWxvcGVycyB0byBkaXNh YmxlIG9yIOKAnHR1bmXigJ0gdGhlDQo+IEkgdGhpbmsgdGVybSBzcGVlZCBpcyB0b28gZ2VuZXJp Yy4gRGVwZW5kaW5nIG9uIHdob20geW91IHRhbGsgdGhpcyBjYW4NCj4gbWVhbjoNCj4gKiBoaWdo IGJhbmR3aWR0aA0KPiAqIGxvdyBsYXRlbmN5DQo+ICogc29tZXRoaW5nIGVsc2UuDQo+IFNvIEkg ZG8gdGhpbmsgdGhlIHRlcm0gIm1pbmltaXNpbmcgdGhlIHRyYW5zcG9ydCBsYXRlbmN5IiBpcyBt b3JlDQo+IHByZWNpc2VseS4NCj4gDQo+IEJlc3QgcmVnYXJkcw0KPiBNaWNoYWVsDQo+ID4gY29u Z2VzdGlvbiBjb250cm9sIGxvZ2ljLCB0byBhY3R1YWxseSBnZXQgdGhlIOKAnHByb21pc2Vk4oCd IG1pbmltdW0NCj4gbGF0ZW5jeS4uLiBBbmQgaWYgYSBwcm90b2NvbCB0YXJnZXRzIHRoZSBXZWIs IGl0IHdpbGwgcHJvYmFibHkgYmUgdXNlZA0KPiBieSBkaXZlcnNlIHVzZXIgY29tbXVuaXRpZXMs IGFuZCBub3QgZXZlcnlib2R5IG1heSBoYXZlIHRoZSBzYW1lDQo+IHVuZGVyc3RhbmRpbmcgb2Yg d2hhdCDigJxjb25nZXN0aW9uIGNvbnRyb2wgYWdpbGl0eeKAnSBtZWFucyB0byBoaW0uLi4NCj4g Pg0KPiA+IE9idmlvdXNseSwgdGhlcmUgaXMgbm90IG11Y2ggdGhlIElFVEYgY2FuIGRvIHRvIHBy ZXZlbnQgdXNlcnMgZnJvbQ0KPiBkaXNhYmxpbmcgb3IgbWVzc2luZyB1cCBjb25nZXN0aW9uIGNv bnRyb2wsIGFuZCBJIGFtIGZpbmUgd2l0aA0KPiBleGNsdWRpbmcgY29uZ2VzdGlvbiBjb250cm9s IGluIHRoZSBjaGFydGVyLg0KPiA+DQo+ID4gQnV0IEkgYmVsaWV2ZSB0aGUgSUVURiBjb3VsZCBw aWNrIGEgcHJvdG9jb2wgYWNyb255bSBhbmQgdXNlIGNoYXJ0ZXINCj4gd29yZGluZyB0aGF0IGZv Y3VzZXMgbW9yZSBvbiB0aGUgZnVuY3Rpb25hbCBwcm9wZXJ0aWVzIG9mIHByb3RvY29sLCB0bw0K PiBtYWtlIGNsZWFyIHRoYXQgaW4gdGhlIEludGVybmV0IG5vdCBldmVyeSB0cmFuc2ZlciBjYW4g YmUgcXVpY2suDQo+ID4NCj4gPiBNaWNoYWVsDQo+ID4NCj4gPg0KPiA+DQo+ID4gRnJvbTogSmFu YSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQo+ID4gU2VudDogVGh1cnNkYXksIEp1 bmUgMDksIDIwMTYgMTI6MjcgQU0NCj4gPiBUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERF KQ0KPiA+IENjOiBSYW5kYWxsIFN0ZXdhcnQ7IE1pY2hhZWwgVMO8eGVuOyBxdWljQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUmU6IFtRVUlDXSBSZXF1aXJlbWVudHMNCj4gPg0KPiA+IE1pY2hhZWws DQo+ID4NCj4gPiBPbiBXZWQsIEp1biA4LCAyMDE2IGF0IDE6NTcgQU0sIFNjaGFyZiwgTWljaGFl bCAoTm9raWEgLSBERSkNCj4gPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4gd3JvdGU6DQo+ID4g R2l2ZW4gd2hhdCBpcyB3cml0dGVuIGJlbG93LCBJIHdvdWxkIHByZWZlciB0aGF0IGFuIElFVEYg cHJvdG9jb2wNCj4gZG9lcyBub3QgdXNlIHRoZSBuYW1lIG9mIGEgcHJvcHJpZXRhcnkgcHJvdG9j b2wNCj4gPg0KPiA+IEFsc28sIGdpdmVuIHRoYXQgbm90IGV2ZXJ5Ym9keSBzZWVtcyB0byBiZSBh YmxlIHRvIHJlcHJvZHVjZSB0aGUNCj4gY2xhaW1lZCBwZXJmb3JtYW5jZSBiZW5lZml0cywgZ2l2 ZW4gdGhlIGxhY2sgb2YgaGFyZHdhcmUgc2VnbWVudGF0aW9uDQo+IG9mZmxvYWQgZXRjLiwgSSBm ZWFyIHRoYXQgdGhlIHByb3Bvc2VkIEJvRiBuYW1lIGNvdWxkIHJhaXNlIHdyb25nDQo+IGV4cGVj dGF0aW9ucy4NCj4gPg0KPiA+IFVubGVzcyBpdCdzIG1pc2NvbW11bmljYXRpb24sIHlvdSBzZWVt IHRvIGJlIHN1Z2dlc3RpbmcgdGhhdCBvdGhlcnMNCj4gaGF2ZSB0cmllZCBhbmQgZmFpbGVkIHRv IHJlYWxpemUgc29tZS9hbnkgb2YgdGhlIGNsYWltZWQgYmVuZWZpdHMgb2YNCj4gUVVJQy4gSSdt IG5vdCBhd2FyZSBvZiBhbnkgc3VjaCB3b3JrLiBJIGFsc28gZG9uJ3QgdW5kZXJzdGFuZCB3aGF0 IHlvdQ0KPiBtZWFuIGJ5ICJsYWNrIG9mIGhhcmR3YXJlIHNlZ21lbnRhdGlvbiBvZmZsb2FkIi4g Q2FuIHlvdSBjbGFyaWZ5Pw0KPiA+DQo+ID4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgd3Jvbmcg ZXhwZWN0YXRpb25zIHRoZSBCb0YgbmFtZSByYWlzZXMuIFRvIGJlDQo+IGNsZWFyLCB0aGVyZSBt YXkgd2VsbCBiZSwgYW5kIGlmIHRoZXJlIGFyZSBhbnkgc3VjaCwgSSB0aGluayB3ZQ0KPiBkZWZp bml0ZWx5IG91Z2h0IHRvIGF0IGxlYXN0IGNsYXJpZnkgdGhlbSBpbiB0aGUgY2hhcnRlciB0ZXh0 LiBDYW4geW91DQo+IGJlIG1vcmUgc3BlY2lmaWMgYWJvdXQgdGhlIHdyb25nIGV4cGVjdGF0aW9u cyB5b3Ugc2VlPw0KPiA+DQo+ID4gLSBqYW5hDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBRVUlDIG1haWxpbmcgbGlzdA0KPiBRVUlDQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYw0K From nobody Thu Jun 9 03:30:42 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D1612D5A8 for ; Thu, 9 Jun 2016 03:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 h-wWUn76cFq7 for ; Thu, 9 Jun 2016 03:30:39 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8D512B02D for ; Thu, 9 Jun 2016 03:30:38 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id p34so17852538qgp.1 for ; Thu, 09 Jun 2016 03:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7G4ueGZBu1LdSSfAoD3WxoZkF2E1WE5aNJYEanjhsB4=; b=ZhEnDW6kV7nzcHatOB6hk7w0R1KJuAxlieQYyxQZ6q/NRaUCYI4HJohrr9B7N814bl a99QVoeFHVnS4Tt1C9+qjStfAsIbHzdIqUAmeC6ychUw9J1Ae19IGHSy642nwbnDmJwE W+c/4lbT7ZC32PWtzIgkFkYjFq8P0NamWRSJA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7G4ueGZBu1LdSSfAoD3WxoZkF2E1WE5aNJYEanjhsB4=; b=dwqzabYD/KG1vhrIdxCCmzYAx3imY5Ur6jIW7rNsq3PXKKJ14rwE4l4Q723RXcj6Kt r5OXcyyefnB1WvCeV98kV40nnkpDDtTuzkNYuUB1N9AkVPR4NB/u5ggpjyQzqPCKfFZB Y9f5Rgh0lNJnxuRxd6dGGLnY6n8mtuE0LVc7GtjMi+OwDtbabNyy7nVJB1D3sDUSYrRT 4/n5w6LXhQco+9UC8EwJi7yOmMwfvPo9BoaNCaWfc8dg4klMvS/Wvt4G0wZIWmeJYoNK 07VHyq+Gu20cgOjuOix7LHK1igKGaBJnyFePb3RsH+/ftOipJfdHrqtALlGhvMmFgLay iphA== X-Gm-Message-State: ALyK8tLEZRH4vCjtQz0VwOuVoJARS3omNJTGQ91QaV4T43CTJzeAt7w4+Pf6ElSyxrprfwaP X-Received: by 10.140.107.198 with SMTP id h64mr8514127qgf.36.1465468237764; Thu, 09 Jun 2016 03:30:37 -0700 (PDT) Received: from [100.127.83.115] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id y140sm1485615qky.19.2016.06.09.03.30.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 03:30:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> Date: Thu, 9 Jun 2016 06:30:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> To: =?utf-8?Q?Michael_T=C3=BCxen?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 10:30:40 -0000 > On Jun 9, 2016, at 5:06 AM, Michael Tuexen = wrote: >=20 >=20 >> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) = wrote: >>=20 >> My concern is that the current charter suggestion markets the = protocol by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency = for applications=E2=80=9D. IMHO this can have rebound effects. >>=20 >> Here is what I mean by wrong expectations: Whether a protocol is = indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to = the best of my knowledge). Some of these effects of=20 > I think this refers to high throughput. For TCP, offloading TCP = processing to a NIC improves performance > of the TCP processing. I'm not sure if this still helps if = encryption/decryption comes into the game. I too was thinking Michael meant offloading such as TSO and LRO. I know = on most of the caches I develop on if I turn off TSO and LRO performance of the box drops by = roughly 50%=E2=80=A6 and I think this will be a consequence of encrypting everything since I don=E2=80=99t = think you can do TSO/LRO unless the hardware/lower-layers has access to things equivalent to TCP = sequence numbers and ACK values, which is what I believe the encryption is meant to hide (from middle = boxes).=20 That will be an extreme price to pay the question is, is it worth it = /and or/ is there some other way to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-) R -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Thu Jun 9 03:42:06 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9850C12D0B9; Thu, 9 Jun 2016 03:42:03 -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 g97HKFCbN3Yh; Thu, 9 Jun 2016 03:42:01 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0561112B02D; Thu, 9 Jun 2016 03:42:00 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:52c7:8000::41b] (unknown [IPv6:2001:67c:10ec:52c7:8000::41b]) by trammell.ch (Postfix) with ESMTPSA id C073C1A0302; Thu, 9 Jun 2016 12:41:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 9 Jun 2016 12:41:29 +0200 Message-Id: <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> To: Randall Stewart X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , "Scharf, Michael \(Nokia - DE\)" , spud , "quic@ietf.org" , Jana Iyengar Subject: [QUIC] Segment offload for UDP-based protocols Re: Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 10:42:04 -0000 --Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Randall, > On 09 Jun 2016, at 12:30, Randall Stewart wrote: >=20 >=20 >> On Jun 9, 2016, at 5:06 AM, Michael Tuexen = wrote: >>=20 >>=20 >>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) = wrote: >>>=20 >>> My concern is that the current charter suggestion markets the = protocol by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency = for applications=E2=80=9D. IMHO this can have rebound effects. >>>=20 >>> Here is what I mean by wrong expectations: Whether a protocol is = indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to = the best of my knowledge). Some of these effects of >> I think this refers to high throughput. For TCP, offloading TCP = processing to a NIC improves performance >> of the TCP processing. I'm not sure if this still helps if = encryption/decryption comes into the game. >=20 > I too was thinking Michael meant offloading such as TSO and LRO. I = know on most of the caches > I develop on if I turn off TSO and LRO performance of the box drops by = roughly 50%=E2=80=A6 and I think > this will be a consequence of encrypting everything since I don=E2=80=99= t think you can do TSO/LRO unless > the hardware/lower-layers has access to things equivalent to TCP = sequence numbers and ACK values, > which is what I believe the encryption is meant to hide (from middle = boxes). >=20 > That will be an extreme price to pay the question is, is it worth it = /and or/ is there some other way > to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-) (adding spud@ietf.org, as this is a relevant question for PLUS, too): The question is what is the minimum information xSO/LRO needs to work. = If I understand how generic segment offload works, if QUIC(/PLUS) = exposes: (1) a header field that can be used to order packets and find gaps that = the kernel can find and interpret, (2) a defined and easily-found boundary between header and payload, such = that the payload retains any framing/message boundaries needed to meet = API contracts, and (3) rules about which header to choose for the "big" segment on receive then adding QUIC(/PLUS) aware SO/LRO to the kernel should be reasonably = simple. I don't see why you need ACK-equivalents to be exposed to make = this work, but I might be missing something. Hardware offload takes longer to deploy, obviously, but runs on = equivalent information. Cheers, Brian --Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6 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 iQIcBAEBCgAGBQJXWUfZAAoJEIoSt78L6kajK7oP/1o1URTm4SjFhApczfEpYklr pZCtX2bQd2Wlv9RvIFu6Lnb/qMnMxA01qkYwr5O2KCxZo1iJ8QDVIZWvTrLs+SLQ u9IVD3MMqrn038bfu6gTBTfSkHewADaujna4xa+oBe6C4x8L1ZLwGgPIHVGzJPWR sb9DRGw+go5PtAbJIFYbP20zZWqAbDMwK9lu9D0HtdJafbQrLTiprctS+SwwKPTV Wds6qJJpHLgVYaN9KNWQROSHQii3I0fIF9+uTOdTUE3lGhyw0vuh5O7J7hC34ac1 kqaI4zB3dg5iRJAEo9v4iXx3S26bPC9wKtZCslgC7t80KlJadJ+YheMzYbfGCy6w jC5n/HIXMf/tYo2zadQNoZynbXsZLv0KN5ilJR/L5X+b5W5bSkF7TAWxt21se1QJ 6qhTSQ0ghJ/V++iAtytZgW+3nQ3BMcvzY9nWd04MnAk3yw9Lno3irQPNt3sjhAax VMQ3BuiKitNrzX7v3bU3Q8VExQGIapuhyWOjTmHXa+Nayd2FmF8IJ5t3bDBxciQ9 Csz8oDhMBd4RudUqUBNYPwRsQrLLd3C6I6VaMJyUlQ7mTSMWysOPMprHTnZJ3Avw HAGzG/Kak5/pCzxBHU4/zl4Gq4dW2OTRrPfhMRtGjWQ5YZhGReYIzrkrDtC1qHgR Gjg0fY3Zud1QNPTpdr6c =16gW -----END PGP SIGNATURE----- --Apple-Mail=_086C2124-3961-4AF3-932A-081514904FF6-- From nobody Thu Jun 9 04:03:04 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D293612B069 for ; Thu, 9 Jun 2016 04:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 MWvdU4uJKI4B for ; Thu, 9 Jun 2016 04:02:58 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 3177512B02D for ; Thu, 9 Jun 2016 04:02:58 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id l44so16883509qgd.0 for ; Thu, 09 Jun 2016 04:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LI9iH2ewDsJlQj+egIR3Quqmf1f2Z7B2vjnig9qhXHw=; b=bWbKgcJJpIaGeN2ttmAcxO3G5f/byZ/Ed3XxQEYpR1dnl+eXDmQDvrUAmva+aQ6Wq3 ou+66xM+t+vx+MUPDaPiIBC52gQpo3XZ+bninUwjAik/IC8HbMyIdRYhq3TgaNeJR5tR W1lNRoLX0LRFFyO40Eo1wumRFSyG5GcXdxg5s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LI9iH2ewDsJlQj+egIR3Quqmf1f2Z7B2vjnig9qhXHw=; b=bSLSC1X+9MbeHPNwYa2ws597mnOdkCxRZTfp0q3uGPf6XrKFgs/VOBQY8fl0NvHRd+ N+mSdPN1YF6kO3Qd4+HFcsLKrecEpCeqEzi7QjBAFxX0FFFAKwrruE7OvmpvdyIcsyNO WTQVDBsb5ocxEhhKFyyotEY2fCTVJrpnPm9T6bo4HDBYFTWkzGjYWkymnQbv7G9Ko45F cYj87scBn7KgEkL6KazvxXMV99QD0dzuQlZYhr17J7TkwYXwoEItV8EJDYuMvk2teb63 RmYfjxNQyO8q001oZ5XaRr+VRWrxvOXExcEMrY8u+yQx/jasrAmvr4t7uWbWd64wj2Gc nJ+w== X-Gm-Message-State: ALyK8tI6gjq5X9o8WUVnS0uHpQA3vtqZrOBtDeYY/eMlaWoc9MUSLtnnBCbBA33HS8Gt7pi2 X-Received: by 10.140.27.203 with SMTP id 69mr9127653qgx.96.1465470177000; Thu, 09 Jun 2016 04:02:57 -0700 (PDT) Received: from [100.127.83.115] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id h66sm1518760qgh.15.2016.06.09.04.02.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 04:02:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> Date: Thu, 9 Jun 2016 07:02:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , spud Subject: Re: [QUIC] Segment offload for UDP-based protocols Re: Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 11:03:01 -0000 > On Jun 9, 2016, at 6:41 AM, Brian Trammell wrote: >=20 > hi Randall, >=20 >> On 09 Jun 2016, at 12:30, Randall Stewart wrote: >>=20 >>=20 >>> On Jun 9, 2016, at 5:06 AM, Michael Tuexen = wrote: >>>=20 >>>=20 >>>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) = wrote: >>>>=20 >>>> My concern is that the current charter suggestion markets the = protocol by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency = for applications=E2=80=9D. IMHO this can have rebound effects. >>>>=20 >>>> Here is what I mean by wrong expectations: Whether a protocol is = indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to = the best of my knowledge). Some of these effects of >>> I think this refers to high throughput. For TCP, offloading TCP = processing to a NIC improves performance >>> of the TCP processing. I'm not sure if this still helps if = encryption/decryption comes into the game. >>=20 >> I too was thinking Michael meant offloading such as TSO and LRO. I = know on most of the caches >> I develop on if I turn off TSO and LRO performance of the box drops = by roughly 50%=E2=80=A6 and I think >> this will be a consequence of encrypting everything since I don=E2=80=99= t think you can do TSO/LRO unless >> the hardware/lower-layers has access to things equivalent to TCP = sequence numbers and ACK values, >> which is what I believe the encryption is meant to hide (from middle = boxes). >>=20 >> That will be an extreme price to pay the question is, is it worth it = /and or/ is there some other way >> to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-) >=20 > (adding spud@ietf.org, as this is a relevant question for PLUS, too): >=20 > The question is what is the minimum information xSO/LRO needs to work. = If I understand how generic segment offload works, if QUIC(/PLUS) = exposes: >=20 > (1) a header field that can be used to order packets and find gaps = that the kernel can find and interpret, My understanding of TSO (which is where we find the most benefit since = its hardware) is the hardware gets a *large* segment (say 64k) and cuts it up into MTU sized pieces duplicating the IP header and doing the = right things with the tcp-sequence number. If the sequence number is encrypted and not exposed that would be rather = difficult with Quic (or any such protocol for that matter even TCP if it was wrapped in UDP and encrypted). The other benefit is of course comes from LRO and thats really not done = in hardware but in software (at least in the implementation on which I work that is) .. where Acks Segments are = combined into bigger chunks.=20 For my work the Acks are what I care about having to process less Acks = is a win (but not nearly as much as TSO).=20 Both Seq and Ack can be compiled by LRO into a =E2=80=9Clarger = segment=E2=80=9D so you need again the exposure of the Ack value as well as the sequence number.. R >=20 > (2) a defined and easily-found boundary between header and payload, = such that the payload retains any framing/message boundaries needed to = meet API contracts, and >=20 > (3) rules about which header to choose for the "big" segment on = receive >=20 > then adding QUIC(/PLUS) aware SO/LRO to the kernel should be = reasonably simple. I don't see why you need ACK-equivalents to be = exposed to make this work, but I might be missing something. >=20 > Hardware offload takes longer to deploy, obviously, but runs on = equivalent information. >=20 > Cheers, >=20 > Brian >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Thu Jun 9 09:56:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C348E12D8A0 for ; Thu, 9 Jun 2016 09:56:14 -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 xsp_BXDkSWJE for ; Thu, 9 Jun 2016 09:56:13 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3729C12D098 for ; Thu, 9 Jun 2016 09:56:13 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id k23so73085100oih.0 for ; Thu, 09 Jun 2016 09:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=tA9RiYdkkNOnEZ/acBgiiy/LSO6+/0TQodoe4obCZZI=; b=MXkGQnyQXCWK8qXL1Q/OjiDZddE9f0XhSYdUdRYXKUho+jDuK/KH6bVZTHHKRX3dV2 m0qv900ggequ8ZT8HwVjF8fFICDVrq7DSrzHe6CL6BXMZqTG/tMNoBADagCovPu8W9um ko38H+yXuiibfLFnMt2SIa9xUcpryN2iTIsntYBx4fXBATk3/g7kUUmv7FvzsXBR9dls ZMXEf8K1CvF5r0v/EY2g/HMaDU/9Hxe99p27OWoJBt1s/RlArIm9VaUvRSdqD/ED2Cjs yyuQtB4SH1slE5ovRKQ2qd+pqYKERHrc67cAnfk0MLg1NlereQawCj4P3n+/EKte/N6Z FvBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tA9RiYdkkNOnEZ/acBgiiy/LSO6+/0TQodoe4obCZZI=; b=StRJoOha2lfet5zhh5GZPpe1bQDFWWUwMg5Dlp2Y27RvT0JmaCC30Ihbf6MkUABD56 j34sVKgYBcoEXyaW+m46lYlZfPMizpe4nAtBjh2pDCEiflGrY3TAJLLHkZ5iLxfpn0Jy XUtzf0HgQ0d2UOHqt6MvGNF/UvKBqyGfYSWEF3aFQZfHnPXyTIWWeSXZ3dr8Qo+wHXt/ vvg2/OxNHIEKoKU2msfeKQkPhPJXm07JpiPy2dxoobwdPjSJicXrlcT9cykzIMi4KMuS cL4MHXbTWvLQoniWf3bdwhCXGJPpqlRCI65d67MaCCpW3a44l1HP8NYCrx2skxs6r6X/ 4wGw== X-Gm-Message-State: ALyK8tKQ0gU+Q4rX3TSlM3ywjmbeuhSv6dMTbGy42+5gdo8g2mFmE8SvWo2i6aIafqz4lLMP9t93zKV398fZBg== X-Received: by 10.202.171.143 with SMTP id u137mr5533381oie.71.1465491372579; Thu, 09 Jun 2016 09:56:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Thu, 9 Jun 2016 09:55:53 -0700 (PDT) From: Ted Hardie Date: Thu, 9 Jun 2016 09:55:53 -0700 Message-ID: To: Spencer Dawkins , Mirja Kuehlewind , quic@ietf.org Content-Type: multipart/alternative; boundary=001a113c2efeaf21e10534db4c74 Archived-At: Subject: [QUIC] Charter dates now in GitHub X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:56:15 -0000 --001a113c2efeaf21e10534db4c74 Content-Type: text/plain; charset=UTF-8 I merged Jana's version of the charter dates and added the text about expecting to make extensive use of interim meetings to the charter here: https://github.com/IETF-QUIC/Charter/blob/master/quic-charter.md Obviously, this is subject to further discussion by the IESG, list, and BoF, but I wanted the strawman discussed so far to be in the doc before tomorrow's BoF call. regards, Ted --001a113c2efeaf21e10534db4c74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I merged Jana's version of the charter = dates and added the text about expecting to make extensive use of interim m= eetings to the charter here:

https://github.com/IETF-QUIC/Charter/= blob/master/quic-charter.md

Obviously, this is subject to = further discussion by the IESG, list, and BoF, but I wanted the strawman di= scussed so far to be in the doc before tomorrow's BoF call.

regards,

Ted
--001a113c2efeaf21e10534db4c74-- From nobody Thu Jun 9 12:17:51 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEFE12D927 for ; Thu, 9 Jun 2016 12:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 VJbD0-zjD-JL for ; Thu, 9 Jun 2016 12:17:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EEE12D907 for ; Thu, 9 Jun 2016 12:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OzvUGNpZ6KUHC2Zsz3wsfHgsprECSKbroYrRPMaVr3w=; b=Re+fywisvd70XpD6XlFfPs5tAs2lfQPsxVdMnPQpon5LusaKnth8DDG8FF/hw223ks7X4E+1uSvENL45qcO+VA25OFwl0RhWChFXFw4uM7PwCOaE4PzlY23ROwo7gRy7JOEVTcGk2NjoRy6P33JF7dqnHTFudjl9JKH99FtIsmk= Received: from CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) by CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 9 Jun 2016 19:17:43 +0000 Received: from CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) by CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) with mapi id 15.01.0497.025; Thu, 9 Jun 2016 19:17:43 +0000 From: Christian Huitema To: Randall Stewart , =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= Thread-Topic: [QUIC] Requirements Thread-Index: AQHRteuqX+4yljhIoEqYteMiLhFYkZ/NpegAgABg/wCAAIWYgIABhREAgAFU8ACAABlOAIAAAQmAgAEVmICAAJ15AIAMCUaAgAAefICAAOIyAIAAoTEAgAARbICAABeYAIAAkAUA Date: Thu, 9 Jun 2016 19:17:43 +0000 Message-ID: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:7::14d] x-ms-office365-filtering-correlation-id: 773b12fa-dbd1-47cf-79e1-08d3909abbaf x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0649; 5:oFcIMPHNJbyopu7JeQ15csZZs1RLmzai/PGLtJHzXKPrOHof8HqOKuKkDAvfTHKB5jct4FCRqfadzWJk3LeDjwiXjlKe98YwHcsgyc80jQXB26YoUmpVDHXTLyPXcwRyaXX/Z64CTaCR738hn6LWpw==; 24:IoigbmTlD7kpAqIh521WvXRDjsAnyyjY4ZHEB/DV5XNR8YuzFhPrzakqv5kfvBEatgIIjkgtbsGtvB6WshxAj8JcP7o4sE+NStihJlcHEss=; 7:1yFgoyDMP8iD36osGQt6IKHQ55RrzssQahOEky5ISIgcZ+DaST9IgImWOFa5Gtr7v9k3Za8WujXQDomsPs8UwYpsh78xyooKDBnqDnftBbewSmIRL2+ZxA6CPMwIGgx2ZwOT9lmC/mStz+4KyIvVQ2Qn9ZQA/PVlnq9X+PpioNYo3LKLJJN3YQVpvirZmD4Fjas9sIISAyK1GS1EDriYXBCn7WB9+HkiG/vPntq9oXw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0649; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0649; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0649; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(377454003)(199003)(102836003)(6116002)(122556002)(5001770100001)(189998001)(86612001)(8676002)(97736004)(5004730100002)(2906002)(586003)(8990500004)(99286002)(10400500002)(11100500001)(8936002)(3660700001)(81166006)(5002640100001)(68736007)(9686002)(5008740100001)(93886004)(4326007)(5003600100002)(3280700002)(76576001)(2900100001)(50986999)(19580395003)(5005710100001)(10290500002)(54356999)(81156014)(92566002)(74316001)(76176999)(19580405001)(10090500001)(106356001)(105586002)(33656002)(2950100001)(106116001)(86362001)(101416001)(77096005)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0649; H:CY1PR0301MB0649.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 19:17:43.5230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0649 Archived-At: Cc: Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 19:17:50 -0000 T24gVGh1cnNkYXksIEp1bmUgOSwgMjAxNiAzOjMxIEFNLCBSYW5kYWxsIFN0ZXdhcnQgd3JvdGU6 DQo+IA0KPiA+IE9uIEp1biA5LCAyMDE2LCBhdCA1OjA2IEFNLCBNaWNoYWVsIFR1ZXhlbg0KPiA8 TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGU+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4g T24gMDkgSnVuIDIwMTYsIGF0IDEwOjAzLCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpDQo+ IDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+IHdyb3RlOg0KPiA+Pi4uLg0KPiA+Pg0KPiA+PiBI ZXJlIGlzIHdoYXQgSSBtZWFuIGJ5IHdyb25nIGV4cGVjdGF0aW9uczogV2hldGhlciBhIHByb3Rv Y29sIGlzDQo+ID4+IGluZGVlZCBmYXN0IG9yIG5vdCBkZXBlbmRzIG9uIG1hbnkgcGFyYW1ldGVy cyBpbmNsdWRpbmcgYXNwZWN0cyBzdWNoDQo+ID4+IGFzIGhhcmR3YXJlIGFjY2VsZXJhdGlvbi9v ZmZsb2FkICh3aGljaCBtYXR0ZXJzIGF0IDEwRy80MEcgbGluZQ0KPiA+PiBzcGVlZCwgdG8gdGhl IGJlc3Qgb2YgbXkga25vd2xlZGdlKS4gU29tZSBvZiB0aGVzZSBlZmZlY3RzIG9mDQo+ID4gSSB0 aGluayB0aGlzIHJlZmVycyB0byBoaWdoIHRocm91Z2hwdXQuIEZvciBUQ1AsIG9mZmxvYWRpbmcg VENQDQo+ID4gcHJvY2Vzc2luZyB0byBhIE5JQyBpbXByb3ZlcyBwZXJmb3JtYW5jZSBvZiB0aGUg VENQIHByb2Nlc3NpbmcuIEknbSBub3Qgc3VyZQ0KPiBpZiB0aGlzIHN0aWxsIGhlbHBzIGlmIGVu Y3J5cHRpb24vZGVjcnlwdGlvbiBjb21lcyBpbnRvIHRoZSBnYW1lLg0KPiANCj4gSSB0b28gd2Fz IHRoaW5raW5nIE1pY2hhZWwgbWVhbnQgb2ZmbG9hZGluZyBzdWNoIGFzIFRTTyBhbmQgTFJPLiBJ IGtub3cgb24NCj4gbW9zdCBvZiB0aGUgY2FjaGVzIEkgZGV2ZWxvcCBvbiBpZiBJIHR1cm4gb2Zm IFRTTyBhbmQgTFJPIHBlcmZvcm1hbmNlIG9mIHRoZQ0KPiBib3ggZHJvcHMgYnkgcm91Z2hseSA1 MCXigKYgYW5kIEkgdGhpbmsgdGhpcyB3aWxsIGJlIGEgY29uc2VxdWVuY2Ugb2YgZW5jcnlwdGlu Zw0KPiBldmVyeXRoaW5nIHNpbmNlIEkgZG9u4oCZdCB0aGluayB5b3UgY2FuIGRvIFRTTy9MUk8g dW5sZXNzIHRoZSBoYXJkd2FyZS9sb3dlci0NCj4gbGF5ZXJzIGhhcyBhY2Nlc3MgdG8gdGhpbmdz IGVxdWl2YWxlbnQgdG8gVENQIHNlcXVlbmNlIG51bWJlcnMgYW5kIEFDSw0KPiB2YWx1ZXMsIHdo aWNoIGlzIHdoYXQgSSBiZWxpZXZlIHRoZSBlbmNyeXB0aW9uIGlzIG1lYW50IHRvIGhpZGUgKGZy b20gbWlkZGxlDQo+IGJveGVzKS4NCg0KU3VyZS4gQnV0IHRoZW4sIHdoaWNoIHBhcnQgb2YgUkZD IDc5MyBkZXNjcmliZXMgaGFyZHdhcmUgb2ZmbG9hZD8gTm9uZSwgb2YgY291cnNlLiBJdCB3YXMg ZGV2ZWxvcGVkIG92ZXIgdGltZSwgd2l0aG91dCBpbnZvbHZpbmcgdGhlIElFVEYuIEJhc2ljYWxs eSwgc29tZSBpbm5vdmF0b3JzIG9ic2VydmVkIHRoZSBpbnN0YWxsZWQgYmFzZWQsIGxvb2tlZCBh dCBhbGwgdGhlc2UgVENQIGNvbm5lY3Rpb25zLCBhbmQgc2F3IGFuIG9wcG9ydHVuaXR5IGZvciBh IG5ldyBwcm9kdWN0LiBDbGVhcmx5LCBpZiB5b3UgY29tcGFyZSBUQ1AgdG8gYW55IG5ldyBwcm90 b2NvbCwgeW91IHdpbGwgZmluZCBsb3RzIG9mIGlubm92YXRpb25zIGZvciBUQ1AsIGluY2x1ZGlu ZyBoYXJkd2FyZSBvZmZsb2FkLCBhbmQgemlsY2ggZm9yIHRoZSBuZXcgcHJvdG9jb2wuDQoNCk9u IHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgbmV3IHByb3RvY29sIGlzIGFjdHVhbGx5IGRlcGxveWVk IGluIGxhcmdlIG51bWJlcnMsIHdlIGNhbiBzdXJlbHkgZXhwZWN0IHNvbWUgaW5ub3ZhdG9ycyB0 byBzZWUgYSBidXNpbmVzcyBvcHBvcnR1bml0eSBhbmQgZGV2ZWxvcCBzb2x1dGlvbnMuIFllcywg aXQgd2lsbCB0YWtlIHNvbWUgdGltZS4gQnV0IGl0IHdpbGwgaGFwcGVuIGV2ZW50dWFsbHkuDQoN Ci0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCiANCg== From nobody Fri Jun 10 09:35:00 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAB412D845; Fri, 10 Jun 2016 09:34:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610163409.30430.29231.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 09:34:09 -0700 Archived-At: X-Mailman-Approved-At: Fri, 10 Jun 2016 09:34:59 -0700 Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, quic@ietf.org, quic-chairs@ietf.org Subject: [QUIC] quic - New Meeting Session Request for IETF 96 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:34:09 -0000 A new meeting session request has just been submitted by Cindy Morgan, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: TSVAREA, SAAG, TLS, RTCWEB, DISPATCH, MAPRG, TSVWG, ICCRG, TCPM, TCPINC, MPTCP, TAPS, LURK, UTA, QUIC, L4S Special Requests: If possible, please schedule after QUIC BOF --------------------------------------------------------- From nobody Fri Jun 10 09:41:37 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ED712D127; Fri, 10 Jun 2016 09:41:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610164136.30501.25516.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 09:41:36 -0700 Archived-At: Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, quic@ietf.org, quic-chairs@ietf.org Subject: [QUIC] quic - Update to a Meeting Session Request for IETF 96 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:41:36 -0000 An update to a meeting session request has just been submitted by Cindy Morgan, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: tsvarea saag tls rtcweb dispatch maprg tsvwg iccrg tcpm tcpinc mptcp taps lurk uta quic l4s Special Requests: --------------------------------------------------------- From nobody Sat Jun 11 16:24:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@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 , Tom Herbert , "draft-ietf-tsvwg-rfc5405bis@ietf.org" , "tsvwg-chairs@ietf.org" , spud , Jim Roskind , "quic@ietf.org" Subject: Re: [QUIC] [tsvwg] Last Call: (UDP Usage Guidelines) to Best Current Practice X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization 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 Sun Jun 12 01:04:42 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8604C12D0FC; Sun, 12 Jun 2016 01:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9sBcz1q8zekQ; Sun, 12 Jun 2016 01:04:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8A112D094; Sun, 12 Jun 2016 01:04:36 -0700 (PDT) Received: from [192.168.178.20] ([93.217.103.112]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M20Jj-1bRtGr03BL-00u3cN; Sun, 12 Jun 2016 10:04:18 +0200 To: IETF Meeting Session Request Tool , session-request@ietf.org References: <20160610164136.30501.25516.idtracker@ietfa.amsl.com> From: Julian Reschke Message-ID: <10e13c19-7224-76fa-b6e7-62767c9e046f@gmx.de> Date: Sun, 12 Jun 2016 10:04:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160610164136.30501.25516.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YjjCyxs/IBQLciAvl2piga0WqH5qSpucS778iLXdIARU6UCAeOI wiuC4oW/HVVU2g6RXZrl8TkERpJyvEqN7cCqk46EZiTpHzgq1m6E5DYw+l9ExHot9GIysqp gIKpiL0RPs0ENkcdNXLRjf/K+H2piEzQMFBofBqO1o7QrUUwLhFAqgpNXl1GSz56/tPGkN8 qVzBYoI4iVYzyu/b6XQKg== X-UI-Out-Filterresults: notjunk:1;V01:K0:LhGl+GkstT8=:n6JumbG1SkWssLtKM38BLK ECwxIjFxIzr9XflRXutnTdjSn7MMhq3SUC7/4WMwaQ3y2Zt+tjumrN5x00/v74IfJ4uLppuih JCGjGcRcLAHMR4VZGLZ+Bq51p50sLY4spPDHp2lFsNAoNONilXbEE/8vdoepX6JQsNDv0igM7 DqOFGN26J9jkQZxRhB5urEBxZ1sxZYJdtuU7N9Ian6CpH2Y82yvUedDlqQ3MqPtUter5MxSCO 0WioW9JXFJ+4jXoyGmHXUslRTVbvfsNsiiQAkC3Vbg8grLMbpRr652aP7ru5BlNHAEMVTiKOt J+gnml+ipo+PDWNRWB+HsczVK7F2aCJMCyj+eRprEMmC0VlC6mdavVwv5eb++09A6+LohqomK WECjxsokfBeHPIhnwJnTwnEaJMMMdg3nDwa4cTLC253ywvwpxon6TQPnABRSqhsKz4Hk4QLOp nzgZj16pO9bDqbYUrDXop0od1nZXorgQ0onvvEv+RN3yHBkkr9PZEa0VmlHXQgN2tR98m1KKo OYC16KcqUaBk1JbqprlmLbCGfvbMWm+y2gr88D/E3A8NfPf7JkBdY3Mm9QfLC5EqnyI7qHsJv Rup66Ecofoh7XeuoRDjC6iCIHBktjolCTKCezmPkZil0GXs4IsmQwwB4SYKAGDL2WRRtj7H1i uapXvmFNwyeaPzCPCb4QRY3KgKco1D83T5evI8hyG0/WGyTlbS3Wil/YeJEb/kCd2iHHcNzhk IaYe0OxdgRHJ6gpXOHiW7TbtkLxJoI+aRHPO2HwSfFhb1Grw/lznaz4kkXFvgsfleFzPhp4So UEgG7SO Archived-At: Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, quic@ietf.org, quic-chairs@ietf.org Subject: Re: [QUIC] quic - Update to a Meeting Session Request for IETF 96 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 08:04:40 -0000 On 2016-06-10 18:41, "IETF Meeting Session Request Tool" wrote: > > > An update to a meeting session request has just been submitted by Cindy Morgan, on behalf of the quic working group. > > > --------------------------------------------------------- > Working Group Name: QUIC > Area Name: Transport Area > Session Requester: Cindy Morgan > > Number of Sessions: 1 > Length of Session(s): 2.5 Hours > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: tsvarea saag tls rtcweb dispatch maprg tsvwg iccrg tcpm tcpinc mptcp taps lurk uta quic l4s > ... Ahem? What about "httpbis"? Best regards, Julian From nobody Sun Jun 12 05:59:25 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE5112D0CA for ; Sun, 12 Jun 2016 05:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_edD3oOXUHf for ; Sun, 12 Jun 2016 05:59:21 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F03E12D147 for ; Sun, 12 Jun 2016 05:59:21 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 9so29028232qtg.2 for ; Sun, 12 Jun 2016 05:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n/UmjlgZ9D3UgSGbLImSwe9MlBkG7bXU4p9AVdy/Q9E=; b=SyDgrJmpLqUcl9D1dvqxbN5nclImopLthFpR7Ven/MYesb4f4jmQDaczSXPmyU3k3v oxYI8VfFv+5OredZb4dXuEgrdp3kShHLr04zQhBYt89tyS60PVdZj2BgQBrPhTqvoygl uNsC26SoH8sbo45PX+xFqdLTouDhBkbVUGJl5lg0gw5l4HjcsoluhpV1/+5MXGkTWKgX xMwU/Y7cT0qI2NO91grBMz3SmNX4eFxaYs74mPisDIXC1lg38fj80kl0MSkxV3QakAj0 3NmggvEgbZKn4eoA0d7w/fKf3oH56ZzBDYQ5O6f/+PpBlm6+PCTTx/0V4qqU4RkBejW4 BCxw== 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=n/UmjlgZ9D3UgSGbLImSwe9MlBkG7bXU4p9AVdy/Q9E=; b=ePKUvGys8oFo5NlbcH5H58KaFZ3uHPT2JAy6PtDsBaMH5NWH+38t4DQ6jpoS/If70X wNzBVZouBxyV827shqOu8L7P5qLP9CpZ/gRnilGUQsoptWZtBmlw80iP3UAtw4joJPCh YeO7D28o5ONFaPrLmfuW1Da/ifoniFoPA2s+9BV+GGd269jYpGz9dzlLNz+T2x4KJ+bW ImA4hDqllpz3zgsBEXXTzfXr/vSAuyUUH+0hCvHq3ca7aSHqriaUAms75X/0QWP2A0/U QTXA9NGoW78tzEsnR/sXljpyVi37B/ec96DcFsTQgT6DUIEj0ce2adZCNIjsRPwECW0E hXCg== X-Gm-Message-State: ALyK8tK/W3E4ZQkyCvFyZ2PpOMep0lMRCZoF88k69sibjMpdDRgB1eercj9TIaLv+gllKMVmn5dGt+y+mfV58g== X-Received: by 10.237.56.97 with SMTP id j88mr10209878qte.94.1465736360572; Sun, 12 Jun 2016 05:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.37 with HTTP; Sun, 12 Jun 2016 05:59:20 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sun, 12 Jun 2016 22:59:20 +1000 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org, Mirja Kuehlewind , Spencer Dawkins Subject: Re: [QUIC] Charter dates now in GitHub X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 12:59:23 -0000 > After the completion of the core protocol deliverable, the group will consider a recharter [...] It doesn't need to include any of this stuff. Part of the point of leaving something to a recharter is that you don't have to write down what it is. That's the joy of it, we could decide to recharter to compose new Morris dancing tunes. On 10 June 2016 at 02:55, Ted Hardie wrote: > I merged Jana's version of the charter dates and added the text about > expecting to make extensive use of interim meetings to the charter here: > > https://github.com/IETF-QUIC/Charter/blob/master/quic-charter.md > > Obviously, this is subject to further discussion by the IESG, list, and BoF, > but I wanted the strawman discussed so far to be in the doc before > tomorrow's BoF call. > > regards, > > Ted > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > From nobody Mon Jun 13 08:55:44 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED0E12D847 for ; Mon, 13 Jun 2016 08:55:42 -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 csbETo3HYxbc for ; Mon, 13 Jun 2016 08:55:40 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6656E12D846 for ; Mon, 13 Jun 2016 08:55:40 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id w5so134954606oib.2 for ; Mon, 13 Jun 2016 08:55: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:from:date:message-id:subject:to :cc; bh=Bv23OCVf2t77xKm6Ggpa7k33eBjRlypobzhLTYJr/as=; b=dUayp2J3k+K3f0NSFNbyWfkrRoOX4ogAc7YiZkcIh6ahpUiB0i6w5fZnr+8Hn+bBlc fpujfiDbanXVFpjzGay+47Xm97HGaDl7qT9kJ+8IZ5dwk7rOghjw+UzN926lT3AlZ1pz L01sGJr1xpcNQfBG3GW1VedwJuKSWeAzP+548pOsQDvRcpKU/vwHDGLH/C5ii07AVgMQ Cki2InU+86bsjXqE6bn1+AZli/YYJ3BdMUgJYJlp85Uvdp9+qPxaY69eCtP/3LnTqPTX PaZ42OB19LcyvWhQ6ap8X08YeOMMyeMlCNjUORBWmasnB5HuAiBNKp+px5XWgbYRHynj ILAA== 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=Bv23OCVf2t77xKm6Ggpa7k33eBjRlypobzhLTYJr/as=; b=mVl7pJLtCZBUM9oDRcDEHEEEqdkZosEcp4x6yWZEJpY6D5v7pxx3VmvqElkiTOiMZr s+L7/ksSxf7RqjP7MX6rZbHLql4lz50mFOiCqWMrRcCmXsDXpHEc+1MEhpZX8hJiXlsI EVUSwOfj2tpRBSIGX9HQ4neABBNIEVSvBkz7WzPHpYbVdHr/0lOm6BxTD5pzu2oW8+jI z5pAq6jjjrnkpXGkHlI1UwGjErvrQarjMlUTaJRKU5kvipBakwpCQnsCNylga7PqGpxw 0HcdvQDxSHBYBDJFVn9joX8l3/fvWvPSODvuxUXJEVk8VniNkKBoaeV2HM20vMcA1Sap g2dA== X-Gm-Message-State: ALyK8tKoN6sGTX3x9elEwV8BbNFDLrPqKuIihKFvJ3n/iyGYOXUcxBNPHhMa4/W92FFyuujTPR4UPdstJgmCyQ== X-Received: by 10.157.48.89 with SMTP id w25mr7610522otd.32.1465833339747; Mon, 13 Jun 2016 08:55:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Mon, 13 Jun 2016 08:55:20 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Mon, 13 Jun 2016 08:55:20 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11414ce08405a005352aeb92 Archived-At: Cc: quic@ietf.org, Mirja Kuehlewind , Spencer Dawkins Subject: Re: [QUIC] Charter dates now in GitHub X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:55:42 -0000 --001a11414ce08405a005352aeb92 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 12, 2016 at 5:59 AM, Martin Thomson wrote: > > After the completion of the core protocol deliverable, the group will > consider a recharter [...] > > It doesn't need to include any of this stuff. Part of the point of > leaving something to a recharter is that you don't have to write down > what it is. I agree that you don't have to. The utility in doing so, at least in my opinion, is that it helps you avoid premature optimizations that might make the later work harder. If, for example, you presumed that QUIC would only support fully reliable communications, you might make choices that would preclude later work that had partial reliability as a goal. Given that I think partial reliability and FEC are real goals here, I'd hate to lose that. Having them in the charter as goals, but with milestones to be set "After the completion of the core protocol" would do the same thing, but other folks hate goals without milestones, so you basically pick your poison. That's the joy of it, we could decide to recharter to > compose new Morris dancing tunes. > > http://www.mit.edu/~jcb/AntiMorris/pratchett.shtml Since it won't be danced properly anyway, let's give that a miss, eh? Ted > On 10 June 2016 at 02:55, Ted Hardie wrote: > > I merged Jana's version of the charter dates and added the text about > > expecting to make extensive use of interim meetings to the charter here: > > > > https://github.com/IETF-QUIC/Charter/blob/master/quic-charter.md > > > > Obviously, this is subject to further discussion by the IESG, list, and > BoF, > > but I wanted the strawman discussed so far to be in the doc before > > tomorrow's BoF call. > > > > regards, > > > > Ted > > > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic > > > --001a11414ce08405a005352aeb92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 12, 2016 at 5:59 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
> After the completion of the core protocol deliverable, the group w= ill consider a recharter [...]

It doesn't need to include any of this stuff.=C2=A0 Part of the point o= f
leaving something to a recharter is that you don't have to write down what it is.=C2=A0

I agree that you don'= t have to.=C2=A0 The utility in doing so, at least in my opinion, is that i= t helps you avoid premature optimizations that might make the later work ha= rder.=C2=A0 If, for example, you presumed that QUIC would only support full= y reliable communications, you might make choices that would preclude later= work that had partial reliability as a goal.=C2=A0 Given that I think part= ial reliability and FEC are real goals here, I'd hate to lose that. Hav= ing them in the charter as goals, but with milestones to be set "After= the completion of the core protocol" would do the same thing, but oth= er folks hate goals without milestones, so you basically pick your poison.<= br>

= That's the joy of it, we could decide to recharter to
compose new Morris dancing tunes.

Since it won't be danced= properly anyway, let's give that a miss, eh?

Ted
=
=C2=A0
On 10 June 2016 at 02:55, Ted Hardie <ted.ietf@gmail.com> wrote:
> I merged Jana's version of the charter dates and added the text ab= out
> expecting to make extensive use of interim meetings to the charter her= e:
>
> https://github.com/IETF-QUIC/Ch= arter/blob/master/quic-charter.md
>
> Obviously, this is subject to further discussion by the IESG, list, an= d BoF,
> but I wanted the strawman discussed so far to be in the doc before
> tomorrow's BoF call.
>
> regards,
>
> Ted
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--001a11414ce08405a005352aeb92-- From nobody Mon Jun 13 10:14:17 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAD712D630; Mon, 13 Jun 2016 10:14:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613171415.6924.86713.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 10:14:15 -0700 Archived-At: Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, quic@ietf.org, quic-chairs@ietf.org Subject: [QUIC] quic - Update to a Meeting Session Request for IETF 96 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:14:16 -0000 An update to a meeting session request has just been submitted by Cindy Morgan, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: TSVAREA, SAAG, TLS, HTTPBIS, WEBPUSH, RTCWEB, ACME, DISPATCH, MAPRG, TSVWG, ICCRG, TCPM, TCPINC, MPTCP, TAPS, T2TRG, IANAPLAN, LURK, LPWAN, PLUS Special Requests: --------------------------------------------------------- From nobody Mon Jun 13 10:21:25 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590AC12D618; Mon, 13 Jun 2016 10:17:38 -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 GaMGEOwu6Tj5; Mon, 13 Jun 2016 10:17:37 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [IPv6:2001:1900:3001:11::28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7384912D5EB; Mon, 13 Jun 2016 10:17:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7665B1E5D6D; Mon, 13 Jun 2016 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80iBZLIEaHwo; Mon, 13 Jun 2016 10:17:06 -0700 (PDT) Received: from [64.170.98.167] (unknown [64.170.98.167]) by c8a.amsl.com (Postfix) with ESMTPSA id 4F1DD1E5D61; Mon, 13 Jun 2016 10:17:06 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cindy Morgan In-Reply-To: <10e13c19-7224-76fa-b6e7-62767c9e046f@gmx.de> Date: Mon, 13 Jun 2016 10:17:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5BCE5E4A-C9F4-48CC-8658-46C0B0BCF32B@amsl.com> References: <20160610164136.30501.25516.idtracker@ietfa.amsl.com> <10e13c19-7224-76fa-b6e7-62767c9e046f@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Mon, 13 Jun 2016 10:21:24 -0700 Cc: session-request@ietf.org, quic-chairs@ietf.org, quic@ietf.org, Spencer Dawkins , IETF Meeting Session Request Tool Subject: Re: [QUIC] quic - Update to a Meeting Session Request for IETF 96 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:17:38 -0000 Hi Julian, Sorry about that--a new version of the datatracker was released while I = was in the middle of entering this request, and the original request was = eaten. When I realized it was missing and went back to re-do the request = for QUIC, I managed to confuse myself and entered the wrong conflicts = list. This has been fixed now. Best regards, Cindy > On Jun 12, 2016, at 1:04 AM, Julian Reschke = wrote: >=20 > On 2016-06-10 18:41, "IETF Meeting Session Request Tool" wrote: >>=20 >>=20 >> An update to a meeting session request has just been submitted by = Cindy Morgan, on behalf of the quic working group. >>=20 >>=20 >> --------------------------------------------------------- >> Working Group Name: QUIC >> Area Name: Transport Area >> Session Requester: Cindy Morgan >>=20 >> Number of Sessions: 1 >> Length of Session(s): 2.5 Hours >> Number of Attendees: 150 >> Conflicts to Avoid: >> First Priority: tsvarea saag tls rtcweb dispatch maprg tsvwg iccrg = tcpm tcpinc mptcp taps lurk uta quic l4s >> ... >=20 > Ahem? What about "httpbis"? >=20 > Best regards, Julian >=20 From nobody Mon Jun 13 10:34:56 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9B912D86E; Mon, 13 Jun 2016 10:34:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613173454.6860.18511.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 10:34:54 -0700 Archived-At: Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, quic@ietf.org, quic-chairs@ietf.org Subject: [QUIC] quic - Update to a Meeting Session Request for IETF 96 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:34:55 -0000 An update to a meeting session request has just been submitted by Cindy Morgan, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: plus lpwan lurk ianaplan t2trg taps mptcp tcpinc tcpm iccrg tsvwg maprg dispatch acme rtcweb webpush httpbis tls saag tsvarea l4s rmcat Special Requests: --------------------------------------------------------- From nobody Tue Jun 14 00:56:01 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E839612D0A4 for ; Tue, 14 Jun 2016 00:55:59 -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 ERVGXdgZajRd for ; Tue, 14 Jun 2016 00:55:58 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 2FE2C12D08D for ; Tue, 14 Jun 2016 00:55:58 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id l44so79924227qgd.0 for ; Tue, 14 Jun 2016 00:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g52Oc2GeYWCVLI/up6i6Ok/iBh2RlzOARbK2OsVyx3I=; b=DlgbNTsfm1iN0n476T2KBusORgD/T5n2yWW/ylZwIvrMLyFSVvh4w9o0iHdvw0GJun oS+47YQwpcpa6IVVNCDN3IVHI855dS0abPnRnLSKGw0PCkujd1OU768vb2LiGGkyoQ82 SFH3GXaUc6BsXHnxBGeFBaCluk3hki+eu6sJbvyzy/vZZePKxUvDhLFhVbVdGpM5gH+0 wU4M7Vypo15wZcrimngX+lhZ1VXmcDcY+6Gu0cfwfPO3ljYaWSS/LbPkenO2XImUVwU6 yAptNtzcwmtmlFhxOjAiB+xIs85sEq9MEn1A4meRhwjZbPLJYALPG5jj0oO6jukFgzAE gqtQ== 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=g52Oc2GeYWCVLI/up6i6Ok/iBh2RlzOARbK2OsVyx3I=; b=Bd/4iupMT71EDvfNkHIcL+/Di5eSExxnN1HQ4PpCKopUNWeLakWz2EjJ3v1nmn2Y1m GWd8PdoAEFusidhTJoS+2E9LDdtFiPlmb7nqFnbo0Z7noK1q46U8/1RNlYqNbVI2LYIO c5e0xf9N3nwtqMXh+Jl9gDVpM+58sQgf8DrXjsZv/XOq+QdUyUWLCaMbMh+1A+sFYQbp 3q/q7+22UMMpFfQdJL5cs/wroZXkQ2HgIs/RLzlQrJd5CjYR0oqjeGFKb3EKhEe7yk6F lVJHGEeV72rECSGBHzlhNVLhbDSDImWGxZ+uRQKCBnkv4Rz8rTGZwcsYueDQH43HnGLZ 9aZg== X-Gm-Message-State: ALyK8tJkW7UpXiIJ4RPc1mZ3bYxCzQTlvlnNuzUTgTETTYl0I1bpAWCPY+79NlKDv/H4mACPfHny5xFdjN1WFQ== X-Received: by 10.140.32.198 with SMTP id h64mr17521547qgh.53.1465890957242; Tue, 14 Jun 2016 00:55:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.37 with HTTP; Tue, 14 Jun 2016 00:55:56 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 14 Jun 2016 08:55:56 +0100 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org, Mirja Kuehlewind , Spencer Dawkins Subject: Re: [QUIC] Charter dates now in GitHub X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 07:56:00 -0000 On 13 June 2016 at 16:55, Ted Hardie wrote: > The utility in doing so, at least in my opinion, is that it helps you avoid > premature optimizations that might make the later work harder. If, for > example, you presumed that QUIC would only support fully reliable > communications, you might make choices that would preclude later work that > had partial reliability as a goal. Given that I think partial reliability > and FEC are real goals here, I'd hate to lose that. If you have constraints on the design that are important, then I expect you to remember these goals and remind us when we do things that violate those constraints. Having things in the charter that aren't in the charter gives a license to argue about things in a very non-concrete fashion, which at best is not especially productive, and at worst can be used to be obstructionist. Given the high expectations people have for this protocol, we're going to have a hard enough time agreeing on things. I actually disagree with you regarding your fears about these features. I think that we could very easily deploy a version of QUIC that didn't have any allowance for partial reliability or FEC. And I think that we SHOULD do that. The reason being is that it gives us a good reason to have working version and feature negotiation much earlier in the process. This doesn't need to be a monolithic protocol design and development process. To me, lightweight version and feature negotiation are more important properties to conserve than some future feature. From nobody Tue Jun 14 10:34:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7517412D866 for ; Tue, 14 Jun 2016 10:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 DrWUOomEqyw3 for ; Tue, 14 Jun 2016 10:34:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1302912D7F6 for ; Tue, 14 Jun 2016 10:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gj0QOEjS4LFuR1B2zTyXgkryQeH6g6nXVyRebj8kW30=; b=Yv0IhfGpEAlZC3zn+5U77ff1hiLz2zgSsYGr0xemUF1ItAST5E/oNyNxIkSmjPEt/dGJ6X+4dG5AvoKKDhzWVedSoaZ9aFOLhEq0shoMbm8B36DbI/bROQorqpF8tyyvTD+SyYZwn6/tlkakX7FoiXIxbK/ctqNbBx8lQuHuIqw= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 17:34:42 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0517.011; Tue, 14 Jun 2016 17:34:43 +0000 From: Christian Huitema To: Martin Thomson , Ted Hardie Thread-Topic: [QUIC] Charter dates now in GitHub Thread-Index: AQHRwm/YWOiKLQHvfEaDZAlakJyvfZ/lz5gAgAHDgQCAAQxkAIAAnPlQ Date: Tue, 14 Jun 2016 17:34:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:2::14d] x-ms-office365-filtering-correlation-id: dfb8edd9-fda2-408c-ede1-08d3947a2bbe x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 6:49mysXyqJFpnTM2vGbSvymv3F0rquk4ciyY4y831Qug4B8T6vlkeUZkNCk2cLAqVLbfal5h3jlgsW8gnhHHqrxOSjtugfE1C0IL3Jwi8JVFikQp995a5Eu5ZvIT47jKapDH0NC2XiETqPIb0amYW+cgk7Fs7N1UpGR/8GWJqJGlnwHStwcxMF/n4sB5SxwJWK77MaVlofk1vXLWYBYACuVn9tOvA0m7Bzjaj4WH1pwRenfiv9YJBT+1+RZhAhVIPaAWY5tRTpCfJ4IOgbSaglX3fref1IK7GGnUl6ib+LT1QpYr/yD5ZL5k7g5SeuP20MQg4KO6LjMgmQu4cWmxgCQ==; 5:TanAvi6OGa5NmXPCMtXfr/Fuw0vPka2LjTx0D/i5ND8RimE5ZKCKwG4LP4jYCtBWKx5QtYmYeVqP5reyk6zT0QMLXEpRfH6VjbJDNjaI11v2LBx6yr78ms+07D30ZX6kbUkTZxYf4LIeIy8zOlZC8w==; 24:lRKwG7QnjivuV5sdL9wSq4hFRyybfevPgc/81+nC8hhVdBgoYUTlR7+zSYC9zScN+wWtp0MwBjT7GQ+V29h5eroch3pRonl8BpoxXMKlP48=; 7:XYjbFynKMnLmI995G4sbP9aNRQGsHv6On+krLqLhLNdlyLUDw0eiRoNCCwtaH15UAJ/Sd1NXqKN3s2c5X9OGndAeX9nllRdQjMjb32Ulz+5fUFy9RiZzZeR6XrLA3y6mBtundNSjA2JgolQA/SfPLwtetTD2VYnwlMcsOtDFkhUXMLhMBGyr7RDLB65EAUKEQGv49YbLonF3l+RsEZbW4BLtyqCLC8/VGB53U5qdQDqbp8hOiAWT8Z/z8CRqzFyD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(51444003)(122556002)(86362001)(4326007)(99286002)(106116001)(2906002)(106356001)(105586002)(586003)(102836003)(6116002)(10090500001)(10290500002)(5005710100001)(10400500002)(8936002)(8990500004)(9686002)(5004730100002)(77096005)(5002640100001)(76176999)(54356999)(74316001)(2950100001)(189998001)(2900100001)(87936001)(76576001)(33656002)(3280700002)(93886004)(101416001)(5008740100001)(92566002)(81166006)(81156014)(8676002)(86612001)(50986999)(97736004)(3660700001)(5003600100002)(68736007)(5001770100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 17:34:42.8574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: "quic@ietf.org" , Mirja Kuehlewind , Spencer Dawkins Subject: Re: [QUIC] Charter dates now in GitHub X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:34:45 -0000 On Tuesday, June 14, 2016 12:56 AM, Martin Thomson wrote: >=20 > ... > I actually disagree with you regarding your fears about these features. = I think > that we could very easily deploy a version of QUIC that didn't have any > allowance for partial reliability or FEC. And I think that we SHOULD do = that. > The reason being is that it gives us a good reason to have working versio= n and > feature negotiation much earlier in the process. This doesn't need to be= a > monolithic protocol design and development process. To me, lightweight > version and feature negotiation are more important properties to conserve > than some future feature. +1. I think that FEC is an interesting source of thought experiments in that re= gard. Just saying FEC is nice, but FEC comes in multiple shades. We can hav= e block codes or convolutional codes. In both cases, we can have variable r= edundancy ratios. We can have self-synchronizing schemes with constant bloc= k or cycle length, or we can have variable size blocks. When using more tha= n trivial XOR, we need to negotiate among many formulas to compute the redu= ndancy. I am not saying that we should have all that complexity in the orig= inal FEC options. I am just following Martin's suggestion that we want a li= ght weight negotiation process that will enable these options in the future= . And we can do the thought experiments at little cost. By the way, the same is true of multipath. There are many variants. Do we u= se a single packet sequence number and spread the packets over multiple pat= hs, or do we use a separate sequence number for error detection on each pat= h? In the latter case, do we keep the "flow" space common across all paths?= Do we follow the same strategies for load sharing and for reconnections? A= gain, the negotiation process should enable many options, even if the stand= ard focuses on one. -- Christian Huitema =20 From nobody Tue Jun 14 11:06:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7A12D880 for ; Tue, 14 Jun 2016 11:06:07 -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 y8D2rWbqjG68 for ; Tue, 14 Jun 2016 11:06:06 -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 1847A12D741 for ; Tue, 14 Jun 2016 11:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=212; q=dns/txt; s=iport; t=1465927566; x=1467137166; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Um0edj2U/Y7OlwL7mgOI0nvs7SnESALR1B7S5pIizzQ=; b=LbeilaNoa8W1okN6zomQ5Xs1TclHWOLLF7FRxqqinG0d1b92UTjKNcLB NFYRA+5fxCIc7jBvo7jKnWKuDYbGTmE+vH6AwI0mLadDDemoXDWkhOsxG BrulAW1YUvzflmSpjzlWoCObFL0nn96mGIS8xC+a2Ss8usx9nLcrWLO7t Y=; X-IronPort-AV: E=Sophos;i="5.26,471,1459814400"; d="scan'208";a="283711053" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 18:06:05 +0000 Received: from [10.152.176.55] ([10.152.176.55]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5EI64Wf001112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 18:06:05 GMT From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jun 2016 12:06:04 -0600 Message-Id: To: quic@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Authenticated-User: dwing Archived-At: Cc: Joe Hildebrand Subject: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 18:06:07 -0000 Joe and I just published "Network Path Requirements for QUIC", = https://tools.ietf.org/html/draft-wing-quic-network-req, which offers = some requirements we believe will help universal QUIC deployment. -d From nobody Tue Jun 14 11:26:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89E112D8B8 for ; Tue, 14 Jun 2016 11:26:45 -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 4q1YJJKyrDnV for ; Tue, 14 Jun 2016 11:26:44 -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 7288312D8B7 for ; Tue, 14 Jun 2016 11:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2222; q=dns/txt; s=iport; t=1465928804; x=1467138404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/FLR3pYXaa2FDAR+PPVlyxuscMvXlMYArywSWtIwV50=; b=lfCRWikkWCNhHrd68Tx4Qm4yHdQhsvyiZB+V1FvDNkMihDKDywDy80Ey bdiBKwrLYcGPBksHPL42Uc0RoGjaZe3mh9IQ+c2izjpPUV4ULPOsRVrNF WrcVfFjeJ0rqevjdFXNjWlBUbOsJaqqN1xfbk0ctBrUe45JD2UVWDoTfz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIBQDJS2BX/4sNJK1egz5WfQa5JYQII?= =?us-ascii?q?oV1AhyBGDwQAQEBAQEBAWUcC4RMAQEEIxFFEAIBCBoCJgICAjAVEAIEDgWIMA6?= =?us-ascii?q?sDpEJAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUmgXeCVodBK4IvBYgPkFQBh?= =?us-ascii?q?gSIJI8ij3MBNR+Dbm6JCX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,471,1459814400"; d="scan'208";a="283719064" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jun 2016 18:26:43 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5EIQhXm029059 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jun 2016 18:26:43 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Jun 2016 14:26:42 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 14 Jun 2016 14:26:42 -0400 From: "Joe Hildebrand (jhildebr)" To: "quic@ietf.org" Thread-Topic: Network Path Requirements for QUIC Thread-Index: AQHRxmdrA4n/SZAVekigMWYxC+73GZ/pJkIA Date: Tue, 14 Jun 2016 18:26:42 +0000 Message-ID: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.176.79] Content-Type: text/plain; charset="utf-8" Content-ID: <8485B7273A9B1849AE0AC4B789A1BAD7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 18:26:46 -0000 T24gNi8xNC8xNiwgMTI6MDYgUE0sICJEYW4gV2luZyAoZHdpbmcpIiA8ZHdpbmdAY2lzY28uY29t PiB3cm90ZToNCg0KPkpvZSBhbmQgSSBqdXN0IHB1Ymxpc2hlZCAiTmV0d29yayBQYXRoIFJlcXVp cmVtZW50cyBmb3IgUVVJQyIsIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5n LXF1aWMtbmV0d29yay1yZXEsIHdoaWNoIG9mZmVycyBzb21lIHJlcXVpcmVtZW50cyB3ZSBiZWxp ZXZlIHdpbGwgaGVscCB1bml2ZXJzYWwgUVVJQyBkZXBsb3ltZW50Lg0KDQpJIGJlbGlldmUgdGhh dCBhIHNtYWxsIGFkZGl0aW9uIHRvIHRoZSBjaGFydGVyIHdvdWxkIGJlIHVzZWZ1bCB0byBlbnN1 cmUgdGhhdCB3ZSBtYWtlIHNvbWUgZXhwbGljaXQgZGVjaXNpb25zIGFib3V0IHRoZSB3b3JrIGlt cGxpZWQgYnkgdGhpcyBkcmFmdCwgYWRkaW5nIHRoZSBjbGF1c2UgIm5ldHdvcmsgcGF0aCBpbnRl cmFjdGlvbnMiIGFzIG9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgbmVlZHMgdG8gYmUgZGVzY3JpYmVk IGluIHRoZSB0cmFuc3BvcnQgd29yazoNCg0KT0xEOg0KDQonJycNClRoZSBmaXJzdCBvZiB0aGVz ZSBpcyB0aGUgY29yZSB0cmFuc3BvcnQgd29yaywgd2hpY2ggd2lsbCBkZXNjcmliZSB0aGUgd2ly ZSBmb3JtYXQsIGFsb25nIHdpdGggdGhlIG1lY2hhbmlzbXMgZm9yIGNvbm5lY3Rpb24gZXN0YWJs aXNobWVudCwgc3RyZWFtIG11bHRpcGxleGluZywgZGF0YSByZWxpYWJpbGl0eSwgbG9zcyBkZXRl Y3Rpb24gYW5kIHJlY292ZXJ5LCBjb25nZXN0aW9uIGNvbnRyb2wsIHZlcnNpb24gbmVnb3RpYXRp b24sIGFuZCBvcHRpb25zIG5lZ290aWF0aW9uLg0KJycnDQoNCk5FVzoNCg0KJycnDQpUaGUgZmly c3Qgb2YgdGhlc2UgaXMgdGhlIGNvcmUgdHJhbnNwb3J0IHdvcmssIHdoaWNoIHdpbGwgZGVzY3Jp YmUgdGhlIHdpcmUgZm9ybWF0LCBhbG9uZyB3aXRoIHRoZSBtZWNoYW5pc21zIGZvciBjb25uZWN0 aW9uIGVzdGFibGlzaG1lbnQsIHN0cmVhbSBtdWx0aXBsZXhpbmcsIGRhdGEgcmVsaWFiaWxpdHks IGxvc3MgZGV0ZWN0aW9uIGFuZCByZWNvdmVyeSwgY29uZ2VzdGlvbiBjb250cm9sLCB2ZXJzaW9u IG5lZ290aWF0aW9uLCBvcHRpb25zIG5lZ290aWF0aW9uLCBhbmQgbmV0d29yayBwYXRoIGludGVy YWN0aW9ucy4NCicnJw0KDQooUHVsbCBSZXF1ZXN0OiBodHRwczovL2dpdGh1Yi5jb20vSUVURi1R VUlDL0NoYXJ0ZXIvcHVsbC84KQ0KDQpXZSBjYW4gYXJndWUgb3ZlciB3aGF0IHRob3NlIGludGVy YWN0aW9ucyBzaG91bGQgYmUgKGluY2x1ZGluZyAibm9uZSIpLCBidXQgSSB3b3VsZCBsaWtlIHVz IHRvIG1ha2UgZXhwbGljaXQgZGVjaXNpb25zLCByYXRoZXIgdGhhbiBsZWF2aW5nIHRoZSBtaWRk bGVib3ggdmVuZG9ycyB0byBvc3NpZnkgYW5kIGJyZWFrIFFVSUMgaW4gdGhlIGV4Y2l0aW5nIHdh eXMgdGhhdCBhcmUgbGlrZWx5IGlmIHRoZXkgcHJvY2VlZCB3aXRob3V0IGFueSBndWlkYW5jZS4g DQoNCkFzIHdlbGwsIEkgd291bGQgbGlrZSB0byByZXF1ZXN0IHNvbWUgdGltZSBvbiB0aGUgQm9G IGFnZW5kYSB0byBkaXNjdXNzIHRoaXMgZHJhZnQsIGF0IGxlYXN0IGF0IGEgaGlnaCBsZXZlbC4g DQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0K From nobody Tue Jun 14 11:54:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A34012D74F for ; Tue, 14 Jun 2016 11:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Z35VZM0dS3T8 for ; Tue, 14 Jun 2016 11:54:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B1612B077 for ; Tue, 14 Jun 2016 11:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DPs6pwmB/8Tqaf8slniBvH/McK5RswhtPn9yNiXLjdE=; b=XrSxtmMmgDenJv9EFW8VwXrGpSmeI9S/z24x5vX6ue58Sm6saiAEPdtfvT1OUfM+oji83Bl4Re+HnzY0Pj9P/vfG3D4H0eQVTCDi4Vu25SlnJjak/OVIO7kWL0muAyt2WQB7vi6d8MartzENhCijRgvLV1cIyHTM/cYDEeRKuBo= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 18:54:35 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0517.011; Tue, 14 Jun 2016 18:54:35 +0000 From: Christian Huitema To: "Joe Hildebrand (jhildebr)" , "quic@ietf.org" Thread-Topic: Network Path Requirements for QUIC Thread-Index: AQHRxmpUm60htf9Ad0SGrBzG1iqBxJ/pTiag Date: Tue, 14 Jun 2016 18:54:35 +0000 Message-ID: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> In-Reply-To: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:2::14d] x-ms-office365-filtering-correlation-id: c66206a5-6091-402b-8d21-08d394855429 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 6:6v/RyhugCIRt65lko8P0TSoolFTZdlC31qrhDdwzRgfK7veLAAvpeBat64mEwB1KihAMs3N2fu0gotmdr7pjQgEc6GQz7Mis+2ZaNaJQ+bx32UX+A6ENfpXo8YAMliU689vkgoVJn4GleBYNh+ae+dpCX/VLIg3daerTyIq/J7PmzpXA9G4ikMcLFlnIT8fA4qmcMMtvthY6vLvN/N1fnVMaHmyRFMFl7utSg+sU3MOIcQdogog8e2d17wfNwkzG+LmwM2UFFrUK2h6Jm8rKlyvNYHoKTRIVnfms1U7N5pKbXjZ0Yzm2eoiHUxrcOaLKn9mEpHdliguUbKrKvG9WIg==; 5:WJ+F+OEtV+FiyAQt1n8qlQUZjlQxt7+FQgeEH3KSlLEiQBU7MKFSLCbAwnQvFDBtSA+JIKQgedSxgJuUcw17qVZOb2JUFomcgab2tHmbMmKObspyrwZBHmKHRH+GgGU3W/JEMl4jX33MeT91PCQ8lw==; 24:p7BrH+aTRBH8M0Kc/fPOoRM1mE9gi7Rz1BofP7BgPGU1UmFw0X3BL3kcmEzoBpDXJDchNgcTdfSYMo0rmOmTZihbWWVjGda9TeskAMSFnYM=; 7:XrnGsRP4Z7udo721qcOR4sngsND+njpFwnRrFNh1bu/pfIGdkr/YMZUH2uRAW0WkhY2XqdAGsquHWsgjU4+9RPWPR7b1e+WEho4zF6NYgTLLC5dQjB8KrwX8f8xkNQQ3yuKvV7RqoRFDUZNlJ+u4Tk1ozxfFbKUWR5/t/N0p8uduKD8yrc8loa7jAxnKIktC0veGV3IIwL23ftAzxhWtvzO3VvY3iJurOMYUndPOvYyFtp85nUZHONWD55bQyfMZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(122556002)(86362001)(4326007)(99286002)(106116001)(2906002)(105586002)(106356001)(586003)(11100500001)(102836003)(6116002)(10090500001)(10290500002)(5005710100001)(10400500002)(2501003)(8936002)(8990500004)(9686002)(5004730100002)(77096005)(5002640100001)(54356999)(76176999)(74316001)(2950100001)(189998001)(2900100001)(76576001)(87936001)(33656002)(3280700002)(101416001)(5008740100001)(92566002)(81166006)(81156014)(8676002)(86612001)(50986999)(97736004)(3660700001)(5003600100002)(5001770100001)(68736007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 18:54:35.0430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 18:54:38 -0000 On Tuesday, June 14, 2016 11:27 AM, Joe Hildebrand wrote: > ... > We can argue over what those interactions should be (including "none"), b= ut I > would like us to make explicit decisions, rather than leaving the middleb= ox > vendors to ossify and break QUIC in the exciting ways that are likely if = they > proceed without any guidance. Since when did guidance stop middle box designers from breaking protocols? = The proper defense against middle boxes is to carefully chose what is outsi= de the encryption envelope, thus limiting the amount of misguided clevernes= s that can be applied by intermediaries.=20 -- Christian Huitema From nobody Tue Jun 14 12:32:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEEB12D0D9 for ; Tue, 14 Jun 2016 12:32:20 -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=unavailable 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 Uf6KO20DsNhF for ; Tue, 14 Jun 2016 12:32:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9233112D0CF for ; Tue, 14 Jun 2016 12:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1570; q=dns/txt; s=iport; t=1465932183; x=1467141783; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7P4Uu27jk7befEEQZ0yzzEK1PmFMsgRR4MY1ygNDRuU=; b=V/9TTT5b9PQILrqTHtKGgjWSbhOdiUHtKqJLXej38Uedjw1ePi1ivFss O7sdKXJim+P0gx4Y01I35IIhx2mME8e3ljcaX/Xz/0XXGwQjaMQrE79l+ z5POlkSyauZ3OHDq+y9ZGcDUWslGUjgeT8J56zskmFR0I68o1Qf/su7/D s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGBQCuWGBX/4MNJK1dgz6BUwa5JYQIh?= =?us-ascii?q?hcCHIEYPBABAQEBAQEBZSeETAEBBCMRRRACAQgYAgImAgICMBUQAgQBDQWIMKw?= =?us-ascii?q?5kQIBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGFJoF3CIJOhEAXgmorgi8BBJhjA?= =?us-ascii?q?Y4ogWmEUoMthTqPcwE1H4IHHIFLbokJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,471,1459814400"; d="scan'208";a="284926604" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jun 2016 19:23:02 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5EJN2pW029093 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jun 2016 19:23:02 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Jun 2016 15:23:01 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 14 Jun 2016 15:23:01 -0400 From: "Joe Hildebrand (jhildebr)" To: Christian Huitema , "quic@ietf.org" Thread-Topic: Network Path Requirements for QUIC Thread-Index: AQHRxmdrA4n/SZAVekigMWYxC+73GZ/pJkIAgABsYID//6NcgA== Date: Tue, 14 Jun 2016 19:23:01 +0000 Message-ID: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.176.79] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 19:32:21 -0000 T24gNi8xNC8xNiwgMTI6NTQgUE0sICJDaHJpc3RpYW4gSHVpdGVtYSIgPGh1aXRlbWFAbWljcm9z b2Z0LmNvbT4gd3JvdGU6DQoNCj5PbiBUdWVzZGF5LCBKdW5lIDE0LCAyMDE2IDExOjI3IEFNLCBK b2UgSGlsZGVicmFuZCB3cm90ZToNCj4+IC4uLg0KPj4gV2UgY2FuIGFyZ3VlIG92ZXIgd2hhdCB0 aG9zZSBpbnRlcmFjdGlvbnMgc2hvdWxkIGJlIChpbmNsdWRpbmcgIm5vbmUiKSwgYnV0IEkNCj4+ IHdvdWxkIGxpa2UgdXMgdG8gbWFrZSBleHBsaWNpdCBkZWNpc2lvbnMsIHJhdGhlciB0aGFuIGxl YXZpbmcgdGhlIG1pZGRsZWJveA0KPj4gdmVuZG9ycyB0byBvc3NpZnkgYW5kIGJyZWFrIFFVSUMg aW4gdGhlIGV4Y2l0aW5nIHdheXMgdGhhdCBhcmUgbGlrZWx5IGlmIHRoZXkNCj4+IHByb2NlZWQg d2l0aG91dCBhbnkgZ3VpZGFuY2UuDQo+DQo+U2luY2Ugd2hlbiBkaWQgZ3VpZGFuY2Ugc3RvcCBt aWRkbGUgYm94IGRlc2lnbmVycyBmcm9tIGJyZWFraW5nIHByb3RvY29scz8gVGhlIHByb3BlciBk ZWZlbnNlIGFnYWluc3QgbWlkZGxlIGJveGVzIGlzIHRvIGNhcmVmdWxseSBjaG9zZSB3aGF0IGlz IG91dHNpZGUgdGhlIGVuY3J5cHRpb24gZW52ZWxvcGUsIHRodXMgbGltaXRpbmcgdGhlIGFtb3Vu dCBvZiBtaXNndWlkZWQgY2xldmVybmVzcyB0aGF0IGNhbiBiZSBhcHBsaWVkIGJ5IGludGVybWVk aWFyaWVzLiANCg0KUGxlYXNlIHJlYWQgdGhlIGRyYWZ0LiAgSSBob3BlIHdlJ3JlIG5vdCBzdWdn ZXN0aW5nIHBhcnRpY3VsYXIgZGVzaWduIGFwcHJvYWNoZXMuICBJZiB3ZSBhcmUsIHdlJ2xsIGNo YW5nZSB0aGUgZHJhZnQuICBXaGF0IEkgaG9wZSB3ZSdyZSByYWlzaW5nIGlzIGEgc2V0IG9mIHBv dGVudGlhbCByZXF1aXJlbWVudHMgdG8gc3RhcnQgdGhlIGRpc2N1c3Npb24gb2YgZXhhY3RseSB3 aGF0IHlvdSdyZSBwcm9wb3Npbmc6IHdoYXQgZ29lcyBpbnNpZGUgYW5kIG91dHNpZGUgdGhlIGNy eXB0byB2ZWlsLiAgQW55dGhpbmcgdGhhdCB3ZSBleHBvc2Ugd2lsbCBvc3NpZnkgaW1tZWRpYXRl bHkuICBBbnl0aGluZyB0aGF0IHdlIGRvbid0IGV4cG9zZSBtYXkgc3RpbGwgb3NzaWZ5LCBidXQg aXQgZXZlbiBsZXNzIHByZWRpY3RhYmxlIHdheXMuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0K DQoNCg== From nobody Tue Jun 14 12:40:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B708512D973 for ; Tue, 14 Jun 2016 12:40:00 -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_H4=-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 p4a0BMj_Nzyh for ; Tue, 14 Jun 2016 12:39:59 -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 42CDC12D114 for ; Tue, 14 Jun 2016 12:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=876; q=dns/txt; s=iport; t=1465933199; x=1467142799; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=31aQ5XcuICjSfFKksvvIJ7RwSJ++gJ5Yvoc87JOafJg=; b=Ql/YDeMEwoEAiScwH4C72FC4BPOWNLiz0Wf+SPh53u9mjbCv+miF0PoD y8Pyvyl+xi28d6DfrEqjIvl3INVgr56v7BOcDUB3ltzmfwPg9X9pU4WlH CwIYlc68Xs/9ZgWkALRx03rw+Svk0Hhxn5ew5N6CbKVtX95rAGMskajmp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCBQA7XGBX/49dJa1dgz6BUwa5JYQIh?= =?us-ascii?q?hcegRg7EQEBAQEBAQFlJ4RMAgQjEUUSAQgaAiYCBDAVEgQBDQWIMKxFkQIBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEcgQGFJoF3glaHQSuCLwEEmGMBjiiBUxaEUoMth?= =?us-ascii?q?TqPcwE0IINubokJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,472,1459814400"; d="scan'208";a="118744144" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 19:39:58 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5EJdwpW028475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jun 2016 19:39:58 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Jun 2016 15:39:57 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 14 Jun 2016 15:39:57 -0400 From: "Joe Hildebrand (jhildebr)" To: Christian Huitema , "quic@ietf.org" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxnSIXtQQEPAqikSyEdhzDw3cyA== Date: Tue, 14 Jun 2016 19:39:57 +0000 Message-ID: <91557F26-AC4C-45C0-8E47-A962276E9CE6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.176.79] Content-Type: text/plain; charset="utf-8" Content-ID: <647F3DACDF89FB4F83D5867FCC700287@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 19:40:01 -0000 T24gNi8xNC8xNiwgMToyMyBQTSwgIlFVSUMgb24gYmVoYWxmIG9mIEpvZSBIaWxkZWJyYW5kIChq aGlsZGVicikiIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoaWxkZWJyQGNp c2NvLmNvbT4gd3JvdGU6DQoNCj5QbGVhc2UgcmVhZCB0aGUgZHJhZnQuICBJIGhvcGUgd2UncmUg bm90IHN1Z2dlc3RpbmcgcGFydGljdWxhciBkZXNpZ24gYXBwcm9hY2hlcy4gIElmIHdlIGFyZSwg d2UnbGwgY2hhbmdlIHRoZSBkcmFmdC4gIFdoYXQgSSBob3BlIHdlJ3JlIHJhaXNpbmcgaXMgYSBz ZXQgb2YgcG90ZW50aWFsIHJlcXVpcmVtZW50cyB0byBzdGFydCB0aGUgZGlzY3Vzc2lvbiBvZiBl eGFjdGx5IHdoYXQgeW91J3JlIHByb3Bvc2luZzogd2hhdCBnb2VzIGluc2lkZSBhbmQgb3V0c2lk ZSB0aGUgY3J5cHRvIHZlaWwuICBBbnl0aGluZyB0aGF0IHdlIGV4cG9zZSB3aWxsIG9zc2lmeSBp bW1lZGlhdGVseS4gIEFueXRoaW5nIHRoYXQgd2UgZG9uJ3QgZXhwb3NlIG1heSBzdGlsbCBvc3Np ZnksIGJ1dCBpdCBldmVuIGxlc3MgcHJlZGljdGFibGUgd2F5cy4NCg0KYnV0ICppbiogZXZlbiBs ZXNzIHByZWRpY3RhYmxlIHdheXMuICBTb3JyeSBmb3IgdGhlIHR5cG8uDQoNCi0tIA0KSm9lIEhp bGRlYnJhbmQNCg0K From nobody Tue Jun 14 12:49:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8092112D92A for ; Tue, 14 Jun 2016 12:49:06 -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 taDy0SwiGA_K for ; Tue, 14 Jun 2016 12:49:03 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFEFD12D91A for ; Tue, 14 Jun 2016 12:49:02 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id p204so1017544oih.3 for ; Tue, 14 Jun 2016 12:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dopxr+xVAp9KhrXK98L/jLvdr8V9AMhqYrKA10+RWaQ=; b=A2Rm4FY9A7CkvCuVota4t5nkw8kSZYrIVdf0v4xVbXggbUoqalzBY83GbQV8cVDGuP 9i81Xm83yN5VhT0OO7dYexfssFd6eojx1Djs8Af1uYiCN38BCzZZ+QHfo9JCgFjPZhC2 SGQo4IkpN7WN1P2z4P+jaH+DRPow9V2juRAVUDV3fdnc824pbLYJMSFRbrJT13YTDlms tCsOLxiSQyTZVBlGujcYCPacWjfC27eL75SRcdyPLgqTIzWGWmoNwll/mC+7jKb8O3C+ 2YbH6gfR0gTl/FK5WEWjCEcRaABPxOC/1wm4LKgnfdR11Q+JFbnxgSUKSxPk2vk4Qpqz TsDA== 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=Dopxr+xVAp9KhrXK98L/jLvdr8V9AMhqYrKA10+RWaQ=; b=dLPfCVcbsjFsvGX0d1dmKpOzFvutZYRuPm4RETW2QYpiK1Fduvp+wcoRYi/xEgQWMu iFiXPgg4cWUEsNhLSwFuojIGCOEFzFMLIdZuuAw2FK28hLp5/GDJnYoaju1yaTBbZOAO 8o1QibQERY8nL41wPxTLQNoLGkvgQmrhitgCXAzhMdE9VMmg7seAoDIwRRR/Ed6LGdbZ sZBLQG5F9QOHAXT66iHizpuBzyWMgAiRyHAbYd0ozeV2fRXlkQJ3J6e9c5hbYw4UVULy 3udXgKNMhgslEazUYNDJ8vapVJFTOdiOGdn9licQTTKcuJ6bJswfnL+9LR9dbYY72ydK QMDQ== X-Gm-Message-State: ALyK8tJXACbuoVkJrUlmXa9RtIQZz0vTaI89Bqr6de5rDiHseREcZXSVM3mQq9vSZuK+U13IS7u5yxpOxupL+A== X-Received: by 10.202.48.18 with SMTP id w18mr9644293oiw.61.1465933741745; Tue, 14 Jun 2016 12:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Tue, 14 Jun 2016 12:48:42 -0700 (PDT) In-Reply-To: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> From: Ted Hardie Date: Tue, 14 Jun 2016 12:48:42 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a113cd59cf0ee990535424b21 Archived-At: Cc: Christian Huitema , "quic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 19:49:06 -0000 --001a113cd59cf0ee990535424b21 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 14, 2016 at 12:23 PM, Joe Hildebrand (jhildebr) > > Please read the draft. I hope we're not suggesting particular design > approaches. That comes across as a little odd, honestly, because there are design approaches already in QUIC for much of what you're looking for (e.g. the visible connection-ID). That makes it appear that you're suggesting changes, when you don't aver you don't intend to.. I kind of suspect that this would work as a "Requirements for UDP-based protocols desiring to provide TCP-like visibility to the path", with a later checklist by QUIC to show how they're met (or if they're not met, and why). > If we are, we'll change the draft. What I hope we're raising is a set of > potential requirements to start the discussion of exactly what you're > proposing: what goes inside and outside the crypto veil. So, there is more than one type of crypto that may be at play here: encryption to make confidential and encryption to make tampering evident. > Anything that we expose will ossify immediately. Anything that we don't > expose may still ossify, but it even less predictable ways. > > I think you're using ossify in an odd way here. I normally use it when something flexible has become rigid. Exposing connection-id, as QUIC does, doesn't ossify connection-id. Middlebox vendors who fire-and-forget may understand that version and never update, but that's not triggered by exposure so much as update cycle issue (some of which are so bad that merely exposing connection-id and QUIC won't trigger an update at all; those will never see the traffic as QUIC). In the long term, I want to see PLUS in this space and hope that it gives us the flexibility we need to go forward. Absent that, I appreciate your taking the time to express what middleboxes want to see on the apth. But I do want us to be careful not to either try to slam the two efforts together nor to make UDP-based protocols mimic TCP-based ones exactly. They will vary, for large values of "they". Take with a grain of salt, as I had little sleep and a strange morning, Ted > -- > Joe Hildebrand > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a113cd59cf0ee990535424b21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 14, 2016 at 12:23 PM, Joe Hildebrand (jhildebr= ) <j

Please read the draft.=C2=A0 I hope we're not suggesting particu= lar design approaches.=C2=A0

That comes acr= oss as a little odd, honestly, because there are design approaches already = in QUIC for much of what you're looking for (e.g. the visible connectio= n-ID).=C2=A0 That makes it appear that you're suggesting changes, when = you don't aver you don't intend to..=C2=A0

I kin= d of suspect that this would work as=C2=A0 a "Requirements for UDP-bas= ed protocols desiring to provide TCP-like visibility to the path", wit= h a later checklist by QUIC to show how they're met (or if they're = not met, and why).=C2=A0
=C2=A0
If we are, we'll change the draft.=C2=A0 What I hope we're= raising is a set of potential requirements to start the discussion of exac= tly what you're proposing: what goes inside and outside the crypto veil= .=C2=A0

So, there is more than one type of = crypto that may be at play here:=C2=A0 encryption to make confidential and = encryption to make tampering evident.=C2=A0
=C2=A0
Anything that we expose will ossify immediately= .=C2=A0 Anything that we don't expose may still ossify, but it even les= s predictable ways.


I think you're using ossify in an odd way here.= =C2=A0 I normally use it when something flexible has become rigid.=C2=A0 Ex= posing connection-id, as QUIC does, doesn't ossify connection-id.=C2=A0= Middlebox vendors who fire-and-forget may understand that version and neve= r update, but that's not triggered by exposure so much as update cycle = issue (some of which are so bad that merely exposing connection-id and QUIC= won't trigger an update at all; those will never see the traffic as QU= IC).

In the long term, I want to see PLUS in this space a= nd hope that it gives us the flexibility we need to go forward.=C2=A0 Absen= t that, I appreciate your taking the time to express what middleboxes want = to see on the apth.=C2=A0 But I do want us to be careful not to either try = to slam the two efforts together nor to make UDP-based protocols mimic TCP-= based ones exactly.=C2=A0 They will vary, for large values of "they&qu= ot;.

Take with a grain of salt, as I had littl= e sleep and a strange morning,

Ted

=C2= =A0
--
Joe Hildebrand



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

--001a113cd59cf0ee990535424b21-- From nobody Tue Jun 14 12:51:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C04312D94A for ; Tue, 14 Jun 2016 12:51:17 -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 QkiR6r5M6wEt for ; Tue, 14 Jun 2016 12:50:41 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1813E12D93E for ; Tue, 14 Jun 2016 12:50:41 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id w5so1152496oib.2 for ; Tue, 14 Jun 2016 12:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ALGduLDwZMvqHaOCNuvpvU78joyngD9/8wnb3FCMhio=; b=mklB0FkSBaEFQ/d9+LOuKQGZqgaokQ/HX1NcfV8PSbmoSQttO6g/7/BaZfVK3F8Mrl jRiHfdrac4lCXm9sRlEli0haxLQmzeHsikRcBV3ccN/hBm+7KQXIHOQhBSyIjmrdtGxp bWP3i+NjdcTK51c0JApdDxnQn217TnKkFkLps4Oc2UpdknFNldqXpjBVnexIdqicxe9P sFTbBBnIxYr6KWmOFBx3OulYH7qlTisB/Gjhb6y6IQVlY33wX2Ngl9TMaypMHCkLT4Gc kxdoMkszZXU+hQczN3q/PneJP0HwoditAM5zHDs0q7TcTEQdLaBkRbTh9dVm5/2Q04W/ HMnw== 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=ALGduLDwZMvqHaOCNuvpvU78joyngD9/8wnb3FCMhio=; b=Glgj5cJ/eWMv0j4wByTPmUqRjmrfogU2gzQMFtPeO5J1/ab0FTofBE4xWc2buXO4dB 3dlyLA0d3eD1bcEWJjNC7y9Cex12Qs915MQb+zaP3Fw/cadH5YBVVqoWWxqtP1Wk01Zr Hja+CPX3f7vi4isCjYa9bANvWdxL2WZ0oThSMqP/ArbjS7yiGvhNTEzrmYFa6HxfKl/n 4fDT1VWj3kmeBZ7EK+WQdnXZPyI3iKABnRgUuLFSyPzNK9pdFm8dojsTXdoBHPvHqltk bjp+BHCQ6JrfTtyKuFQ+Dyn2x14Aioy7doUL9YUO3rlITndtBh1r3HOBbk6VRju+9PFu uDDQ== X-Gm-Message-State: ALyK8tK3KpUD2wdSqTgoz5SxW/ZpksChpZpdQODiZuCDiAMlfB3QgiYLGzoorrHszrlGgQgFUT2ZNlj8c7QeKg== X-Received: by 10.202.72.130 with SMTP id v124mr10061431oia.136.1465933840460; Tue, 14 Jun 2016 12:50:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Tue, 14 Jun 2016 12:50:20 -0700 (PDT) In-Reply-To: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> From: Ted Hardie Date: Tue, 14 Jun 2016 12:50:20 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a113daf26d332d805354251e4 Archived-At: Cc: Christian Huitema , "quic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 19:51:17 -0000 --001a113daf26d332d805354251e4 Content-Type: text/plain; charset=UTF-8 The typos below are strong evidence on the need for the mentioned salt. I meant, of course, "That makes it appear that you're suggesting changes, when you aver you don't intend to." (I must be sleepy, as no one awake uses "aver" in a sentence). apologies, Ted On Tue, Jun 14, 2016 at 12:48 PM, Ted Hardie wrote: > On Tue, Jun 14, 2016 at 12:23 PM, Joe Hildebrand (jhildebr) > >> >> Please read the draft. I hope we're not suggesting particular design >> approaches. > > > That comes across as a little odd, honestly, because there are design > approaches already in QUIC for much of what you're looking for (e.g. the > visible connection-ID). That makes it appear that you're suggesting > changes, when you don't aver you don't intend to.. > > I kind of suspect that this would work as a "Requirements for UDP-based > protocols desiring to provide TCP-like visibility to the path", with a > later checklist by QUIC to show how they're met (or if they're not met, and > why). > > >> If we are, we'll change the draft. What I hope we're raising is a set of >> potential requirements to start the discussion of exactly what you're >> proposing: what goes inside and outside the crypto veil. > > > So, there is more than one type of crypto that may be at play here: > encryption to make confidential and encryption to make tampering evident. > > >> Anything that we expose will ossify immediately. Anything that we don't >> expose may still ossify, but it even less predictable ways. >> >> > I think you're using ossify in an odd way here. I normally use it when > something flexible has become rigid. Exposing connection-id, as QUIC does, > doesn't ossify connection-id. Middlebox vendors who fire-and-forget may > understand that version and never update, but that's not triggered by > exposure so much as update cycle issue (some of which are so bad that > merely exposing connection-id and QUIC won't trigger an update at all; > those will never see the traffic as QUIC). > > In the long term, I want to see PLUS in this space and hope that it gives > us the flexibility we need to go forward. Absent that, I appreciate your > taking the time to express what middleboxes want to see on the apth. But I > do want us to be careful not to either try to slam the two efforts together > nor to make UDP-based protocols mimic TCP-based ones exactly. They will > vary, for large values of "they". > > Take with a grain of salt, as I had little sleep and a strange morning, > > Ted > > > >> -- >> Joe Hildebrand >> >> >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >> > > --001a113daf26d332d805354251e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The typos below are strong evidence on the need = for the mentioned salt.=C2=A0 I meant, of course,=C2=A0 "That makes it= appear that you're suggesting changes, when you aver you don't int= end to."=C2=A0 (I must be sleepy, as no one awake uses "aver"= ; in a sentence).

apologies,

Ted

On Tue, Jun 14, 2016 at = 12:48 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Tue, Jun 14, 2016 at 12:23 PM, = Joe Hildebrand (jhildebr) <j

Please read the draft.=C2=A0 I hope we're not suggesting particu= lar design approaches.=C2=A0

That co= mes across as a little odd, honestly, because there are design approaches a= lready in QUIC for much of what you're looking for (e.g. the visible co= nnection-ID).=C2=A0 That makes it appear that you're suggesting changes= , when you don't aver you don't intend to..=C2=A0

I kind of suspect that this would work as=C2=A0 a "Requirements for = UDP-based protocols desiring to provide TCP-like visibility to the path&quo= t;, with a later checklist by QUIC to show how they're met (or if they&= #39;re not met, and why).=C2=A0
=C2=A0
If we are, we'll change the draft.=C2= =A0 What I hope we're raising is a set of potential requirements to sta= rt the discussion of exactly what you're proposing: what goes inside an= d outside the crypto veil.=C2=A0

So,= there is more than one type of crypto that may be at play here:=C2=A0 encr= yption to make confidential and encryption to make tampering evident.=C2=A0=
=C2=A0
Anything that we expose will ossify immediately.=C2=A0 Anything that we d= on't expose may still ossify, but it even less predictable ways.


I think you're using ossify in an odd way here.=C2=A0 I no= rmally use it when something flexible has become rigid.=C2=A0 Exposing conn= ection-id, as QUIC does, doesn't ossify connection-id.=C2=A0 Middlebox = vendors who fire-and-forget may understand that version and never update, b= ut that's not triggered by exposure so much as update cycle issue (some= of which are so bad that merely exposing connection-id and QUIC won't = trigger an update at all; those will never see the traffic as QUIC).
In the long term, I want to see PLUS in this space and hope tha= t it gives us the flexibility we need to go forward.=C2=A0 Absent that, I a= ppreciate your taking the time to express what middleboxes want to see on t= he apth.=C2=A0 But I do want us to be careful not to either try to slam the= two efforts together nor to make UDP-based protocols mimic TCP-based ones = exactly.=C2=A0 They will vary, for large values of "they".

Take with a grain of salt, as I had little sleep and= a strange morning,

Ted
=C2=A0
--
Joe Hildebrand



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


--001a113daf26d332d805354251e4-- From nobody Tue Jun 14 13:08:34 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0276E12D110 for ; Tue, 14 Jun 2016 13:08:30 -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_H4=-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 eFUfRRunaNnZ for ; Tue, 14 Jun 2016 13:08:27 -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 57B4D12D60F for ; Tue, 14 Jun 2016 13:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4340; q=dns/txt; s=iport; t=1465934905; x=1467144505; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1WJTiZiv2llSZckn2UJS++WQw/68ZoKQbknRi0rKNP4=; b=RgOeHMMoUN/GaWAXO9/HJ+FIyJRUCoNr6vDrb3J8Fi/7C8C2aSKGsoPd dxT0DDvf8XTjtHWu49Rtth2SzO7Ndl9QB+OjzqvB0nV0QCIayOmu1pPS+ 3xlcu4eDEhtzSbFepS/GKP31piOnwrUyHtFKYtyPUAGHqvsxWnM+c955C Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGBQBqY2BX/5pdJa1dgz6BUwavMolzh?= =?us-ascii?q?AiGFwIcgRg8EAEBAQEBAQFlJ4RMAQEEIxFFEAIBCBoCIwMCAgIfERQBEAIEDgW?= =?us-ascii?q?IFgMXrFONBg2DcwEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUmgXeCVoJDgX2DA?= =?us-ascii?q?SuCLwWYLzQBjC6BeoFphFKDLYU6hk2BOodsATUfg25uiQl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,472,1459814400"; d="scan'208";a="118752814" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 20:08:24 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5EK8OQ9018503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jun 2016 20:08:24 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Jun 2016 16:08:23 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 14 Jun 2016 16:08:23 -0400 From: "Joe Hildebrand (jhildebr)" To: Ted Hardie Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmdrA4n/SZAVekigMWYxC+73GZ/pJkIAgABsYID//6NcgIAAa8MA//+g6wA= Date: Tue, 14 Jun 2016 20:08:23 +0000 Message-ID: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.152.176.79] Content-Type: text/plain; charset="utf-8" Content-ID: <4FB3B0A6C3E8124D8E8BB10D9EFEAA2B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Christian Huitema , "quic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 20:08:30 -0000 DQpPbiA2LzE0LzE2LCAxOjQ4IFBNLCAiVGVkIEhhcmRpZSIgPHRlZC5pZXRmQGdtYWlsLmNvbT4g d3JvdGU6DQoNCj5PbiBUdWUsIEp1biAxNCwgMjAxNiBhdCAxMjoyMyBQTSwgSm9lIEhpbGRlYnJh bmQgKGpoaWxkZWJyKSANCj48aiA8bWFpbHRvOmpoaWxkZWJyQGNpc2NvLmNvbT4NCj4NCj5QbGVh c2UgcmVhZCB0aGUgZHJhZnQuICBJIGhvcGUgd2UncmUgbm90IHN1Z2dlc3RpbmcgcGFydGljdWxh ciBkZXNpZ24gYXBwcm9hY2hlcy4gDQoNCihub3RlOiBJIGFwb2xvZ2l6ZSBmb3IgYXNzdW1pbmcg dGhhdCBzb21lb25lIGRpZG4ndCByZWFkIHRoZSBkcmFmdC4gIFRoYXQgd2FzIHVua2luZCBhbmQg dW5uZWNlc3NhcnkuKQ0KDQo+VGhhdCBjb21lcyBhY3Jvc3MgYXMgYSBsaXR0bGUgb2RkLCBob25l c3RseSwgYmVjYXVzZSB0aGVyZSBhcmUgZGVzaWduIGFwcHJvYWNoZXMgYWxyZWFkeSBpbiBRVUlD IGZvciBtdWNoIG9mIHdoYXQgeW91J3JlIGxvb2tpbmcgZm9yIChlLmcuIHRoZSB2aXNpYmxlIGNv bm5lY3Rpb24tSUQpLiAgVGhhdCBtYWtlcyBpdCBhcHBlYXIgdGhhdCB5b3UncmUgc3VnZ2VzdGlu ZyBjaGFuZ2VzLCB3aGVuIHlvdSBkb24ndCBhdmVyIHlvdSBkb24ndCBpbnRlbmQNCj4gdG8uLiAg DQoNCkl0IGFwcGVhcmVkIHRvIG1lIGFzIGlmIHRoZSBjb25uZWN0aW9uIElEIG1pZ2h0IGNoYW5n ZSBvdmVyIHRoZSBjb3Vyc2Ugb2YgYSBjb25uZWN0aW9uLCBvciBiZSBlbGlkZWQgaW4gcGFja2V0 cyBsYXRlciBpbiB0aGUgZmxvdy4gIElmIHRoYXQgaXNuJ3QgdGhlIGNhc2UsIFFVSUMgYWxyZWFk eSBtZWV0cyB0aGlzIHJlcXVpcmVtZW50Lg0KDQo+SSBraW5kIG9mIHN1c3BlY3QgdGhhdCB0aGlz IHdvdWxkIHdvcmsgYXMgIGEgIlJlcXVpcmVtZW50cyBmb3IgVURQLWJhc2VkIHByb3RvY29scyBk ZXNpcmluZyB0byBwcm92aWRlIFRDUC1saWtlIHZpc2liaWxpdHkgdG8gdGhlIHBhdGgiLCB3aXRo IGEgbGF0ZXIgY2hlY2tsaXN0IGJ5IFFVSUMgdG8gc2hvdyBob3cgdGhleSdyZSBtZXQgKG9yIGlm IHRoZXkncmUgbm90IG1ldCwgYW5kIHdoeSkuIA0KDQpUaGF0J3MgYSB2YWxpZCBhcHByb2FjaCwg YW5kIEknbGwgbGlrZWx5IGJlIHByZXNlbnRpbmcgdGhpcyBpbiB0aGUgUExVUyBCb0YgdG8gdGhh dCBlZmZlY3QNCg0KPlNvLCB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIHR5cGUgb2YgY3J5cHRvIHRo YXQgbWF5IGJlIGF0IHBsYXkgaGVyZTogIGVuY3J5cHRpb24gdG8gbWFrZSBjb25maWRlbnRpYWwg YW5kIGVuY3J5cHRpb24gdG8gbWFrZSB0YW1wZXJpbmcgZXZpZGVudC4gDQoNCkFncmVlLiAgSSBj YW4ndCBpbWFnaW5lIG11Y2ggb3RoZXIgdGhhbiB0aGUgYWRkcmVzcy9wb3J0IDQtdHVwbGUgYmVp bmcgb3V0c2lkZSB0aGUgdGFtcGVyLWV2aWRlbnQgc2VhbCAoYmVjYXVzZSBvZiBOQVQgYW5kIFBB VCkuICBUaGVyZSBtYXkgYmUgc29tZSBjYXNlcyBmb3Igc2NyYXRjaCBzcGFjZSwgYnV0IEkgc3Vz cGVjdCB3ZSB3b3VsZCBuZWVkIGEgcmVhbGx5IGltcG9ydGFudCB1c2UgY2FzZSBiZWZvcmUgd2Ug Z290IGNvbnNlbnN1cyBvbiBzdWNoIGEgdGhpbmcuIA0KDQo+SSB0aGluayB5b3UncmUgdXNpbmcg b3NzaWZ5IGluIGFuIG9kZCB3YXkgaGVyZS4gIEkgbm9ybWFsbHkgdXNlIGl0IHdoZW4gc29tZXRo aW5nIGZsZXhpYmxlIGhhcyBiZWNvbWUgcmlnaWQuICBFeHBvc2luZyBjb25uZWN0aW9uLWlkLCBh cyBRVUlDIGRvZXMsIGRvZXNuJ3Qgb3NzaWZ5IGNvbm5lY3Rpb24taWQuICBNaWRkbGVib3ggdmVu ZG9ycyB3aG8gZmlyZS1hbmQtZm9yZ2V0IG1heSB1bmRlcnN0YW5kIHRoYXQgdmVyc2lvbiBhbmQg bmV2ZXINCj4gdXBkYXRlLCBidXQgdGhhdCdzIG5vdCB0cmlnZ2VyZWQgYnkgZXhwb3N1cmUgc28g bXVjaCBhcyB1cGRhdGUgY3ljbGUgaXNzdWUgKHNvbWUgb2Ygd2hpY2ggYXJlIHNvIGJhZCB0aGF0 IG1lcmVseSBleHBvc2luZyBjb25uZWN0aW9uLWlkIGFuZCBRVUlDIHdvbid0IHRyaWdnZXIgYW4g dXBkYXRlIGF0IGFsbDsgdGhvc2Ugd2lsbCBuZXZlciBzZWUgdGhlIHRyYWZmaWMgYXMgUVVJQyku DQoNCkluIHBhcnRpY3VsYXIsIEkgbWVhbnQgdGhlIHZlcnNpb24gbnVtYmVycyBoZXJlLiAgSW4g YWJzZW5jZSBvZiBzb21lIG1vcmUgdGhvdWdodCwgSSB3b3VsZCBleHBlY3QgbWlkZGxlYm94IHZl bmRvcnMgdG8gdXNlIGEgcGFydGljdWxhciB2ZXJzaW9uIG51bWJlciB0byB0cnkgdG8gY2xhc3Np ZnkgdHJhZmZpYyBhcyAidGhpcyBpcyBRVUlDIiwgd2hpY2ggd291bGQgYmUgYSBob3JyaWJsZSBv dXRjb21lIGZvciBldmVyeW9uZS4NCg0KPkluIHRoZSBsb25nIHRlcm0sIEkgd2FudCB0byBzZWUg UExVUyBpbiB0aGlzIHNwYWNlIGFuZCBob3BlIHRoYXQgaXQgZ2l2ZXMgdXMgdGhlIGZsZXhpYmls aXR5IHdlIG5lZWQgdG8gZ28gZm9yd2FyZC4gIEFic2VudCB0aGF0LCBJIGFwcHJlY2lhdGUgeW91 ciB0YWtpbmcgdGhlIHRpbWUgdG8gZXhwcmVzcyB3aGF0IG1pZGRsZWJveGVzIHdhbnQgdG8gc2Vl IG9uIHRoZSBhcHRoLiAgQnV0IEkgZG8gd2FudCB1cyB0byBiZSBjYXJlZnVsIG5vdA0KPiB0byBl aXRoZXIgdHJ5IHRvIHNsYW0gdGhlIHR3byBlZmZvcnRzIHRvZ2V0aGVyIG5vciB0byBtYWtlIFVE UC1iYXNlZCBwcm90b2NvbHMgbWltaWMgVENQLWJhc2VkIG9uZXMgZXhhY3RseS4gIFRoZXkgd2ls bCB2YXJ5LCBmb3IgbGFyZ2UgdmFsdWVzIG9mICJ0aGV5Ii4NCg0KSSB0aGluayBhIHBvdGVudGlh bCBQTFVTIHdvcmtpbmcgZ3JvdXAgd291bGQgYmUgYSB1c2VmdWwgd2F5IHRvIGV4cGxvcmUgYm90 aCB0aGUgcmVxdWlyZW1lbnRzIGFuZCBhIG5pY2VseS1sYXllcmVkIHByb3RvY29sLiAgQWJzZW50 IGEgY2hhcnRlci1sZXZlbCBjb21taXRtZW50IHRoYXQgYSBwb3RlbnRpYWwgUVVJQyB3b3JraW5n IGdyb3VwIHdvdWxkIHVzZSB0aGUgb3V0cHV0IG9mIHRoYXQgd29yayAod2hpY2ggSSdtICpub3Qq IGFyZ3VpbmcgZm9yKSwgaGF2aW5nIGEgc21hbGwgYWRkaXRpb24gdG8gdGhlIGNoYXJ0ZXIgdG8g ZW5zdXJlIHRoYXQgd2UgZGlzY3VzcyB3aGF0IGtpbmRzIG9mIHBhdGggYnJlYWthZ2UgUVVJQyBp cyBleHBsaWNpdGx5IHNpZ25pbmcgdXAgZm9yIHNlZW1zIGxpa2UgYSByZWxhdGl2ZWx5IHNtYWxs IGFzay4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg== From nobody Tue Jun 14 23:35:04 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124CB12D0D9 for ; Tue, 14 Jun 2016 23:35:03 -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 jogvsXI2NA4Y for ; Tue, 14 Jun 2016 23:35:00 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 28E6E12D0A7 for ; Tue, 14 Jun 2016 23:34:59 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id c72so11788541ywb.1 for ; Tue, 14 Jun 2016 23:34:59 -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=Pn37GObQOX8na/sIfBoQEe6kmbZugME79uhKRP0CGN0=; b=CCwrA7TbnuG4HobifbTlctAk9S41oQmoXG+UDjEWEGs1mhlj8I5q/9/xxj1OtC7ZCI ePHKkj9/Sly9p2TZCvjQD7+3PUNeQoQGb9H/5rak1NKst8bCcOWHP4tY65Qhquo9ULSu lTILAKCIia5DNfxa3xRe+MkhBbqGlZ3To9ojnz0I1soqplgV5G2p3ReYeckfQI3AxbFC OTYn7IaqeUXqtDfx7CKp/NpvER+AWD69ebcIlZJ2aObKFYmTxha2BPRpIm+YtApGldU3 xt4I2Txvrtb093qMcKrzinaep1GXs3DoKWUVe7CcEo2GvPz+PjhfWyVs/31GOB+7Jg02 yfIA== 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=Pn37GObQOX8na/sIfBoQEe6kmbZugME79uhKRP0CGN0=; b=b9LVE7ofMyW9+3glWFhyFz9lNUDHc6hW436e9XDY1hKQrRVddUbXb+wdS6xiUELUoh L5/BfVvlt0qPGKeQOJvYlpn0LRN8/0a3W+1Z+MdCCLlo5gUFTgEO/UN4mK7aK9TGYvoC /7gemN6sYAGM/m1xlM9Rn/aKl0Kc0H9wQYOBpnCbqIHCPQJbIFa+0cOmFQ6lFOf4+tDf +oAwB2HEHWjWSsF8Ep97xRBoLeMKydF/mPiq0EFk+PV3QH13S+XEpJQbWNqfOSJc+JqL diZmdYxQgI4/eqzFIxfSH/mdi3Cjpo6ARSowzJULhZIrG6qTdgLgq0PN7aVm/U8bye/p lFow== X-Gm-Message-State: ALyK8tLEv/MQaZFHL7ydPoLYeebJyw5Ncy2QzjpiK0pnCKdroM/N91kUCS1JoWinCxau7GvEUpHl5Fl3IjAm7J0J X-Received: by 10.37.49.193 with SMTP id x184mr13197666ybx.57.1465972498239; Tue, 14 Jun 2016 23:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.224.136 with HTTP; Tue, 14 Jun 2016 23:34:57 -0700 (PDT) In-Reply-To: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> From: Jana Iyengar Date: Tue, 14 Jun 2016 23:34:57 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a1148af1802873f05354b5227 Archived-At: Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 06:35:03 -0000 --001a1148af1802873f05354b5227 Content-Type: text/plain; charset=UTF-8 Hi Dan, Joe, Thanks for putting this draft together and for sharing it. I want to add just a few thoughts to the conversation. QUIC currently has most of the QUIC header fields encrypted and authenticated (invisible to the network), and some header fields authenticated but not encrypted (visible to the network but tamper resistant). The fields that are exposed have well-defined use cases --- Connection ID, for example, is visible and can be used by load-balancers to direct traffic belonging to a QUIC connection to the same server. I expect that these fields will be debated and discussed in the wg, and I think these considerations will be quite helpful when that conversation is underway. It'll be good to identify precisely which fields of QUIC that aren't currently exposed should be exposed (or vice versa), to have a debate in more concrete terms. Specifically, if you have suggestions for which fields in QUIC ought to be made visible or invisible, or about which mechanisms ought to be added, I think that'd be helpful. On the proposed addition to the charter text, I am unclear on the intent. Is it to document possible breakages, or is the intent to prescribe middlebox behavior? I'm not sure how useful the former can be, and I think the latter is a pretty significant effort (and central to PLUS, I believe.) I don't think the proposed addition to the charter text is appropriate. FWIW, I agree that work in PLUS should inform work in QUIC. I'd like to suggest that, for purely pragmatic reasons, we wait for PLUS to do its work and for QUIC to do its work before incorporating PLUS's lessons into QUIC. Mixing these two at this early stage, when scoping as tightly as reasonably possible is critical, does not seem advisable. This may not be what you're suggesting at all, so we may already be on the same page. - jana On Tue, Jun 14, 2016 at 1:08 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > On 6/14/16, 1:48 PM, "Ted Hardie" wrote: > > >On Tue, Jun 14, 2016 at 12:23 PM, Joe Hildebrand (jhildebr) > > > > > >Please read the draft. I hope we're not suggesting particular design > approaches. > > (note: I apologize for assuming that someone didn't read the draft. That > was unkind and unnecessary.) > > >That comes across as a little odd, honestly, because there are design > approaches already in QUIC for much of what you're looking for (e.g. the > visible connection-ID). That makes it appear that you're suggesting > changes, when you don't aver you don't intend > > to.. > > It appeared to me as if the connection ID might change over the course of > a connection, or be elided in packets later in the flow. If that isn't the > case, QUIC already meets this requirement. > > >I kind of suspect that this would work as a "Requirements for UDP-based > protocols desiring to provide TCP-like visibility to the path", with a > later checklist by QUIC to show how they're met (or if they're not met, and > why). > > That's a valid approach, and I'll likely be presenting this in the PLUS > BoF to that effect > > >So, there is more than one type of crypto that may be at play here: > encryption to make confidential and encryption to make tampering evident. > > Agree. I can't imagine much other than the address/port 4-tuple being > outside the tamper-evident seal (because of NAT and PAT). There may be > some cases for scratch space, but I suspect we would need a really > important use case before we got consensus on such a thing. > > >I think you're using ossify in an odd way here. I normally use it when > something flexible has become rigid. Exposing connection-id, as QUIC does, > doesn't ossify connection-id. Middlebox vendors who fire-and-forget may > understand that version and never > > update, but that's not triggered by exposure so much as update cycle > issue (some of which are so bad that merely exposing connection-id and QUIC > won't trigger an update at all; those will never see the traffic as QUIC). > > In particular, I meant the version numbers here. In absence of some more > thought, I would expect middlebox vendors to use a particular version > number to try to classify traffic as "this is QUIC", which would be a > horrible outcome for everyone. > > >In the long term, I want to see PLUS in this space and hope that it gives > us the flexibility we need to go forward. Absent that, I appreciate your > taking the time to express what middleboxes want to see on the apth. But I > do want us to be careful not > > to either try to slam the two efforts together nor to make UDP-based > protocols mimic TCP-based ones exactly. They will vary, for large values > of "they". > > I think a potential PLUS working group would be a useful way to explore > both the requirements and a nicely-layered protocol. Absent a > charter-level commitment that a potential QUIC working group would use the > output of that work (which I'm *not* arguing for), having a small addition > to the charter to ensure that we discuss what kinds of path breakage QUIC > is explicitly signing up for seems like a relatively small ask. > > -- > Joe Hildebrand > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a1148af1802873f05354b5227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan, Joe,

Thanks for putting this dr= aft together and for sharing it. I want to add just a few thoughts to the c= onversation.

QUIC currently has most of the QUIC h= eader fields encrypted and authenticated (invisible to the network), and so= me header fields authenticated but not encrypted (visible to the network bu= t tamper resistant). The fields that are exposed have well-defined use case= s --- Connection ID, for example, is visible and can be used by load-balanc= ers to direct traffic belonging to a QUIC connection to the same server. I = expect that these fields will be debated and discussed in the wg, and I thi= nk these considerations will be quite helpful when that conversation is und= erway. It'll be good to identify precisely which fields of QUIC that ar= en't currently exposed should be exposed (or vice versa), to have a deb= ate in more concrete terms. =C2=A0

Specifically, i= f you have suggestions for which fields in QUIC ought to be made visible or= invisible, or about which mechanisms ought to be added, I think that'd= be helpful.

On the proposed addition to the chart= er text, I am unclear on the intent. Is it to document possible breakages, = or is the intent to prescribe middlebox behavior? I'm not sure how usef= ul the former can be, and I think the latter is a pretty significant effort= (and central to PLUS, I believe.) I don't think the proposed addition = to the charter text is appropriate.=C2=A0

FWIW, I = agree that work in PLUS should inform work in QUIC. I'd like to suggest= that, for purely pragmatic reasons, we wait for PLUS to do its work and fo= r QUIC to do its work before incorporating PLUS's lessons into QUIC. Mi= xing these two at this early stage, when scoping as tightly as reasonably p= ossible is critical, does not seem advisable. This may not be what you'= re suggesting at all, so we may already be on the same page.

=
- jana


=
On Tue, Jun 14, 2016 at 1:08 PM, Joe Hildebrand = (jhildebr) <jhildebr@cisco.com> wrote:

On 6/14/16, 1:48 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:

>On Tue, Jun 14, 2016 at 12:23 PM, Joe Hildebrand (jhildebr)
><j <mailto:jhildebr@= cisco.com>
>
>Please read the draft.=C2=A0 I hope we're not suggesting particular= design approaches.

(note: I apologize for assuming that someone didn't read the dra= ft.=C2=A0 That was unkind and unnecessary.)

>That comes across as a little odd, honestly, because there are design a= pproaches already in QUIC for much of what you're looking for (e.g. the= visible connection-ID).=C2=A0 That makes it appear that you're suggest= ing changes, when you don't aver you don't intend
> to..

It appeared to me as if the connection ID might change over the cour= se of a connection, or be elided in packets later in the flow.=C2=A0 If tha= t isn't the case, QUIC already meets this requirement.

>I kind of suspect that this would work as=C2=A0 a "Requirements fo= r UDP-based protocols desiring to provide TCP-like visibility to the path&q= uot;, with a later checklist by QUIC to show how they're met (or if the= y're not met, and why).

That's a valid approach, and I'll likely be presenting this = in the PLUS BoF to that effect

>So, there is more than one type of crypto that may be at play here:=C2= =A0 encryption to make confidential and encryption to make tampering eviden= t.

Agree.=C2=A0 I can't imagine much other than the address/port 4-= tuple being outside the tamper-evident seal (because of NAT and PAT).=C2=A0= There may be some cases for scratch space, but I suspect we would need a r= eally important use case before we got consensus on such a thing.

>I think you're using ossify in an odd way here.=C2=A0 I normally us= e it when something flexible has become rigid.=C2=A0 Exposing connection-id= , as QUIC does, doesn't ossify connection-id.=C2=A0 Middlebox vendors w= ho fire-and-forget may understand that version and never
> update, but that's not triggered by exposure so much as update cyc= le issue (some of which are so bad that merely exposing connection-id and Q= UIC won't trigger an update at all; those will never see the traffic as= QUIC).

In particular, I meant the version numbers here.=C2=A0 In absence of= some more thought, I would expect middlebox vendors to use a particular ve= rsion number to try to classify traffic as "this is QUIC", which = would be a horrible outcome for everyone.

>In the long term, I want to see PLUS in this space and hope that it giv= es us the flexibility we need to go forward.=C2=A0 Absent that, I appreciat= e your taking the time to express what middleboxes want to see on the apth.= =C2=A0 But I do want us to be careful not
> to either try to slam the two efforts together nor to make UDP-based p= rotocols mimic TCP-based ones exactly.=C2=A0 They will vary, for large valu= es of "they".

I think a potential PLUS working group would be a useful way to expl= ore both the requirements and a nicely-layered protocol.=C2=A0 Absent a cha= rter-level commitment that a potential QUIC working group would use the out= put of that work (which I'm *not* arguing for), having a small addition= to the charter to ensure that we discuss what kinds of path breakage QUIC = is explicitly signing up for seems like a relatively small ask.

--
Joe Hildebrand


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

--001a1148af1802873f05354b5227-- From nobody Wed Jun 15 14:33:09 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA0612D614 for ; Wed, 15 Jun 2016 14:33:06 -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 HVV6B03U9C_x for ; Wed, 15 Jun 2016 14:33:04 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCF012D176 for ; Wed, 15 Jun 2016 14:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18495; q=dns/txt; s=iport; t=1466026384; x=1467235984; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=o6ZB8WsEeLCgpRqpWzMQTEMI0jnVah7U+VVpfnjpIek=; b=cl2bsxmIdNw0hF0VpNLLX4sfW/YM9FgW6ijpUrVyLD82PdOcTi+65/Vt 9C8hkAL51CNK77jXd4musSK5xkfO0XTpukIXeUl8CrmjOUIPU/nkHEAX6 ifKKnChgQDyPzlLzHONFNUT/pPgTzo1YC/uJ2OvpsDu3ayFxXIcWGLCt/ w=; X-IronPort-AV: E=Sophos;i="5.26,477,1459814400"; d="scan'208,217";a="285439151" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 21:33:03 +0000 Received: from [10.152.176.78] ([10.152.176.78]) (authenticated bits=0) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5FLX2mw022627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 21:33:03 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_15AA79FA-90A6-4BD5-BDF2-A69F14F5AB58" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Wed, 15 Jun 2016 15:33:02 -0600 Message-Id: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) X-Authenticated-User: dwing Archived-At: Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , Joe Hildebrand Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:33:06 -0000 --Apple-Mail=_15AA79FA-90A6-4BD5-BDF2-A69F14F5AB58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15-Jun-2016 12:34 am, Jana Iyengar wrote:=20 > Hi Dan, Joe, >=20 > Thanks for putting this draft together and for sharing it. I want to = add just a few thoughts to the conversation. >=20 > QUIC currently has most of the QUIC header fields encrypted and = authenticated (invisible to the network), and some header fields = authenticated but not encrypted (visible to the network but tamper = resistant). The fields that are exposed have well-defined use cases --- = Connection ID, for example, is visible and can be used by load-balancers = to direct traffic belonging to a QUIC connection to the same server. I = expect that these fields will be debated and discussed in the wg, and I = think these considerations will be quite helpful when that conversation = is underway. It'll be good to identify precisely which fields of QUIC = that aren't currently exposed should be exposed (or vice versa), to have = a debate in more concrete terms. =20 Yes, hence Joe's charter pull request. > Specifically, if you have suggestions for which fields in QUIC ought = to be made visible or invisible, or about which mechanisms ought to be = added, I think that'd be helpful. draft-wing-quic-network-req tries to up-level its recommendations by = saying 'we need consent' rather than suggesting how to achieve it. = Consent could be achieved in probably 3 or 4 different ways, and we need = a technique that works with multicast QUIC and with persistent QUIC = connections. It's up to WG to agree consent is necessary, then to agree = how to accomplish consent. We have identified other things that impact = the network and need discussion in the working group (some small, some = larger): Should the network clear its state immediately after QUIC = public reset, set timer, wait for a little while. Is the network's sole = identification the QUIC version in the client-initiated connection, and = can we avoid the network treating that specially (which will be good and = bad, I am remembering network treatment of IKE's UDP 500 and 4500). If = QUIC endpoint sends or receives many bogus QUIC packets, how can network = help stop or rate limit those, to defend the links and defend other = hosts on that network. If path drops state due to a timeout (or crash, = or software update, or whatever), how should the endpoints learn and how = should they react. Those previous things are discussed in the I-D. In = addition, QUIC complicates network diagnostics and measurements, as = well, which will be added in a later version of the I-D. > On the proposed addition to the charter text, I am unclear on the = intent. Is it to document possible breakages, or is the intent to = prescribe middlebox behavior? The intent is to change QUIC, as necessary, and to change network = devices, as necessary, so that QUIC can be successfully deployed on more = networks. > I'm not sure how useful the former can be, and I think the latter is a = pretty significant effort (and central to PLUS, I believe.) I don't = think the proposed addition to the charter text is appropriate.=20 >=20 > FWIW, I agree that work in PLUS should inform work in QUIC. I'd like = to suggest that, for purely pragmatic reasons, we wait for PLUS to do = its work and for QUIC to do its work before incorporating PLUS's lessons = into QUIC. Mixing these two at this early stage, when scoping as tightly = as reasonably possible is critical, does not seem advisable. This may = not be what you're suggesting at all, so we may already be on the same = page. Correct -- it's not what I am suggesting at all. The document and = charter pull request are for QUIC, not PLUS. -d > - jana >=20 >=20 > On Tue, Jun 14, 2016 at 1:08 PM, Joe Hildebrand (jhildebr) = > wrote: >=20 > On 6/14/16, 1:48 PM, "Ted Hardie" > wrote: >=20 > >On Tue, Jun 14, 2016 at 12:23 PM, Joe Hildebrand (jhildebr) > >> > > > >Please read the draft. I hope we're not suggesting particular design = approaches. >=20 > (note: I apologize for assuming that someone didn't read the draft. = That was unkind and unnecessary.) >=20 > >That comes across as a little odd, honestly, because there are design = approaches already in QUIC for much of what you're looking for (e.g. the = visible connection-ID). That makes it appear that you're suggesting = changes, when you don't aver you don't intend > > to.. >=20 > It appeared to me as if the connection ID might change over the course = of a connection, or be elided in packets later in the flow. If that = isn't the case, QUIC already meets this requirement. >=20 > >I kind of suspect that this would work as a "Requirements for = UDP-based protocols desiring to provide TCP-like visibility to the = path", with a later checklist by QUIC to show how they're met (or if = they're not met, and why). >=20 > That's a valid approach, and I'll likely be presenting this in the = PLUS BoF to that effect >=20 > >So, there is more than one type of crypto that may be at play here: = encryption to make confidential and encryption to make tampering = evident. >=20 > Agree. I can't imagine much other than the address/port 4-tuple being = outside the tamper-evident seal (because of NAT and PAT). There may be = some cases for scratch space, but I suspect we would need a really = important use case before we got consensus on such a thing. >=20 > >I think you're using ossify in an odd way here. I normally use it = when something flexible has become rigid. Exposing connection-id, as = QUIC does, doesn't ossify connection-id. Middlebox vendors who = fire-and-forget may understand that version and never > > update, but that's not triggered by exposure so much as update cycle = issue (some of which are so bad that merely exposing connection-id and = QUIC won't trigger an update at all; those will never see the traffic as = QUIC). >=20 > In particular, I meant the version numbers here. In absence of some = more thought, I would expect middlebox vendors to use a particular = version number to try to classify traffic as "this is QUIC", which would = be a horrible outcome for everyone. >=20 > >In the long term, I want to see PLUS in this space and hope that it = gives us the flexibility we need to go forward. Absent that, I = appreciate your taking the time to express what middleboxes want to see = on the apth. But I do want us to be careful not > > to either try to slam the two efforts together nor to make UDP-based = protocols mimic TCP-based ones exactly. They will vary, for large = values of "they". >=20 > I think a potential PLUS working group would be a useful way to = explore both the requirements and a nicely-layered protocol. Absent a = charter-level commitment that a potential QUIC working group would use = the output of that work (which I'm *not* arguing for), having a small = addition to the charter to ensure that we discuss what kinds of path = breakage QUIC is explicitly signing up for seems like a relatively small = ask. >=20 > -- > Joe Hildebrand >=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic = >=20 --Apple-Mail=_15AA79FA-90A6-4BD5-BDF2-A69F14F5AB58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 15-Jun-2016 12:34 am, Jana Iyengar <jri@google.com> wrote: =
Hi Dan, Joe,

Thanks for putting this = draft together and for sharing it. I want to add just a few thoughts to = the conversation.

QUIC currently has most of the QUIC header fields encrypted = and authenticated (invisible to the network), and some header fields = authenticated but not encrypted (visible to the network but tamper = resistant). The fields that are exposed have well-defined use cases --- = Connection ID, for example, is visible and can be used by load-balancers = to direct traffic belonging to a QUIC connection to the same server. I = expect that these fields will be debated and discussed in the wg, and I = think these considerations will be quite helpful when that conversation = is underway. It'll be good to identify precisely which fields of QUIC = that aren't currently exposed should be exposed (or vice versa), to have = a debate in more concrete terms. =  

Yes, = hence Joe's charter pull request.

Specifically, if you have suggestions for which fields in = QUIC ought to be made visible or invisible, or about which mechanisms = ought to be added, I think that'd be = helpful.

draft-wing-quic-network-req tries to up-level its = recommendations by saying 'we need consent' rather than suggesting how = to achieve it.  Consent could be achieved in probably 3 or 4 = different ways, and we need a technique that works with multicast QUIC = and with persistent QUIC connections.  It's up to WG to agree = consent is necessary, then to agree how to accomplish consent.  We = have identified other things that impact the network and need discussion = in the working group (some small, some larger):  Should the network = clear its state immediately after QUIC public reset, set timer, wait for = a little while.  Is the network's sole identification the QUIC = version in the client-initiated connection, and can we avoid the network = treating that specially (which will be good and bad, I am remembering = network treatment of  IKE's UDP 500 and 4500).  If QUIC = endpoint sends or receives many bogus QUIC packets, how can network help = stop or rate limit those, to defend the links and defend other hosts on = that network.  If path drops state due to a timeout (or crash, or software = update, or whatever), how should the endpoints learn and how should they = react.  Those previous things are discussed in the I-D.  In = addition, QUIC complicates network diagnostics and measurements, as = well, which will be added in a later version of the I-D.

On the proposed addition to the = charter text, I am unclear on the intent. Is it to document possible = breakages, or is the intent to prescribe middlebox behavior? =

The intent = is to change QUIC, as necessary, and to change network devices, as = necessary, so that QUIC can be successfully deployed on more = networks.

I'm= not sure how useful the former can be, and I think the latter is a = pretty significant effort (and central to PLUS, I believe.) I don't = think the proposed addition to the charter text is = appropriate. 

FWIW, I agree that work in PLUS should inform work in QUIC. = I'd like to suggest that, for purely pragmatic reasons, we wait for PLUS = to do its work and for QUIC to do its work before incorporating PLUS's = lessons into QUIC. Mixing these two at this early stage, when scoping as = tightly as reasonably possible is critical, does not seem advisable. = This may not be what you're suggesting at all, so we may already be on = the same page.

Correct -- it's not what I am suggesting at = all.  The document and charter pull request are for QUIC, not = PLUS.

-d


- = jana


On Tue, = Jun 14, 2016 at 1:08 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:

On 6/14/16, 1:48 PM, "Ted Hardie" <ted.ietf@gmail.com> = wrote:

>On Tue, Jun 14, 2016 at 12:23 PM, Joe Hildebrand (jhildebr)
><j <mailto:jhildebr@cisco.com>
>
>Please read the draft.  I hope we're not suggesting particular = design approaches.

(note: I apologize for assuming that someone didn't read the = draft.  That was unkind and unnecessary.)

>That comes across as a little odd, honestly, because there are = design approaches already in QUIC for much of what you're looking for = (e.g. the visible connection-ID).  That makes it appear that you're = suggesting changes, when you don't aver you don't intend
> to..

It appeared to me as if the connection ID might change over the = course of a connection, or be elided in packets later in the flow.  = If that isn't the case, QUIC already meets this requirement.

>I kind of suspect that this would work as  a "Requirements for = UDP-based protocols desiring to provide TCP-like visibility to the = path", with a later checklist by QUIC to show how they're met (or if = they're not met, and why).

That's a valid approach, and I'll likely be presenting this in = the PLUS BoF to that effect

>So, there is more than one type of crypto that may be at play = here:  encryption to make confidential and encryption to make = tampering evident.

Agree.  I can't imagine much other than the address/port = 4-tuple being outside the tamper-evident seal (because of NAT and = PAT).  There may be some cases for scratch space, but I suspect we = would need a really important use case before we got consensus on such a = thing.

>I think you're using ossify in an odd way here.  I normally use = it when something flexible has become rigid.  Exposing = connection-id, as QUIC does, doesn't ossify connection-id.  = Middlebox vendors who fire-and-forget may understand that version and = never
> update, but that's not triggered by exposure so much as update = cycle issue (some of which are so bad that merely exposing connection-id = and QUIC won't trigger an update at all; those will never see the = traffic as QUIC).

In particular, I meant the version numbers here.  In absence = of some more thought, I would expect middlebox vendors to use a = particular version number to try to classify traffic as "this is QUIC", = which would be a horrible outcome for everyone.

>In the long term, I want to see PLUS in this space and hope that it = gives us the flexibility we need to go forward.  Absent that, I = appreciate your taking the time to express what middleboxes want to see = on the apth.  But I do want us to be careful not
> to either try to slam the two efforts together nor to make = UDP-based protocols mimic TCP-based ones exactly.  They will vary, = for large values of "they".

I think a potential PLUS working group would be a useful way to = explore both the requirements and a nicely-layered protocol.  = Absent a charter-level commitment that a potential QUIC working group = would use the output of that work (which I'm *not* arguing for), having = a small addition to the charter to ensure that we discuss what kinds of = path breakage QUIC is explicitly signing up for seems like a relatively = small ask.

--
Joe Hildebrand


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



= --Apple-Mail=_15AA79FA-90A6-4BD5-BDF2-A69F14F5AB58-- From nobody Wed Jun 15 18:41:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A799912D82B for ; Wed, 15 Jun 2016 18:41:13 -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 rj3nNSHlp07N for ; Wed, 15 Jun 2016 18:41:11 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD0212D594 for ; Wed, 15 Jun 2016 18:41:11 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id g20so30450193ywb.0 for ; Wed, 15 Jun 2016 18:41:11 -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=uzmxQF/liqtSx9xp4VjjkJKjVv7u2fWAVYc3Fr8a3UI=; b=JXFerED8prpktnKhwCHJFFtuYupAbS/Tp6B8DF/q+qsQlz/k0empoYXYd+tiK5t/RC GUbvd5UWS4k3Ya8vz6rDB38VsDaEZrYxOvhfluTTDcBlKuyZfS4w/ozlBJwdYQh1ktpL UKy6p5dnasukcgeETFVVRusF2VB8JfpQrgEOeTPpckBMC0vf8T4qQDjG7RNJX6cDbwFc VfAWXwMbvsvYxufaDI+/AqkN/ILHVu/6mwuKaev2rRypLHUINLOWbPeyM5qzT5CaF8sw 7Nkyy8RGju3vuCwja2cm7M0iusb+5gGZ74p+LohgahBGLhnZ16ivOPVcqKPdGE02rHhs 49ow== 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=uzmxQF/liqtSx9xp4VjjkJKjVv7u2fWAVYc3Fr8a3UI=; b=k5aljhfctfHpi8HpFZFolvmscBfpawTMF9Cc4EYjHmeBmGKvEVAHPGIy3bpCSqCQVR fS6jX0N8UGKPJiD3xCvDujdB78o+KBhvAagM8FkuVbOTt5t73L1IUYCr7XGYYpHTrG+u E99G+RzmMZ3H6OeU8AGBbkUCABu54K76bTbiH6zuvXFPNurBvH2HhhtG04VU8mU09Xnt Zpf7q8bXIu/J76aC+9N9H1V1dawsfVZnOjqLkaoQIdk/wCWR3RY9H13+Xd/jhT4sTaBW 7FUrux4AbNdNGHM3r1AWusC7s8X5quLtmTLOheFNnNx+xCHJwAA4r5pFQ9pW/cRSd3DY tCAg== X-Gm-Message-State: ALyK8tIJJ2KkAX+7EpIL9LcwYv3ngEUe7RSLrqN/T6RRj6ZNS2IPANyJlR1nOOCDLG1atV0YMwwvkhp3dCfjdAsY X-Received: by 10.37.33.197 with SMTP id h188mr1114440ybh.165.1466041270659; Wed, 15 Jun 2016 18:41:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.224.136 with HTTP; Wed, 15 Jun 2016 18:41:09 -0700 (PDT) In-Reply-To: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> From: Jana Iyengar Date: Wed, 15 Jun 2016 18:41:09 -0700 Message-ID: To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=001a114388d82a68bd05355b55af Archived-At: Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , Joe Hildebrand Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 01:41:14 -0000 --001a114388d82a68bd05355b55af Content-Type: text/plain; charset=UTF-8 Hi Dan, > draft-wing-quic-network-req tries to up-level its recommendations by > saying 'we need consent' rather than suggesting how to achieve it. Consent > could be achieved in probably 3 or 4 different ways, and we need a > technique that works with multicast QUIC and with persistent QUIC > connections. It's up to WG to agree consent is > necessary, then to agree how to accomplish consent. We have identified > other things that impact the network and need discussion in the working > group (some small, some larger): Should the network clear its state > immediately after QUIC public reset, set timer, wait for a little while. > Is the network's sole identification the QUIC version in the > client-initiated connection, and can we avoid the network treating that > specially (which will be good and bad, I am remembering network treatment > of IKE's UDP 500 and 4500). If QUIC endpoint sends or receives many bogus > QUIC packets, how can network help stop or rate limit those, to defend the > links and defend other hosts on that network. If path drops state due to > a timeout (or crash, or software update, or whatever), how should the > endpoints learn and how should they react. Those previous things are > discussed in the I-D. In addition, QUIC complicates network diagnostics > and measurements, as well, which will be added in a later version of the > I-D. > I understand what the draft describes, and as I said, I think this is useful when the wg is discussing what is visible in the QUIC header and what isn't. The wg can decide whether to care about a particular middlebox function or not. That said, I think this may be one of our core disagreements: absent agreement on what middlebox functions are essential, it's hard to argue how QUIC should solve for them. We saw a very similar conversation play out in MPTCP. There were many questions about how legacy middleboxes would treat MPTCP options and modifications to TCP header bits. The problem was that there were too many boogeymen middleboxes out there, and it was usually anybody's guess how important any one particular behavior was. There was small-scale measurement work done that helped direct the conversation, but this is tricky territory -- tricky largely because of the lack of substantial data about particular middlebox behaviors and their prevalence and importance. In terms of how these apply to QUIC, we have data from the current deployment of QUIC, and that can hopefully be brought to bear on the decisions in the working group. Beyond that, I think it's all thin ice. We can certainly try and get consensus on specific middlebox behaviors as important, but that conversation is more general than just QUIC, and since your draft is precisely such a list, I'd argue that it probably belongs in PLUS, TSVAREA/TSVWG, or INTAREA. > On the proposed addition to the charter text, I am unclear on the intent. > Is it to document possible breakages, or is the intent to prescribe > middlebox behavior? > > > The intent is to change QUIC, as necessary, and to change network devices, > as necessary, so that QUIC can be successfully deployed on more networks. > That QUIC needs to work around middleboxes is already stated in the charter as "Enabling deployment over unmodified Internet paths". If legacy middleboxes exist on path, this goal has them covered. On changing network devices, this may be our other core disagreement. The charter is proposing to work on QUIC, and not to modify network devices, again because of what I said above. I think that a generalized form of this draft is more relevant in a broader forum (as noted earlier), and once the requirements are made clear, surely the QUIC wg can work on figuring out how to solve for them in QUIC. - jana --001a114388d82a68bd05355b55af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan,
=C2=A0
draft-wing-quic-network-req tries to up-level its recommendati= ons by saying 'we need consent' rather than suggesting how to achie= ve it.=C2=A0 Consent could be achieved in probably 3 or 4 different ways, a= nd we need a technique that works with multicast QUIC and with persistent Q= UIC connections.=C2=A0 It's up to WG to agree consent is
=
necessary, then to agree how to accomplish consent.=C2=A0 We have iden= tified other things that impact the network and need discussion in the work= ing group (some small, some larger): =C2=A0Should the network clear its sta= te immediately after QUIC public reset, set timer, wait for a little while.= =C2=A0 Is the network's sole identification the QUIC version in the cli= ent-initiated connection, and can we avoid the network treating that specia= lly (which will be good and bad, I am remembering network treatment of =C2= =A0IKE's UDP 500 and 4500).=C2=A0 If QUIC endpoint sends or receives ma= ny bogus QUIC packets, how can network help stop or rate limit those, to de= fend the links and defend other hosts on that network.=C2=A0 If=C2=A0path drops state due to a timeout (or c= rash, or software update, or whatever), how should the endpoints learn and = how should they react.=C2=A0 Those previous things are discussed in the I-D= .=C2=A0 In addition, QUIC complicates network diagnostics and measurements,= as well, which will be added in a later version of the I-D.

I understand what the draft desc= ribes, and as I said, I think this is useful when the wg is discussing what= is visible in the QUIC header and what isn't. The wg can decide whethe= r to care about a particular middlebox function or not.

That said, I think this may be one of our core disagreements: absent = agreement on what middlebox functions are essential, it's hard to argue= how QUIC should solve for them. We saw a very similar conversation play ou= t in MPTCP. There were many questions about how legacy middleboxes would tr= eat MPTCP options and modifications to TCP header bits. The problem was tha= t there were too many boogeymen middleboxes out there, and it was usually a= nybody's guess how important any one particular behavior was. There was= small-scale measurement work done that helped direct the conversation, but= this is tricky territory -- tricky largely because of the lack of substant= ial data about particular middlebox behaviors and their prevalence and impo= rtance.

In terms of how these apply to QUIC, = we have data from the current deployment of QUIC, and that can hopefully be= brought to bear on the decisions in the working group. Beyond that, I thin= k it's all thin ice. We can certainly try and get consensus on specific= middlebox behaviors as important, but that conversation is more general th= an just QUIC, and since your draft is precisely such a list, I'd argue = that it probably belongs in PLUS, TSVAREA/TSVWG, or INTAREA.
On the proposed add= ition to the charter text, I am unclear on the intent. Is it to document po= ssible breakages, or is the intent to prescribe middlebox behavior?
<= /div>

The intent is to change = QUIC, as necessary, and to change network devices, as necessary, so that QU= IC can be successfully deployed on more networks.

That QUIC needs to work around middleboxes is alre= ady stated in the charter as "Enabling deployment over unmodified Inte= rnet paths". If legacy middleboxes exist on path, this goal has them c= overed.=C2=A0

On changing network devices, this ma= y be our other core disagreement. The charter is proposing to work on QUIC,= and not to modify network devices, again because of what I said above. I t= hink that a generalized form of this draft is more relevant in a broader fo= rum (as noted earlier), and once the requirements are made clear, surely th= e QUIC wg can work on figuring out how to solve for them in QUIC.

- jana


--001a114388d82a68bd05355b55af-- From nobody Thu Jun 16 02:13:45 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A606412B042; Thu, 16 Jun 2016 02:13:39 -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 aid5LXFS1bK7; Thu, 16 Jun 2016 02:13:32 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2B612B008; Thu, 16 Jun 2016 02:13:29 -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 47EED1A056B; Thu, 16 Jun 2016 11:12:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 16 Jun 2016 11:12:56 +0200 Message-Id: <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ted Hardie , =?utf-8?Q?=F0=9F=94=93Dan_Wing?= , Joe Hildebrand , spud , Christian Huitema , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 09:13:39 -0000 --Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, all, (adding spud@ietf.org) On one point, below: > On 16 Jun 2016, at 03:41, Jana Iyengar wrote: >=20 > Hi Dan, >=20 >> draft-wing-quic-network-req tries to up-level its recommendations by = saying 'we need consent' rather than suggesting how to achieve it. = Consent could be achieved in probably 3 or 4 different ways, and we need = a technique that works with multicast QUIC and with persistent QUIC = connections. It's up to WG to agree consent is >> necessary, then to agree how to accomplish consent. We have = identified other things that impact the network and need discussion in = the working group (some small, some larger): Should the network clear = its state immediately after QUIC public reset, set timer, wait for a = little while. Is the network's sole identification the QUIC version in = the client-initiated connection, and can we avoid the network treating = that specially (which will be good and bad, I am remembering network = treatment of IKE's UDP 500 and 4500). If QUIC endpoint sends or = receives many bogus QUIC packets, how can network help stop or rate = limit those, to defend the links and defend other hosts on that network. = If path drops state due to a timeout (or crash, or software update, or = whatever), how should the endpoints learn and how should they react. = Those previous things are discussed in the I-D. In addition, QUIC = complicates network diagnostics and measurements, as well, which will be = added in a later version of the I-D. >=20 > I understand what the draft describes, and as I said, I think this is = useful when the wg is discussing what is visible in the QUIC header and = what isn't. The wg can decide whether to care about a particular = middlebox function or not. >=20 > That said, I think this may be one of our core disagreements: absent = agreement on what middlebox functions are essential, it's hard to argue = how QUIC should solve for them. We saw a very similar conversation play = out in MPTCP. There were many questions about how legacy middleboxes = would treat MPTCP options and modifications to TCP header bits. The = problem was that there were too many boogeymen middleboxes out there, = and it was usually anybody's guess how important any one particular = behavior was. There was small-scale measurement work done that helped = direct the conversation, but this is tricky territory -- tricky largely = because of the lack of substantial data about particular middlebox = behaviors and their prevalence and importance. >=20 > In terms of how these apply to QUIC, we have data from the current = deployment of QUIC, and that can hopefully be brought to bear on the = decisions in the working group. Beyond that, I think it's all thin ice. = We can certainly try and get consensus on specific middlebox behaviors = as important, but that conversation is more general than just QUIC, and = since your draft is precisely such a list, I'd argue that it probably = belongs in PLUS, TSVAREA/TSVWG, or INTAREA. PLUS BoF proponent hat on: I think there is a point here that might make = sense to add to the PLUS draft charter that would naturally feed into = QUIC: - Define a view of "essential middlebox functions", and a description of = the information from endpoints required to drive them. As you say, part of the problem is there is no agreement on either of = these questions. A focused discussion here could hopefully come to some = consensus. QUIC isn't really the place for this IMO, since the answer is = bigger than one instance of a new protocol over UDP. I'm not sure a = general INTAREA/TSVAREA activity would have the right focus, and I'm not = sure it's really in scope for TSVWG. draft-wing-quic-network-req looks to me (slightly rearranged and with = the QUIC-specific language stripped out) as a candidate document for = this work item. It's alsouseful input to the engineering work on a = universal shim protocol we intend to do in PLUS. (And as a bonus, if = both QUIC and PLUS are working from a common, defined view of what sort = of functions are essential, future integration between them won't be = complicated by differing architectural views). Cheers, Brian --Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D 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 iQIcBAEBCgAGBQJXYm2ZAAoJEIoSt78L6kajRNoP/j79ts/kO8/qOIjr9xpVbKwA lk27WXkd0wPVagddcQqeOPxndJj4q6DuEmFVzYDseMNiEDtRvO9qnQS5oLlMGmkf 5x5YGLNKoUIrdUWFsNw8iAF6qsDvnRR8jBt+UB+qN41Ru6NQDdzoyyW2YJxfQCcV DAqrQIaZk0JWs8sRyBTuYYExoBBcSukVI9TUVH02nbEZCNpESGpZOGx2ufIvqAm2 pKLlA5/F6KdgcPVrozLPiU+gUYL4VXTs6uV1R2r2evSHwOBgo43uqzbrJlC7N98I Wz5zceIp2tnhrGBvdI2LMx9lGCVv0+It+glaJyPud0zEAr8OQ27al9WMMrYbBTlP lvzAmx1rrPtvXIkfL57fj/2AuIH7TiCi5VgZZGjRgSrGiKUOB/ScexY830mmEsEK qtSyCYC8FZKMaIuULCP2n1TUuyI8ZhzvWWYBVF9f2AdyrE8B7DHp8Zmf9Evw2aQ9 o8lLcwl0dzyaD+/VN47LekkQb+opEbJJtzVfRWupIRJg4lCBwf8ld6E/9/hftlUT W0pkksOnDT3j1UXr93BdlYYPIpN1RkCJjyHcoM073lnevDuThoOZ5ddM1WlCVLud rgqpZv4B4p/IpBo0dZDl8/Fr+xLFJfPnjZ7/46uPQ49ICYoXU37+5l+c+a+2cGYQ s+1qIwfiAHP64MvmSLLA =VrAW -----END PGP SIGNATURE----- --Apple-Mail=_F6BBC019-2440-49E6-859E-E9FEE99F7F7D-- From nobody Thu Jun 16 05:58:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A2112D5F0 for ; Thu, 16 Jun 2016 05:58:29 -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 ebBRHTKapjC3 for ; Thu, 16 Jun 2016 05:58:28 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1634712D576 for ; Thu, 16 Jun 2016 05:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11057; q=dns/txt; s=iport; t=1466081908; x=1467291508; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=5BmflleO/pXax0bwUvVhxUmiTHI7S9TZw9eHebwSJsQ=; b=ix+iFiuqqFoDkIyZGuRGs9fXIv+PkHYSXc6HvNgkj2n1kFASMv8h8OPi X4Xe/GD5HSusRCoAMJftTfGG6Y+l/6cvGtqnanVcTqXUv0EeOXwcvvIbP uErYLqs08WvS65pA7qAgGqf5vIxeX/cLrouw37MZuE8WPT2ofuI0wOczQ M=; X-IronPort-AV: E=Sophos;i="5.26,480,1459814400"; d="scan'208,217";a="285708775" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 12:58:27 +0000 Received: from [10.24.91.230] ([10.24.91.230]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5GCwPSY013675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2016 12:58:26 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_4040681A-0528-4543-B397-7DC9563839F5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Thu, 16 Jun 2016 06:58:25 -0600 Message-Id: <492CE699-E2A4-4923-A51B-B341DB581889@cisco.com> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) X-Authenticated-User: dwing Archived-At: Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , Joe Hildebrand Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:58:30 -0000 --Apple-Mail=_4040681A-0528-4543-B397-7DC9563839F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15-Jun-2016 07:41 pm, Jana Iyengar wrote:=20 > Hi Dan, > =20 > draft-wing-quic-network-req tries to up-level its recommendations by = saying 'we need consent' rather than suggesting how to achieve it. = Consent could be achieved in probably 3 or 4 different ways, and we need = a technique that works with multicast QUIC and with persistent QUIC = connections. It's up to WG to agree consent is > necessary, then to agree how to accomplish consent. We have = identified other things that impact the network and need discussion in = the working group (some small, some larger): Should the network clear = its state immediately after QUIC public reset, set timer, wait for a = little while. Is the network's sole identification the QUIC version in = the client-initiated connection, and can we avoid the network treating = that specially (which will be good and bad, I am remembering network = treatment of IKE's UDP 500 and 4500). If QUIC endpoint sends or = receives many bogus QUIC packets, how can network help stop or rate = limit those, to defend the links and defend other hosts on that network. = If path drops state due to a timeout (or crash, or software update, or = whatever), how should the endpoints learn and how should they react. = Those previous things are discussed in the I-D. In addition, QUIC = complicates network diagnostics and measurements, as well, which will be = added in a later version of the I-D. >=20 > I understand what the draft describes, and as I said, I think this is = useful when the wg is discussing what is visible in the QUIC header and = what isn't. The wg can decide whether to care about a particular = middlebox function or not. The document does not discuss just middleboxes. -d > That said, I think this may be one of our core disagreements: absent = agreement on what middlebox functions are essential, it's hard to argue = how QUIC should solve for them. We saw a very similar conversation play = out in MPTCP. There were many questions about how legacy middleboxes = would treat MPTCP options and modifications to TCP header bits. The = problem was that there were too many boogeymen middleboxes out there, = and it was usually anybody's guess how important any one particular = behavior was. There was small-scale measurement work done that helped = direct the conversation, but this is tricky territory -- tricky largely = because of the lack of substantial data about particular middlebox = behaviors and their prevalence and importance. >=20 > In terms of how these apply to QUIC, we have data from the current = deployment of QUIC, and that can hopefully be brought to bear on the = decisions in the working group. Beyond that, I think it's all thin ice. = We can certainly try and get consensus on specific middlebox behaviors = as important, but that conversation is more general than just QUIC, and = since your draft is precisely such a list, I'd argue that it probably = belongs in PLUS, TSVAREA/TSVWG, or INTAREA. >> On the proposed addition to the charter text, I am unclear on the = intent. Is it to document possible breakages, or is the intent to = prescribe middlebox behavior? >=20 > The intent is to change QUIC, as necessary, and to change network = devices, as necessary, so that QUIC can be successfully deployed on more = networks. >=20 > That QUIC needs to work around middleboxes is already stated in the = charter as "Enabling deployment over unmodified Internet paths". If = legacy middleboxes exist on path, this goal has them covered.=20 >=20 > On changing network devices, this may be our other core disagreement. = The charter is proposing to work on QUIC, and not to modify network = devices, again because of what I said above. I think that a generalized = form of this draft is more relevant in a broader forum (as noted = earlier), and once the requirements are made clear, surely the QUIC wg = can work on figuring out how to solve for them in QUIC. >=20 > - jana >=20 >=20 --Apple-Mail=_4040681A-0528-4543-B397-7DC9563839F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 15-Jun-2016 07:41 pm, Jana Iyengar <jri@google.com> wrote: =
Hi Dan,
 
draft-wing-quic-network-req = tries to up-level its recommendations by saying 'we need consent' rather = than suggesting how to achieve it.  Consent could be achieved in = probably 3 or 4 different ways, and we need a technique that works with = multicast QUIC and with persistent QUIC connections.  It's up to WG = to agree consent is
necessary, then to agree how = to accomplish consent.  We have identified other things that impact = the network and need discussion in the working group (some small, some = larger):  Should the network clear its state immediately after QUIC = public reset, set timer, wait for a little while.  Is the network's = sole identification the QUIC version in the client-initiated connection, = and can we avoid the network treating that specially (which will be good = and bad, I am remembering network treatment of  IKE's UDP 500 and = 4500).  If QUIC endpoint sends or receives many bogus QUIC packets, = how can network help stop or rate limit those, to defend the links and = defend other hosts on that network.  If path drops state due to a = timeout (or crash, or software update, or whatever), how should the = endpoints learn and how should they react.  Those previous things = are discussed in the I-D.  In addition, QUIC complicates network = diagnostics and measurements, as well, which will be added in a later = version of the I-D.

I understand what the = draft describes, and as I said, I think this is useful when the wg is = discussing what is visible in the QUIC header and what isn't. The wg can = decide whether to care about a particular middlebox function or = not.

The document does not discuss just = middleboxes.

-d

That said, I think this may be one = of our core disagreements: absent agreement on what middlebox functions = are essential, it's hard to argue how QUIC should solve for them. We saw = a very similar conversation play out in MPTCP. There were many questions = about how legacy middleboxes would treat MPTCP options and modifications = to TCP header bits. The problem was that there were too many boogeymen = middleboxes out there, and it was usually anybody's guess how important = any one particular behavior was. There was small-scale measurement work = done that helped direct the conversation, but this is tricky territory = -- tricky largely because of the lack of substantial data about = particular middlebox behaviors and their prevalence and = importance.

In terms of how these apply to QUIC, we have data from the = current deployment of QUIC, and that can hopefully be brought to bear on = the decisions in the working group. Beyond that, I think it's all thin = ice. We can certainly try and get consensus on specific middlebox = behaviors as important, but that conversation is more general than just = QUIC, and since your draft is precisely such a list, I'd argue that it = probably belongs in PLUS, TSVAREA/TSVWG, or = INTAREA.
On the proposed addition to the charter text, I am unclear on = the intent. Is it to document possible breakages, or is the intent to = prescribe middlebox behavior?

The intent is to = change QUIC, as necessary, and to change network devices, as necessary, = so that QUIC can be successfully deployed on more = networks.

That QUIC needs to work around = middleboxes is already stated in the charter as "Enabling deployment = over unmodified Internet paths". If legacy middleboxes exist on path, = this goal has them covered. 

On changing network devices, this may = be our other core disagreement. The charter is proposing to work on = QUIC, and not to modify network devices, again because of what I said = above. I think that a generalized form of this draft is more relevant in = a broader forum (as noted earlier), and once the requirements are made = clear, surely the QUIC wg can work on figuring out how to solve for them = in QUIC.

- = jana




= --Apple-Mail=_4040681A-0528-4543-B397-7DC9563839F5-- From nobody Thu Jun 16 07:03:11 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E4912D0CE for ; Thu, 16 Jun 2016 07:03:09 -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 8ejsi67KVAkQ for ; Thu, 16 Jun 2016 07:03:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217A012B04A for ; Thu, 16 Jun 2016 07:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6618; q=dns/txt; s=iport; t=1466085788; x=1467295388; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fi6CE9eV1obUQVZyxC9AgTiq8U3ZyVM9UMxJF1XECZw=; b=IaOCV16ScRrnGzptyicEeh05SBjXrOavVv4V1awSYUpbRI/jAl9bt9tw xHIvSDW+ny6rZZ7YnXc4viAyrKlbQCdpm8suFWasEGBR+669a8zIMl3RS KJRQfAfRpLDkurKZ4Q0iOBe3j3hAMoSc8BUtyrOk9oQmPTXauY818m+pR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQB/sGJX/4gNJK1egz6BUwa4RoIPg?= =?us-ascii?q?XqGFwIcgQs4FAEBAQEBAQFlHAuETAEBBCMRMSQCAQgaAiYCAgIwFRACBBOIMK8?= =?us-ascii?q?pkGEBAQEBAQEBAQEBAQEBAQEBIYEBhSaBd4FTgQOHQSuCLwWYcQGIfIUsjyKPd?= =?us-ascii?q?AEeNoIIHIFMbokFfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,480,1459814400"; d="scan'208";a="119363088" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2016 14:03:07 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5GE363p018039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Jun 2016 14:03:07 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 16 Jun 2016 10:03:05 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 16 Jun 2016 10:03:05 -0400 From: "Joe Hildebrand (jhildebr)" To: "quic@ietf.org" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmdrA4n/SZAVekigMWYxC+73GZ/pJkIAgABsYID//6NcgIAAa8MA//+g6wCAAROkgIAA+uwAgABFU4CAAGq4gA== Date: Thu, 16 Jun 2016 14:03:05 +0000 Message-ID: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.21] Content-Type: text/plain; charset="utf-8" Content-ID: <0249F3B0426614419A3FA68061A429F3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:03:09 -0000 T24gNi8xNS8xNiwgNzo0MSBQTSwgIkphbmEgSXllbmdhciIgPGpyaUBnb29nbGUuY29tPiB3cm90 ZToNCg0KPkkgdW5kZXJzdGFuZCB3aGF0IHRoZSBkcmFmdCBkZXNjcmliZXMsIGFuZCBhcyBJIHNh aWQsIEkgdGhpbmsgdGhpcyBpcyB1c2VmdWwgd2hlbiB0aGUgd2cgaXMgZGlzY3Vzc2luZyB3aGF0 IGlzIHZpc2libGUgaW4gdGhlIFFVSUMgaGVhZGVyIGFuZCB3aGF0IGlzbid0LiBUaGUgd2cgY2Fu IGRlY2lkZSB3aGV0aGVyIHRvIGNhcmUgYWJvdXQgYSBwYXJ0aWN1bGFyIG1pZGRsZWJveCBmdW5j dGlvbiBvciBub3QuDQoNCkdyZWF0LiAgTGV0J3MgZ2V0IGEgbGl0dGxlIGJpdCBvZiBjaGFydGVy IHRleHQgYWRkZWQgdGhhdCBzYXlzIHRoYXQsIHRoZW4uICBJdCBtYXkgYmUgdGhhdCB0aGUgdGV4 dCBJIHByb3Bvc2VkIGRpZG4ndCBjYXB0dXJlIHRoYXQgbnVhbmNlIGFkZXF1YXRlbHkuDQoNCj5U aGF0IHNhaWQsIEkgdGhpbmsgdGhpcyBtYXkgYmUgb25lIG9mIG91ciBjb3JlIGRpc2FncmVlbWVu dHM6IGFic2VudCBhZ3JlZW1lbnQgb24gd2hhdCBtaWRkbGVib3ggZnVuY3Rpb25zIGFyZSBlc3Nl bnRpYWwsIGl0J3MgaGFyZCB0byBhcmd1ZSBob3cgUVVJQyBzaG91bGQgc29sdmUgZm9yIHRoZW0u IFdlIHNhdyBhIHZlcnkgc2ltaWxhciBjb252ZXJzYXRpb24gcGxheSBvdXQgaW4gTVBUQ1AuIFRo ZXJlIHdlcmUgbWFueSBxdWVzdGlvbnMNCj4gYWJvdXQgaG93IGxlZ2FjeSBtaWRkbGVib3hlcyB3 b3VsZCB0cmVhdCBNUFRDUCBvcHRpb25zIGFuZCBtb2RpZmljYXRpb25zIHRvIFRDUCBoZWFkZXIg Yml0cy4gVGhlIHByb2JsZW0gd2FzIHRoYXQgdGhlcmUgd2VyZSB0b28gbWFueSBib29nZXltZW4g bWlkZGxlYm94ZXMgb3V0IHRoZXJlLCBhbmQgaXQgd2FzIHVzdWFsbHkgYW55Ym9keSdzIGd1ZXNz IGhvdyBpbXBvcnRhbnQgYW55IG9uZSBwYXJ0aWN1bGFyIGJlaGF2aW9yIHdhcy4gVGhlcmUgd2Fz DQo+IHNtYWxsLXNjYWxlIG1lYXN1cmVtZW50IHdvcmsgZG9uZSB0aGF0IGhlbHBlZCBkaXJlY3Qg dGhlIGNvbnZlcnNhdGlvbiwgYnV0IHRoaXMgaXMgdHJpY2t5IHRlcnJpdG9yeSAtLSB0cmlja3kg bGFyZ2VseSBiZWNhdXNlIG9mIHRoZSBsYWNrIG9mIHN1YnN0YW50aWFsIGRhdGEgYWJvdXQgcGFy dGljdWxhciBtaWRkbGVib3ggYmVoYXZpb3JzIGFuZCB0aGVpciBwcmV2YWxlbmNlIGFuZCBpbXBv cnRhbmNlLg0KDQpXZSdyZSBub3QgdGFsa2luZyBhYm91dCBib29nZXltYW4gbWlkZGxlYm94ZXMg aGVyZS4gIFRoZXJlIGlzIG5vIG1lYXN1cmVtZW50IG5lZWRlZCwgYW5kIG5vIHRlc3RpbmcuDQoN CldlJ3JlIHRhbGtpbmcgYWJvdXQgZmlyZXdhbGxzIHRoYXQgY3VycmVudGx5IGJsb2NrIFVEUCwg c3VjaCBhcyB0aGUgb25lIEknbSBnb2luZyB0aHJvdWdoIHJpZ2h0IG5vdy4gIEkgd291bGQgbGlr ZSB0byBhZGQgZXhwbGljaXQgUVVJQyBzdXBwb3J0IHRvIHRoYXQgYm94IHNvIHRoYXQgd2UgY2Fu IGdldCB0aGUgYmVuZWZpdHMgb2YgUVVJQyBkZXBsb3ltZW50LiAgSSB3b3VsZCBsaWtlIGFueSB3 b3JraW5nIGdyb3VwIHdlIGZvcm0gdG8gZG8gbmV3IHRyYW5zcG9ydCBwcm90b2NvbHMgdG8gaGF2 ZSBpbiBzY29wZSBob3cgdGhhdCBuZXcgdHJhbnNwb3J0IGRlcGxveXMsIGFuZCBmaXJld2FsbCB0 cmF2ZXJzYWwgaXMgYSBrZXkgcmVhbC13b3JsZCBkZXBsb3ltZW50IG1lY2hhbmlzbS4NCg0KSSB3 b3VsZCBiZSBoYXBweSB3aXRoIGRpZmZlcmVudCBjaGFydGVyIGxhbmd1YWdlIHRoYXQgYWxsb3dz IGEgcG90ZW50aWFsIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgYWRkaW5nIGxhbmd1YWdlIHRo YXQgdGVsbHMgZmlyZXdhbGxzIGFuZCBsb2FkIGJhbGFuY2VycyB3aGF0IHRvIGRvIHdpdGggdGhl IGJpdHMgdGhhdCBhcmUgZXhwb3NlZCwgaW4gb3JkZXIgdG8gbWF4aW1pemUgdXNlciBleHBlcmll bmNlLCBhbmQgYWxsb3cgZmlyZXdhbGxzIGFuZCBsb2FkIGJhbGFuY2VycyB0byBkbyB0aGUgYmVz dCB0aGV5IGNhbiB0byBwcm90ZWN0IHRoZSBhcHBsaWNhdGlvbnMsIGhvc3RzLCBhbmQgbmV0d29y a3Mgb24gd2hvc2UgYmVoYWxmIHRoZXkgYXJlIGRlcGxveWVkLiAgSSB3b3VsZCBsaWtlIGEgcG90 ZW50aWFsIHdvcmtpbmcgZ3JvdXAgdG8gYmUgYWJsZSB0byBkaXNjdXNzIHdoYXQgaGFwcGVucyB3 aGVuIHNpZ25hbHMgZnJvbSB0aGUgbmV0d29yayBwYXRoIHN1Y2ggYXMgSUNNUCBhcmUgcmVjZWl2 ZWQsIGFzIHdlbGwgYXMgd2hlbiB0aGV5IHNob3VsZCBiZSBzZW50LiAgVGhhdCBtaWdodCBtZWFu IHNvbWUgY2hhbmdlcyB0byB0aGUgcHJvdG9jb2wsIGJ1dCBob3BlZnVsbHkgbW9zdCBvZiBpdCBp cyBqdXN0IHdyaXRpbmcgZG93biBzb21lIG9mIHRoZSBhc3N1bXB0aW9ucyB0aGF0IHBlb3BsZSB3 aXRoIG1vcmUgUVVJQyBpbnR1aXRpb24gaGF2ZSBhYm91dCB3aGF0IGZpcmV3YWxscyBhbmQgbG9h ZCBiYWxhbmNlcnMgYXJlIGdvaW5nIHRvIGRvIHdpdGggdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMg YWxyZWFkeSBleHBvc2VkIHRvIHRoZSBwYXRoLg0KDQpJIGFncmVlIHRoYXQgYW55IG1vcmUgaW50 ZXJlc3RpbmcgcGF0aCBpbnRlcmFjdGlvbnMsIHRvIHRoZSBleHRlbnQgdGhhdCB0aGV5IG1pZ2h0 IGJlIGludGVyZXN0aW5nLCBhcmUgbW9yZSBpbiB0aGUgcmVhbG0gb2YgUExVUy4NCg0KPkluIHRl cm1zIG9mIGhvdyB0aGVzZSBhcHBseSB0byBRVUlDLCB3ZSBoYXZlIGRhdGEgZnJvbSB0aGUgY3Vy cmVudCBkZXBsb3ltZW50IG9mIFFVSUMsIGFuZCB0aGF0IGNhbiBob3BlZnVsbHkgYmUgYnJvdWdo dCB0byBiZWFyIG9uIHRoZSBkZWNpc2lvbnMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuIEJleW9uZCB0 aGF0LCBJIHRoaW5rIGl0J3MgYWxsIHRoaW4gaWNlLiBXZSBjYW4gY2VydGFpbmx5IHRyeSBhbmQg Z2V0IGNvbnNlbnN1cyBvbiBzcGVjaWZpYw0KPiBtaWRkbGVib3ggYmVoYXZpb3JzIGFzIGltcG9y dGFudCwgYnV0IHRoYXQgY29udmVyc2F0aW9uIGlzIG1vcmUgZ2VuZXJhbCB0aGFuIGp1c3QgUVVJ QywgYW5kIHNpbmNlIHlvdXIgZHJhZnQgaXMgcHJlY2lzZWx5IHN1Y2ggYSBsaXN0LCBJJ2QgYXJn dWUgdGhhdCBpdCBwcm9iYWJseSBiZWxvbmdzIGluIFBMVVMsIFRTVkFSRUEvVFNWV0csIG9yIElO VEFSRUEuDQoNCkknbSBmaW5lIHdpdGggd29ya2luZyBvbiBhIGdlbmVyaWMgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgaW4gUExVUyBvciBUU1ZXRy4gIEkgYW0gbm90IGZpbmUgd2l0aCBhbnkgZGlzY3Vz c2lvbiBvZiBob3cgdGhhdCBkcmFmdCBhcHBsaWVzIHRvIFFVSUMgYmVpbmcgcnVsZWQgb3V0IG9m IGNoYXJ0ZXIgYnkgYSBwb3RlbnRpYWwgUVVJQyB3b3JraW5nIGdyb3VwLiAgSSBiZWxpZXZlIHdl IG5lZWQgc29tZSBjaGFydGVyIHRleHQgdG8gcHJvdGVjdCB0aGF0IGNvbnZlcnNhdGlvbi4NCg0K Pk9uIHRoZSBwcm9wb3NlZCBhZGRpdGlvbiB0byB0aGUgY2hhcnRlciB0ZXh0LCBJIGFtIHVuY2xl YXIgb24gdGhlIGludGVudC4gSXMgaXQgdG8gZG9jdW1lbnQgcG9zc2libGUgYnJlYWthZ2VzLCBv ciBpcyB0aGUgaW50ZW50IHRvIHByZXNjcmliZSBtaWRkbGVib3ggYmVoYXZpb3I/DQoNClRoZSBp bnRlbnQgaXMgdG8gZGVzY3JpYmUgaG93IFFVSUMgZGVwbG95cyBvbiB0aGUgbmV0d29yaywgaW5j bHVkaW5nIGNvbnNpZGVyaW5nIHdoYXQsIGlmIGFueSwgY2hhbmdlcyBhcmUgbmVlZGVkIHRvIG1h a2UgdGhhdCBkZXBsb3ltZW50IG1vcmUgZWZmaWNpZW50Lg0KDQo+VGhhdCBRVUlDIG5lZWRzIHRv IHdvcmsgYXJvdW5kIG1pZGRsZWJveGVzIGlzIGFscmVhZHkgc3RhdGVkIGluIHRoZSBjaGFydGVy IGFzICJFbmFibGluZyBkZXBsb3ltZW50IG92ZXIgdW5tb2RpZmllZCBJbnRlcm5ldCBwYXRocyIu IElmIGxlZ2FjeSBtaWRkbGVib3hlcyBleGlzdCBvbiBwYXRoLCB0aGlzIGdvYWwgaGFzIHRoZW0g Y292ZXJlZC4gDQoNCkkgZG8gbm90IGJlbGlldmUgdGhpcyBpcyBhZGVxdWF0ZS4gIFRoZSBpbnRl bnQgaXMgbm90IHRvIGRlc2NyaWJlIGxlZ2FjeSBkZXZpY2VzLiAgVGhlIGludGVudCBpcyB0byBi ZSBhYmxlIHRvIGJ1aWxkIG5ldyBkZXZpY2VzIHRoYXQgYXJlIFFVSUMtZW5hYmxlZCwgYW5kIHRv IGFkdmFudGFnZSBRVUlDIHRyYWZmaWMgYWdhaW5zdCBsYXJnZS1zY2FsZSBVRFAgYmlhc2VzIHRo YXQgc29tZSBuZXR3b3JrIG9wZXJhdG9ycyBoYXZlIGluIHBsYWNlLiANCg0KPk9uIGNoYW5naW5n IG5ldHdvcmsgZGV2aWNlcywgdGhpcyBtYXkgYmUgb3VyIG90aGVyIGNvcmUgZGlzYWdyZWVtZW50 LiBUaGUgY2hhcnRlciBpcyBwcm9wb3NpbmcgdG8gd29yayBvbiBRVUlDLCBhbmQgbm90IHRvIG1v ZGlmeSBuZXR3b3JrIGRldmljZXMsIGFnYWluIGJlY2F1c2Ugb2Ygd2hhdCBJIHNhaWQgYWJvdmUu IEkgdGhpbmsgdGhhdCBhIGdlbmVyYWxpemVkIGZvcm0gb2YgdGhpcyBkcmFmdCBpcyBtb3JlIHJl bGV2YW50IGluIGEgYnJvYWRlcg0KPiBmb3J1bSAoYXMgbm90ZWQgZWFybGllciksIGFuZCBvbmNl IHRoZSByZXF1aXJlbWVudHMgYXJlIG1hZGUgY2xlYXIsIHN1cmVseSB0aGUgUVVJQyB3ZyBjYW4g d29yayBvbiBmaWd1cmluZyBvdXQgaG93IHRvIHNvbHZlIGZvciB0aGVtIGluIFFVSUMuDQoNClFV SUMgd2lsbCBub3QgYmUgYWJsZSB0byBiZSBkZXBsb3llZCBvbiBzb21lIG5ldHdvcmtzLCBzdWNo IGFzIHRoZSBvbmUgSSdtIG9uIHJpZ2h0IG5vdywgdW5sZXNzIHdlIGRlc2NyaWJlIHRoZSBjaGFu Z2VzIHRoYXQgYXJlIG5lY2Vzc2FyeSBmb3IgdGhlIG5ldHdvcmsgZGV2aWNlcyB0aGF0IGFyZSBj dXJyZW50bHkgYmxvY2tpbmcgaXQuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0K From nobody Thu Jun 16 10:15:17 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6912DA14 for ; Thu, 16 Jun 2016 10:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 9GgHRvBJWBGa for ; Thu, 16 Jun 2016 10:15:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EEE12D61A for ; Thu, 16 Jun 2016 10:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y7O+JWU3MjqLVRq9oJ9aLfsfpAsAP8dlPx/tdaLjcH0=; b=mtNdzac+lHjDRWVZrq6ogA/ZMupBsDmTxYblSwoUx6IhYaLVP2fAtenrWQnLWkUEOwIdxzUWg4NfjG9zTWrykNpjacM6P+7QFI7Lpl17+nmxzWxV46YU5tNyO2praSCjJdbYUXlZ/aCnSPvOYpDxICXDIzJAOsMduOri6VV45pY= Received: from CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) by CY1PR0301MB0650.namprd03.prod.outlook.com (10.160.158.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Thu, 16 Jun 2016 17:14:56 +0000 Received: from CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) by CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) with mapi id 15.01.0517.011; Thu, 16 Jun 2016 17:14:57 +0000 From: Christian Huitema To: "Joe Hildebrand (jhildebr)" , "quic@ietf.org" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmpUm60htf9Ad0SGrBzG1iqBxJ/pTiaggAAJWoCAAActAIAABX+AgACvEICAAPrsAIAARVOAgADPS4CAADA/UA== Date: Thu, 16 Jun 2016 17:14:56 +0000 Message-ID: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.160.201] x-ms-office365-filtering-correlation-id: 6353fa64-8368-44a2-61d3-08d39609bdc3 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0650; 6:KbfS7KVZv5B0R1JkaZv5iCm7mzX0THSgNx8igOCrxGuQAJxYH4suv+nwD4zmFRmg7mFrq7DLcmczfCxmqXZN5NubJyAgCOu3imLM6QY7/7mMBP01BALoCnlKcDwx1BwI9+Oig65704FGjq66onGPjlOXidB9t+JcalhMbkB2B6e0YkNGlzKz7FMLVpg+nwvil3FA9y/v5D0zfjDuNkNN1ao3yJ/BqvMPmYkxFw+aj741zXLUIdDdB0EnS4+SjMvgMM/yWGlasT9Z6O4q9tcnuLFcGqTUhF4sZTqKd3/EiaZQhA1/YTKqOgDRdg8jE31heHYo1ik5Kga0QtwENefcEA==; 5:KeNIxgd0/4eaCkxrDYCmdIxpBaeLs1mnK/S8FEIxySPWgQOuTiHltm4Lovci/WX3ZWNycfYyh7FBLdp1xv9Q4MvMkhe6soVLft24DBiTLLHzUo7j6cyMUqFAoptxEOEfMqtRR1LgW0Hu9hM93qPIFQ==; 24:aGhxFXzNN/IJJCZzfXtLtIATMIHn3sJJERc5O1oOOeXCMlLbczFEY5Hd3G+gk1KWkSvl9Z/PuE231Pm/mVPa5vl5AKvsgEvAthC8L+bBods=; 7:Abnk0n94XV57BLP7ceBlqKZLKVBlR9mYxj1cxWktKlvCdqiD/moRGiQEWCudHxAd+bZUzjIGjAnq8Xjg76srmwQVjolL/E4K1dmCbRUU2TDCFYty4pqtTykhdi4q5WKW6a0G5v3mOOCp8iIBs0tkWFAgmxwEvn50MzInPWXYUzEwAslmDZSXdkUkE+LXmbLuy8gmEsN4n/e2Eg7cX7ujKblDbFKgUrGnrXa9lo3K+1U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0650; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0650; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0650; x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(24454002)(377454003)(51444003)(10290500002)(2900100001)(10400500002)(2950100001)(77096005)(5004730100002)(5005710100001)(8936002)(92566002)(99286002)(93886004)(9686002)(87936001)(68736007)(8990500004)(74316001)(6116002)(102836003)(86612001)(3846002)(76576001)(586003)(86362001)(105586002)(106356001)(5002640100001)(106116001)(5003600100002)(97736004)(5001770100001)(2906002)(81166006)(81156014)(107886002)(8676002)(189998001)(33656002)(3660700001)(3280700002)(10090500001)(2501003)(5008740100001)(54356999)(50986999)(66066001)(76176999)(122556002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0650; H:CY1PR0301MB0649.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2016 17:14:56.9530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0650 Archived-At: Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 17:15:16 -0000 On Thursday, June 16, 2016 7:03 AM, Joe Hildebrand wrote: > ... > I do not believe this is adequate. The intent is not to describe legacy = devices. > The intent is to be able to build new devices that are QUIC-enabled, and = to > advantage QUIC traffic against large-scale UDP biases that some network > operators have in place. Joe, I think that we need state the requirements precisely. I heard a wide = range of potential requirements in the MARNEW workshop, and then on the SPU= D and PLUS mailing list, and then in your draft. I am concerned that genera= l goals like "make QUIC friendly to firewalls" can derive into an endless l= ist of feature requirements. If we write anything at all in the charter, it= has to cut to the core of the issue. I heard two common requirements, "marking the beginning and end of a flow,"= because that helps firewalls and load balancers manage resource, and "asse= ssing consent," because that helps differentiating between regular traffic = and attack traffic. Is there more? > QUIC will not be able to be deployed on some networks, such as the=20 > one I'm on right now, unless we describe the changes that are necessary > for the network devices that are currently blocking it. There are such networks. But there also are networks today that block outgo= ing TCP connections, because of some policy considerations. We don't change= TCP for that. We simply accept that these networks are making a tradeoff. = They care so much about some of their policies that they are willing to for= ego some of the value of the Internet. That's probably fine. Over time, the= cost/advantage balance of the tradeoff will change, and the policies will = probably evolve. -- Christian Huitema From nobody Thu Jun 16 10:40:11 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C932D12D6B2 for ; Thu, 16 Jun 2016 10:40:09 -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 5Hm8dUcYaj2B for ; Thu, 16 Jun 2016 10:40:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD1112B019 for ; Thu, 16 Jun 2016 10:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6060; q=dns/txt; s=iport; t=1466098808; x=1467308408; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pOi/1s6+3oWU1aHjc/9GLTKy2h5kQpNx7N7dm9noH4Y=; b=jpa0YEM4K3E3sPtNwCg00JLroOBir8roF3dnjbGZzDJafHbFLozuER9/ qF7N96B5uI2Yx46BUhQ2hUFIAkOOCSVPmQPG/si48PyPPqssCn4gwK+Lw 1N5gdAjJRch4t0apTwX1/uGDZbFbALUZgqElbNuymKECrMSwgdLD2GtfW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOBQBI5GJX/5hdJa1egz6BUwa4RoQJh?= =?us-ascii?q?hcCHIEQOxEBAQEBAQEBZSeETAEBAwEOFRExCAEbAgEIGgImAgICMBUQAgQBEog?= =?us-ascii?q?oCK9/kGIBAQEBAQEBAQEBAQEBAQEBAQEfgQGFJoF3CIJOhECDASuCLwWYcQGOK?= =?us-ascii?q?I8ij3QBNCCCCByBTG6JBX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,481,1459814400"; d="scan'208";a="119443734" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 17:40:07 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5GHe7Ae008929 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jun 2016 17:40:07 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 16 Jun 2016 13:40:06 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 16 Jun 2016 13:40:06 -0400 From: "Joe Hildebrand (jhildebr)" To: Christian Huitema , "quic@ietf.org" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmdrA4n/SZAVekigMWYxC+73GZ/pJkIAgABsYID//6NcgIAAa8MA//+g6wCAAROkgIAA+uwAgABFU4CAAGq4gIAAmi0A//+icwA= Date: Thu, 16 Jun 2016 17:40:06 +0000 Message-ID: <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <2696B4DF7DB21A4790A171CF8E1CE140@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 17:40:10 -0000 T24gNi8xNi8xNiwgMTE6MTQgQU0sICJDaHJpc3RpYW4gSHVpdGVtYSIgPGh1aXRlbWFAbWljcm9z b2Z0LmNvbT4gd3JvdGU6DQoNCj5Kb2UsIEkgdGhpbmsgdGhhdCB3ZSBuZWVkIHN0YXRlIHRoZSBy ZXF1aXJlbWVudHMgcHJlY2lzZWx5LiBJIGhlYXJkIGEgd2lkZSByYW5nZSBvZiBwb3RlbnRpYWwg cmVxdWlyZW1lbnRzIGluIHRoZSBNQVJORVcgd29ya3Nob3AsIGFuZCB0aGVuIG9uIHRoZSBTUFVE IGFuZCBQTFVTIG1haWxpbmcgbGlzdCwgYW5kIHRoZW4gaW4geW91ciBkcmFmdC4gSSBhbSBjb25j ZXJuZWQgdGhhdCBnZW5lcmFsIGdvYWxzIGxpa2UgIm1ha2UgUVVJQyBmcmllbmRseSB0byBmaXJl d2FsbHMiIGNhbiBkZXJpdmUgaW50byBhbiBlbmRsZXNzIGxpc3Qgb2YgZmVhdHVyZSByZXF1aXJl bWVudHMuIElmIHdlIHdyaXRlIGFueXRoaW5nIGF0IGFsbCBpbiB0aGUgY2hhcnRlciwgaXQgaGFz IHRvIGN1dCB0byB0aGUgY29yZSBvZiB0aGUgaXNzdWUuDQoNCldlIGNhbiBlbnVtZXJhdGUgdGhl c2UgaWYgeW91IHdpc2gsIGJ1dCBpZiB3ZSBjb21lIHVwIHdpdGggYW5vdGhlciBvbmUgdGhhdCB0 aGUgd29ya2luZyBncm91cCB3YW50cyB0byB0YWNrbGUsIEnigJlkIHByZWZlciBub3QgdG8gaGF2 ZSB0byByZWNoYXJ0ZXIuICBBIGxpdHRsZSBiaXQgb2YgbGFuZ3VhZ2Ugc2F5aW5nIOKAnGFuZCBz aW1pbGFyIGlzc3Vlc+KAnSB3b3VsZCBiZSBlbm91Z2ggZm9yIG1lLg0KDQo+SSBoZWFyZCB0d28g Y29tbW9uIHJlcXVpcmVtZW50cywgIm1hcmtpbmcgdGhlIGJlZ2lubmluZyBhbmQgZW5kIG9mIGEg ZmxvdywiIGJlY2F1c2UgdGhhdCBoZWxwcyBmaXJld2FsbHMgYW5kIGxvYWQgYmFsYW5jZXJzIG1h bmFnZSByZXNvdXJjZSwgYW5kICJhc3Nlc3NpbmcgY29uc2VudCwiIGJlY2F1c2UgdGhhdCBoZWxw cyBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiByZWd1bGFyIHRyYWZmaWMgYW5kIGF0dGFjayB0cmFm ZmljLiBJcyB0aGVyZSBtb3JlPw0KDQpJZiB5b3Ugd2FudCB0aGUgcHJvY2Vzc2luZyB0byBiZSBl ZmZpY2llbnQgKGFuZCBub3Qgb3NzaWZ5IHNvbWV0aGluZyB1bmludGVuZGVkKSwgYmVpbmcgYWJs ZSB0byBzZXBhcmF0ZSBRVUlDIHRyYWZmaWMgZnJvbSBub24tUVVJQyBVRFAgdHJhZmZpYyBlYXNp bHkgd291bGQgYmUgdXNlZnVsLiAgT3RoZXJ3aXNlLCBwYXRoIGRldmljZXMgYXJlIGxpa2VseSB0 byBncmFiIHdoYXRldmVyIHZlcnNpb24gbnVtYmVyIHRoZXkgc2VlIGFzIHRoZSBkaXNjcmltaW5h bnQuDQoNCklmIOKAnG1hcmtpbmcgdGhlIGJlZ2lubmluZyBvZiBhIGZsb3figJ0gYWxzbyBpbmNs dWRlcyBiZWluZyBhYmxlIHRvIHRlbGwgZWFzaWx5IHdoaWNoIHNpZGUgaW50ZW5kZWQgdG8gaW5p dGlhdGUgdGhlIGNvbnZlcnNhdGlvbiwgdGhlbiB0aGF04oCZcyBmaW5lLg0KDQpUaGUgcHJvdG9j b2wgbmVlZHMgdG8gZW5zdXJlIHRoYXQgYSBwYXRoIGVsZW1lbnQgY2FuIGFzc29jaWF0ZSBmdXJ0 aGVyIHRyYWZmaWMgb24gYSBRVUlDIGNvbm5lY3Rpb24gd2l0aCB0aGUgYmVnaW5uaW5nIG9mIHRo ZSBmbG93Lg0KDQpUaGVyZSBwcm9iYWJseSBuZWVkcyB0byBiZSByZWNvbW1lbmRhdGlvbnMgZm9y IHRpbWUtb3V0cywgcGFydGljdWxhcmx5IGFyb3VuZCB0aGUgZW5kIG9mIHRoZSBmbG93Lg0KDQpU aGUgcHJvdG9jb2wgZG9jIG5lZWRzIHRvIGRlc2NyaWJlIHdoYXQgaGFwcGVucyB3aXRoIGFzc29j aWF0ZWQgSUNNUC4NCg0KVGhlIHByb3RvY29sIG5lZWRzIHRvIHNheSB3aGF0IGhhcHBlbnMgd2hl biBhIG5ldHdvcmsgb3IgaG9zdCByZWNlaXZlcyBhIFFVSUMgcGFja2V0IGl0IHdhc27igJl0IGV4 cGVjdGluZy4NCg0KV2UgbmVlZCB0byB0aGluayBhYm91dCByZXR1cm4gcm91dGFiaWxpdHkuDQoN ClRoZSBwcm90b2NvbCBuZWVkcyB0byBrZWVwIGluIG1pbmQgdGhhdCBzdGF0ZSB3aWxsIGJlIGdl bmVyYXRlZCBpbiB0aGUgbmV0d29yaywgc28gdGhhdCBhcyB3ZSBhZGQgbXVsdGktcGF0aCBleHRl bnNpb25zIChmb3IgZXhhbXBsZSksIHdlIGRvbuKAmXQganVzdCBzdGFydCBzZW5kaW5nIHRyYWZm aWMgb24gYSBuZXcgcGF0aCB3aXRob3V0IGZpcnN0IHN0YXJ0aW5nIGEgbmV3IGZsb3cuDQoNCkl0 IGlzIHBvc3NpYmxlIHRoYXQgd2UgbWlnaHQgd2FudCB0byBkZXNjcmliZSB3aGF0IGEgbG9hZCBi YWxhbmNlciBzaG91bGQgZG8gd2hlbiBpdCBkcm9wcyBRVUlDIHN0YXRlIGR1ZSB0byBhIHRpbWVv dXQgKG9yIHdoZW4gaXQgaXMgKmFib3V0KiB0byBkcm9wIHN0YXRlKS4gIFdlIG1pZ2h0IHdhbnQg aXQgdG8gc2VuZCBhIGhpbnQgdG8gb25lIG9yIGJvdGggb2YgdGhlIGVuZHBvaW50cywgdG8gYXZv aWQgaGF2aW5nIHRvIGRpYWdub3NlIG1pZC1zdHJlYW0gYmxhY2sgaG9sZXMuICBTb21lIGxvYWQg VENQIGxvYWQgYmFsYW5jZXJzIHNlbmQgUlNUcyBpbiBib3RoIGRpcmVjdGlvbnMgaW4gdGhpcyBj YXNlLCBmb3IgZXhhbXBsZS4NCg0KV2Ugc2hvdWxkIGFuYWx5emUgdGhlIGtub3duIGF0dGFja3Mg b24gVENQIChhdCBsZWFzdCkgdG8gZW5zdXJlIHRoYXQgUVVJQyBpcyBub3QgaW1tZWRpYXRlbHkg dnVsbmVyYWJsZSB0byB0aGUgc29ydHMgb2YgdGhpbmdzIHdl4oCZdmUgYWxyZWFkeSBmaXhlZCBv dmVyIHRoZSBsYXN0IDQwIHllYXJzLiANCg0KVGhlcmUgYXJlIHByb2JhYmx5IGEgY291cGxlIG9m IG90aGVycywgYW5kIEnigJltIG9wZW4gdG8gbW9kaWZ5aW5nIHRoZSBsaXN0IGFzIHBlb3BsZSBz ZWUgZml0LiAgQWx0ZXJuYXRlbHksIGlmIHdlIGNhbiBmaW5kIGEgd2F5IHRvIGRlc2NyaWJlIHRo ZXNlIGtpbmQgb2YgZGlzY3Vzc2lvbnMgaW4gYSB3YXkgdGhhdCBkb2VzIG5vdCBicmluZyBpbiB0 aGUgZXhwbGljaXQgcGF0aCBjb21tdW5pY2F0aW9uIGJpdHMgdGhhdCB3ZSBleHBsb3JlZCBpbiBT UFVELCBJIHRoaW5rIHRoZSBjaGFydGVyIHdvdWxkIGJlIGVhc2llciB0byB1bmRlcnN0YW5kLiAN Cg0KPj4gUVVJQyB3aWxsIG5vdCBiZSBhYmxlIHRvIGJlIGRlcGxveWVkIG9uIHNvbWUgbmV0d29y a3MsIHN1Y2ggYXMgdGhlIA0KPj4gb25lIEknbSBvbiByaWdodCBub3csIHVubGVzcyB3ZSBkZXNj cmliZSB0aGUgY2hhbmdlcyB0aGF0IGFyZSBuZWNlc3NhcnkNCj4+IGZvciB0aGUgbmV0d29yayBk ZXZpY2VzIHRoYXQgYXJlIGN1cnJlbnRseSBibG9ja2luZyBpdC4NCj4NCj5UaGVyZSBhcmUgc3Vj aCBuZXR3b3Jrcy4gQnV0IHRoZXJlIGFsc28gYXJlIG5ldHdvcmtzIHRvZGF5IHRoYXQgYmxvY2sg b3V0Z29pbmcgVENQIGNvbm5lY3Rpb25zLCBiZWNhdXNlIG9mIHNvbWUgcG9saWN5IGNvbnNpZGVy YXRpb25zLiBXZSBkb24ndCBjaGFuZ2UgVENQIGZvciB0aGF0LiBXZSBzaW1wbHkgYWNjZXB0IHRo YXQgdGhlc2UgbmV0d29ya3MgYXJlIG1ha2luZyBhIHRyYWRlb2ZmLiBUaGV5IGNhcmUgc28gbXVj aCBhYm91dCBzb21lIG9mIHRoZWlyIHBvbGljaWVzIHRoYXQgdGhleSBhcmUgd2lsbGluZyB0byBm b3JlZ28gc29tZSBvZiB0aGUgdmFsdWUgb2YgdGhlIEludGVybmV0LiBUaGF0J3MgcHJvYmFibHkg ZmluZS4gT3ZlciB0aW1lLCB0aGUgY29zdC9hZHZhbnRhZ2UgYmFsYW5jZSBvZiB0aGUgdHJhZGVv ZmYgd2lsbCBjaGFuZ2UsIGFuZCB0aGUgcG9saWNpZXMgd2lsbCBwcm9iYWJseSBldm9sdmUuDQoN CkFyZSB5b3Ugc2F5aW5nIHRoYXQgcGVvcGxlIHdpbGwgd2FudCBRVUlDIHNvIG11Y2ggdGhhdCB0 aGV5IHdpbGwgb3BlbiB0aGVpciBmaXJld2FsbHMgdXAgdG8gYWxsIFVEUCB0cmFmZmljIGluIGJv dGggZGlyZWN0aW9ucz8gIE9yIHRoYXQgdGhlIHRlcnJpYmxlIHRpbWluZy1iYXNlZCBoZXVyaXN0 aWNzIHdlIGhhdmUgZm9yIGdlbmVyaWMgVURQIHdpbGwgYmUgZW5vdWdoIGZvciBhIGxhcmdlIGVu dGVycHJpc2U/ICBPciB0aGF0IHRoZSBjdXJyZW50IHByb3RvY29sIGRlc2NyaXB0aW9uLCB3aXRo b3V0IGRpc2N1c3Npb24gYW5kIGFuYWx5c2lzLCBzaG91bGQgYmUgcHJlc3VtZWQgdG8gYmUgcGVy ZmVjdCBpbiB0aGlzIHJlZ2FyZD8NCg0KRm9yIG9uY2UsIHdlIGhhdmUgYSBjaGFuY2UgdG8gZG8g c29tZSB0aG91Z2h0ZnVsIGVuZ2luZWVyaW5nIGJlZm9yZSBhIHByb3RvY29sIGlzIGZ1bGx5IHNw ZWNpZmllZCB0byBjb25zaWRlciBob3cgaXQgd2lsbCBiZSBkZXBsb3llZCwgYmFraW5nIGRlY2Fk ZXMgb2YgbGVhcm5pbmcgaW50byB0aGUgZGVzaWduLiAgSSB0aGluayB0aGUgYXBwcm9hY2ggdGhh dCB0aGUgVExTIHdvcmtpbmcgZ3JvdXAgaGFzIGJlZW4gZG9pbmcgb24gVExTIDEuMyB0byBjb25z aWRlciBhdHRhY2sgdmVjdG9ycywgYmFja3dhcmQtY29tcGF0aWJpbGl0eSwgZXRjLiBpcyBhIG1v ZGVsIGZvciB3aGF0IGlzIG5lZWRlZCBmcm9tIGEgcHJvdG9jb2wgb2YgUVVJQ+KAmXMgcG90ZW50 aWFsIGltcGFjdC4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQo= From nobody Thu Jun 16 11:45:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A5D12D83C for ; Thu, 16 Jun 2016 11:45: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 rkWMjbD29I-E for ; Thu, 16 Jun 2016 11:45:11 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0DD12D12D for ; Thu, 16 Jun 2016 11:45:09 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id C4C1E1A0307; Thu, 16 Jun 2016 20:45:07 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F4563216-26F7-4979-AE22-2FF61BDBDB49"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> Date: Thu, 16 Jun 2016 20:45:11 +0200 Message-Id: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Christian Huitema , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:45:13 -0000 --Apple-Mail=_F4563216-26F7-4979-AE22-2FF61BDBDB49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Joe, Christian, all, (hatless, inline reply...) > On 16 Jun 2016, at 19:40, Joe Hildebrand (jhildebr) = wrote: >=20 > On 6/16/16, 11:14 AM, "Christian Huitema" = wrote: >=20 >> Joe, I think that we need state the requirements precisely. I heard a = wide range of potential requirements in the MARNEW workshop, and then on = the SPUD and PLUS mailing list, and then in your draft. I am concerned = that general goals like "make QUIC friendly to firewalls" can derive = into an endless list of feature requirements. If we write anything at = all in the charter, it has to cut to the core of the issue. >=20 > We can enumerate these if you wish, but if we come up with another one = that the working group wants to tackle, I=E2=80=99d prefer not to have = to recharter. A little bit of language saying =E2=80=9Cand similar = issues=E2=80=9D would be enough for me. It seems to me that a lot of what we're talking about here goes to = aligning the operation of QUIC with the expectations of people who = actually run networks. We've got lots of running code out there that = assumes that "connection-oriented Internet transport protocol" and "TCP" = are synonymous. There's the code on firewalls, but that's relatively = easy to patch compared to the "code" in the heads of network and system = administrators. The closer the control points and network-level = information available are equivalent to those available in TCP, the less = friction with this existing practice. There are obvious tradeoffs in = visibility and exploitability that must be evaulated, but this is = engineering the WG should do. In any event, reusing people's intuition = about TCP to the extent it fits with QUIC seems useful to me. Given that, would the following change to the charter (adding one = sentence to the paragraph for focus area one) be acceptable? OLD: The first of these is the core transport work, which will describe the = wire format, along with the mechanisms for connection establishment, = stream multiplexing, data reliability, loss detection and recovery, = congestion control, version negotiation, and options negotiation. Work = on congestion control will describe use of an existing congestion = controller as a default scheme for QUIC. QUIC is expected to support = rapid iterability and experimentation, and this work will describe a = versioning process that enables distributed experimentation with QUIC. NEW: The first of these is the core transport work, which will describe the = wire format, along with the mechanisms for connection establishment, = stream multiplexing, data reliability, loss detection and recovery, = congestion control, version negotiation, and options negotiation. This = work will consider deployability, manageability and diagnosability of = the wire format, including how the wire format will be processed by = devices on path. Work on congestion control will describe use of an = existing congestion controller as a default scheme for QUIC. QUIC is = expected to support rapid iterability and experimentation, and this work = will describe a versioning process that enables distributed = experimentation with QUIC. Indeed, I would hope that manageability and diagnosability -- which = includes enabling firewalls to keep state, and making it possible to = differentiate attack traffic -- are requirements for any IETF transport = protocol going forward. The discussion below, I think, needs to happen in the WG. General = guidance here can come from PLUS (and indeed, I see a lot of points = raised in the SPUD-derived requirements document draft-trammell-spud-req = in Joe's list below), but the detailed evaluation of these aspects of = how the protocol will interact with devices on path in the specific case = of QUIC are a matter for QUIC. I believe the suggestion above allows = that work to happen. Cheers, Brian >> I heard two common requirements, "marking the beginning and end of a = flow," because that helps firewalls and load balancers manage resource, = and "assessing consent," because that helps differentiating between = regular traffic and attack traffic. Is there more? >=20 > If you want the processing to be efficient (and not ossify something = unintended), being able to separate QUIC traffic from non-QUIC UDP = traffic easily would be useful. Otherwise, path devices are likely to = grab whatever version number they see as the discriminant. >=20 > If =E2=80=9Cmarking the beginning of a flow=E2=80=9D also includes = being able to tell easily which side intended to initiate the = conversation, then that=E2=80=99s fine. >=20 > The protocol needs to ensure that a path element can associate further = traffic on a QUIC connection with the beginning of the flow. >=20 > There probably needs to be recommendations for time-outs, particularly = around the end of the flow. >=20 > The protocol doc needs to describe what happens with associated ICMP. >=20 > The protocol needs to say what happens when a network or host receives = a QUIC packet it wasn=E2=80=99t expecting. >=20 > We need to think about return routability. >=20 > The protocol needs to keep in mind that state will be generated in the = network, so that as we add multi-path extensions (for example), we = don=E2=80=99t just start sending traffic on a new path without first = starting a new flow. >=20 > It is possible that we might want to describe what a load balancer = should do when it drops QUIC state due to a timeout (or when it is = *about* to drop state). We might want it to send a hint to one or both = of the endpoints, to avoid having to diagnose mid-stream black holes. = Some load TCP load balancers send RSTs in both directions in this case, = for example. >=20 > We should analyze the known attacks on TCP (at least) to ensure that = QUIC is not immediately vulnerable to the sorts of things we=E2=80=99ve = already fixed over the last 40 years. >=20 > There are probably a couple of others, and I=E2=80=99m open to = modifying the list as people see fit. Alternately, if we can find a way = to describe these kind of discussions in a way that does not bring in = the explicit path communication bits that we explored in SPUD, I think = the charter would be easier to understand. >=20 >>> QUIC will not be able to be deployed on some networks, such as the >>> one I'm on right now, unless we describe the changes that are = necessary >>> for the network devices that are currently blocking it. >>=20 >> There are such networks. But there also are networks today that block = outgoing TCP connections, because of some policy considerations. We = don't change TCP for that. We simply accept that these networks are = making a tradeoff. They care so much about some of their policies that = they are willing to forego some of the value of the Internet. That's = probably fine. Over time, the cost/advantage balance of the tradeoff = will change, and the policies will probably evolve. >=20 > Are you saying that people will want QUIC so much that they will open = their firewalls up to all UDP traffic in both directions? Or that the = terrible timing-based heuristics we have for generic UDP will be enough = for a large enterprise? Or that the current protocol description, = without discussion and analysis, should be presumed to be perfect in = this regard? >=20 > For once, we have a chance to do some thoughtful engineering before a = protocol is fully specified to consider how it will be deployed, baking = decades of learning into the design. I think the approach that the TLS = working group has been doing on TLS 1.3 to consider attack vectors, = backward-compatibility, etc. is a model for what is needed from a = protocol of QUIC=E2=80=99s potential impact. >=20 > -- > Joe Hildebrand >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_F4563216-26F7-4979-AE22-2FF61BDBDB49 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 iQIcBAEBCgAGBQJXYvO3AAoJEIoSt78L6kajyIQP/RegwDd51VKJxRiUlYO1oCr3 k2PfOuSBqQ7+Tk642mfy9SJGHs9Z3X4XEW5uDYnBXMjw9P06yHslGuhxxOrgYlME iX4VGtDJJaUaEgLBb78HFgmVlVrpnJwjQwypFfynipSSxGnafy6Ok8hGkszw6C6O XpGr1oh37yOrSJJCAvwnXBQs/G98yFgWi1XWLZLH55F9imohITNYOqtV+M3hWdtl UFhaphNWrt3YKmf/gmwXWoJrogK+prCIKFlWf9qtQ5wlFl5wf7KKdPpWOiWBWGgG OalYSCoQqMjDNGVkmqehq79ORavrVM5B/zCZ8QLBcdh40UiPMB2l2I4+T6FFRjQS p/mE+bklxT0Fm/xMKraFhb0Twb0qMwL24iiuJHX5cwOtoUFS5+Vxr9yTPUXBFyq3 fHi0c7Xzt674TezNSlM6ci9cK6vLctFnESsNVvJcKuhUfJBQQI5wpT5R/cbpnSM3 YseFYbDKwVV8HzQS2NloknqGaYUe4wV6n4wVw1aczvLPYKuzK4LltWnBTZDfu2oZ ZJW0AivagXq8YGEk6nrvEbeGy1Hb8QwXAGZ/s4njjNNYiNFv6PUZNilgyUk3pdmB SuVBoxS3zHy2YyOYu5PqqYSpuh07Rk+tH/yEUOfWTT7jxB8Lcs2XyP8cI1SRReMV 3odfyCQkDDshBuYWIKRn =Xpwg -----END PGP SIGNATURE----- --Apple-Mail=_F4563216-26F7-4979-AE22-2FF61BDBDB49-- From nobody Thu Jun 16 23:52:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB86F12D0FB for ; Thu, 16 Jun 2016 23:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, 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, UNPARSEABLE_RELAY=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 0hopwMJ-R0gM for ; Thu, 16 Jun 2016 23:52:17 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FDF12B024 for ; Thu, 16 Jun 2016 23:52:17 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7040DC0366; Fri, 17 Jun 2016 08:52:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 39FA51A0070; Fri, 17 Jun 2016 08:52:16 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0294.000; Fri, 17 Jun 2016 08:52:16 +0200 From: To: Brian Trammell , "Joe Hildebrand (jhildebr)" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmpUm60htf9Ad0SGrBzG1iqBxJ/pTiaggAAJWoCAAActAIAABX+AgACvEICAAPrsAIAARVOAgADPS4CAADA/UP//6twAgAASL4CAAOZ18A== Date: Fri, 17 Jun 2016 06:52:15 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DB4755@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Christian Huitema , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 06:52:20 -0000 RGVhciBCcmlhbiwgYWxsLCANCg0KVGhlIE5FVyBwcm9wb3NhbCBpcyBhbiBlbmhhbmNlbWVudCBi dXQgSU1ITyB0aGUgdGV4dCBzaG91bGQgYmUgZXhwbGljaXQgdGhhdCB0aGUgd2lyZSBmb3JtYXQg Y2FuIGJlIGNoYW5nZWQgYWNjb3JkaW5nbHkuIFRoZSBkZWNpc2lvbiB3aGV0aGVyIGEgY2hhbmdl IGlzIG5lZWRlZCBhbmQgd2hpY2ggY2hhbmdlcyBhcmUgbmVlZGVkLCBpcyB1cCB0byB0aGUgV0cu DQoNCkkgc3VnZ2VzdCB0aGlzIG1vZGlmaWNhdGlvbiB0byB0aGUgQnJpYW4ncyB0ZXh0OiAgDQoN Ck9MRDoNCg0KICAgVGhpcyB3b3JrIHdpbGwgY29uc2lkZXIgZGVwbG95YWJpbGl0eSwgbWFuYWdl YWJpbGl0eSBhbmQNCiAgIGRpYWdub3NhYmlsaXR5IG9mIHRoZSB3aXJlIGZvcm1hdCwgaW5jbHVk aW5nIGhvdyB0aGUgd2lyZSBmb3JtYXQgd2lsbA0KICAgYmUgcHJvY2Vzc2VkIGJ5IGRldmljZXMg b24gcGF0aC4NCg0KTkVXOg0KDQogICBUaGlzIHdvcmsgd2lsbCBjb25zaWRlciBpc3N1ZXMgcmFp c2VkIGJ5IGRlcGxveWFiaWxpdHkgYW5kDQogICBkaWFnbm9zYWJpbGl0eSwgYXMgd2VsbCBhcyBu ZXR3b3JrIG1hbmFnZW1lbnQgaW1wbGljYXRpb25zLCBpbmNsdWRpbmcNCiAgIGhvdyB0aGUgd2ly ZSBmb3JtYXQgd2lsbCBiZSBwcm9jZXNzZWQgYnkgZGV2aWNlcyBvbiBwYXRoLiAgVGhlDQogICBz cGVjaWZpY2F0aW9uIG9mIHRoZSB3aXJlIGZvcm1hdCB3aWxsIGJlIHVwZGF0ZWQgdG8gYWNjb21t b2RhdGUgdGhlc2UNCiAgIGlzc3Vlcy4NCg0KVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0K PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBCcmlhbiBUcmFtbWVsbA0KPiBFbnZvecOp wqA6IGpldWRpIDE2IGp1aW4gMjAxNiAyMDo0NQ0KPiDDgMKgOiBKb2UgSGlsZGVicmFuZCAoamhp bGRlYnIpDQo+IENjwqA6IENocmlzdGlhbiBIdWl0ZW1hOyBxdWljQGlldGYub3JnDQo+IE9iamV0 wqA6IFJlOiBbUVVJQ10gTmV0d29yayBQYXRoIFJlcXVpcmVtZW50cyBmb3IgUVVJQw0KPiANCj4g aGkgSm9lLCBDaHJpc3RpYW4sIGFsbCwNCj4gDQo+IChoYXRsZXNzLCBpbmxpbmUgcmVwbHkuLi4p DQo+IA0KPiA+IE9uIDE2IEp1biAyMDE2LCBhdCAxOTo0MCwgSm9lIEhpbGRlYnJhbmQgKGpoaWxk ZWJyKSA8amhpbGRlYnJAY2lzY28uY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+IE9uIDYvMTYvMTYs IDExOjE0IEFNLCAiQ2hyaXN0aWFuIEh1aXRlbWEiIDxodWl0ZW1hQG1pY3Jvc29mdC5jb20+IHdy b3RlOg0KPiA+DQo+ID4+IEpvZSwgSSB0aGluayB0aGF0IHdlIG5lZWQgc3RhdGUgdGhlIHJlcXVp cmVtZW50cyBwcmVjaXNlbHkuIEkgaGVhcmQgYQ0KPiB3aWRlIHJhbmdlIG9mIHBvdGVudGlhbCBy ZXF1aXJlbWVudHMgaW4gdGhlIE1BUk5FVyB3b3Jrc2hvcCwgYW5kIHRoZW4gb24NCj4gdGhlIFNQ VUQgYW5kIFBMVVMgbWFpbGluZyBsaXN0LCBhbmQgdGhlbiBpbiB5b3VyIGRyYWZ0LiBJIGFtIGNv bmNlcm5lZA0KPiB0aGF0IGdlbmVyYWwgZ29hbHMgbGlrZSAibWFrZSBRVUlDIGZyaWVuZGx5IHRv IGZpcmV3YWxscyIgY2FuIGRlcml2ZSBpbnRvDQo+IGFuIGVuZGxlc3MgbGlzdCBvZiBmZWF0dXJl IHJlcXVpcmVtZW50cy4gSWYgd2Ugd3JpdGUgYW55dGhpbmcgYXQgYWxsIGluDQo+IHRoZSBjaGFy dGVyLCBpdCBoYXMgdG8gY3V0IHRvIHRoZSBjb3JlIG9mIHRoZSBpc3N1ZS4NCj4gPg0KPiA+IFdl IGNhbiBlbnVtZXJhdGUgdGhlc2UgaWYgeW91IHdpc2gsIGJ1dCBpZiB3ZSBjb21lIHVwIHdpdGgg YW5vdGhlciBvbmUNCj4gdGhhdCB0aGUgd29ya2luZyBncm91cCB3YW50cyB0byB0YWNrbGUsIEni gJlkIHByZWZlciBub3QgdG8gaGF2ZSB0bw0KPiByZWNoYXJ0ZXIuICBBIGxpdHRsZSBiaXQgb2Yg bGFuZ3VhZ2Ugc2F5aW5nIOKAnGFuZCBzaW1pbGFyIGlzc3Vlc+KAnSB3b3VsZCBiZQ0KPiBlbm91 Z2ggZm9yIG1lLg0KPiANCj4gSXQgc2VlbXMgdG8gbWUgdGhhdCBhIGxvdCBvZiB3aGF0IHdlJ3Jl IHRhbGtpbmcgYWJvdXQgaGVyZSBnb2VzIHRvDQo+IGFsaWduaW5nIHRoZSBvcGVyYXRpb24gb2Yg UVVJQyB3aXRoIHRoZSBleHBlY3RhdGlvbnMgb2YgcGVvcGxlIHdobw0KPiBhY3R1YWxseSBydW4g bmV0d29ya3MuIFdlJ3ZlIGdvdCBsb3RzIG9mIHJ1bm5pbmcgY29kZSBvdXQgdGhlcmUgdGhhdA0K PiBhc3N1bWVzIHRoYXQgImNvbm5lY3Rpb24tb3JpZW50ZWQgSW50ZXJuZXQgdHJhbnNwb3J0IHBy b3RvY29sIiBhbmQgIlRDUCINCj4gYXJlIHN5bm9ueW1vdXMuIFRoZXJlJ3MgdGhlIGNvZGUgb24g ZmlyZXdhbGxzLCBidXQgdGhhdCdzIHJlbGF0aXZlbHkgZWFzeQ0KPiB0byBwYXRjaCBjb21wYXJl ZCB0byB0aGUgImNvZGUiIGluIHRoZSBoZWFkcyBvZiBuZXR3b3JrIGFuZCBzeXN0ZW0NCj4gYWRt aW5pc3RyYXRvcnMuIFRoZSBjbG9zZXIgdGhlIGNvbnRyb2wgcG9pbnRzIGFuZCBuZXR3b3JrLWxl dmVsDQo+IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhcmUgZXF1aXZhbGVudCB0byB0aG9zZSBhdmFp bGFibGUgaW4gVENQLCB0aGUgbGVzcw0KPiBmcmljdGlvbiB3aXRoIHRoaXMgZXhpc3RpbmcgcHJh Y3RpY2UuIFRoZXJlIGFyZSBvYnZpb3VzIHRyYWRlb2ZmcyBpbg0KPiB2aXNpYmlsaXR5IGFuZCBl eHBsb2l0YWJpbGl0eSB0aGF0IG11c3QgYmUgZXZhdWxhdGVkLCBidXQgdGhpcyBpcw0KPiBlbmdp bmVlcmluZyB0aGUgV0cgc2hvdWxkIGRvLiBJbiBhbnkgZXZlbnQsIHJldXNpbmcgcGVvcGxlJ3Mg aW50dWl0aW9uDQo+IGFib3V0IFRDUCB0byB0aGUgZXh0ZW50IGl0IGZpdHMgd2l0aCBRVUlDIHNl ZW1zIHVzZWZ1bCB0byBtZS4NCj4gDQo+IEdpdmVuIHRoYXQsIHdvdWxkIHRoZSBmb2xsb3dpbmcg Y2hhbmdlIHRvIHRoZSBjaGFydGVyIChhZGRpbmcgb25lIHNlbnRlbmNlDQo+IHRvIHRoZSBwYXJh Z3JhcGggZm9yIGZvY3VzIGFyZWEgb25lKSBiZSBhY2NlcHRhYmxlPw0KPiANCj4gT0xEOg0KPiAN Cj4gVGhlIGZpcnN0IG9mIHRoZXNlIGlzIHRoZSBjb3JlIHRyYW5zcG9ydCB3b3JrLCB3aGljaCB3 aWxsIGRlc2NyaWJlIHRoZQ0KPiB3aXJlIGZvcm1hdCwgYWxvbmcgd2l0aCB0aGUgbWVjaGFuaXNt cyBmb3IgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50LA0KPiBzdHJlYW0gbXVsdGlwbGV4aW5nLCBk YXRhIHJlbGlhYmlsaXR5LCBsb3NzIGRldGVjdGlvbiBhbmQgcmVjb3ZlcnksDQo+IGNvbmdlc3Rp b24gY29udHJvbCwgdmVyc2lvbiBuZWdvdGlhdGlvbiwgYW5kIG9wdGlvbnMgbmVnb3RpYXRpb24u IFdvcmsgb24NCj4gY29uZ2VzdGlvbiBjb250cm9sIHdpbGwgZGVzY3JpYmUgdXNlIG9mIGFuIGV4 aXN0aW5nIGNvbmdlc3Rpb24gY29udHJvbGxlcg0KPiBhcyBhIGRlZmF1bHQgc2NoZW1lIGZvciBR VUlDLiBRVUlDIGlzIGV4cGVjdGVkIHRvIHN1cHBvcnQgcmFwaWQNCj4gaXRlcmFiaWxpdHkgYW5k IGV4cGVyaW1lbnRhdGlvbiwgYW5kIHRoaXMgd29yayB3aWxsIGRlc2NyaWJlIGEgdmVyc2lvbmlu Zw0KPiBwcm9jZXNzIHRoYXQgZW5hYmxlcyBkaXN0cmlidXRlZCBleHBlcmltZW50YXRpb24gd2l0 aCBRVUlDLg0KPiANCj4gTkVXOg0KPiANCj4gVGhlIGZpcnN0IG9mIHRoZXNlIGlzIHRoZSBjb3Jl IHRyYW5zcG9ydCB3b3JrLCB3aGljaCB3aWxsIGRlc2NyaWJlIHRoZQ0KPiB3aXJlIGZvcm1hdCwg YWxvbmcgd2l0aCB0aGUgbWVjaGFuaXNtcyBmb3IgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50LA0K PiBzdHJlYW0gbXVsdGlwbGV4aW5nLCBkYXRhIHJlbGlhYmlsaXR5LCBsb3NzIGRldGVjdGlvbiBh bmQgcmVjb3ZlcnksDQo+IGNvbmdlc3Rpb24gY29udHJvbCwgdmVyc2lvbiBuZWdvdGlhdGlvbiwg YW5kIG9wdGlvbnMgbmVnb3RpYXRpb24uIFRoaXMNCj4gd29yayB3aWxsIGNvbnNpZGVyIGRlcGxv eWFiaWxpdHksIG1hbmFnZWFiaWxpdHkgYW5kIGRpYWdub3NhYmlsaXR5IG9mIHRoZQ0KPiB3aXJl IGZvcm1hdCwgaW5jbHVkaW5nIGhvdyB0aGUgd2lyZSBmb3JtYXQgd2lsbCBiZSBwcm9jZXNzZWQg YnkgZGV2aWNlcyBvbg0KPiBwYXRoLiBXb3JrIG9uIGNvbmdlc3Rpb24gY29udHJvbCB3aWxsIGRl c2NyaWJlIHVzZSBvZiBhbiBleGlzdGluZw0KPiBjb25nZXN0aW9uIGNvbnRyb2xsZXIgYXMgYSBk ZWZhdWx0IHNjaGVtZSBmb3IgUVVJQy4gUVVJQyBpcyBleHBlY3RlZCB0bw0KPiBzdXBwb3J0IHJh cGlkIGl0ZXJhYmlsaXR5IGFuZCBleHBlcmltZW50YXRpb24sIGFuZCB0aGlzIHdvcmsgd2lsbCBk ZXNjcmliZQ0KPiBhIHZlcnNpb25pbmcgcHJvY2VzcyB0aGF0IGVuYWJsZXMgZGlzdHJpYnV0ZWQg ZXhwZXJpbWVudGF0aW9uIHdpdGggUVVJQy4NCj4gDQo+IEluZGVlZCwgSSB3b3VsZCBob3BlIHRo YXQgbWFuYWdlYWJpbGl0eSBhbmQgZGlhZ25vc2FiaWxpdHkgLS0gd2hpY2gNCj4gaW5jbHVkZXMg ZW5hYmxpbmcgZmlyZXdhbGxzIHRvIGtlZXAgc3RhdGUsIGFuZCBtYWtpbmcgaXQgcG9zc2libGUg dG8NCj4gZGlmZmVyZW50aWF0ZSBhdHRhY2sgdHJhZmZpYyAtLSBhcmUgcmVxdWlyZW1lbnRzIGZv ciBhbnkgSUVURiB0cmFuc3BvcnQNCj4gcHJvdG9jb2wgZ29pbmcgZm9yd2FyZC4NCj4gDQo+IFRo ZSBkaXNjdXNzaW9uIGJlbG93LCBJIHRoaW5rLCBuZWVkcyB0byBoYXBwZW4gaW4gdGhlIFdHLiBH ZW5lcmFsIGd1aWRhbmNlDQo+IGhlcmUgY2FuIGNvbWUgZnJvbSBQTFVTIChhbmQgaW5kZWVkLCBJ IHNlZSBhIGxvdCBvZiBwb2ludHMgcmFpc2VkIGluIHRoZQ0KPiBTUFVELWRlcml2ZWQgcmVxdWly ZW1lbnRzIGRvY3VtZW50IGRyYWZ0LXRyYW1tZWxsLXNwdWQtcmVxIGluIEpvZSdzIGxpc3QNCj4g YmVsb3cpLCBidXQgdGhlIGRldGFpbGVkIGV2YWx1YXRpb24gb2YgdGhlc2UgYXNwZWN0cyBvZiBo b3cgdGhlIHByb3RvY29sDQo+IHdpbGwgaW50ZXJhY3Qgd2l0aCBkZXZpY2VzIG9uIHBhdGggaW4g dGhlIHNwZWNpZmljIGNhc2Ugb2YgUVVJQyBhcmUgYQ0KPiBtYXR0ZXIgZm9yIFFVSUMuIEkgYmVs aWV2ZSB0aGUgc3VnZ2VzdGlvbiBhYm92ZSBhbGxvd3MgdGhhdCB3b3JrIHRvDQo+IGhhcHBlbi4N Cj4gDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBCcmlhbg0KPiANCj4gDQo+ID4+IEkgaGVhcmQgdHdv IGNvbW1vbiByZXF1aXJlbWVudHMsICJtYXJraW5nIHRoZSBiZWdpbm5pbmcgYW5kIGVuZCBvZiBh DQo+IGZsb3csIiBiZWNhdXNlIHRoYXQgaGVscHMgZmlyZXdhbGxzIGFuZCBsb2FkIGJhbGFuY2Vy cyBtYW5hZ2UgcmVzb3VyY2UsDQo+IGFuZCAiYXNzZXNzaW5nIGNvbnNlbnQsIiBiZWNhdXNlIHRo YXQgaGVscHMgZGlmZmVyZW50aWF0aW5nIGJldHdlZW4NCj4gcmVndWxhciB0cmFmZmljIGFuZCBh dHRhY2sgdHJhZmZpYy4gSXMgdGhlcmUgbW9yZT8NCj4gPg0KPiA+IElmIHlvdSB3YW50IHRoZSBw cm9jZXNzaW5nIHRvIGJlIGVmZmljaWVudCAoYW5kIG5vdCBvc3NpZnkgc29tZXRoaW5nDQo+IHVu aW50ZW5kZWQpLCBiZWluZyBhYmxlIHRvIHNlcGFyYXRlIFFVSUMgdHJhZmZpYyBmcm9tIG5vbi1R VUlDIFVEUCB0cmFmZmljDQo+IGVhc2lseSB3b3VsZCBiZSB1c2VmdWwuICBPdGhlcndpc2UsIHBh dGggZGV2aWNlcyBhcmUgbGlrZWx5IHRvIGdyYWINCj4gd2hhdGV2ZXIgdmVyc2lvbiBudW1iZXIg dGhleSBzZWUgYXMgdGhlIGRpc2NyaW1pbmFudC4NCj4gPg0KPiA+IElmIOKAnG1hcmtpbmcgdGhl IGJlZ2lubmluZyBvZiBhIGZsb3figJ0gYWxzbyBpbmNsdWRlcyBiZWluZyBhYmxlIHRvIHRlbGwN Cj4gZWFzaWx5IHdoaWNoIHNpZGUgaW50ZW5kZWQgdG8gaW5pdGlhdGUgdGhlIGNvbnZlcnNhdGlv biwgdGhlbiB0aGF04oCZcyBmaW5lLg0KPiA+DQo+ID4gVGhlIHByb3RvY29sIG5lZWRzIHRvIGVu c3VyZSB0aGF0IGEgcGF0aCBlbGVtZW50IGNhbiBhc3NvY2lhdGUgZnVydGhlcg0KPiB0cmFmZmlj IG9uIGEgUVVJQyBjb25uZWN0aW9uIHdpdGggdGhlIGJlZ2lubmluZyBvZiB0aGUgZmxvdy4NCj4g Pg0KPiA+IFRoZXJlIHByb2JhYmx5IG5lZWRzIHRvIGJlIHJlY29tbWVuZGF0aW9ucyBmb3IgdGlt ZS1vdXRzLCBwYXJ0aWN1bGFybHkNCj4gYXJvdW5kIHRoZSBlbmQgb2YgdGhlIGZsb3cuDQo+ID4N Cj4gPiBUaGUgcHJvdG9jb2wgZG9jIG5lZWRzIHRvIGRlc2NyaWJlIHdoYXQgaGFwcGVucyB3aXRo IGFzc29jaWF0ZWQgSUNNUC4NCj4gPg0KPiA+IFRoZSBwcm90b2NvbCBuZWVkcyB0byBzYXkgd2hh dCBoYXBwZW5zIHdoZW4gYSBuZXR3b3JrIG9yIGhvc3QgcmVjZWl2ZXMgYQ0KPiBRVUlDIHBhY2tl dCBpdCB3YXNu4oCZdCBleHBlY3RpbmcuDQo+ID4NCj4gPiBXZSBuZWVkIHRvIHRoaW5rIGFib3V0 IHJldHVybiByb3V0YWJpbGl0eS4NCj4gPg0KPiA+IFRoZSBwcm90b2NvbCBuZWVkcyB0byBrZWVw IGluIG1pbmQgdGhhdCBzdGF0ZSB3aWxsIGJlIGdlbmVyYXRlZCBpbiB0aGUNCj4gbmV0d29yaywg c28gdGhhdCBhcyB3ZSBhZGQgbXVsdGktcGF0aCBleHRlbnNpb25zIChmb3IgZXhhbXBsZSksIHdl IGRvbuKAmXQNCj4ganVzdCBzdGFydCBzZW5kaW5nIHRyYWZmaWMgb24gYSBuZXcgcGF0aCB3aXRo b3V0IGZpcnN0IHN0YXJ0aW5nIGEgbmV3DQo+IGZsb3cuDQo+ID4NCj4gPiBJdCBpcyBwb3NzaWJs ZSB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gZGVzY3JpYmUgd2hhdCBhIGxvYWQgYmFsYW5jZXINCj4g c2hvdWxkIGRvIHdoZW4gaXQgZHJvcHMgUVVJQyBzdGF0ZSBkdWUgdG8gYSB0aW1lb3V0IChvciB3 aGVuIGl0IGlzICphYm91dCoNCj4gdG8gZHJvcCBzdGF0ZSkuICBXZSBtaWdodCB3YW50IGl0IHRv IHNlbmQgYSBoaW50IHRvIG9uZSBvciBib3RoIG9mIHRoZQ0KPiBlbmRwb2ludHMsIHRvIGF2b2lk IGhhdmluZyB0byBkaWFnbm9zZSBtaWQtc3RyZWFtIGJsYWNrIGhvbGVzLiAgU29tZSBsb2FkDQo+ IFRDUCBsb2FkIGJhbGFuY2VycyBzZW5kIFJTVHMgaW4gYm90aCBkaXJlY3Rpb25zIGluIHRoaXMg Y2FzZSwgZm9yIGV4YW1wbGUuDQo+ID4NCj4gPiBXZSBzaG91bGQgYW5hbHl6ZSB0aGUga25vd24g YXR0YWNrcyBvbiBUQ1AgKGF0IGxlYXN0KSB0byBlbnN1cmUgdGhhdA0KPiBRVUlDIGlzIG5vdCBp bW1lZGlhdGVseSB2dWxuZXJhYmxlIHRvIHRoZSBzb3J0cyBvZiB0aGluZ3Mgd2XigJl2ZSBhbHJl YWR5DQo+IGZpeGVkIG92ZXIgdGhlIGxhc3QgNDAgeWVhcnMuDQo+ID4NCj4gPiBUaGVyZSBhcmUg cHJvYmFibHkgYSBjb3VwbGUgb2Ygb3RoZXJzLCBhbmQgSeKAmW0gb3BlbiB0byBtb2RpZnlpbmcg dGhlDQo+IGxpc3QgYXMgcGVvcGxlIHNlZSBmaXQuICBBbHRlcm5hdGVseSwgaWYgd2UgY2FuIGZp bmQgYSB3YXkgdG8gZGVzY3JpYmUNCj4gdGhlc2Uga2luZCBvZiBkaXNjdXNzaW9ucyBpbiBhIHdh eSB0aGF0IGRvZXMgbm90IGJyaW5nIGluIHRoZSBleHBsaWNpdA0KPiBwYXRoIGNvbW11bmljYXRp b24gYml0cyB0aGF0IHdlIGV4cGxvcmVkIGluIFNQVUQsIEkgdGhpbmsgdGhlIGNoYXJ0ZXINCj4g d291bGQgYmUgZWFzaWVyIHRvIHVuZGVyc3RhbmQuDQo+ID4NCj4gPj4+IFFVSUMgd2lsbCBub3Qg YmUgYWJsZSB0byBiZSBkZXBsb3llZCBvbiBzb21lIG5ldHdvcmtzLCBzdWNoIGFzIHRoZQ0KPiA+ Pj4gb25lIEknbSBvbiByaWdodCBub3csIHVubGVzcyB3ZSBkZXNjcmliZSB0aGUgY2hhbmdlcyB0 aGF0IGFyZQ0KPiBuZWNlc3NhcnkNCj4gPj4+IGZvciB0aGUgbmV0d29yayBkZXZpY2VzIHRoYXQg YXJlIGN1cnJlbnRseSBibG9ja2luZyBpdC4NCj4gPj4NCj4gPj4gVGhlcmUgYXJlIHN1Y2ggbmV0 d29ya3MuIEJ1dCB0aGVyZSBhbHNvIGFyZSBuZXR3b3JrcyB0b2RheSB0aGF0IGJsb2NrDQo+IG91 dGdvaW5nIFRDUCBjb25uZWN0aW9ucywgYmVjYXVzZSBvZiBzb21lIHBvbGljeSBjb25zaWRlcmF0 aW9ucy4gV2UgZG9uJ3QNCj4gY2hhbmdlIFRDUCBmb3IgdGhhdC4gV2Ugc2ltcGx5IGFjY2VwdCB0 aGF0IHRoZXNlIG5ldHdvcmtzIGFyZSBtYWtpbmcgYQ0KPiB0cmFkZW9mZi4gVGhleSBjYXJlIHNv IG11Y2ggYWJvdXQgc29tZSBvZiB0aGVpciBwb2xpY2llcyB0aGF0IHRoZXkgYXJlDQo+IHdpbGxp bmcgdG8gZm9yZWdvIHNvbWUgb2YgdGhlIHZhbHVlIG9mIHRoZSBJbnRlcm5ldC4gVGhhdCdzIHBy b2JhYmx5IGZpbmUuDQo+IE92ZXIgdGltZSwgdGhlIGNvc3QvYWR2YW50YWdlIGJhbGFuY2Ugb2Yg dGhlIHRyYWRlb2ZmIHdpbGwgY2hhbmdlLCBhbmQgdGhlDQo+IHBvbGljaWVzIHdpbGwgcHJvYmFi bHkgZXZvbHZlLg0KPiA+DQo+ID4gQXJlIHlvdSBzYXlpbmcgdGhhdCBwZW9wbGUgd2lsbCB3YW50 IFFVSUMgc28gbXVjaCB0aGF0IHRoZXkgd2lsbCBvcGVuDQo+IHRoZWlyIGZpcmV3YWxscyB1cCB0 byBhbGwgVURQIHRyYWZmaWMgaW4gYm90aCBkaXJlY3Rpb25zPyAgT3IgdGhhdCB0aGUNCj4gdGVy cmlibGUgdGltaW5nLWJhc2VkIGhldXJpc3RpY3Mgd2UgaGF2ZSBmb3IgZ2VuZXJpYyBVRFAgd2ls bCBiZSBlbm91Z2gNCj4gZm9yIGEgbGFyZ2UgZW50ZXJwcmlzZT8gIE9yIHRoYXQgdGhlIGN1cnJl bnQgcHJvdG9jb2wgZGVzY3JpcHRpb24sIHdpdGhvdXQNCj4gZGlzY3Vzc2lvbiBhbmQgYW5hbHlz aXMsIHNob3VsZCBiZSBwcmVzdW1lZCB0byBiZSBwZXJmZWN0IGluIHRoaXMgcmVnYXJkPw0KPiA+ DQo+ID4gRm9yIG9uY2UsIHdlIGhhdmUgYSBjaGFuY2UgdG8gZG8gc29tZSB0aG91Z2h0ZnVsIGVu Z2luZWVyaW5nIGJlZm9yZSBhDQo+IHByb3RvY29sIGlzIGZ1bGx5IHNwZWNpZmllZCB0byBjb25z aWRlciBob3cgaXQgd2lsbCBiZSBkZXBsb3llZCwgYmFraW5nDQo+IGRlY2FkZXMgb2YgbGVhcm5p bmcgaW50byB0aGUgZGVzaWduLiAgSSB0aGluayB0aGUgYXBwcm9hY2ggdGhhdCB0aGUgVExTDQo+ IHdvcmtpbmcgZ3JvdXAgaGFzIGJlZW4gZG9pbmcgb24gVExTIDEuMyB0byBjb25zaWRlciBhdHRh Y2sgdmVjdG9ycywNCj4gYmFja3dhcmQtY29tcGF0aWJpbGl0eSwgZXRjLiBpcyBhIG1vZGVsIGZv ciB3aGF0IGlzIG5lZWRlZCBmcm9tIGEgcHJvdG9jb2wNCj4gb2YgUVVJQ+KAmXMgcG90ZW50aWFs IGltcGFjdC4NCj4gPg0KPiA+IC0tDQo+ID4gSm9lIEhpbGRlYnJhbmQNCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gUVVJQyBtYWls aW5nIGxpc3QNCj4gPiBRVUlDQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9xdWljDQoNCg== From nobody Fri Jun 17 06:38:36 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4C012D5D5 for ; Fri, 17 Jun 2016 06:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 MtkS090oIESR for ; Fri, 17 Jun 2016 06:38:33 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 7D09E12D5AB for ; Fri, 17 Jun 2016 06:38:33 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id h14so15889028pfe.1 for ; Fri, 17 Jun 2016 06:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YmERYvN6mKCrANRBqlw/V/Pz9FqQdedbI+9yXkWQL2U=; b=JbONUoFHpDWlEJ3Ath2jPefMVu2Lfb9zUNSZhtIQKw6RzJIarp1md4lfZP4wOibGn9 x/JkGHxt51fPuCt9GLzZ9oTpBaC44XCojkDWfRQOhSxiaAEDbWDLTztEhxBMC1t7pw/e M+K/Z3YN98aeyyrcWuS7dlckWLsNvc1+7AGSI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YmERYvN6mKCrANRBqlw/V/Pz9FqQdedbI+9yXkWQL2U=; b=gDhejKx7BTTmibrh8qSAF3uTRMKFgpjra249RaCsx02hNSa1O9zwV1YFZQedMRwQuV H8tbL8lmpGMFWLiXccPcxzTes4dSE2KihHIFzF4q80n74CRFm5Kth1x3lZCLluI1mEFs o5zibYbjwxTxVaodJf/iApiLRbsAdWBxZMriOTZm+dn0O8BBwq/ISPwB5AEph6ThwKTs 4MVr2mRVh5obfU+U5f44h+uoa3ye4idwCma5s7JbGrcYbj4ydLHR5mX9zRIyuoLhLc5o fv7soQzfjMONtbZnBOJU8/bwfnOD6XldNO36a55wU0iM7pAHV+9MqkDyEnauRgi9q/9y 1ocg== X-Gm-Message-State: ALyK8tI31bV+CQOVmIMFhmO0ek7mFWb+PT3L5cob4/aZv+QFbHMNr/KYO1dIh63NgtG9+SlX X-Received: by 10.98.33.23 with SMTP id h23mr2514430pfh.42.1466170712718; Fri, 17 Jun 2016 06:38:32 -0700 (PDT) Received: from [172.20.0.165] ([12.157.112.125]) by smtp.gmail.com with ESMTPSA id w194sm60116056pfd.58.2016.06.17.06.38.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 17 Jun 2016 06:38:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: Date: Fri, 17 Jun 2016 06:38:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> To: =?utf-8?Q?Michael_T=C3=BCxen?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:38:35 -0000 All: So I think the final list of features that have so far been mentioned as = requirements are: 1. Legacy NAT traversal (doable via UDP encapsulation) 2. Pacing 3. FEC 4. Path MTU limit 5. Fast connection setup 6. Improved loss recovery 7. CC agility 8. Encryption of transport layer information 9. Multi-Streaming 10. Implementable in User Space 11. 0-RTT connection setup^^ Now from the perspective of my employer and our current network, I would = like to see=20 a couple of other things added: 12. It *must* be implementable in the kernel (i.e. no floating point, or = at least integer equivalents to=20 any floating point operations defined). 13. The ability to do LRO/TSO in some fashion, this does *not* exclude = the possibility of enhanced hardware (i.e. we are not limited to the current set of = hardware).. but we should have some provision to gain TSO especially. I realize this is in = opposition (somewhat) to the encrypt every part but a bare minimum seen by middle boxes.. = but I think its needed :-) ^^ In cases where two endpoints have never talked to each other 0 RTT = would not be required. -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Fri Jun 17 07:00:43 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA6812D607 for ; Fri, 17 Jun 2016 07:00:41 -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 2cMlQ_VSeK5B for ; Fri, 17 Jun 2016 07:00:39 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4668312D5E7 for ; Fri, 17 Jun 2016 07:00:38 -0700 (PDT) Received: from public-docking-cx-0298.ethz.ch (public-docking-pat-cx-mapped-0012.ethz.ch [195.176.111.13]) by trammell.ch (Postfix) with ESMTPSA id 11B671A19BA; Fri, 17 Jun 2016 16:00:07 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_544C0DB5-B3C0-44DA-BF57-78F5895BB798"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Fri, 17 Jun 2016 16:00:07 +0200 Message-Id: <451E945B-3DCC-4A30-8AE6-F128D48FD87C@trammell.ch> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> To: Randall Stewart X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Jana Iyengar Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:00:41 -0000 --Apple-Mail=_544C0DB5-B3C0-44DA-BF57-78F5895BB798 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17 Jun 2016, at 15:38, Randall Stewart wrote: >=20 > All: >=20 > So I think the final list of features that have so far been mentioned = as requirements are: >=20 > 1. Legacy NAT traversal (doable via UDP encapsulation) > 2. Pacing > 3. FEC > 4. Path MTU limit > 5. Fast connection setup > 6. Improved loss recovery > 7. CC agility > 8. Encryption of transport layer information > 9. Multi-Streaming > 10. Implementable in User Space > 11. 0-RTT connection setup^^ >=20 > Now from the perspective of my employer and our current network, I = would like to see > a couple of other things added: >=20 > 12. It *must* be implementable in the kernel (i.e. no floating point, = or at least integer equivalents to > any floating point operations defined). > 13. The ability to do LRO/TSO in some fashion, this does *not* exclude = the possibility of > enhanced hardware (i.e. we are not limited to the current set of = hardware).. but we should > have some provision to gain TSO especially. I realize this is in = opposition (somewhat) to > the encrypt every part but a bare minimum seen by middle boxes.. = but I think its needed :-) One clarifying question: Is the requirement here really "segmentation offload," or is the = requirement "minimize context switching"? Cheers, Brian >=20 >=20 > ^^ In cases where two endpoints have never talked to each other 0 RTT = would not be required. > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_544C0DB5-B3C0-44DA-BF57-78F5895BB798 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 iQIcBAEBCgAGBQJXZAJnAAoJEIoSt78L6kajAy4QAKXPJYbQzrbi3kGytJkkDxGt SbFab9T5HAVstb3MHCVWJB/16tlNiwthVMSA1pY+dPJFghqOiTNevxBMgNuglRpV G8H8tqDG/abT2pML3XZcLzRCCXs/yk8OS2QpOp2OyUH9idS1Ep80o14+fw3X8uvd m40hNUknoAKkqv6pCHl3BsY2iw69Vq7oN+6g81BygEFX2/4zVD9lPBG9GhUpGg/2 PZRSo5vG2NMsIaO17EkvYshcbqwiUkT188qXJqv8SLYJx2jgHuaTVrzzysMhi5NS foNVHN+scrI9TJOCxymwJw30xFmztclvcUmglavhTglMvOxdUYdGM7iz/FxyWNl3 7OK7d+aDHMhMB7adMNp8sU0+wKsl9rTX3JObhgLQhfbV9DgMK80SN4XvloGKZBd+ dRo2UIZU+KucJkQZQtq8fePgtnB3funN0o6yZ6/acrqRtYWIamQieRDvLbKkUWKv dhfs2ZVkes6U4xPSG2MDJ3HaQorzKqZES2gmQcscEHWm4vdb+h7x3HYwW04MjqiY CUS3uR4cJ+xcSu8hMCD3GPD03I6xXLkDbcxTX4V5ppCB59CGfL+9m/WcP5mdZ0l2 zsqQUsRoNG1P/HYShsOJdZu2fqvwUZ+vQoZfHyhq7cvLftAT5zaW4+zSl9bkT8Bj B3lW/AZRuAS61dlDOi/V =rV0k -----END PGP SIGNATURE----- --Apple-Mail=_544C0DB5-B3C0-44DA-BF57-78F5895BB798-- From nobody Fri Jun 17 07:03:56 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFF612D6A7 for ; Fri, 17 Jun 2016 07:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 aUDOJ-_IF7ME for ; Fri, 17 Jun 2016 07:03:39 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB69D12D5C0 for ; Fri, 17 Jun 2016 07:03:38 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id b5so28913756pas.3 for ; Fri, 17 Jun 2016 07:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5emuEKNaadDMcgp4nt7pyAfaPqJI1e3CE67p4KXSAQE=; b=PNTNbimUpoXkdhN4OF9iQANhUYHI0+cXMSSKcMS6mp+QcQ9fPNEc05vBifV1vZdOC7 I2Z1MaAeeyyxVygx1qVyUq+eWpYVuAWs0wB89EFELk7y9axIhoscyM7Oez4FK/Ubiadj 0FXSLMrGjEpwb1+Aer425atbJ2iWOL7mPYDa8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5emuEKNaadDMcgp4nt7pyAfaPqJI1e3CE67p4KXSAQE=; b=P1eFuQq7ihQXqRKKFwUvfJ++1GYMxx+FEGoE+P8gzsp4hcA1LKfgnnHaOmSF69l0AU /ehud+TkkIPa5JtgDpJxZt3K75drfvxflKy4yCGp5i8PNL3Q/dhPUfOH+LCsz9LhDHx8 6ZeCKqfzHF+gHMc9v3ce7MDnQfS1oylg3xrtrFHw5mAj9mLwOzwFI51ZCe44p1597Y34 J8zLZXXCyw2GwO/3Z0Qo0AI7tnMCPMP9Lt1C8E52Far/gn9f8CLratBsMmXqfnQLasxJ v8wkGbLXzf9bdFrZclihqQe9aQNjQsMKPJxlwovOkPCu9+Q/5TJBnxCR6WVB/0a7j5kM QWzQ== X-Gm-Message-State: ALyK8tLRChyHnBgfMubpfZjY4pZEJ/8UN2hWW/ZAgsyItXi26FXRUeL49zGH19FO2FjkURC4 X-Received: by 10.66.85.197 with SMTP id j5mr2579470paz.87.1466172218258; Fri, 17 Jun 2016 07:03:38 -0700 (PDT) Received: from [10.16.208.207] ([69.53.240.0]) by smtp.gmail.com with ESMTPSA id r7sm11684949pfa.3.2016.06.17.07.03.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 17 Jun 2016 07:03:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: <451E945B-3DCC-4A30-8AE6-F128D48FD87C@trammell.ch> Date: Fri, 17 Jun 2016 07:03:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23946A08-826F-4A44-99C5-5F490A3FCC29@netflix.com> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> <451E945B-3DCC-4A30-8AE6-F128D48FD87C@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Jana Iyengar Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:03:46 -0000 > On Jun 17, 2016, at 7:00 AM, Brian Trammell wrote: >=20 >>=20 >> On 17 Jun 2016, at 15:38, Randall Stewart wrote: >>=20 >> All: >>=20 >> So I think the final list of features that have so far been mentioned = as requirements are: >>=20 >> 1. Legacy NAT traversal (doable via UDP encapsulation) >> 2. Pacing >> 3. FEC >> 4. Path MTU limit >> 5. Fast connection setup >> 6. Improved loss recovery >> 7. CC agility >> 8. Encryption of transport layer information >> 9. Multi-Streaming >> 10. Implementable in User Space >> 11. 0-RTT connection setup^^ >>=20 >> Now from the perspective of my employer and our current network, I = would like to see >> a couple of other things added: >>=20 >> 12. It *must* be implementable in the kernel (i.e. no floating point, = or at least integer equivalents to >> any floating point operations defined). >> 13. The ability to do LRO/TSO in some fashion, this does *not* = exclude the possibility of >> enhanced hardware (i.e. we are not limited to the current set of = hardware).. but we should >> have some provision to gain TSO especially. I realize this is in = opposition (somewhat) to >> the encrypt every part but a bare minimum seen by middle boxes.. = but I think its needed :-) >=20 > One clarifying question: >=20 > Is the requirement here really "segmentation offload," or is the = requirement "minimize context switching=E2=80=9D? Its not minimizing context switching :-) We really need Segmentation offload.. when that is turned off the CPU = performance goes into the dumper=E2=80=A6=20 Without TSO/LRO (and especially TSO) our performance is cut by at least = 50% R >=20 > Cheers, >=20 > Brian >=20 >>=20 >>=20 >> ^^ In cases where two endpoints have never talked to each other 0 RTT = would not be required. >> -------- >> Randall Stewart >> rrs@netflix.com >> 803-317-4952 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Fri Jun 17 07:49:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CA412D62F for ; Fri, 17 Jun 2016 07:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 m6l__qn_EN1g for ; Fri, 17 Jun 2016 07:49:15 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D3612D625 for ; Fri, 17 Jun 2016 07:49:15 -0700 (PDT) Received: from [192.168.1.102] (p508F0051.dip0.t-ipconnect.de [80.143.0.81]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 528CA721E280D; Fri, 17 Jun 2016 16:49:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: <23946A08-826F-4A44-99C5-5F490A3FCC29@netflix.com> Date: Fri, 17 Jun 2016 16:49:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <347EAB6E-9A7B-4548-95EA-4755F394DB5B@lurchi.franken.de> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> <451E945B-3DCC-4A30-8AE6-F128D48FD87C@trammell.ch> <23946A08-826F-4A44-99C5-5F490A3FCC29@netflix.com> To: Randall Stewart X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Jana Iyengar Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:49:18 -0000 > On 17 Jun 2016, at 16:03, Randall Stewart wrote: >=20 >=20 >> On Jun 17, 2016, at 7:00 AM, Brian Trammell wrote: >>=20 >>>=20 >>> On 17 Jun 2016, at 15:38, Randall Stewart wrote: >>>=20 >>> All: >>>=20 >>> So I think the final list of features that have so far been = mentioned as requirements are: >>>=20 >>> 1. Legacy NAT traversal (doable via UDP encapsulation) >>> 2. Pacing >>> 3. FEC >>> 4. Path MTU limit >>> 5. Fast connection setup >>> 6. Improved loss recovery >>> 7. CC agility >>> 8. Encryption of transport layer information >>> 9. Multi-Streaming >>> 10. Implementable in User Space >>> 11. 0-RTT connection setup^^ >>>=20 >>> Now from the perspective of my employer and our current network, I = would like to see >>> a couple of other things added: >>>=20 >>> 12. It *must* be implementable in the kernel (i.e. no floating = point, or at least integer equivalents to >>> any floating point operations defined). >>> 13. The ability to do LRO/TSO in some fashion, this does *not* = exclude the possibility of >>> enhanced hardware (i.e. we are not limited to the current set of = hardware).. but we should >>> have some provision to gain TSO especially. I realize this is in = opposition (somewhat) to >>> the encrypt every part but a bare minimum seen by middle boxes.. = but I think its needed :-) >>=20 >> One clarifying question: >>=20 >> Is the requirement here really "segmentation offload," or is the = requirement "minimize context switching=E2=80=9D? >=20 > Its not minimizing context switching :-) >=20 > We really need Segmentation offload.. when that is turned off the CPU = performance goes into the > dumper=E2=80=A6=20 >=20 > Without TSO/LRO (and especially TSO) our performance is cut by at = least 50% Would it be a way to say 13. Ability for offload protocol processing to hardware, for example by = future NICs. This would allow things like LRO/TSO (which means some sort of packet = batching), checksumming, hashing, encryption, decryption offload, or whatever makes = sense for the particular protocol. Best regards Michael >=20 > R >=20 >>=20 >> Cheers, >>=20 >> Brian >>=20 >>>=20 >>>=20 >>> ^^ In cases where two endpoints have never talked to each other 0 = RTT would not be required. >>> -------- >>> Randall Stewart >>> rrs@netflix.com >>> 803-317-4952 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> QUIC mailing list >>> QUIC@ietf.org >>> https://www.ietf.org/mailman/listinfo/quic >=20 > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 From nobody Fri Jun 17 07:52:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757DC12D686 for ; Fri, 17 Jun 2016 07:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 Rp7wfAzZXrsF for ; Fri, 17 Jun 2016 07:52:04 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1B612D625 for ; Fri, 17 Jun 2016 07:52:00 -0700 (PDT) Received: from [192.168.1.102] (p508F0051.dip0.t-ipconnect.de [80.143.0.81]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id EF30E721E280D; Fri, 17 Jun 2016 16:51:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Tuexen In-Reply-To: Date: Fri, 17 Jun 2016 16:51:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3556BF13-6B9C-48B0-BBD4-AF6220DA2E02@lurchi.franken.de> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> To: Randall Stewart X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:52:06 -0000 > On 17 Jun 2016, at 15:38, Randall Stewart wrote: >=20 > All: >=20 > So I think the final list of features that have so far been mentioned = as requirements are: >=20 > 1. Legacy NAT traversal (doable via UDP encapsulation) > 2. Pacing > 3. FEC I think FEC is at a different requirements level as the other = requirements. At least this is not considered as a core feature according to https://github.com/IETF-QUIC/Charter/blob/master/quic-charter.md Best regards Michael > 4. Path MTU limit > 5. Fast connection setup > 6. Improved loss recovery > 7. CC agility > 8. Encryption of transport layer information > 9. Multi-Streaming > 10. Implementable in User Space > 11. 0-RTT connection setup^^ >=20 > Now from the perspective of my employer and our current network, I = would like to see=20 > a couple of other things added: >=20 > 12. It *must* be implementable in the kernel (i.e. no floating point, = or at least integer equivalents to=20 > any floating point operations defined). > 13. The ability to do LRO/TSO in some fashion, this does *not* exclude = the possibility of > enhanced hardware (i.e. we are not limited to the current set of = hardware).. but we should > have some provision to gain TSO especially. I realize this is in = opposition (somewhat) to > the encrypt every part but a bare minimum seen by middle boxes.. = but I think its needed :-) >=20 >=20 >=20 >=20 > ^^ In cases where two endpoints have never talked to each other 0 RTT = would not be required. > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 From nobody Fri Jun 17 09:10:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B26112D7FA for ; Fri, 17 Jun 2016 09:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 67LtCYELRtL6 for ; Fri, 17 Jun 2016 09:09:32 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) (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 8C1F012D7F8 for ; Fri, 17 Jun 2016 09:09:25 -0700 (PDT) Received: from [85.158.138.179] by server-5.bemta-3.messagelabs.com id B1/23-02783-3B024675; Fri, 17 Jun 2016 16:09:23 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRWlGSWpSXmKPExsVy+MWXDt3NCin hBrd+8Vn0LOB2YPRYsuQnUwBjFGtmXlJ+RQJrxvklrewFF/gqXt7dy9rA2MzTxcjFISRwgVFi 4fYnrBDOXkaJpz1bWSCc3UwS83cfYIRwjjBKNF07xQ7hbGaU+Hj6IFAZJwebgKvE0V132EFsE QFliTlLF4PZwgJmEg/fTgWaywEUt5a4fzodokRPYk3TLUYQm0VAVeLM7l42EJtXIFRiz7Z7YC MZBWQlvjSuZgaxmQXEJW49mc8EYksICEgs2XOeGcIWlXj5+B8rRI2OxILdn9ggbG2JZQtfM0P MFJQ4OfMJywRG4VlIRs1C0jILScssJC0LGFlWMaoXpxaVpRbpmuolFWWmZ5TkJmbm6BoaGOvl phYXJ6an5iQmFesl5+duYgRGQD0DA+MOxstfnQ4xSnIwKYnyRrCnhAvxJeWnVGYkFmfEF5Xmp BYfYpTh4FCS4P0gB5QTLEpNT61Iy8wBxiJMWoKDR0mE9wFImre4IDG3ODMdInWKUVFKnFcMGM FCAiCJjNI8uDZY/F9ilJUS5mVkYGAQ4ilILcrNLEGVf8UozsGoJMz7G2Q8T2ZeCdz0V0CLmYA Wa85LBllckoiQkmpgPOL1LOnCCefJKVzrkyPuM19Lsz0vm+lzselRwHem9a/Wh5ilWRR/NPXl Mjl782ekd6n19+UHz/++XfHEKOBt2+FvV50uhlX9+5HU25hk9Shzz2+hp5osX+aIXuN9FubTt /bGb46VO968+S6T19gnwNrs5V8Zr3/e85tRk/zTLeIT7e1eu96RVGIpzkg01GIuKk4EAEfpsY v6AgAA X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-8.tower-169.messagelabs.com!1466179762!44802777!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23654 invoked from network); 17 Jun 2016 16:09:23 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-8.tower-169.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 17 Jun 2016 16:09:23 -0000 Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout04.vodafone.com (Postfix) with ESMTP id 3rWQDf6lv6znV6s for ; Fri, 17 Jun 2016 18:09:22 +0200 (CEST) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3rWQDf4bGdzQvcL for ; Fri, 17 Jun 2016 18:09:22 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3rWQDf4GSyzQv0r for ; Fri, 17 Jun 2016 18:09:22 +0200 (CEST) Received: from AVOEXH03W.internal.vodafone.com (145.230.15.141) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 17 Jun 2016 18:09:22 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.75]) by AVOEXH03W.internal.vodafone.com ([145.230.15.141]) with mapi id 14.03.0224.002; Fri, 17 Jun 2016 18:09:22 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "quic@ietf.org" Thread-Topic: Re: [QUIC] Network Path Requirements for QUIC Thread-Index: AdHIspJzdBqAKTv5SGSPAf5nwhBxPw== Date: Fri, 17 Jun 2016 16:09:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 17 Jun 2016 09:10:20 -0700 Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 16:09:33 -0000 Dan and Joe, many thanks for drafting this. >1. Introduction > Unfortunately, the lack of header information in QUIC prevents the networ= k path from identifying QUIC traffic=20 Well, it's not _prevented_ from being identified by a network probe, becaus= e of the QUIC public flags: but yes, an IANA protocol number for the IP hea= der would indeed help get QUIC through anti-UDP firewalls and make the QUIC= distinction from other UDP faster. > 3. Association with Existing Consent > [...] If QUIC does not allow the path to associate packets with a consent= at greater assurance than just matching the 5-tuple (relying on the endpoint software to filt= er all attacks) the network cannot filter attacks such as denials of servic= e. The public ConnectionID should allow that assurance, no? Or do you mean spe= cifically at the firewall which may not be looking beyond IP headers? > 4. Long-lived Connections and HTTP Server Push The public ConnectionID could help here as well, to detect a QUIC connectio= n and allow a longer-lived firewall pinhole. But again this depends on the = firewall capability. Please can you expand on the HTTP Server Push case? Currently our firewalls= allow UDP for network-attached device requests, which open a firewall pinh= ole for a set time. Unsolicited UDP pushed from the Internet will be subjec= t to blocking or rate-limiting, so assuring the consent is important here. 5. Identification > Recommendation: Provide path-visible mechanism to identify a QUIC packet. Specifically I'd like that in the IP header (i.e. IANA number) for performa= nce. (and from a later point by Joe:) > The protocol needs to say what happens when a network or host receives a = QUIC packet it wasn't expecting.=20 Yes, and knowing quickly that it is a _QUIC_ packet certainly helps. All best, Kevin Mr Kevin Smith=20 Vodafone R&D From nobody Fri Jun 17 09:45:39 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA0C12D158 for ; Fri, 17 Jun 2016 09:45:37 -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 OOl8dvXB5pjD for ; Fri, 17 Jun 2016 09:45:35 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F5F12D09C for ; Fri, 17 Jun 2016 09:45:35 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id m124so7153317wme.1 for ; Fri, 17 Jun 2016 09:45:35 -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=lw/YJX/qCfpZVvvrCYKA2oHX3UHvtYUzg3F4dLN+Ru4=; b=S5quXxwqfmUOURHc0xIrByVrp9bj/JHwpoIGjQJjcjpl9YaaRO/BiGcfLyYqntjQjc lh5qkIen5myK5x8AwdF61gZx8ZWoT6+O2xBCtlEgRmb0TMhWOZCUYsHRrJ+z2sY+Exo0 2sKyAGr5Ctrl/muloRRxzCv4XnX+jn0+L13TsNKOyfHhdsY2DXOFdP4QZjt2Ne3SRrNI DvyAywUY8UwcNpdEWyvi6vFHEbBGOXa+AKVQYRcc8R01MOvE2gqR1FP8iVjimye7Htkx TXhm1bO74H77H+g900yOZh5iLyM01Aq9jpMnG3zozT96jbak2fWZgtvxXwbHugADpILi ANUg== 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=lw/YJX/qCfpZVvvrCYKA2oHX3UHvtYUzg3F4dLN+Ru4=; b=OlKAxr+pippWeXcdcN3D3jXoRwQUTpgE7mm4/rhVtodCsPNcnUymZbNg8eEriEIj5C CTBskyx2bqKCh5rMsrfzZ/fQUmT0/sToxsd278hwKYelZqNgpzV/+vG+qbLV1JKy+Uh1 PP2F/ZG3AHSVfG2qWqxgeXJSqwu2PdajiJ8s7l0+Xcm6gTdmRB8WIFZw1HxMyf/9EQ4S 5SMm+V9ZtSWJl6HOKysPOZesEqU2VOlZcSMzVGDHhWuG369qOdlETVJllnnd2oujSN4N aql32ljLLxA0cLjSDUxpytqd136SI6eUObVXxbDqbNZ/YW/pPM6zqQFi01FjqxTjg+wZ VKeg== X-Gm-Message-State: ALyK8tK1IHgLCsAcp21LqYh/3nTKpZ5kYbE2JaUko9xVEQIDyx78yM3NEXXjxexdzUPyoPjDNEAd62IVnDwj9FCd X-Received: by 10.28.166.150 with SMTP id p144mr545612wme.57.1466181933733; Fri, 17 Jun 2016 09:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.154.83 with HTTP; Fri, 17 Jun 2016 09:45:14 -0700 (PDT) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Fri, 17 Jun 2016 09:45:14 -0700 Message-ID: To: "Smith, Kevin, (R&D) Vodafone Group" Content-Type: multipart/alternative; boundary=94eb2c127cd0567aa605357c153d Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 16:45:37 -0000 --94eb2c127cd0567aa605357c153d Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 9:09 AM, Smith, Kevin, (R&D) Vodafone Group < Kevin.Smith@vodafone.com> wrote: > Dan and Joe, many thanks for drafting this. > > >1. Introduction > > Unfortunately, the lack of header information in QUIC prevents the > network path from identifying QUIC > traffic > > Well, it's not _prevented_ from being identified by a network probe, > because of the QUIC public flags: but yes, an IANA protocol number for the > IP header would indeed help get QUIC through anti-UDP firewalls and make > the QUIC distinction from other UDP faster. > > > 3. Association with Existing Consent > > [...] If QUIC does not allow the path to associate packets with a > consent at greater assurance > than just matching the 5-tuple (relying on the endpoint software to > filter all attacks) the network cannot filter attacks such as denials of > service. > > The public ConnectionID should allow that assurance, no? Or do you mean > specifically at the firewall which may not be looking beyond IP headers? > > > 4. Long-lived Connections and HTTP Server Push > The public ConnectionID could help here as well, to detect a QUIC > connection and allow a longer-lived firewall pinhole. But again this > depends on the firewall capability. > > Please can you expand on the HTTP Server Push case? Currently our > firewalls allow UDP for network-attached device requests, which open a > firewall pinhole for a set time. Unsolicited UDP pushed from the Internet > will be subject to blocking or rate-limiting, so assuring the consent is > important here. > > HTTP/2.0 server push is not fully general push, and specifically does not allow unsolicited pushes, the RFC says "Pushed responses are always associated with an explicit request from the client". 5. Identification > > Recommendation: Provide path-visible mechanism to identify a QUIC packet. > Specifically I'd like that in the IP header (i.e. IANA number) for > performance. > > (and from a later point by Joe:) > > The protocol needs to say what happens when a network or host receives a > QUIC packet it wasn't expecting. > > Yes, and knowing quickly that it is a _QUIC_ packet certainly helps. > > All best, > Kevin > > Mr Kevin Smith > Vodafone R&D > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --94eb2c127cd0567aa605357c153d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 17, 2016 at 9:09 AM, Smith, Kevin, (R&D) Vodafone Group= <Kevin.Sm= ith@vodafone.com> wrote:
Dan and Joe, man= y thanks for drafting this.

>1.=C2=A0 Introduction
> Unfortunately, the lack of header information in QUIC prevents the net= work path from identifying QUIC
=C2=A0 =C2=A0traffic

Well, it's not _prevented_ from being identified by a network probe, be= cause of the QUIC public flags: but yes, an IANA protocol number for the IP= header would indeed help get QUIC through anti-UDP firewalls and make the = QUIC distinction from other UDP faster.

> 3.=C2=A0 Association with Existing Consent
> [...] If QUIC does not allow the path to associate packets with a cons= ent at greater assurance
=C2=A0 =C2=A0than just matching the 5-tuple (relying on the endpoint softwa= re to filter all attacks) the network cannot filter attacks such as denials= of service.

The public ConnectionID should allow that assurance, no? Or do you mean spe= cifically at the firewall which may not be looking beyond IP headers?

> 4.=C2=A0 Long-lived Connections and HTTP Server Push
The public ConnectionID could help here as well, to detect a QUIC connectio= n and allow a longer-lived firewall pinhole. But again this depends on the = firewall capability.

Please can you expand on the HTTP Server Push case? Currently our firewalls= allow UDP for network-attached device requests, which open a firewall pinh= ole for a set time. Unsolicited UDP pushed from the Internet will be subjec= t to blocking or rate-limiting, so assuring the consent is important here.<= br>
HTTP/2.0 server push is not fully general push, and s= pecifically does not allow unsolicited pushes, the RFC says "Pushed responses are always associated w= ith an explicit request from
=C2=A0 =C2=A0the client". =C2=A0=C2=A0= =C2=A0

5. Identification
> Recommendation: Provide path-visible mechanism to identify a QUIC pack= et.
Specifically I'd like that in the IP header (i.e. IANA number) for perf= ormance.

(and from a later point by Joe:)
> The protocol needs to say what happens when a n= etwork or host receives a QUIC packet it wasn't expecting.

Yes, and knowing quickly that it is a _QUIC_ packet certainly helps.=

All best,
Kevin

Mr Kevin Smith
Vodafone R&D

_______________________________________________
QUIC mailing list
QUIC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/quic



--
=
Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--94eb2c127cd0567aa605357c153d-- From nobody Fri Jun 17 12:12:36 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B523812D9D9 for ; Fri, 17 Jun 2016 12:12:34 -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 yT4Vv_eYXI_g for ; Fri, 17 Jun 2016 12:12:33 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE98812D9D8 for ; Fri, 17 Jun 2016 12:12:32 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id f126so816536wma.1 for ; Fri, 17 Jun 2016 12:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J+fkJ4296CjUzvIpmcExaohGc7xEDVILk7+sgMeb88I=; b=zHdVkmr5X6zROKu6N9lR8U9t7oYM7pVJ7cWsSV2/9FwH8f8ZrlU8C/Y7jfRvXp61I2 EaAW09vRPPc0LYAuIGgZXI6Wx3xP1/aeEPFUGTjhQgOIEnQdoO7TqxHrYr/2s0u9585u 6Ew5lXnXW1aYDily6s4d8AuFCi6NKu++sdJECK7JSJGNQ/efn/hL4aVXXxp7EJtSVoss e/yTgNzPtt/5npGVjA8TibxftKmMlQBpv8NUJJSAO5xtB8Mp8CEwucLh89iNeyedypRP ouRfxpNM+XS5jp7y7GYaZnlswhB0GGt24kYHQ6Nj5cF0dbE2a6vidaln+xDbjYr5iNr6 y6CA== 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=J+fkJ4296CjUzvIpmcExaohGc7xEDVILk7+sgMeb88I=; b=RXClxZfFfj/pK2C5Wn2Za42D5hV26c3d2CvJabUR2BUU1qNQzsAhiudZxPvGu8hSrm xDwGDA7jTpqQjoEaHO84MxgTSFsPGdHSdjbhqANbwOVGNtprKwzyWpzIr6Q0Ei3pXGfF 1JctD9lHFwXeIuoxezMALdokp4h4ccvNeGB071D9rlZLvERN+s3kmphqcJZhnVfSPl/t ttLmAzt5kmUzRDAUGySx2o0fyya/INHyrD4oXjPPAIm1whvVrqvEmVZGma65g9kgC6Y/ zm5QPp8K5wK+uNQZXLH4Nq3apbAv0iKWBbHmHKlpX47ihLWbZu9om8K0MfigLki+K3Yv rnGw== X-Gm-Message-State: ALyK8tIr2DLB+txmRmyHtmjXlo9sN/wyg8hDbr1ZBLJ6Gllr82mZHxq4miiMBZ2MUluJ3lvYesFzMXtZbPQ7Bg== X-Received: by 10.28.184.77 with SMTP id i74mr101548wmf.66.1466190751231; Fri, 17 Jun 2016 12:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.22 with HTTP; Fri, 17 Jun 2016 12:12:30 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 17 Jun 2016 20:12:30 +0100 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ted Hardie , "quic@ietf.org" , Mirja Kuehlewind , Spencer Dawkins Subject: Re: [QUIC] Charter dates now in GitHub X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:12:35 -0000 On 14 June 2016 at 18:34, Christian Huitema wrote: >> I actually disagree with you regarding your fears about these features. I think >> that we could very easily deploy a version of QUIC that didn't have any >> allowance for partial reliability or FEC. And I think that we SHOULD do that. >> The reason being is that it gives us a good reason to have working version and >> feature negotiation much earlier in the process. This doesn't need to be a >> monolithic protocol design and development process. To me, lightweight >> version and feature negotiation are more important properties to conserve >> than some future feature. > > +1. FWIW, I have created a pull request against the proposed charter that enacts my proposal. https://github.com/IETF-QUIC/Charter/pull/10 From nobody Fri Jun 17 12:53:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2E12DA67 for ; Fri, 17 Jun 2016 12:53:39 -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 Wx5lwZlpMnBc for ; Fri, 17 Jun 2016 12:53:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB6312DA66 for ; Fri, 17 Jun 2016 12:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5182; q=dns/txt; s=iport; t=1466193216; x=1467402816; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cykOCqBSyQbOj8DyKnHHiBUitTRp8msDHDrMdVWoGEs=; b=lXhcUeYgYrs6uz8y5mU0wX14PFUWvHbopeM1zw62A2k4xRRcublyeAhX N03nIVhzXa6pQhXrn1JGqrCLZ1qYUPsNvhEXKbe8futkpf68A/rV7A/zX NESr8Cx/ao8ll/VoGJvDwJWF/p7/FeMRlIWF4xTqI5lSD6qx26ENrq38L A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgC0VGRX/5JdJa1TCoM+Vn0GuE6CD?= =?us-ascii?q?4F6gmCDNx6BCTgUAQEBAQEBAWUnhEwBBAEjEVcBCBoCJgIEMBUSBAESiCgIsDu?= =?us-ascii?q?QTgEBAQEBAQEDAQEBAQEBAQEfgQGFJoF3CIJOhBgSFoMBK4IvBZhxAY4ogWmEU?= =?us-ascii?q?ohnj3QBHjaCCByBTG6IfH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,485,1459814400"; d="scan'208";a="119868221" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 19:53:35 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5HJrZv4001002 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 19:53:36 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 17 Jun 2016 15:53:35 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 17 Jun 2016 15:53:35 -0400 From: "Joe Hildebrand (jhildebr)" To: "Smith, Kevin, (R&D) Vodafone Group" , "quic@ietf.org" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRyNHungnMNByYeE6HaTevmuxVOw== Date: Fri, 17 Jun 2016 19:53:35 +0000 Message-ID: <39812194-C385-42D3-A877-C0BC4320231D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <48E72132929E5A47916AD596ED1C5159@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:53:40 -0000 T24gNi8xNy8xNiwgMTA6MDkgQU0sICJRVUlDIG9uIGJlaGFsZiBvZiBTbWl0aCwgS2V2aW4sIChS JkQpIFZvZGFmb25lIEdyb3VwIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBL ZXZpbi5TbWl0aEB2b2RhZm9uZS5jb20+IHdyb3RlOg0KDQo+RGFuIGFuZCBKb2UsIG1hbnkgdGhh bmtzIGZvciBkcmFmdGluZyB0aGlzLg0KPg0KPj4xLiAgSW50cm9kdWN0aW9uDQo+PiBVbmZvcnR1 bmF0ZWx5LCB0aGUgbGFjayBvZiBoZWFkZXIgaW5mb3JtYXRpb24gaW4gUVVJQyBwcmV2ZW50cyB0 aGUgbmV0d29yayBwYXRoIGZyb20gaWRlbnRpZnlpbmcgUVVJQw0KPiAgIHRyYWZmaWMgDQo+DQo+ V2VsbCwgaXQncyBub3QgX3ByZXZlbnRlZF8gZnJvbSBiZWluZyBpZGVudGlmaWVkIGJ5IGEgbmV0 d29yayBwcm9iZSwgYmVjYXVzZSBvZiB0aGUgUVVJQyBwdWJsaWMgZmxhZ3M6IGJ1dCB5ZXMsIGFu IElBTkEgcHJvdG9jb2wgbnVtYmVyIGZvciB0aGUgSVAgaGVhZGVyIHdvdWxkIGluZGVlZCBoZWxw IGdldCBRVUlDIHRocm91Z2ggYW50aS1VRFAgZmlyZXdhbGxzIGFuZCBtYWtlIHRoZSBRVUlDIGRp c3RpbmN0aW9uIGZyb20gb3RoZXIgVURQIGZhc3Rlci4NCg0KSeKAmW0gd29ycmllZCBhYm91dCB0 aGUgcmVhbC13b3JsZCBkZXBsb3lhYmlsaXR5IG9mIGEgbmV3IHByb3RvY29sIG51bWJlci4gIFRo YXTigJlzIHNvbWV0aGluZyB0aGF0IHdpbGwgcmVxdWlyZSBib3RoIGVuZHBvaW50IGtlcm5lbCBj aGFuZ2VzIGFzIHdlbGwgYXMgbG90cyBvZiBuZXR3b3JrIGVxdWlwbWVudCBjaGFuZ2VzLiAgV2Xi gJl2ZSBsZWFybmVkIGZyb20gU0NUUCB0aGF0IGp1c3QgaGF2aW5nIGEgYmV0dGVyIHByb3RvY29s IGhhcyBub3QgYmVlbiBlbm91Z2ggdG8gb3ZlcmNvbWUgdGhhdCBzZXQgb2YgbGltaXRhdGlvbnMg YXQgSW50ZXJuZXQgc2NhbGUuDQoNClRoZSBRVUlDIHB1YmxpYyBmbGFncyBtYXkgb3IgbWF5IG5v dCBiZSBlbm91Z2ggdG8gZGlzdGluZ3Vpc2ggUVVJQyB0cmFmZmljIGZyb20gb3RoZXIgdHJhZmZp YyBvbiB0aGUgc2FtZSBVRFAgZGVzdGluYXRpb24gcG9ydC4gIFRoYXQgaXMgdXNlZnVsIGFuYWx5 c2lzIGZvciBhIHBvdGVudGlhbCB3b3JraW5nIGdyb3VwIHRvIHB1cnN1ZSwgYW5kIGl0IHNob3Vs ZCBiZSBpbiBzY29wZSBpbiB0aGUgY2hhcnRlci4NCg0KPj4gMy4gIEFzc29jaWF0aW9uIHdpdGgg RXhpc3RpbmcgQ29uc2VudA0KPj4gWy4uLl0gSWYgUVVJQyBkb2VzIG5vdCBhbGxvdyB0aGUgcGF0 aCB0byBhc3NvY2lhdGUgcGFja2V0cyB3aXRoIGEgY29uc2VudCBhdCBncmVhdGVyIGFzc3VyYW5j ZQ0KPiAgIHRoYW4ganVzdCBtYXRjaGluZyB0aGUgNS10dXBsZSAocmVseWluZyBvbiB0aGUgZW5k cG9pbnQgc29mdHdhcmUgdG8gZmlsdGVyIGFsbCBhdHRhY2tzKSB0aGUgbmV0d29yayBjYW5ub3Qg ZmlsdGVyIGF0dGFja3Mgc3VjaCBhcyBkZW5pYWxzIG9mIHNlcnZpY2UuDQo+DQo+VGhlIHB1Ymxp YyBDb25uZWN0aW9uSUQgc2hvdWxkIGFsbG93IHRoYXQgYXNzdXJhbmNlLCBubz8gT3IgZG8geW91 IG1lYW4gc3BlY2lmaWNhbGx5IGF0IHRoZSBmaXJld2FsbCB3aGljaCBtYXkgbm90IGJlIGxvb2tp bmcgYmV5b25kIElQIGhlYWRlcnM/DQoNClRoZSBDb25uZWN0aW9uSUQgbWF5IGJlIGVub3VnaCBm b3IgdGhpcywgaWYgd2UgY2FuIHRlbGwgd2hpY2ggZGlyZWN0aW9uIHRoZSBjb25uZWN0aW9uIGF0 dGVtcHQgaXMgZ29pbmcsIHBhcnRpY3VsYXJseSBpbiBhbGwgb2YgdGhlIGVkZ2UgY2FzZXMsIGFu ZCB3aGlsZSB0aGUgcHJvdG9jb2wgaXMgdW5kZXIgYXR0YWNrLiAgVGhlcmUgbWlnaHQgbmVlZCB0 byBiZSBzb21lIHRleHQgaW4gdGhlIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGhvdyB5b3UgdGVs bCB3aGljaCBlbmQgaXMgdGhlIGNsaWVudCwgYW5kIHRoZW4gd2hlbiBhbmQgaG93IHRvIG1haW50 YWluIGFuZCBtYXRjaCB0aGUgQ29ubmVjdGlvbklEIGluIHRoZSBuZXR3b3JrLiAgT3IgdGhlcmUg bWF5IG5vdC4gIEJ1dCBhIHBvdGVudGlhbCB3b3JraW5nIGdyb3VwIHNob3VsZCBiZSBhYmxlIHRv IGRvIHRoYXQgYW5hbHlzaXMuDQoNCg0KPj4gNC4gIExvbmctbGl2ZWQgQ29ubmVjdGlvbnMgYW5k IEhUVFAgU2VydmVyIFB1c2gNCj5UaGUgcHVibGljIENvbm5lY3Rpb25JRCBjb3VsZCBoZWxwIGhl cmUgYXMgd2VsbCwgdG8gZGV0ZWN0IGEgUVVJQyBjb25uZWN0aW9uIGFuZCBhbGxvdyBhIGxvbmdl ci1saXZlZCBmaXJld2FsbCBwaW5ob2xlLiBCdXQgYWdhaW4gdGhpcyBkZXBlbmRzIG9uIHRoZSBm aXJld2FsbCBjYXBhYmlsaXR5Lg0KPg0KPlBsZWFzZSBjYW4geW91IGV4cGFuZCBvbiB0aGUgSFRU UCBTZXJ2ZXIgUHVzaCBjYXNlPyBDdXJyZW50bHkgb3VyIGZpcmV3YWxscyBhbGxvdyBVRFAgZm9y IG5ldHdvcmstYXR0YWNoZWQgZGV2aWNlIHJlcXVlc3RzLCB3aGljaCBvcGVuIGEgZmlyZXdhbGwg cGluaG9sZSBmb3IgYSBzZXQgdGltZS4gVW5zb2xpY2l0ZWQgVURQIHB1c2hlZCBmcm9tIHRoZSBJ bnRlcm5ldCB3aWxsIGJlIHN1YmplY3QgdG8gYmxvY2tpbmcgb3IgcmF0ZS1saW1pdGluZywgc28g YXNzdXJpbmcgdGhlIGNvbnNlbnQgaXMgaW1wb3J0YW50IGhlcmUuDQoNCknigJltIGVudmlzaW9u aW5nIHRoYXQgeW91ciBmaXJld2FsbHMgd2lsbCBiZSBhYmxlIHRvIHRyZWF0IFFVSUMgY29ubmVj dGlvbnMgdmVyeSBzaW1pbGFybHkgdG8gaG93IHlvdSB0cmVhdCBUQ1AgY29ubmVjdGlvbnMsIGlu IHRlcm1zIG9mIHNlY3VyaXR5LCBidXQgd2l0aG91dCBhcyBtdWNoIGluc2lnaHQgaW50byB0aGUg Y29uZ2VzdGlvbiBhbmQgcmV0cmFuc21pc3Npb24gcHJvcGVydGllcy4gIFdlIGRvbuKAmXQgeWV0 IGhhdmUgYW5hbHlzaXMgdGhhdCBzdWdnZXN0cyB0aGF0IGl04oCZcyBwb3NzaWJsZSB0byBkbyB0 aGlzLCBob3dldmVyLCBhbmQgYSBwb3RlbnRpYWwgd29ya2luZyBncm91cCBzaG91bGQgYmUgYWJs ZSB0byBoYXZlIHRoYXQgZGlzY3Vzc2lvbi4NCg0KPjUuIElkZW50aWZpY2F0aW9uDQo+PiBSZWNv bW1lbmRhdGlvbjogUHJvdmlkZSBwYXRoLXZpc2libGUgbWVjaGFuaXNtIHRvIGlkZW50aWZ5IGEg UVVJQyBwYWNrZXQuDQo+U3BlY2lmaWNhbGx5IEknZCBsaWtlIHRoYXQgaW4gdGhlIElQIGhlYWRl ciAoaS5lLiBJQU5BIG51bWJlcikgZm9yIHBlcmZvcm1hbmNlLg0KPg0KPihhbmQgZnJvbSBhIGxh dGVyIHBvaW50IGJ5IEpvZTopDQo+PiBUaGUgcHJvdG9jb2wgbmVlZHMgdG8gc2F5IHdoYXQgaGFw cGVucyB3aGVuIGEgbmV0d29yayBvciBob3N0IHJlY2VpdmVzIGEgUVVJQyBwYWNrZXQgaXQgd2Fz bid0IGV4cGVjdGluZy4gDQo+DQo+WWVzLCBhbmQga25vd2luZyBxdWlja2x5IHRoYXQgaXQgaXMg YSBfUVVJQ18gcGFja2V0IGNlcnRhaW5seSBoZWxwcy4NCg0KTm9kLiAgV2UgY3VycmVudGx5IGhh dmUgYSBRVUlDIHZlcnNpb24gbnVtYmVyIHRoYXTigJlzIHZpc2libGUsIGJ1dCB0aGF0IHZlcnNp b24gbnVtYmVyIHdpbGwgY2hhbmdlIG92ZXIgdGltZS4gIFRoZSBhbmFseXNpcyB0aGF0IHdlIGRp ZCBmb3IgdGhlIFNQVUQgcHJvdG90eXBlIHNob3dlZCB0aGF0IHRoZSBtYWdpYyBudW1iZXIgd2Ug cGlja2VkIHJlbmRlcmVkIFNQVUQgcGFja2V0cyBkaXN0aW5ndWlzaGFibGUgZnJvbSB0aGUgZXhp c3Rpbmcgd2lkZWx5LWRlcGxveWVkIFVEUCBwcm90b2NvbHMuICBTaW1pbGFyIGFuYWx5c2lzIHNo b3VsZCBiZSBkb25lIGZvciBRVUlDIGJ5IGEgcG90ZW50aWFsIHdvcmtpbmcgZ3JvdXAuDQoNCi0t IA0KSm9lIEhpbGRlYnJhbmQNCg0KDQo= From nobody Fri Jun 17 12:55:12 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C5812DA6F for ; Fri, 17 Jun 2016 12:55:10 -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 mUQV-u4JzpVj for ; Fri, 17 Jun 2016 12:55:08 -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 DCA5412DA6A for ; Fri, 17 Jun 2016 12:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11040; q=dns/txt; s=iport; t=1466193307; x=1467402907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BZZzIAPbWDpQJ7njDH3qLh1pPC9TzXr+wXGZFw4KDkM=; b=AsFNAlCtfrRdBfYdsyaZVt5BvyqkXZpNUgGtXQA9E+rqJ8UvuKmMzIgH aKiDalSUXsWSP0DbUIn8S+YVnYRCmbnhtaqzt0bK5CtynNEwHps7jZrId Jvr1rVShOIX1REmtOa9vAZa+6PNoFfaVEbBdw0DLHNEfmScERKRQ1ve0y k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuBQAyVWRX/51dJa1dgz5WfQa6XYF6F?= =?us-ascii?q?wuFdQIcgQk6EgEBAQEBAQFlJ4RMAQEEAQEBCxURMQgBCxACAQgOCgICJgICAiU?= =?us-ascii?q?LFRACBA4FiDAOsC2QTgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFJoF3CIJOh?= =?us-ascii?q?0Ergi8FiBOQXgGOKI8ij3QBJQEuggMFHIFMboh8fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,485,1459814400"; d="scan'208";a="116269096" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 19:55:06 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5HJt6Fl015759 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 19:55:06 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 17 Jun 2016 15:55:05 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 17 Jun 2016 15:55:05 -0400 From: "Joe Hildebrand (jhildebr)" To: Brian Trammell Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmdrA4n/SZAVekigMWYxC+73GZ/pJkIAgABsYID//6NcgIAAa8MA//+g6wCAAROkgIAA+uwAgABFU4CAAGq4gIAAmi0A//+icwAADtiVgAAoKMIA Date: Fri, 17 Jun 2016 19:55:05 +0000 Message-ID: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <2DF9FB6910FBD44A904529AA37E1540B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Christian Huitema , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:55:11 -0000 WW91ciBzdWdnZXN0ZWQgY2hhcnRlciB0ZXh0IHdvcmtzIGZvciBtZS4gIEkgdGhpbmsgaXQgaXMg bXVjaCBtb3JlIGNsZWFyIHRoYW4gd2hhdCBJIG9yaWdpbmFsbHkgc3VnZ2VzdGVkLg0KDQotLSAN CkpvZSBIaWxkZWJyYW5kDQoNCg0KT24gNi8xNi8xNiwgMTI6NDUgUE0sICJRVUlDIG9uIGJlaGFs ZiBvZiBCcmlhbiBUcmFtbWVsbCIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg aWV0ZkB0cmFtbWVsbC5jaD4gd3JvdGU6DQoNCj5oaSBKb2UsIENocmlzdGlhbiwgYWxsLA0KPg0K PihoYXRsZXNzLCBpbmxpbmUgcmVwbHkuLi4pDQo+DQo+PiBPbiAxNiBKdW4gMjAxNiwgYXQgMTk6 NDAsIEpvZSBIaWxkZWJyYW5kIChqaGlsZGVicikgPGpoaWxkZWJyQGNpc2NvLmNvbT4gd3JvdGU6 DQo+PiANCj4+IE9uIDYvMTYvMTYsIDExOjE0IEFNLCAiQ2hyaXN0aWFuIEh1aXRlbWEiIDxodWl0 ZW1hQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gSm9lLCBJIHRoaW5rIHRoYXQgd2Ug bmVlZCBzdGF0ZSB0aGUgcmVxdWlyZW1lbnRzIHByZWNpc2VseS4gSSBoZWFyZCBhIHdpZGUgcmFu Z2Ugb2YgcG90ZW50aWFsIHJlcXVpcmVtZW50cyBpbiB0aGUgTUFSTkVXIHdvcmtzaG9wLCBhbmQg dGhlbiBvbiB0aGUgU1BVRCBhbmQgUExVUyBtYWlsaW5nIGxpc3QsIGFuZCB0aGVuIGluIHlvdXIg ZHJhZnQuIEkgYW0gY29uY2VybmVkIHRoYXQgZ2VuZXJhbCBnb2FscyBsaWtlICJtYWtlIFFVSUMg ZnJpZW5kbHkgdG8gZmlyZXdhbGxzIiBjYW4gZGVyaXZlIGludG8gYW4gZW5kbGVzcyBsaXN0IG9m IGZlYXR1cmUgcmVxdWlyZW1lbnRzLiBJZiB3ZSB3cml0ZSBhbnl0aGluZyBhdCBhbGwgaW4gdGhl IGNoYXJ0ZXIsIGl0IGhhcyB0byBjdXQgdG8gdGhlIGNvcmUgb2YgdGhlIGlzc3VlLg0KPj4gDQo+ PiBXZSBjYW4gZW51bWVyYXRlIHRoZXNlIGlmIHlvdSB3aXNoLCBidXQgaWYgd2UgY29tZSB1cCB3 aXRoIGFub3RoZXIgb25lIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2FudHMgdG8gdGFja2xlLCBJ 4oCZZCBwcmVmZXIgbm90IHRvIGhhdmUgdG8gcmVjaGFydGVyLiAgQSBsaXR0bGUgYml0IG9mIGxh bmd1YWdlIHNheWluZyDigJxhbmQgc2ltaWxhciBpc3N1ZXPigJ0gd291bGQgYmUgZW5vdWdoIGZv ciBtZS4NCj4NCj5JdCBzZWVtcyB0byBtZSB0aGF0IGEgbG90IG9mIHdoYXQgd2UncmUgdGFsa2lu ZyBhYm91dCBoZXJlIGdvZXMgdG8gYWxpZ25pbmcgdGhlIG9wZXJhdGlvbiBvZiBRVUlDIHdpdGgg dGhlIGV4cGVjdGF0aW9ucyBvZiBwZW9wbGUgd2hvIGFjdHVhbGx5IHJ1biBuZXR3b3Jrcy4gV2Un dmUgZ290IGxvdHMgb2YgcnVubmluZyBjb2RlIG91dCB0aGVyZSB0aGF0IGFzc3VtZXMgdGhhdCAi Y29ubmVjdGlvbi1vcmllbnRlZCBJbnRlcm5ldCB0cmFuc3BvcnQgcHJvdG9jb2wiIGFuZCAiVENQ IiBhcmUgc3lub255bW91cy4gVGhlcmUncyB0aGUgY29kZSBvbiBmaXJld2FsbHMsIGJ1dCB0aGF0 J3MgcmVsYXRpdmVseSBlYXN5IHRvIHBhdGNoIGNvbXBhcmVkIHRvIHRoZSAiY29kZSIgaW4gdGhl IGhlYWRzIG9mIG5ldHdvcmsgYW5kIHN5c3RlbSBhZG1pbmlzdHJhdG9ycy4gVGhlIGNsb3NlciB0 aGUgY29udHJvbCBwb2ludHMgYW5kIG5ldHdvcmstbGV2ZWwgaW5mb3JtYXRpb24gYXZhaWxhYmxl IGFyZSBlcXVpdmFsZW50IHRvIHRob3NlIGF2YWlsYWJsZSBpbiBUQ1AsIHRoZSBsZXNzIGZyaWN0 aW9uIHdpdGggdGhpcyBleGlzdGluZyBwcmFjdGljZS4gVGhlcmUgYXJlIG9idmlvdXMgdHJhZGVv ZmZzIGluIHZpc2liaWxpdHkgYW5kIGV4cGxvaXRhYmlsaXR5IHRoYXQgbXVzdCBiZSBldmF1bGF0 ZWQsIGJ1dCB0aGlzIGlzIGVuZ2luZWVyaW5nIHRoZSBXRyBzaG91bGQgZG8uIEluIGFueSBldmVu dCwgcmV1c2luZyBwZW9wbGUncyBpbnR1aXRpb24gYWJvdXQgVENQIHRvIHRoZSBleHRlbnQgaXQg Zml0cyB3aXRoIFFVSUMgc2VlbXMgdXNlZnVsIHRvIG1lLg0KPg0KPkdpdmVuIHRoYXQsIHdvdWxk IHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHRoZSBjaGFydGVyIChhZGRpbmcgb25lIHNlbnRlbmNl IHRvIHRoZSBwYXJhZ3JhcGggZm9yIGZvY3VzIGFyZWEgb25lKSBiZSBhY2NlcHRhYmxlPw0KPg0K Pk9MRDoNCj4NCj5UaGUgZmlyc3Qgb2YgdGhlc2UgaXMgdGhlIGNvcmUgdHJhbnNwb3J0IHdvcmss IHdoaWNoIHdpbGwgZGVzY3JpYmUgdGhlIHdpcmUgZm9ybWF0LCBhbG9uZyB3aXRoIHRoZSBtZWNo YW5pc21zIGZvciBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQsIHN0cmVhbSBtdWx0aXBsZXhpbmcs IGRhdGEgcmVsaWFiaWxpdHksIGxvc3MgZGV0ZWN0aW9uIGFuZCByZWNvdmVyeSwgY29uZ2VzdGlv biBjb250cm9sLCB2ZXJzaW9uIG5lZ290aWF0aW9uLCBhbmQgb3B0aW9ucyBuZWdvdGlhdGlvbi4g V29yayBvbiBjb25nZXN0aW9uIGNvbnRyb2wgd2lsbCBkZXNjcmliZSB1c2Ugb2YgYW4gZXhpc3Rp bmcgY29uZ2VzdGlvbiBjb250cm9sbGVyIGFzIGEgZGVmYXVsdCBzY2hlbWUgZm9yIFFVSUMuIFFV SUMgaXMgZXhwZWN0ZWQgdG8gc3VwcG9ydCByYXBpZCBpdGVyYWJpbGl0eSBhbmQgZXhwZXJpbWVu dGF0aW9uLCBhbmQgdGhpcyB3b3JrIHdpbGwgZGVzY3JpYmUgYSB2ZXJzaW9uaW5nIHByb2Nlc3Mg dGhhdCBlbmFibGVzIGRpc3RyaWJ1dGVkIGV4cGVyaW1lbnRhdGlvbiB3aXRoIFFVSUMuDQo+DQo+ TkVXOg0KPg0KPlRoZSBmaXJzdCBvZiB0aGVzZSBpcyB0aGUgY29yZSB0cmFuc3BvcnQgd29yaywg d2hpY2ggd2lsbCBkZXNjcmliZSB0aGUgd2lyZSBmb3JtYXQsIGFsb25nIHdpdGggdGhlIG1lY2hh bmlzbXMgZm9yIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCwgc3RyZWFtIG11bHRpcGxleGluZywg ZGF0YSByZWxpYWJpbGl0eSwgbG9zcyBkZXRlY3Rpb24gYW5kIHJlY292ZXJ5LCBjb25nZXN0aW9u IGNvbnRyb2wsIHZlcnNpb24gbmVnb3RpYXRpb24sIGFuZCBvcHRpb25zIG5lZ290aWF0aW9uLiBU aGlzIHdvcmsgd2lsbCBjb25zaWRlciBkZXBsb3lhYmlsaXR5LCBtYW5hZ2VhYmlsaXR5IGFuZCBk aWFnbm9zYWJpbGl0eSBvZiB0aGUgd2lyZSBmb3JtYXQsIGluY2x1ZGluZyBob3cgdGhlIHdpcmUg Zm9ybWF0IHdpbGwgYmUgcHJvY2Vzc2VkIGJ5IGRldmljZXMgb24gcGF0aC4gV29yayBvbiBjb25n ZXN0aW9uIGNvbnRyb2wgd2lsbCBkZXNjcmliZSB1c2Ugb2YgYW4gZXhpc3RpbmcgY29uZ2VzdGlv biBjb250cm9sbGVyIGFzIGEgZGVmYXVsdCBzY2hlbWUgZm9yIFFVSUMuIFFVSUMgaXMgZXhwZWN0 ZWQgdG8gc3VwcG9ydCByYXBpZCBpdGVyYWJpbGl0eSBhbmQgZXhwZXJpbWVudGF0aW9uLCBhbmQg dGhpcyB3b3JrIHdpbGwgZGVzY3JpYmUgYSB2ZXJzaW9uaW5nIHByb2Nlc3MgdGhhdCBlbmFibGVz IGRpc3RyaWJ1dGVkIGV4cGVyaW1lbnRhdGlvbiB3aXRoIFFVSUMuDQo+DQo+SW5kZWVkLCBJIHdv dWxkIGhvcGUgdGhhdCBtYW5hZ2VhYmlsaXR5IGFuZCBkaWFnbm9zYWJpbGl0eSAtLSB3aGljaCBp bmNsdWRlcyBlbmFibGluZyBmaXJld2FsbHMgdG8ga2VlcCBzdGF0ZSwgYW5kIG1ha2luZyBpdCBw b3NzaWJsZSB0byBkaWZmZXJlbnRpYXRlIGF0dGFjayB0cmFmZmljIC0tIGFyZSByZXF1aXJlbWVu dHMgZm9yIGFueSBJRVRGIHRyYW5zcG9ydCBwcm90b2NvbCBnb2luZyBmb3J3YXJkLg0KPg0KPlRo ZSBkaXNjdXNzaW9uIGJlbG93LCBJIHRoaW5rLCBuZWVkcyB0byBoYXBwZW4gaW4gdGhlIFdHLiBH ZW5lcmFsIGd1aWRhbmNlIGhlcmUgY2FuIGNvbWUgZnJvbSBQTFVTIChhbmQgaW5kZWVkLCBJIHNl ZSBhIGxvdCBvZiBwb2ludHMgcmFpc2VkIGluIHRoZSBTUFVELWRlcml2ZWQgcmVxdWlyZW1lbnRz IGRvY3VtZW50IGRyYWZ0LXRyYW1tZWxsLXNwdWQtcmVxIGluIEpvZSdzIGxpc3QgYmVsb3cpLCBi dXQgdGhlIGRldGFpbGVkIGV2YWx1YXRpb24gb2YgdGhlc2UgYXNwZWN0cyBvZiBob3cgdGhlIHBy b3RvY29sIHdpbGwgaW50ZXJhY3Qgd2l0aCBkZXZpY2VzIG9uIHBhdGggaW4gdGhlIHNwZWNpZmlj IGNhc2Ugb2YgUVVJQyBhcmUgYSBtYXR0ZXIgZm9yIFFVSUMuIEkgYmVsaWV2ZSB0aGUgc3VnZ2Vz dGlvbiBhYm92ZSBhbGxvd3MgdGhhdCB3b3JrIHRvIGhhcHBlbi4NCj4NCj4NCj5DaGVlcnMsDQo+ DQo+QnJpYW4NCj4NCj4NCj4+PiBJIGhlYXJkIHR3byBjb21tb24gcmVxdWlyZW1lbnRzLCAibWFy a2luZyB0aGUgYmVnaW5uaW5nIGFuZCBlbmQgb2YgYSBmbG93LCIgYmVjYXVzZSB0aGF0IGhlbHBz IGZpcmV3YWxscyBhbmQgbG9hZCBiYWxhbmNlcnMgbWFuYWdlIHJlc291cmNlLCBhbmQgImFzc2Vz c2luZyBjb25zZW50LCIgYmVjYXVzZSB0aGF0IGhlbHBzIGRpZmZlcmVudGlhdGluZyBiZXR3ZWVu IHJlZ3VsYXIgdHJhZmZpYyBhbmQgYXR0YWNrIHRyYWZmaWMuIElzIHRoZXJlIG1vcmU/DQo+PiAN Cj4+IElmIHlvdSB3YW50IHRoZSBwcm9jZXNzaW5nIHRvIGJlIGVmZmljaWVudCAoYW5kIG5vdCBv c3NpZnkgc29tZXRoaW5nIHVuaW50ZW5kZWQpLCBiZWluZyBhYmxlIHRvIHNlcGFyYXRlIFFVSUMg dHJhZmZpYyBmcm9tIG5vbi1RVUlDIFVEUCB0cmFmZmljIGVhc2lseSB3b3VsZCBiZSB1c2VmdWwu ICBPdGhlcndpc2UsIHBhdGggZGV2aWNlcyBhcmUgbGlrZWx5IHRvIGdyYWIgd2hhdGV2ZXIgdmVy c2lvbiBudW1iZXIgdGhleSBzZWUgYXMgdGhlIGRpc2NyaW1pbmFudC4NCj4+IA0KPj4gSWYg4oCc bWFya2luZyB0aGUgYmVnaW5uaW5nIG9mIGEgZmxvd+KAnSBhbHNvIGluY2x1ZGVzIGJlaW5nIGFi bGUgdG8gdGVsbCBlYXNpbHkgd2hpY2ggc2lkZSBpbnRlbmRlZCB0byBpbml0aWF0ZSB0aGUgY29u dmVyc2F0aW9uLCB0aGVuIHRoYXTigJlzIGZpbmUuDQo+PiANCj4+IFRoZSBwcm90b2NvbCBuZWVk cyB0byBlbnN1cmUgdGhhdCBhIHBhdGggZWxlbWVudCBjYW4gYXNzb2NpYXRlIGZ1cnRoZXIgdHJh ZmZpYyBvbiBhIFFVSUMgY29ubmVjdGlvbiB3aXRoIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGZsb3cu DQo+PiANCj4+IFRoZXJlIHByb2JhYmx5IG5lZWRzIHRvIGJlIHJlY29tbWVuZGF0aW9ucyBmb3Ig dGltZS1vdXRzLCBwYXJ0aWN1bGFybHkgYXJvdW5kIHRoZSBlbmQgb2YgdGhlIGZsb3cuDQo+PiAN Cj4+IFRoZSBwcm90b2NvbCBkb2MgbmVlZHMgdG8gZGVzY3JpYmUgd2hhdCBoYXBwZW5zIHdpdGgg YXNzb2NpYXRlZCBJQ01QLg0KPj4gDQo+PiBUaGUgcHJvdG9jb2wgbmVlZHMgdG8gc2F5IHdoYXQg aGFwcGVucyB3aGVuIGEgbmV0d29yayBvciBob3N0IHJlY2VpdmVzIGEgUVVJQyBwYWNrZXQgaXQg d2FzbuKAmXQgZXhwZWN0aW5nLg0KPj4gDQo+PiBXZSBuZWVkIHRvIHRoaW5rIGFib3V0IHJldHVy biByb3V0YWJpbGl0eS4NCj4+IA0KPj4gVGhlIHByb3RvY29sIG5lZWRzIHRvIGtlZXAgaW4gbWlu ZCB0aGF0IHN0YXRlIHdpbGwgYmUgZ2VuZXJhdGVkIGluIHRoZSBuZXR3b3JrLCBzbyB0aGF0IGFz IHdlIGFkZCBtdWx0aS1wYXRoIGV4dGVuc2lvbnMgKGZvciBleGFtcGxlKSwgd2UgZG9u4oCZdCBq dXN0IHN0YXJ0IHNlbmRpbmcgdHJhZmZpYyBvbiBhIG5ldyBwYXRoIHdpdGhvdXQgZmlyc3Qgc3Rh cnRpbmcgYSBuZXcgZmxvdy4NCj4+IA0KPj4gSXQgaXMgcG9zc2libGUgdGhhdCB3ZSBtaWdodCB3 YW50IHRvIGRlc2NyaWJlIHdoYXQgYSBsb2FkIGJhbGFuY2VyIHNob3VsZCBkbyB3aGVuIGl0IGRy b3BzIFFVSUMgc3RhdGUgZHVlIHRvIGEgdGltZW91dCAob3Igd2hlbiBpdCBpcyAqYWJvdXQqIHRv IGRyb3Agc3RhdGUpLiAgV2UgbWlnaHQgd2FudCBpdCB0byBzZW5kIGEgaGludCB0byBvbmUgb3Ig Ym90aCBvZiB0aGUgZW5kcG9pbnRzLCB0byBhdm9pZCBoYXZpbmcgdG8gZGlhZ25vc2UgbWlkLXN0 cmVhbSBibGFjayBob2xlcy4gIFNvbWUgbG9hZCBUQ1AgbG9hZCBiYWxhbmNlcnMgc2VuZCBSU1Rz IGluIGJvdGggZGlyZWN0aW9ucyBpbiB0aGlzIGNhc2UsIGZvciBleGFtcGxlLg0KPj4gDQo+PiBX ZSBzaG91bGQgYW5hbHl6ZSB0aGUga25vd24gYXR0YWNrcyBvbiBUQ1AgKGF0IGxlYXN0KSB0byBl bnN1cmUgdGhhdCBRVUlDIGlzIG5vdCBpbW1lZGlhdGVseSB2dWxuZXJhYmxlIHRvIHRoZSBzb3J0 cyBvZiB0aGluZ3Mgd2XigJl2ZSBhbHJlYWR5IGZpeGVkIG92ZXIgdGhlIGxhc3QgNDAgeWVhcnMu DQo+PiANCj4+IFRoZXJlIGFyZSBwcm9iYWJseSBhIGNvdXBsZSBvZiBvdGhlcnMsIGFuZCBJ4oCZ bSBvcGVuIHRvIG1vZGlmeWluZyB0aGUgbGlzdCBhcyBwZW9wbGUgc2VlIGZpdC4gIEFsdGVybmF0 ZWx5LCBpZiB3ZSBjYW4gZmluZCBhIHdheSB0byBkZXNjcmliZSB0aGVzZSBraW5kIG9mIGRpc2N1 c3Npb25zIGluIGEgd2F5IHRoYXQgZG9lcyBub3QgYnJpbmcgaW4gdGhlIGV4cGxpY2l0IHBhdGgg Y29tbXVuaWNhdGlvbiBiaXRzIHRoYXQgd2UgZXhwbG9yZWQgaW4gU1BVRCwgSSB0aGluayB0aGUg Y2hhcnRlciB3b3VsZCBiZSBlYXNpZXIgdG8gdW5kZXJzdGFuZC4NCj4+IA0KPj4+PiBRVUlDIHdp bGwgbm90IGJlIGFibGUgdG8gYmUgZGVwbG95ZWQgb24gc29tZSBuZXR3b3Jrcywgc3VjaCBhcyB0 aGUNCj4+Pj4gb25lIEknbSBvbiByaWdodCBub3csIHVubGVzcyB3ZSBkZXNjcmliZSB0aGUgY2hh bmdlcyB0aGF0IGFyZSBuZWNlc3NhcnkNCj4+Pj4gZm9yIHRoZSBuZXR3b3JrIGRldmljZXMgdGhh dCBhcmUgY3VycmVudGx5IGJsb2NraW5nIGl0Lg0KPj4+IA0KPj4+IFRoZXJlIGFyZSBzdWNoIG5l dHdvcmtzLiBCdXQgdGhlcmUgYWxzbyBhcmUgbmV0d29ya3MgdG9kYXkgdGhhdCBibG9jayBvdXRn b2luZyBUQ1AgY29ubmVjdGlvbnMsIGJlY2F1c2Ugb2Ygc29tZSBwb2xpY3kgY29uc2lkZXJhdGlv bnMuIFdlIGRvbid0IGNoYW5nZSBUQ1AgZm9yIHRoYXQuIFdlIHNpbXBseSBhY2NlcHQgdGhhdCB0 aGVzZSBuZXR3b3JrcyBhcmUgbWFraW5nIGEgdHJhZGVvZmYuIFRoZXkgY2FyZSBzbyBtdWNoIGFi b3V0IHNvbWUgb2YgdGhlaXIgcG9saWNpZXMgdGhhdCB0aGV5IGFyZSB3aWxsaW5nIHRvIGZvcmVn byBzb21lIG9mIHRoZSB2YWx1ZSBvZiB0aGUgSW50ZXJuZXQuIFRoYXQncyBwcm9iYWJseSBmaW5l LiBPdmVyIHRpbWUsIHRoZSBjb3N0L2FkdmFudGFnZSBiYWxhbmNlIG9mIHRoZSB0cmFkZW9mZiB3 aWxsIGNoYW5nZSwgYW5kIHRoZSBwb2xpY2llcyB3aWxsIHByb2JhYmx5IGV2b2x2ZS4NCj4+IA0K Pj4gQXJlIHlvdSBzYXlpbmcgdGhhdCBwZW9wbGUgd2lsbCB3YW50IFFVSUMgc28gbXVjaCB0aGF0 IHRoZXkgd2lsbCBvcGVuIHRoZWlyIGZpcmV3YWxscyB1cCB0byBhbGwgVURQIHRyYWZmaWMgaW4g Ym90aCBkaXJlY3Rpb25zPyAgT3IgdGhhdCB0aGUgdGVycmlibGUgdGltaW5nLWJhc2VkIGhldXJp c3RpY3Mgd2UgaGF2ZSBmb3IgZ2VuZXJpYyBVRFAgd2lsbCBiZSBlbm91Z2ggZm9yIGEgbGFyZ2Ug ZW50ZXJwcmlzZT8gIE9yIHRoYXQgdGhlIGN1cnJlbnQgcHJvdG9jb2wgZGVzY3JpcHRpb24sIHdp dGhvdXQgZGlzY3Vzc2lvbiBhbmQgYW5hbHlzaXMsIHNob3VsZCBiZSBwcmVzdW1lZCB0byBiZSBw ZXJmZWN0IGluIHRoaXMgcmVnYXJkPw0KPj4gDQo+PiBGb3Igb25jZSwgd2UgaGF2ZSBhIGNoYW5j ZSB0byBkbyBzb21lIHRob3VnaHRmdWwgZW5naW5lZXJpbmcgYmVmb3JlIGEgcHJvdG9jb2wgaXMg ZnVsbHkgc3BlY2lmaWVkIHRvIGNvbnNpZGVyIGhvdyBpdCB3aWxsIGJlIGRlcGxveWVkLCBiYWtp bmcgZGVjYWRlcyBvZiBsZWFybmluZyBpbnRvIHRoZSBkZXNpZ24uICBJIHRoaW5rIHRoZSBhcHBy b2FjaCB0aGF0IHRoZSBUTFMgd29ya2luZyBncm91cCBoYXMgYmVlbiBkb2luZyBvbiBUTFMgMS4z IHRvIGNvbnNpZGVyIGF0dGFjayB2ZWN0b3JzLCBiYWNrd2FyZC1jb21wYXRpYmlsaXR5LCBldGMu IGlzIGEgbW9kZWwgZm9yIHdoYXQgaXMgbmVlZGVkIGZyb20gYSBwcm90b2NvbCBvZiBRVUlD4oCZ cyBwb3RlbnRpYWwgaW1wYWN0Lg0KPj4gDQo+PiAtLQ0KPj4gSm9lIEhpbGRlYnJhbmQNCj4+IA0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFFV SUMgbWFpbGluZyBsaXN0DQo+PiBRVUlDQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMNCj4NCg0K From nobody Fri Jun 17 14:54:13 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D8C12DBCB for ; Fri, 17 Jun 2016 14:54:12 -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 3r6SsYZwmSmK for ; Fri, 17 Jun 2016 14:54:11 -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 3C47412D8F3 for ; Fri, 17 Jun 2016 14:54:11 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-c3-576471814e61 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.C3.27088.18174675; Fri, 17 Jun 2016 23:54:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0294.000; Fri, 17 Jun 2016 23:54:08 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: "quic@ietf.org" Thread-Topic: HTTP/2 on M-QUIC- fallback to MPTCP? Thread-Index: AQHRyOLGZAh2yeEB5kC19PcKJW47jg== Date: Fri, 17 Jun 2016 21:54:08 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <2DE6A23BF0E68845A8B3BE5CE935D58F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7k25jYUq4wcmbmhY9C7gdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXR+LONqeAZU8X+KZtZGxjvMHUxcnJICJhITHiylB3CFpO4cG89 WxcjF4eQwBFGicNvtjNDOEsYJc5suMoMUsUm4C3R1nKYBcQWEVCWmLN0MVi3sICuxPdjPxgh 4kYS7d+WAdkcQLaexLfbwSBhFgFVif49T9lAbF4Ba4mOf1fARjIKyErc/34PbCSzgLjErSfz oY4TkFiy5zwzhC0q8fLxP1YQWxRo5Jd78xgh4koSaw9vZwFZxSygKbF+lz6EaS1xZ04RxERF iSndD9khtgpKnJz5hGUCo+gsJMtmITTPQmiehaR5FpLmBYysqxhFi1OLk3LTjYz0Uosyk4uL 8/P08lJLNjECI+Tglt8GOxhfPnc8xCjAwajEw5uomBwuxJpYVlyZe4hRgoNZSYQ3ID8lXIg3 JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVAOjxNLy4pYzNbdC AuaarDvyKste14zLJH+R5PZUZ4uT8evOH3pZcFfzWGbCoqV31aqi77DIP1Y7XFEkt2Nuv2+e sv8r01PHPCrf661iuieukZ63fNch5hNrpn2bGvPz4eSLgVySRrX7WNvifoYdfHwhvfri1xeZ 2z6XbP6+6Fhdw0zNdXV7anZPUGIpzkg01GIuKk4EAKG4R42MAgAA Archived-At: Subject: [QUIC] HTTP/2 on M-QUIC- fallback to MPTCP? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 21:54:12 -0000 SGksDQoNClRoZSB1c2Ugb2YgSFRUUC8yIG9uIE11bHRpcGF0aC1RVUlDIGlzIG5vdyBpbiB0aGUg c2NvcGUgb2YgdGhlIHByb3Bvc2VkDQpjaGFydGVyIGFuZCBmYWxsIGJhY2sgZnJvbSBRVUlDIHRv IFRDUCBtYXkgc29tZXRpbWVzIGJlIG5lY2Vzc2FyeS4NCg0KU2hvdWxkIHRodXMgSFRUUC8yIG9u IE1QLVRDUCBhbHNvIGJlIGEgcG9zc2liaWxpdHkgYW5kIHdvcmtlZCBvbj8NCg0KVGhvdWdodHMg b24gdGhpcz8NCg0KUmVnYXJkcw0KR8O2cmFuDQoNCg0K From nobody Fri Jun 17 15:57:28 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAB012DAC1 for ; Fri, 17 Jun 2016 15:57:27 -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 O3sCKLfbnwyj for ; Fri, 17 Jun 2016 15:57:25 -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 1D82912D681 for ; Fri, 17 Jun 2016 15:57:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2CA01D930B; Sat, 18 Jun 2016 00:57:23 +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 ioY1+4tTF+IY; Sat, 18 Jun 2016 00:57:22 +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 DFC64D9304; Sat, 18 Jun 2016 00:57:22 +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: Sat, 18 Jun 2016 00:57:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E65864D-0AB6-4C9F-BA94-E4AEC24D464A@tik.ee.ethz.ch> References: To: =?utf-8?Q?G=C3=B6ran_Eriksson_AP?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] HTTP/2 on M-QUIC- fallback to MPTCP? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 22:57:27 -0000 I would say this is a question for the mptcp list=E2=80=A6 and they plan = to discussion re-chartering in Berlin. Mirja > Am 17.06.2016 um 23:54 schrieb G=C3=B6ran Eriksson AP = : >=20 > Hi, >=20 > The use of HTTP/2 on Multipath-QUIC is now in the scope of the = proposed > charter and fall back from QUIC to TCP may sometimes be necessary. >=20 > Should thus HTTP/2 on MP-TCP also be a possibility and worked on? >=20 > Thoughts on this? >=20 > Regards > G=C3=B6ran >=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Fri Jun 17 17:00:04 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0472912DC4D for ; Fri, 17 Jun 2016 17:00:00 -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, HTML_MESSAGE=0.001, 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 saquutD6JAjE for ; Fri, 17 Jun 2016 16:59:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E0012DC4B for ; Fri, 17 Jun 2016 16:59:57 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1EA5B27879C for ; Sat, 18 Jun 2016 08:59:55 +0900 (JST) Received: by mail-yw0-f179.google.com with SMTP id b75so26422514ywe.1 for ; Fri, 17 Jun 2016 16:59:55 -0700 (PDT) X-Gm-Message-State: ALyK8tIt3PQEop80CzyJwP+teOB/KWiC05yduUdsB1RqCTQioCol81iIDi/GaSmPIBb1tW2kwfF70mtpbhF7Hw== X-Received: by 10.37.124.5 with SMTP id x5mr2625251ybc.43.1466207988911; Fri, 17 Jun 2016 16:59:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.196.3 with HTTP; Fri, 17 Jun 2016 16:59:48 -0700 (PDT) In-Reply-To: <4E65864D-0AB6-4C9F-BA94-E4AEC24D464A@tik.ee.ethz.ch> References: <4E65864D-0AB6-4C9F-BA94-E4AEC24D464A@tik.ee.ethz.ch> From: Yoshifumi Nishida Date: Fri, 17 Jun 2016 16:59:48 -0700 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a114c6fbe589930053582264b Archived-At: Cc: "quic@ietf.org" , =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= Subject: Re: [QUIC] HTTP/2 on M-QUIC- fallback to MPTCP? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 00:00:00 -0000 --001a114c6fbe589930053582264b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, If both endpoints's kernel support MPTCP, they can choose to use MPTCP whenever they open a TCP connection. So, HTTP/2 on MPTCP might already exist in the wild. (MPTCP is not a new transport protocol. It's an extension to TCP) But, it will be a fun topic to discuss for optimization or some other purposes.If some people have already tried and found something, we might want to hear from them. Thanks, -- Yoshi On Fri, Jun 17, 2016 at 3:57 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > I would say this is a question for the mptcp list=E2=80=A6 and they plan = to > discussion re-chartering in Berlin. > > Mirja > > > > Am 17.06.2016 um 23:54 schrieb G=C3=B6ran Eriksson AP < > goran.ap.eriksson@ericsson.com>: > > > > Hi, > > > > The use of HTTP/2 on Multipath-QUIC is now in the scope of the proposed > > charter and fall back from QUIC to TCP may sometimes be necessary. > > > > Should thus HTTP/2 on MP-TCP also be a possibility and worked on? > > > > Thoughts on this? > > > > Regards > > G=C3=B6ran > > > > > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a114c6fbe589930053582264b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

If both endpoints's kerne= l support MPTCP,=C2=A0they can choose to use MPTCP=C2=A0whenever they open = a TCP connection.
So, HTTP/2 on MPTCP might already exist in the wild. = (MPTCP is not a new transport protocol. It's an extension to TCP)=C2=A0=
But, it will be a fun topic to discuss for optimization or some = other purposes.If some people have already tried and found something, we mi= ght want to hear from them.

Thanks,
=
--
Yoshi


On Fri, Jun 17, 2016 at 3:57 PM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
I would say this is a question for the mptcp list=E2=80=A6 and= they plan to discussion re-chartering in Berlin.

Mirja


> Am 17.06.2016 um 23:54 schrieb G=C3=B6ran Eriksson AP <goran.ap.eriksson@ericsson.com>= ;:
>
> Hi,
>
> The use of HTTP/2 on Multipath-QUIC is now in the scope of the propose= d
> charter and fall back from QUIC to TCP may sometimes be necessary.
>
> Should thus HTTP/2 on MP-TCP also be a possibility and worked on?
>
> Thoughts on this?
>
> Regards
> G=C3=B6ran
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

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

--001a114c6fbe589930053582264b-- From nobody Fri Jun 17 18:26:25 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DFC12DCC3 for ; Fri, 17 Jun 2016 18:26:24 -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 Mkc01s0rm99o for ; Fri, 17 Jun 2016 18:26:21 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A6912DCBF for ; Fri, 17 Jun 2016 18:26:21 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id z186so86109587ywd.2 for ; Fri, 17 Jun 2016 18:26:21 -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=w/wOn9xFRJxVX6EH9Nvp5EPfcodh5//rrVYn1tqc4jc=; b=K/MPywquGzyP7wcwFDVwj08315Cijb6CxlAJYJYyU1Rbv/nGIFQPpnwT5WWcOYz3D6 NX+uUXBqcOwoFMXNlzMUTNfA//B6bsXalhIMtbE6mK9ygJ/9plMttpfq9JnJS2ae2nsQ /89GDLxZwLznqi8o5aB0+QfgqirWA/eC6fJKUaRF/lXKg7AM4eUIJcn0O0nlWMBLBFkx dp/xBw0LHr6Dw44sGxmBP5inmyTtXpcgJQhMhQA9udtZcLpPXQuHcGZ7Ak2NFJbV6QuG issk0+C/2+QJK5gXbz9EGwvB9AdeOKocNyeY83xkaQI701hlbouXLojP5OUSyriENk98 RgVg== 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=w/wOn9xFRJxVX6EH9Nvp5EPfcodh5//rrVYn1tqc4jc=; b=GnyP50JycEU4wfX7097xPP7UgrGlt7WQx7+sB73nmqCdth8pVGxuakWg0o97HV7vlu ZyQm4vbkEWmRX4cxCkAswsJew8BFjaExZFQLTy+U+OLrUWdwOBCApEoSBoE05cHch8JG xgX8JlsrI8CE7hWx2+62b1ozuwLdF92yQw87KRRiO7VBtPGbQ+rBnE5K4AtZmRPOrgm+ YKajqt36mjUL5JWT3xddDp1eeQaXRBDfndVf1ihWUK1bAHZJRgouJWqNey5OybP+NIon jwATkjHMx2UUB9ag1YMiTBk0MmOOvbZeNYPkYCwpUTCSOSjQpGIP2Jshb2v1y3udP6Eg uxqQ== X-Gm-Message-State: ALyK8tJDvv+eksRS7BpoXlUpLMb0HB12lgZxcMU7USM6TJSraEtue6nUPAhBCaCx106VIclE3snc/t+ke+30mL9N X-Received: by 10.13.210.67 with SMTP id u64mr2913222ywd.42.1466213180304; Fri, 17 Jun 2016 18:26:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.219.83 with HTTP; Fri, 17 Jun 2016 18:26:19 -0700 (PDT) In-Reply-To: <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <27E99769-77F1-4F61-B7FD-31AFF3866F68@trammell.ch> From: Jana Iyengar Date: Fri, 17 Jun 2016 18:26:19 -0700 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114e7e30c75be90535835b5f Archived-At: Cc: Ted Hardie , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= , Joe Hildebrand , spud , Christian Huitema , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 01:26:24 -0000 --001a114e7e30c75be90535835b5f Content-Type: text/plain; charset=UTF-8 On Thu, Jun 16, 2016 at 2:12 AM, Brian Trammell wrote: > hi Jana, all, > > (adding spud@ietf.org) > > On one point, below: > > > On 16 Jun 2016, at 03:41, Jana Iyengar wrote: > > > > Hi Dan, > > > >> draft-wing-quic-network-req tries to up-level its recommendations by > saying 'we need consent' rather than suggesting how to achieve it. Consent > could be achieved in probably 3 or 4 different ways, and we need a > technique that works with multicast QUIC and with persistent QUIC > connections. It's up to WG to agree consent is > >> necessary, then to agree how to accomplish consent. We have identified > other things that impact the network and need discussion in the working > group (some small, some larger): Should the network clear its state > immediately after QUIC public reset, set timer, wait for a little while. > Is the network's sole identification the QUIC version in the > client-initiated connection, and can we avoid the network treating that > specially (which will be good and bad, I am remembering network treatment > of IKE's UDP 500 and 4500). If QUIC endpoint sends or receives many bogus > QUIC packets, how can network help stop or rate limit those, to defend the > links and defend other hosts on that network. If path drops state due to a > timeout (or crash, or software update, or whatever), how should the > endpoints learn and how should they react. Those previous things are > discussed in the I-D. In addition, QUIC complicates network diagnostics > and measurements, as well, which will be added in a later version of the > I-D. > > > > I understand what the draft describes, and as I said, I think this is > useful when the wg is discussing what is visible in the QUIC header and > what isn't. The wg can decide whether to care about a particular middlebox > function or not. > > > > That said, I think this may be one of our core disagreements: absent > agreement on what middlebox functions are essential, it's hard to argue how > QUIC should solve for them. We saw a very similar conversation play out in > MPTCP. There were many questions about how legacy middleboxes would treat > MPTCP options and modifications to TCP header bits. The problem was that > there were too many boogeymen middleboxes out there, and it was usually > anybody's guess how important any one particular behavior was. There was > small-scale measurement work done that helped direct the conversation, but > this is tricky territory -- tricky largely because of the lack of > substantial data about particular middlebox behaviors and their prevalence > and importance. > > > > In terms of how these apply to QUIC, we have data from the current > deployment of QUIC, and that can hopefully be brought to bear on the > decisions in the working group. Beyond that, I think it's all thin ice. We > can certainly try and get consensus on specific middlebox behaviors as > important, but that conversation is more general than just QUIC, and since > your draft is precisely such a list, I'd argue that it probably belongs in > PLUS, TSVAREA/TSVWG, or INTAREA. > > PLUS BoF proponent hat on: I think there is a point here that might make > sense to add to the PLUS draft charter that would naturally feed into QUIC: > > - Define a view of "essential middlebox functions", and a description of > the information from endpoints required to drive them. > > As you say, part of the problem is there is no agreement on either of > these questions. A focused discussion here could hopefully come to some > consensus. QUIC isn't really the place for this IMO, since the answer is > bigger than one instance of a new protocol over UDP. I'm not sure a general > INTAREA/TSVAREA activity would have the right focus, and I'm not sure it's > really in scope for TSVWG. > > draft-wing-quic-network-req looks to me (slightly rearranged and with the > QUIC-specific language stripped out) as a candidate document for this work > item. It's alsouseful input to the engineering work on a universal shim > protocol we intend to do in PLUS. (And as a bonus, if both QUIC and PLUS > are working from a common, defined view of what sort of functions are > essential, future integration between them won't be complicated by > differing architectural views). > +1. - jana --001a114e7e30c75be90535835b5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 16, 2016 at 2:12 AM, Brian Trammell <<= a href=3D"mailto:ietf@trammell.ch" target=3D"_blank">ietf@trammell.ch&g= t; wrote:
hi Jana, all,

(adding spud@ietf.org)

On one point, below:

> On 16 Jun 2016, at 03:41, Jana Iyengar <jri@google.com> wrote:
>
> Hi Dan,
>
>> draft-wing-quic-network-req tries to up-level its recommendations = by saying 'we need consent' rather than suggesting how to achieve i= t.=C2=A0 Consent could be achieved in probably 3 or 4 different ways, and w= e need a technique that works with multicast QUIC and with persistent QUIC = connections.=C2=A0 It's up to WG to agree consent is
>> necessary, then to agree how to accomplish consent.=C2=A0 We have = identified other things that impact the network and need discussion in the = working group (some small, some larger):=C2=A0 Should the network clear its= state immediately after QUIC public reset, set timer, wait for a little wh= ile.=C2=A0 Is the network's sole identification the QUIC version in the= client-initiated connection, and can we avoid the network treating that sp= ecially (which will be good and bad, I am remembering network treatment of= =C2=A0 IKE's UDP 500 and 4500).=C2=A0 If QUIC endpoint sends or receive= s many bogus QUIC packets, how can network help stop or rate limit those, t= o defend the links and defend other hosts on that network.=C2=A0 If path dr= ops state due to a timeout (or crash, or software update, or whatever), how= should the endpoints learn and how should they react.=C2=A0 Those previous= things are discussed in the I-D.=C2=A0 In addition, QUIC complicates netwo= rk diagnostics and measurements, as well, which will be added in a later ve= rsion of the I-D.
>
> I understand what the draft describes, and as I said, I think this is = useful when the wg is discussing what is visible in the QUIC header and wha= t isn't. The wg can decide whether to care about a particular middlebox= function or not.
>
> That said, I think this may be one of our core disagreements: absent a= greement on what middlebox functions are essential, it's hard to argue = how QUIC should solve for them. We saw a very similar conversation play out= in MPTCP. There were many questions about how legacy middleboxes would tre= at MPTCP options and modifications to TCP header bits. The problem was that= there were too many boogeymen middleboxes out there, and it was usually an= ybody's guess how important any one particular behavior was. There was = small-scale measurement work done that helped direct the conversation, but = this is tricky territory -- tricky largely because of the lack of substanti= al data about particular middlebox behaviors and their prevalence and impor= tance.
>
> In terms of how these apply to QUIC, we have data from the current dep= loyment of QUIC, and that can hopefully be brought to bear on the decisions= in the working group. Beyond that, I think it's all thin ice. We can c= ertainly try and get consensus on specific middlebox behaviors as important= , but that conversation is more general than just QUIC, and since your draf= t is precisely such a list, I'd argue that it probably belongs in PLUS,= TSVAREA/TSVWG, or INTAREA.

PLUS BoF proponent hat on: I think there is a point here that might = make sense to add to the PLUS draft charter that would naturally feed into = QUIC:

- Define a view of "essential middlebox functions", and a descrip= tion of the information from endpoints required to drive them.

As you say, part of the problem is there is no agreement on either of these= questions. A focused discussion here could hopefully come to some consensu= s. QUIC isn't really the place for this IMO, since the answer is bigger= than one instance of a new protocol over UDP. I'm not sure a general I= NTAREA/TSVAREA activity would have the right focus, and I'm not sure it= 's really in scope for TSVWG.

draft-wing-quic-network-req looks to me (slightly rearranged and with the Q= UIC-specific language stripped out) as a candidate document for this work i= tem. It's alsouseful input to the engineering work on a universal shim = protocol we intend to do in PLUS. (And as a bonus, if both QUIC and PLUS ar= e working from a common, defined view of what sort of functions are essenti= al, future integration between them won't be complicated by differing a= rchitectural views).

+1.
=C2= =A0
- jana
--001a114e7e30c75be90535835b5f-- From nobody Fri Jun 17 19:25:52 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB8D12DCB5 for ; Fri, 17 Jun 2016 19:25:51 -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 l9ya88KImWWs for ; Fri, 17 Jun 2016 19:25:49 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29D412DCB4 for ; Fri, 17 Jun 2016 19:25:48 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d137so11038854ywe.3 for ; Fri, 17 Jun 2016 19:25:48 -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=2A4XiXorf/HY+VuqBrDe110sRZ9pro7CMNJ08KnZ3R8=; b=We31u9y7sFDaQTW0Bk3c3SEqyYT2WCed4CdVELqP+pKtJIHWH2fwrvxICNzNQ04Ica xpUsSpsMRp7ubeGAMGab0XuV6PBICCuldeWQdH9iy7tQfI5UcaRgDQuJOsJWgJtsHDTx Tjar6bjiSokWqpo801uffVtty3EVFTA+kzcEPSxrOGDXH1lMOhRx1J0KWUiiRfT9XBTb TH5ijw1XdHdaQ0jULW9K5n0p7uTQEgDxDjOB+c4noy3HIu0/HaiJut7vIsIUl2guz8/U o6FCeW3LltT2LNhutgA6tIovWpSDSPHFrG9rHToB0uV/i2LTP6vf2jXTgEPGmwz2UbUE P/LQ== 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=2A4XiXorf/HY+VuqBrDe110sRZ9pro7CMNJ08KnZ3R8=; b=aLgBptyYEv54lcsLaB37jwZNRhVhu0upf9JDDqXus6dBuxusXxLaTQ8mdt+TI5NvRR FjzycM5qUMEATq+rZK3VqTlBNtVBFRLkCbEPNp3u+QOwneO2l6Yk1BhKFDc2h9SQ8DnM LjLXpj3hZY/krc/5sBzIb027JVer0vlkymraYgfAXpCou4qLRNPeiW/GeEg72yzVLxh6 0uYDtysVjf0FxJRrMdjVfWcaK1p39xZazJiBebkWR++VEV4fIdvaalAOwd2/8F8NJbOB KaqlE3VwjHDcjaCb1Dednv29E53DGypEbg3+MWTv/Z5LgheITx8KQEsj84/YrQQTvbM7 hy2g== X-Gm-Message-State: ALyK8tLCcHktvkKP9DwJF4QjPlaOC/6qo2Hk+ZH4tNkCpv0zq/1DvnGPLiPnW9XJSXtoj+tozYZnfJnccyGPBsKV X-Received: by 10.129.72.12 with SMTP id v12mr3056028ywa.110.1466216747718; Fri, 17 Jun 2016 19:25:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.219.83 with HTTP; Fri, 17 Jun 2016 19:25:46 -0700 (PDT) In-Reply-To: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> From: Jana Iyengar Date: Fri, 17 Jun 2016 19:25:46 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a114ddbac69ccbf0535843042 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 02:25:52 -0000 --001a114ddbac69ccbf0535843042 Content-Type: text/plain; charset=UTF-8 Joe, I'd like to first say that I'm glad we're having this conversation now, since I expected this conversation to happen sooner or later. We clearly have differences, but I understand where you're coming from and I want to thank you for engaging reasonably (not that I would have expected anything lesser from you.) Responses inline. >I understand what the draft describes, and as I said, I think this is > useful when the wg is discussing what is visible in the QUIC header and > what isn't. The wg can decide whether to care about a particular middlebox > function or not. > > Great. Let's get a little bit of charter text added that says that, > then. It may be that the text I proposed didn't capture that nuance > adequately. I think the wording was unclear, and I think I'm probably fine with Brian's proposed text (I'll respond to the proposed text separately.) That said, the charter text is only a placeholder for a conversation we want to have in the wg. My disagreement is with the conversation that you're proposing. > >That said, I think this may be one of our core disagreements: absent > agreement on what middlebox functions are essential, it's hard to argue how > QUIC should solve for them. We saw a very similar conversation play out in > MPTCP. There were many questions > > about how legacy middleboxes would treat MPTCP options and modifications > to TCP header bits. The problem was that there were too many boogeymen > middleboxes out there, and it was usually anybody's guess how important any > one particular behavior was. There was > > small-scale measurement work done that helped direct the conversation, > but this is tricky territory -- tricky largely because of the lack of > substantial data about particular middlebox behaviors and their prevalence > and importance. > > We're not talking about boogeyman middleboxes here. There is no > measurement needed, and no testing. > That's not a convincing argument -- with no measurement or data, there's only boogeymen middleboxes... > We're talking about firewalls that currently block UDP, such as the one > I'm going through right now. I would like to add explicit QUIC support to > that box so that ... and that's your boogeyman. Fortunately, there's data on this -- we shared this in the BarBoF last year. That's about 7% of users. QUIC works well for 92% of the users trying to use it (this is at massive scales of usage), as shown on this slide . This data has been independently validated by non-Google WebRTC deployments. So, this question can at least be scoped to 7% of users. I'll also point out that just being about to identify QUIC is not going to be enough for the entire 7%, so it's really < 7%. we can get the benefits of QUIC deployment. I would like any working group > we form to do new transport protocols to have in scope how that new > transport deploys, and firewall traversal is a key real-world deployment > mechanism. > > I would be happy with different charter language that allows a potential > working group to consider adding language that tells firewalls and load > balancers what to do with the bits that are exposed, in order to maximize > user experience, and allow firewalls and load balancers to do the best they > can to protect the applications, hosts, and networks on whose behalf they > are deployed. I would like a potential working group to be able to discuss > what happens when signals from the network path such as ICMP are received, > as well as when they should be sent. That might mean some changes to the > protocol, but hopefully most of it is just writing down some of the > assumptions that people with more QUIC intuition have about what firewalls > and load balancers are going to do with the information that is already > exposed to the path. > I don't agree with this line of reasoning. The QUIC wg should specify what the endpoints do on receiving ICMP messages from the network. But you are also asking for the QUIC wg to specify normative behavior of firewalls, when there is no equivalent consensus on what they ought to do for TCP. We're talking about solving for a list of problems that has no consensus. More importantly, my opinion is that this wg may not have the right set of folks with whom you want to drive consensus on this list of firewall behaviors. "People with more QUIC intuition" certainly will have some idea of what behaviors to build for (and I expect that to happen), but these people will have quite limited idea what firewalls need to do on path, and what information firewalls need. IMO, you need network operations folks to be having that conversation, and QUIC is inconveniently not being proposed in OPSAREA (I'm not sure which wg would be appropriate, which is why I proposed INTAREA. Perhaps OPSAREA is a better fit.) I agree that any more interesting path interactions, to the extent that > they might be interesting, are more in the realm of PLUS. Why are these less interesting path interactions? Exposing bits to allow firewalls to do "what they do" is not going to be trivial, since "what they do" is not agreed upon elsewhere. I would love to believe you, but you must understand that your word (or yours and Dan's) just isn't enough here. > >In terms of how these apply to QUIC, we have data from the current > deployment of QUIC, and that can hopefully be brought to bear on the > decisions in the working group. Beyond that, I think it's all thin ice. We > can certainly try and get consensus on specific > > middlebox behaviors as important, but that conversation is more general > than just QUIC, and since your draft is precisely such a list, I'd argue > that it probably belongs in PLUS, TSVAREA/TSVWG, or INTAREA. > > I'm fine with working on a generic version of the draft in PLUS or TSVWG. > I am not fine with any discussion of how that draft applies to QUIC being > ruled out of charter by a potential QUIC working group. I believe we need > some charter text to protect that conversation. Fair enough; though I'll continue to ask for data when the conversation comes up. >On the proposed addition to the charter text, I am unclear on the intent. > Is it to document possible breakages, or is the intent to prescribe > middlebox behavior? > > The intent is to describe how QUIC deploys on the network, including > considering what, if any, changes are needed to make that deployment more > efficient. > > >That QUIC needs to work around middleboxes is already stated in the > charter as "Enabling deployment over unmodified Internet paths". If legacy > middleboxes exist on path, this goal has them covered. > > I do not believe this is adequate. The intent is not to describe legacy > devices. The intent is to be able to build new devices that are > QUIC-enabled, and to advantage QUIC traffic against large-scale UDP biases > that some network operators have in place. I definitely agree with the spirit, but I worry about this not being scoped tightly enough to prevent ratholes of various shapes and sizes. > >On changing network devices, this may be our other core disagreement. The > charter is proposing to work on QUIC, and not to modify network devices, > again because of what I said above. I think that a generalized form of this > draft is more relevant in a broader > > forum (as noted earlier), and once the requirements are made clear, > surely the QUIC wg can work on figuring out how to solve for them in QUIC. > > QUIC will not be able to be deployed on some networks, such as the one I'm > on right now, unless we describe the changes that are necessary for the > network devices that are currently blocking it. > Understood, and as much as I would love to see the universal deployment of QUIC, let's be clear that it's not a problem for 92% of users at the moment. - jana --001a114ddbac69ccbf0535843042 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joe,=

I'= ;d like to first say that I'm glad we're having this conversation n= ow, since I expected this conversation to happen sooner or later. We clearl= y have differences, but I understand where you're coming from and I wan= t to=C2=A0thank you for engaging reasonably (not that I would have expected= anything lesser from you.)=C2=A0

Responses inline.

>I understand what the draft describes, and as I said, I think this is u= seful when the wg is discussing what is visible in the QUIC header and what= isn't. The wg can decide whether to care about a particular middlebox = function or not.

Great.=C2=A0 Let's get a little bit of charter text added that s= ays that, then.=C2=A0 It may be that the text I proposed didn't capture= that nuance adequately.

I think the wordin= g was unclear, and I think I'm probably fine with Brian's proposed = text (I'll respond to the proposed text separately.) That said, the cha= rter text is only a placeholder for a conversation we want to have in the w= g. My disagreement is with the conversation that you're proposing.
=C2=A0
>That said, I think this may be one of our core disagreements: absent ag= reement on what middlebox functions are essential, it's hard to argue h= ow QUIC should solve for them. We saw a very similar conversation play out = in MPTCP. There were many questions
> about how legacy middleboxes would treat MPTCP options and modificatio= ns to TCP header bits. The problem was that there were too many boogeymen m= iddleboxes out there, and it was usually anybody's guess how important = any one particular behavior was. There was
> small-scale measurement work done that helped direct the conversation,= but this is tricky territory -- tricky largely because of the lack of subs= tantial data about particular middlebox behaviors and their prevalence and = importance.

We're not talking about boogeyman middleboxes here.=C2=A0 There = is no measurement needed, and no testing.

That's not a convincing argument -- with no measurement or data, the= re's only boogeymen middleboxes...
=C2=A0
We're talking about firewalls that currently block UDP, such as the one= I'm going through right now.=C2=A0 I would like to add explicit QUIC s= upport to that box so that

... and that= 9;s your boogeyman. Fortunately, there's data on this -- we shared this= in the BarBoF last year. That's about 7% of users. QUIC works well for= 92% of the users trying to use it (this is at massive scales of usage), as= shown on=C2=A0this sli= de. This data has been independently validated by non-Google WebRTC dep= loyments. So, this question can at least be scoped to 7% of users. I'll= also point out that just being about to identify QUIC is not going to be e= nough for the entire 7%, so it's really < 7%.

we can get the benefits of QUIC deployment.=C2=A0 I would li= ke any working group we form to do new transport protocols to have in scope= how that new transport deploys, and firewall traversal is a key real-world= deployment mechanism.

I would be happy with different charter language that allows a potential wo= rking group to consider adding language that tells firewalls and load balan= cers what to do with the bits that are exposed, in order to maximize user e= xperience, and allow firewalls and load balancers to do the best they can t= o protect the applications, hosts, and networks on whose behalf they are de= ployed.=C2=A0 I would like a potential working group to be able to discuss = what happens when signals from the network path such as ICMP are received, = as well as when they should be sent.=C2=A0 That might mean some changes to = the protocol, but hopefully most of it is just writing down some of the ass= umptions that people with more QUIC intuition have about what firewalls and= load balancers are going to do with the information that is already expose= d to the path.

I don't agree with t= his line of reasoning. The QUIC wg should specify what the endpoints do on = receiving ICMP messages from the network. But you are also asking for the Q= UIC wg to specify normative behavior of firewalls, when there is no equival= ent consensus on what they ought to do for TCP.=C2=A0 We're talking abo= ut solving for a list of problems that has no consensus. More importantly, = my opinion is that this wg may not have the right set of folks with whom yo= u want to drive consensus on this list of firewall behaviors. "People = with more QUIC intuition" certainly will have some idea of what behavi= ors to build for (and I expect that to happen), but these people will have = quite limited idea what firewalls need to do on path, and what information = firewalls need. IMO, you need network operations folks to be having that co= nversation, and QUIC is inconveniently not being proposed in OPSAREA (I'= ;m not sure which wg would be appropriate, which is why I proposed INTAREA.= Perhaps OPSAREA is a better fit.)

I agree that any more interesting path interactions, to the extent that the= y might be interesting, are more in the realm of PLUS.
Why are these less interesting path interactions? Exposing bits= to allow firewalls to do "what they do" is not going to be trivi= al, since "what they do" is not agreed upon elsewhere. I would lo= ve to believe you, but you must understand that your word (or yours and Dan= 's) just isn't enough here.
=C2=A0
= >In terms of how these apply to QUIC, we have data from the current depl= oyment of QUIC, and that can hopefully be brought to bear on the decisions = in the working group. Beyond that, I think it's all thin ice. We can ce= rtainly try and get consensus on specific
> middlebox behaviors as important, but that conversation is more genera= l than just QUIC, and since your draft is precisely such a list, I'd ar= gue that it probably belongs in PLUS, TSVAREA/TSVWG, or INTAREA.

I'm fine with working on a generic version of the draft in PLUS = or TSVWG.=C2=A0 I am not fine with any discussion of how that draft applies= to QUIC being ruled out of charter by a potential QUIC working group.=C2= =A0 I believe we need some charter text to protect that conversation.

Fair enough; though I'll continue to ask for= data when the conversation comes up.

= >On the proposed addition to the charter text, I am unclear on the inten= t. Is it to document possible breakages, or is the intent to prescribe midd= lebox behavior?

The intent is to describe how QUIC deploys on the network, including= considering what, if any, changes are needed to make that deployment more = efficient.

>That QUIC needs to work around middleboxes is already stated in the cha= rter as "Enabling deployment over unmodified Internet paths". If = legacy middleboxes exist on path, this goal has them covered.

I do not believe this is adequate.=C2=A0 The intent is not to descri= be legacy devices.=C2=A0 The intent is to be able to build new devices that= are QUIC-enabled, and to advantage QUIC traffic against large-scale UDP bi= ases that some network operators have in place.

=
I definitely agree with the spirit, but I worry about this not being s= coped tightly enough to prevent ratholes of various shapes and sizes.
=
=C2=A0
>On changing network devices, this may be our other core disagreement. T= he charter is proposing to work on QUIC, and not to modify network devices,= again because of what I said above. I think that a generalized form of thi= s draft is more relevant in a broader
> forum (as noted earlier), and once the requirements are made clear, su= rely the QUIC wg can work on figuring out how to solve for them in QUIC.
QUIC will not be able to be deployed on some networks, such as the o= ne I'm on right now, unless we describe the changes that are necessary = for the network devices that are currently blocking it.

Understood, and as much as I would love to see the univers= al deployment of QUIC, let's be clear that it's not a problem for 9= 2% of users at the moment.

- jana

--001a114ddbac69ccbf0535843042-- From nobody Fri Jun 17 20:11:12 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9E12D776 for ; Fri, 17 Jun 2016 20:11:10 -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 p-E30eUFTpVS for ; Fri, 17 Jun 2016 20:11:07 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 781D112B01A for ; Fri, 17 Jun 2016 20:11:07 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id w195so1699008ywd.0 for ; Fri, 17 Jun 2016 20:11:07 -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=fsaIsFRn3d/i9YCUz/5GgdISqKBgxk/Vee/tQ7RCFTo=; b=MO8nx1/wFQ4khdj+EA/Vw4E09rEz4O8N6C9wasLNDBM5b/9Sp6tudXuavwGTzThr7R j5ac61pDV6z2Bvq1g0xM/90LWjDzxQDiHppHNkOmfxBywLlsFRegaOH5X61b8LPtjxhN b6P0d/KkkoZdI2oMAFveRiKGRDcw4yUoAiVejVrKfKB286osMC9syVsFuJ8N2l4gtaj6 7IgtwWA9lKjLXzKweKUp1ol5YWY/15IuWc69eFkjBwupvegpWT4jJ9DzGUnmr1H556ju H/Bpgln9mybnFwQ0EIaSuun2K11ddRCnk/OEmbAod8lC9YnrIdB9eITmRLp+EcKFWz5g 6RNQ== 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=fsaIsFRn3d/i9YCUz/5GgdISqKBgxk/Vee/tQ7RCFTo=; b=UolM1ljltSl40WvRp1dUXVrbZ3VYN7GXgJxli1rlbyGxRW5bcC0Gei2+QsAU7iYiwP wI3a2HL9FrNN4aWhALDF2XK0Y/7XF0ns0Zdq1mBXhSblrOZjGqtSGVYmmFarqo305DRs vX7lQ8DEBtz+2765c6TMovUUQcxxr8vxOe70QyEVxv/qpOQ7lMKH53NsMemINRsXfEQJ uLLd31dhi5/XgGF26xZyFysxBoKKT75CNnYIaRNL+7o/TdGB0d6uknvtrSy4NJk+ygav WOeeOdovJe6nv3a1TPnXeelt0WAECXF2u/6Et997QSNFfpm23dqXe1pcL7xIVgPLxih7 gWeg== X-Gm-Message-State: ALyK8tJz9uVkgAbVvpWUbueVXphzNXeIFwzndZ9t8i4DWcxXxbwYKoeF++TFaZMkMJQasmOglqeypZ4PNF3QJgse X-Received: by 10.13.223.151 with SMTP id i145mr3005930ywe.189.1466219466355; Fri, 17 Jun 2016 20:11:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.219.83 with HTTP; Fri, 17 Jun 2016 20:11:05 -0700 (PDT) In-Reply-To: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> From: Jana Iyengar Date: Fri, 17 Jun 2016 20:11:05 -0700 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114e4a2474d471053584d2ed Archived-At: Cc: Christian Huitema , "quic@ietf.org" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 03:11:10 -0000 --001a114e4a2474d471053584d2ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > Given that, would the following change to the charter (adding one sentenc= e > to the paragraph for focus area one) be acceptable? > > OLD: > > The first of these is the core transport work, which will describe the > wire format, along with the mechanisms for connection establishment, stre= am > multiplexing, data reliability, loss detection and recovery, congestion > control, version negotiation, and options negotiation. Work on congestion > control will describe use of an existing congestion controller as a defau= lt > scheme for QUIC. QUIC is expected to support rapid iterability and > experimentation, and this work will describe a versioning process that > enables distributed experimentation with QUIC. > > NEW: > > The first of these is the core transport work, which will describe the > wire format, along with the mechanisms for connection establishment, stre= am > multiplexing, data reliability, loss detection and recovery, congestion > control, version negotiation, and options negotiation. This work will > consider deployability, manageability and diagnosability of the wire > format, including how the wire format will be processed by devices on pat= h. > Work on congestion control will describe use of an existing congestion > controller as a default scheme for QUIC. QUIC is expected to support rapi= d > iterability and experimentation, and this work will describe a versioning > process that enables distributed experimentation with QUIC. > Indeed, I would hope that manageability and diagnosability -- which > includes enabling firewalls to keep state, and making it possible to > differentiate attack traffic -- are requirements for any IETF transport > protocol going forward. > I'm fine with adding this text. That said, I don't think this requirement that you mention for any IETF transport is clear. What state are we talking about? I don't know of a clear definition of "attack traffic", though I very much agree that network operators have to deal with this problem for UDP. Without concrete requirements, it's hard to define a solution in the transport. - jana The discussion below, I think, needs to happen in the WG. General guidance > here can come from PLUS (and indeed, I see a lot of points raised in the > SPUD-derived requirements document draft-trammell-spud-req in Joe's list > below), but the detailed evaluation of these aspects of how the protocol > will interact with devices on path in the specific case of QUIC are a > matter for QUIC. I believe the suggestion above allows that work to happe= n. > > > Cheers, > > Brian > > > >> I heard two common requirements, "marking the beginning and end of a > flow," because that helps firewalls and load balancers manage resource, a= nd > "assessing consent," because that helps differentiating between regular > traffic and attack traffic. Is there more? > > > > If you want the processing to be efficient (and not ossify something > unintended), being able to separate QUIC traffic from non-QUIC UDP traffi= c > easily would be useful. Otherwise, path devices are likely to grab > whatever version number they see as the discriminant. > > > > If =E2=80=9Cmarking the beginning of a flow=E2=80=9D also includes bein= g able to tell > easily which side intended to initiate the conversation, then that=E2=80= =99s fine. > > > > The protocol needs to ensure that a path element can associate further > traffic on a QUIC connection with the beginning of the flow. > > > > There probably needs to be recommendations for time-outs, particularly > around the end of the flow. > > > > The protocol doc needs to describe what happens with associated ICMP. > > > > The protocol needs to say what happens when a network or host receives = a > QUIC packet it wasn=E2=80=99t expecting. > > > > We need to think about return routability. > > > > The protocol needs to keep in mind that state will be generated in the > network, so that as we add multi-path extensions (for example), we don=E2= =80=99t > just start sending traffic on a new path without first starting a new flo= w. > > > > It is possible that we might want to describe what a load balancer > should do when it drops QUIC state due to a timeout (or when it is *about= * > to drop state). We might want it to send a hint to one or both of the > endpoints, to avoid having to diagnose mid-stream black holes. Some load > TCP load balancers send RSTs in both directions in this case, for example= . > > > > We should analyze the known attacks on TCP (at least) to ensure that > QUIC is not immediately vulnerable to the sorts of things we=E2=80=99ve a= lready > fixed over the last 40 years. > > > > There are probably a couple of others, and I=E2=80=99m open to modifyin= g the > list as people see fit. Alternately, if we can find a way to describe > these kind of discussions in a way that does not bring in the explicit pa= th > communication bits that we explored in SPUD, I think the charter would be > easier to understand. > > > >>> QUIC will not be able to be deployed on some networks, such as the > >>> one I'm on right now, unless we describe the changes that are necessa= ry > >>> for the network devices that are currently blocking it. > >> > >> There are such networks. But there also are networks today that block > outgoing TCP connections, because of some policy considerations. We don't > change TCP for that. We simply accept that these networks are making a > tradeoff. They care so much about some of their policies that they are > willing to forego some of the value of the Internet. That's probably fine= . > Over time, the cost/advantage balance of the tradeoff will change, and th= e > policies will probably evolve. > > > > Are you saying that people will want QUIC so much that they will open > their firewalls up to all UDP traffic in both directions? Or that the > terrible timing-based heuristics we have for generic UDP will be enough f= or > a large enterprise? Or that the current protocol description, without > discussion and analysis, should be presumed to be perfect in this regard? > > > > For once, we have a chance to do some thoughtful engineering before a > protocol is fully specified to consider how it will be deployed, baking > decades of learning into the design. I think the approach that the TLS > working group has been doing on TLS 1.3 to consider attack vectors, > backward-compatibility, etc. is a model for what is needed from a protoco= l > of QUIC=E2=80=99s potential impact. > > > > -- > > Joe Hildebrand > > > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a114e4a2474d471053584d2ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Given that, would the following change to the charter (adding one sentence = to the paragraph for focus area one) be acceptable?

OLD:

The first of these is the core transport work, which will describe the wire= format, along with the mechanisms for connection establishment, stream mul= tiplexing, data reliability, loss detection and recovery, congestion contro= l, version negotiation, and options negotiation. Work on congestion control= will describe use of an existing congestion controller as a default scheme= for QUIC. QUIC is expected to support rapid iterability and experimentatio= n, and this work will describe a versioning process that enables distribute= d experimentation with QUIC.

NEW:

The first of these is the core transport work, which will describe the wire= format, along with the mechanisms for connection establishment, stream mul= tiplexing, data reliability, loss detection and recovery, congestion contro= l, version negotiation, and options negotiation. This work will consider de= ployability, manageability and diagnosability of the wire format, including= how the wire format will be processed by devices on path. Work on congesti= on control will describe use of an existing congestion controller as a defa= ult scheme for QUIC. QUIC is expected to support rapid iterability and expe= rimentation, and this work will describe a versioning process that enables = distributed experimentation with QUIC.

=C2= =A0
Indeed, I would hope that manageability and diagnosability -- which include= s enabling firewalls to keep state, and making it possible to differentiate= attack traffic -- are requirements for any IETF transport protocol going f= orward.

I'm fine with adding this t= ext. That said, I don't think this requirement that you mention for any= IETF transport is clear. What state are we talking about? I don't know= of a clear definition of "attack traffic", though I very much ag= ree that network operators have to deal with this problem for UDP. Without = concrete requirements, it's hard to define a solution in the transport.=

- jana

The discussion below, I think, needs to happen in the WG. General guidance = here can come from PLUS (and indeed, I see a lot of points raised in the SP= UD-derived requirements document draft-trammell-spud-req in Joe's list = below), but the detailed evaluation of these aspects of how the protocol wi= ll interact with devices on path in the specific case of QUIC are a matter = for QUIC. I believe the suggestion above allows that work to happen.


Cheers,

Brian


>> I heard two common requirements, "marking the beginning and e= nd of a flow," because that helps firewalls and load balancers manage = resource, and "assessing consent," because that helps differentia= ting between regular traffic and attack traffic. Is there more?
>
> If you want the processing to be efficient (and not ossify something u= nintended), being able to separate QUIC traffic from non-QUIC UDP traffic e= asily would be useful.=C2=A0 Otherwise, path devices are likely to grab wha= tever version number they see as the discriminant.
>
> If =E2=80=9Cmarking the beginning of a flow=E2=80=9D also includes bei= ng able to tell easily which side intended to initiate the conversation, th= en that=E2=80=99s fine.
>
> The protocol needs to ensure that a path element can associate further= traffic on a QUIC connection with the beginning of the flow.
>
> There probably needs to be recommendations for time-outs, particularly= around the end of the flow.
>
> The protocol doc needs to describe what happens with associated ICMP.<= br> >
> The protocol needs to say what happens when a network or host receives= a QUIC packet it wasn=E2=80=99t expecting.
>
> We need to think about return routability.
>
> The protocol needs to keep in mind that state will be generated in the= network, so that as we add multi-path extensions (for example), we don=E2= =80=99t just start sending traffic on a new path without first starting a n= ew flow.
>
> It is possible that we might want to describe what a load balancer sho= uld do when it drops QUIC state due to a timeout (or when it is *about* to = drop state).=C2=A0 We might want it to send a hint to one or both of the en= dpoints, to avoid having to diagnose mid-stream black holes.=C2=A0 Some loa= d TCP load balancers send RSTs in both directions in this case, for example= .
>
> We should analyze the known attacks on TCP (at least) to ensure that Q= UIC is not immediately vulnerable to the sorts of things we=E2=80=99ve alre= ady fixed over the last 40 years.
>
> There are probably a couple of others, and I=E2=80=99m open to modifyi= ng the list as people see fit.=C2=A0 Alternately, if we can find a way to d= escribe these kind of discussions in a way that does not bring in the expli= cit path communication bits that we explored in SPUD, I think the charter w= ould be easier to understand.
>
>>> QUIC will not be able to be deployed on some networks, such as= the
>>> one I'm on right now, unless we describe the changes that = are necessary
>>> for the network devices that are currently blocking it.
>>
>> There are such networks. But there also are networks today that bl= ock outgoing TCP connections, because of some policy considerations. We don= 't change TCP for that. We simply accept that these networks are making= a tradeoff. They care so much about some of their policies that they are w= illing to forego some of the value of the Internet. That's probably fin= e. Over time, the cost/advantage balance of the tradeoff will change, and t= he policies will probably evolve.
>
> Are you saying that people will want QUIC so much that they will open = their firewalls up to all UDP traffic in both directions?=C2=A0 Or that the= terrible timing-based heuristics we have for generic UDP will be enough fo= r a large enterprise?=C2=A0 Or that the current protocol description, witho= ut discussion and analysis, should be presumed to be perfect in this regard= ?
>
> For once, we have a chance to do some thoughtful engineering before a = protocol is fully specified to consider how it will be deployed, baking dec= ades of learning into the design.=C2=A0 I think the approach that the TLS w= orking group has been doing on TLS 1.3 to consider attack vectors, backward= -compatibility, etc. is a model for what is needed from a protocol of QUIC= =E2=80=99s potential impact.
>
> --
> Joe Hildebrand
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic


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


--001a114e4a2474d471053584d2ed-- From nobody Sat Jun 18 02:52:01 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81DB12D738 for ; Sat, 18 Jun 2016 02:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7NM7-fd4Nbj for ; Sat, 18 Jun 2016 02:51:57 -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 D7A4212D73E for ; Sat, 18 Jun 2016 02:51:56 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id r201so185884wme.1 for ; Sat, 18 Jun 2016 02:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ETvONE4ZJHt1Q9z/nxamnozFNpWRyNBr24cQDDQy9Eg=; b=xUHFUYlGCDXwwtiqU2+IXR0a1wX/0MgyoIdZzlkMeWR65ieRINRBHozrxTmO6+r4nL IdjFBeyYB7uFKHE7kH6gJ0f22tUKsXCowQHQ9S1zKYOGWMwwdy6XSCyZIgcQWC/MMT/Y bWH5gQexJnWg+7xlPQA4uk3+o5Njs6F6pPvxKC/e4U7Co+cHlJ1TbxvNz+znA9EZnNAh utxjVzcCuzuVmh4goNE6QFE7L2UnLVac/UQfXwed9ZTk0PMb0m6to9+z4o+hyJiyItDF U1nvTpBWWNnNqW/hp0QslICyf5eUltcujE9wRgJi466A1HKlMGhTRaAG96RUr0vl8CBg uNZg== 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:message-id:date :user-agent:mime-version:in-reply-to; bh=ETvONE4ZJHt1Q9z/nxamnozFNpWRyNBr24cQDDQy9Eg=; b=cqCEq5rDgIEIuofO8ZUBv3cluk39nTO8dK+4JOtskAl1GJYez6Yt+kH3QAm0O362vH pww/LZbhBclg70PZPShThOCl55Wr9XZJApwCWY5vZCbrIw4WfA9IhlyDxDliV9/8d2n8 +yZA4CFDsoirFVVHlWZfcCHG8i6ePPNNmFG2paq4NkpcujZWW8B1CJ75bX2YmTY4h883 75r/WDCPrCz6cvdscT/ecmB+Yi6UaKUEv1C26CuXCMloq6sQL+4w9Cmri2zM7ITQZgPP NfmDJSmMPjMxNUd7Uxv4oD1L5SkczC0ik5jUlqpsaPIlUxw0RUltsqkJA0BzJoXOqTmr gswQ== X-Gm-Message-State: ALyK8tI940IprTLqR4PLM6nzCKQ1jt+KZFMdqungCliB1YClIUXNw7J4/jMwl+xhQbBDvehA6nsBQX9EIa9SEfFTgIdBOkRYc2UzCULYLWQYsKOCSF508mUZ X-Received: by 10.28.130.12 with SMTP id e12mr2442760wmd.20.1466243515321; Sat, 18 Jun 2016 02:51:55 -0700 (PDT) Received: from [192.168.1.3] ([87.66.241.151]) by smtp.gmail.com with ESMTPSA id a191sm2942926wme.5.2016.06.18.02.51.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Jun 2016 02:51:54 -0700 (PDT) To: =?UTF-8?Q?G=c3=b6ran_Eriksson_AP?= , "quic@ietf.org" References: From: Olivier Bonaventure Message-ID: <7e39edf4-80ae-f08e-64e1-98e9ffc7dff3@tessares.net> Date: Sat, 18 Jun 2016 11:51:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Archived-At: Subject: Re: [QUIC] HTTP/2 on M-QUIC- fallback to MPTCP? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 09:51:59 -0000 Hello, > > The use of HTTP/2 on Multipath-QUIC is now in the scope of the proposed > charter and fall back from QUIC to TCP may sometimes be necessary. > > Should thus HTTP/2 on MP-TCP also be a possibility and worked on? Fallback to TCP implies fallback to any TCP extension that can be negotiated during the three-way handshake, including RFC1323, SACK, MPTCP or tcpcrypt. HTTP/2 over MP-TCP has clear benefits compared to HTTP/1.0 over MPTCP since there are fewer transport connections and these will carry more data, giving time for the MPTCP subflows to correctly utilise the available paths. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Sun Jun 19 05:16:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8037612B05A for ; Sun, 19 Jun 2016 05:16:29 -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 ZzUsVfw0em5c for ; Sun, 19 Jun 2016 05:16:27 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DEA5112D0A7 for ; Sun, 19 Jun 2016 05:16:26 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 9E89F1A0F1C; Sun, 19 Jun 2016 14:15:54 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9AFD9CFE-37CE-42A7-A504-77132A955420"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Sun, 19 Jun 2016 14:16:00 +0200 Message-Id: <785139E5-B347-4B4E-AD62-C44F2D67BE06@trammell.ch> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Christian Huitema , "quic@ietf.org" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 12:16:29 -0000 --Apple-Mail=_9AFD9CFE-37CE-42A7-A504-77132A955420 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Jana, (hatless, inline) > On 18 Jun 2016, at 05:11, Jana Iyengar wrote: >=20 >=20 > Given that, would the following change to the charter (adding one = sentence to the paragraph for focus area one) be acceptable? >=20 > OLD: >=20 > The first of these is the core transport work, which will describe the = wire format, along with the mechanisms for connection establishment, = stream multiplexing, data reliability, loss detection and recovery, = congestion control, version negotiation, and options negotiation. Work = on congestion control will describe use of an existing congestion = controller as a default scheme for QUIC. QUIC is expected to support = rapid iterability and experimentation, and this work will describe a = versioning process that enables distributed experimentation with QUIC. >=20 > NEW: >=20 > The first of these is the core transport work, which will describe the = wire format, along with the mechanisms for connection establishment, = stream multiplexing, data reliability, loss detection and recovery, = congestion control, version negotiation, and options negotiation. This = work will consider deployability, manageability and diagnosability of = the wire format, including how the wire format will be processed by = devices on path. Work on congestion control will describe use of an = existing congestion controller as a default scheme for QUIC. QUIC is = expected to support rapid iterability and experimentation, and this work = will describe a versioning process that enables distributed = experimentation with QUIC. >=20 >=20 > Indeed, I would hope that manageability and diagnosability -- which = includes enabling firewalls to keep state, and making it possible to = differentiate attack traffic -- are requirements for any IETF transport = protocol going forward. >=20 > I'm fine with adding this text. That said, I don't think this = requirement that you mention for any IETF transport is clear. What state = are we talking about? The *bare minimum* here is perhaps best called "connection = establishable": (1) what current practice (ab)uses SYN/ACK to mean (the = server decided a given connection request was OK enough to continue) and = (2) some indication that the entity that sent the first packet on an = n-tuple can actually receive traffic on the source address it gave, = roughly equivalent to the third ACK leg of the TCP 3WHS. We should have a longer discussion about how much more state might be = useful in the WG; that's what I hope to accomplish with my charter text = proposal. But without at least this much being visible to on-path = devices, QUIC will be largely incompatible with TCP-centric network = management practice, which I'm afraid will come with negative = consequences for deployment. > I don't know of a clear definition of "attack traffic", Heh. If I knew of one of *those*, that was always network visible and = didn't rely on the evil bit, I'd be in a different business. :) But I = think there are some basic signals a transport protocol can radiate = toward devices on the path that makes it possible for such devices to = reduce such traffic, as above. Cheers, Brian > though I very much agree that network operators have to deal with this = problem for UDP. Without concrete requirements, it's hard to define a = solution in the transport. >=20 > - jana >=20 > The discussion below, I think, needs to happen in the WG. General = guidance here can come from PLUS (and indeed, I see a lot of points = raised in the SPUD-derived requirements document draft-trammell-spud-req = in Joe's list below), but the detailed evaluation of these aspects of = how the protocol will interact with devices on path in the specific case = of QUIC are a matter for QUIC. I believe the suggestion above allows = that work to happen. >=20 >=20 > Cheers, >=20 > Brian >=20 >=20 > >> I heard two common requirements, "marking the beginning and end of = a flow," because that helps firewalls and load balancers manage = resource, and "assessing consent," because that helps differentiating = between regular traffic and attack traffic. Is there more? > > > > If you want the processing to be efficient (and not ossify something = unintended), being able to separate QUIC traffic from non-QUIC UDP = traffic easily would be useful. Otherwise, path devices are likely to = grab whatever version number they see as the discriminant. > > > > If =E2=80=9Cmarking the beginning of a flow=E2=80=9D also includes = being able to tell easily which side intended to initiate the = conversation, then that=E2=80=99s fine. > > > > The protocol needs to ensure that a path element can associate = further traffic on a QUIC connection with the beginning of the flow. > > > > There probably needs to be recommendations for time-outs, = particularly around the end of the flow. > > > > The protocol doc needs to describe what happens with associated = ICMP. > > > > The protocol needs to say what happens when a network or host = receives a QUIC packet it wasn=E2=80=99t expecting. > > > > We need to think about return routability. > > > > The protocol needs to keep in mind that state will be generated in = the network, so that as we add multi-path extensions (for example), we = don=E2=80=99t just start sending traffic on a new path without first = starting a new flow. > > > > It is possible that we might want to describe what a load balancer = should do when it drops QUIC state due to a timeout (or when it is = *about* to drop state). We might want it to send a hint to one or both = of the endpoints, to avoid having to diagnose mid-stream black holes. = Some load TCP load balancers send RSTs in both directions in this case, = for example. > > > > We should analyze the known attacks on TCP (at least) to ensure that = QUIC is not immediately vulnerable to the sorts of things we=E2=80=99ve = already fixed over the last 40 years. > > > > There are probably a couple of others, and I=E2=80=99m open to = modifying the list as people see fit. Alternately, if we can find a way = to describe these kind of discussions in a way that does not bring in = the explicit path communication bits that we explored in SPUD, I think = the charter would be easier to understand. > > > >>> QUIC will not be able to be deployed on some networks, such as the > >>> one I'm on right now, unless we describe the changes that are = necessary > >>> for the network devices that are currently blocking it. > >> > >> There are such networks. But there also are networks today that = block outgoing TCP connections, because of some policy considerations. = We don't change TCP for that. We simply accept that these networks are = making a tradeoff. They care so much about some of their policies that = they are willing to forego some of the value of the Internet. That's = probably fine. Over time, the cost/advantage balance of the tradeoff = will change, and the policies will probably evolve. > > > > Are you saying that people will want QUIC so much that they will = open their firewalls up to all UDP traffic in both directions? Or that = the terrible timing-based heuristics we have for generic UDP will be = enough for a large enterprise? Or that the current protocol = description, without discussion and analysis, should be presumed to be = perfect in this regard? > > > > For once, we have a chance to do some thoughtful engineering before = a protocol is fully specified to consider how it will be deployed, = baking decades of learning into the design. I think the approach that = the TLS working group has been doing on TLS 1.3 to consider attack = vectors, backward-compatibility, etc. is a model for what is needed from = a protocol of QUIC=E2=80=99s potential impact. > > > > -- > > Joe Hildebrand > > > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic >=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic >=20 >=20 --Apple-Mail=_9AFD9CFE-37CE-42A7-A504-77132A955420 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 iQIcBAEBCgAGBQJXZo0BAAoJEIoSt78L6kajhg0P/Rxg+LSyPKW1Ora3RXn0+2dD RwpsSIUDq9b8P7GUfa2Y0fYJJSAKegmuOPCaiAiLinshbKD7r5hzmiKsnVJqQgSx 5U6fj8USAxs6HV8QyQ4Du+jdyNk+t98PTvlaKGsbjloMRwKQ9sxmtV8yiza5Aoob CTBd/LcHiJgYVbNaWsbqdEMVo9PFQqqDKvPSi4CPEZfnH9MemDTjrPxfFTWm6P82 VVxlSDWZUSyxiuSTgGuwm6wzWTW2NzHt+ivaCqCJdQVX1sdJ920SOo2y5Cjze4UC iY9aZLrJ/JP53pH6cbLQ5ETyDirsxDuHg2r3cBtEhQBDify+e/kWpNF5U1Z5ygg1 v+FM79irbx6wNi/Vl/NJ2vMVQSnAbWDowyHwZgOUUS9Ky01d88DuBJrlNs5IPGY2 GwJjnqfEMIaT0ZXiMBsvB0xfAN7yx//R+Klzb7alyyxWnsUDVf0RmilRQSW8UmgV 1D9pTVztWAdn0+mpGTaFzsRAfZ1LRha1xfvhnBIUIJlYAUj9OgkfK2ix2ysvFMjd 7OHNzHOEEM6LNLrDGQk2LQFuByNX5XNKdudkjAk95EifObFh4B/DoBY2+nzOqlad tS2avUXaIuCtJz53IiESSWu0azveKsp+rF79sEv3tQsagwwtAQP9i1HlIm8V9OvV YN3T5j42DAola0BVEgln =i8+B -----END PGP SIGNATURE----- --Apple-Mail=_9AFD9CFE-37CE-42A7-A504-77132A955420-- From nobody Sun Jun 19 21:19:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4568B12D932 for ; Sun, 19 Jun 2016 21:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dPpCDB1cGFsG for ; Sun, 19 Jun 2016 21:19:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 B4A7412D8E3 for ; Sun, 19 Jun 2016 21:19:43 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 67AC622E1F3; Mon, 20 Jun 2016 00:19:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: <39812194-C385-42D3-A877-C0BC4320231D@cisco.com> Date: Mon, 20 Jun 2016 14:19:34 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <70336B4F-4137-4D08-8DA6-4CC458DB5EBC@mnot.net> References: <39812194-C385-42D3-A877-C0BC4320231D@cisco.com> To: Joe Hildebrand X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 04:19:46 -0000 > On 18 Jun 2016, at 5:53 AM, Joe Hildebrand (jhildebr) = wrote: >=20 >>> 4. Long-lived Connections and HTTP Server Push >> The public ConnectionID could help here as well, to detect a QUIC = connection and allow a longer-lived firewall pinhole. But again this = depends on the firewall capability. >>=20 >> Please can you expand on the HTTP Server Push case? Currently our = firewalls allow UDP for network-attached device requests, which open a = firewall pinhole for a set time. Unsolicited UDP pushed from the = Internet will be subject to blocking or rate-limiting, so assuring the = consent is important here. >=20 > I=E2=80=99m envisioning that your firewalls will be able to treat QUIC = connections very similarly to how you treat TCP connections, in terms of = security, but without as much insight into the congestion and = retransmission properties. We don=E2=80=99t yet have analysis that = suggests that it=E2=80=99s possible to do this, however, and a potential = working group should be able to have that discussion. The Server Push mention here seems spurious; I think you're trying to = talk about the issues with long-lived, idle / "long polling" styles of = communication, not specific to Server Push.=20 The biggest current use cases for Server Push are around avoiding a RT = to fetch a pages' assets; WebPush is using it for long polling, but = that's relatively obscure, so referring to Server Push here is going to = confuse people. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 20 02:29:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6412D9CB for ; Mon, 20 Jun 2016 02:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 hvsvBHdd-wEe for ; Mon, 20 Jun 2016 02:29:38 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.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 3AD1412D9C4 for ; Mon, 20 Jun 2016 02:29:37 -0700 (PDT) Received: from [85.158.136.83] by server-5.bemta-5.messagelabs.com id 91/3E-29837-087B7675; Mon, 20 Jun 2016 09:29:36 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRWlGSWpSXmKPExsVy+MWXDt2y7en hBl/+aVv0LOB2YPRYsuQnUwBjFGtmXlJ+RQJrxvPfvxgLjvBW7Dq5lrWBcSZ3FyMXh5DABUaJ y8e+MXcxcgI5exkl3vwRhkjsZpL4+uU3E4RzhFGiof8aI4Qzl1Hi369WVpAWNgFXiaO77rCD2 CICyhJzli4Gs4UFzCQevp0KVMMBFLeWuH86HaJET+Ldzf1MIDaLgKrEivvv2UBKeAVCJc43ZY CEGQVkJb40rgY7iFlAXOLWk/lg5RICAhJL9pxnhrBFJV4+/scKUaMjsWD3JzYIW1ti2cLXYDW 8AoISJ2c+YZnAKDwLyahZSFpmIWmZhaRlASPLKkb14tSistQiXTO9pKLM9IyS3MTMHF1DA1O9 3NTi4sT01JzEpGK95PzcTYzA4GcAgh2MUxucDzFKcjApifLaFKeHC/El5adUZiQWZ8QXleakF h9ilOHgUJLgvTEXKCdYlJqeWpGWmQOMQ5i0BAePkgjvL5A0b3FBYm5xZjpE6hSjopQ472aQhA BIIqM0D64NFvuXGGWlhHkZgQ4R4ilILcrNLEGVf8UozsGoJMzLMg9oCk9mXgnc9FdAi5mAFi/ rB1tckoiQkmpg1EufMS15ffbtiV+/PIie7fVjiR3TsoIV64vLLVu4EvymevQwPLerfpY8SWLx jnNP/FesX+CYlhK0R6jPauZ0+aoHP/O55VQm863KL7nuP0OXY/sF7d1+yT+uyLg7dYpuOKxht mlt54IzYgf25dqdPJAyq/9k3a3Uz9bR03pm2b/hL/r6npu/VYmlOCPRUIu5qDgRACjBfjj4Ag AA X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-12.tower-36.messagelabs.com!1466414828!40470752!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14640 invoked from network); 20 Jun 2016 09:28:15 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-12.tower-36.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 20 Jun 2016 09:28:15 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout04.vodafone.com (Postfix) with ESMTP id 3rY5983RNJznVj6 for ; Mon, 20 Jun 2016 11:27:08 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3rY5982HpGzxQ7n for ; Mon, 20 Jun 2016 11:27:08 +0200 (CEST) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3rY59812knzxQDQ for ; Mon, 20 Jun 2016 11:27:08 +0200 (CEST) Received: from VOEXC30W.internal.vodafone.com (145.230.103.202) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 20 Jun 2016 11:27:04 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.75]) by voexc30w ([145.230.103.202]) with mapi id 14.03.0224.002; Mon, 20 Jun 2016 11:27:02 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "quic@ietf.org" Thread-Topic: Re: [QUIC] Network Path Requirements for QUIC Thread-Index: AdHK1eTgZF8A5FaTS56C/HYdHESNyA== Date: Mon, 20 Jun 2016 09:27:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 09:29:40 -0000 Hello Mark, >>>> 4. Long-lived Connections and HTTP Server Push >>> The public ConnectionID could help here as well, to detect a QUIC conne= ction and allow a longer-lived firewall pinhole. But again this depends on = the firewall capability. >>>=20 >>> Please can you expand on the HTTP Server Push case? Currently our firew= alls allow UDP for network-attached device requests, which open a firewall = pinhole for a set time. Unsolicited UDP pushed from the Internet will be su= bject to blocking or rate-limiting, so assuring the consent is important he= re. >>=20 >> I'm envisioning that your firewalls will be able to treat QUIC connectio= ns very similarly to how you treat TCP connections, in terms of security, b= ut without as much insight into the congestion and retransmission propertie= s. We don't yet have analysis that suggests that it's possible to do this,= however, and a potential working group should be able to have that discuss= ion. >The Server Push mention here seems spurious; I think you're trying to talk= about the issues with long-lived, idle / "long polling" styles of communic= ation, not specific to Server Push.=20 Yes, that's right - fair point. >The biggest current use cases for Server Push are around avoiding a RT to = fetch a pages' assets; WebPush is using it for long polling, but that's rel= atively obscure, so referring to Server Push here is going to confuse peopl= e. Yes, my mistake on nomenclature. I'm rather thinking of pushes stemming fro= m Push API/Notification API growing in popularity, but then these involve e= xplicit permission ('assured consent') and so are not unsolicited.=20 Thanks for the clarifications! Cheers Kevin Mr Kevin Smith=20 Vodafone Group R&D From nobody Mon Jun 20 09:04:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73212D1DC for ; Mon, 20 Jun 2016 09:04:36 -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 1tAvIaiqSCtX for ; Mon, 20 Jun 2016 09:04:34 -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 6546F12D0CE for ; Mon, 20 Jun 2016 09:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9845; q=dns/txt; s=iport; t=1466438674; x=1467648274; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4OUKJVDmckpB5lQOB6NhIGFjDjn8lKqTCxJrHAhAetg=; b=M2VznSh67sSlSk+WrXUxzn/KGm6bvu4jZFtMkOkDOVi6NUcgw+o/AP9B wAdRTSuoK/pclf7drZtfw1nYvVEVbHeHrcwlLpQCCS9AH0KaRJijUOK4Q BUBRHL9WSA0OJosWw/3vxE2RHDmLaj5OVhntxyat97PnQ/gBlftAn2eyW k=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCqE2hX/4sNJK1dgz5WfQa6ZoF6F?= =?us-ascii?q?wuFdQKBNDgUAQEBAQEBAWUnhEsBAQEDAQEBAQsVQggBCwULAgEIDgoqAgInCyU?= =?us-ascii?q?CBAENBQ4NiA0IDrBGkDYBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWIHoFTgQOEK?= =?us-ascii?q?oMXK4IvBYgUkGACAYMtgWqJEo8ij3YBHjaCCByBTG6JSX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,499,1459814400"; d="asc'?scan'208";a="116974823" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2016 16:04:26 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5KG4QsJ014809 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 16:04:26 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 11:04:26 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 11:04:26 -0500 From: "Matt Miller (mamille2)" To: Brian Trammell , Jana Iyengar Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmpT3QkIi+dpe0ejS5V80mQ1GJ/po2CAgAAH8YCAAActAIAABYCAgACvEICAAPrsAIAARVKAgADPTICAADWaAIAABwgAgAASL4CAAh+tgIACKpUAgAHSJoA= Date: Mon, 20 Jun 2016 16:04:26 +0000 Message-ID: <40E3E4E2-322C-4B97-9F22-3FEBFE7D6039@cisco.com> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <36A34F1E-7673-4A5D-9263-DCE246276C85@cisco.com> <785139E5-B347-4B4E-AD62-C44F2D67BE06@trammell.ch> In-Reply-To: <785139E5-B347-4B4E-AD62-C44F2D67BE06@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.24.65] Content-Type: multipart/signed; boundary="Apple-Mail=_AB6B548F-214E-4E41-BCE9-32E73C7DF4E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Christian Huitema , "quic@ietf.org" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:04:36 -0000 --Apple-Mail=_AB6B548F-214E-4E41-BCE9-32E73C7DF4E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To me it's clear this discussion needs to continue to happen, and needs = to be in scope for the proposed WG. To that end, I think Brian's = suggested text does that and ought to be adopted. -- - m&m Matt Miller Cisco Systems, Inc. > On Jun 19, 2016, at 06:16, Brian Trammell wrote: >=20 > hi Jana, >=20 > (hatless, inline) >=20 >> On 18 Jun 2016, at 05:11, Jana Iyengar wrote: >>=20 >>=20 >> Given that, would the following change to the charter (adding one = sentence to the paragraph for focus area one) be acceptable? >>=20 >> OLD: >>=20 >> The first of these is the core transport work, which will describe = the wire format, along with the mechanisms for connection establishment, = stream multiplexing, data reliability, loss detection and recovery, = congestion control, version negotiation, and options negotiation. Work = on congestion control will describe use of an existing congestion = controller as a default scheme for QUIC. QUIC is expected to support = rapid iterability and experimentation, and this work will describe a = versioning process that enables distributed experimentation with QUIC. >>=20 >> NEW: >>=20 >> The first of these is the core transport work, which will describe = the wire format, along with the mechanisms for connection establishment, = stream multiplexing, data reliability, loss detection and recovery, = congestion control, version negotiation, and options negotiation. This = work will consider deployability, manageability and diagnosability of = the wire format, including how the wire format will be processed by = devices on path. Work on congestion control will describe use of an = existing congestion controller as a default scheme for QUIC. QUIC is = expected to support rapid iterability and experimentation, and this work = will describe a versioning process that enables distributed = experimentation with QUIC. >>=20 >>=20 >> Indeed, I would hope that manageability and diagnosability -- which = includes enabling firewalls to keep state, and making it possible to = differentiate attack traffic -- are requirements for any IETF transport = protocol going forward. >>=20 >> I'm fine with adding this text. That said, I don't think this = requirement that you mention for any IETF transport is clear. What state = are we talking about? >=20 > The *bare minimum* here is perhaps best called "connection = establishable": (1) what current practice (ab)uses SYN/ACK to mean (the = server decided a given connection request was OK enough to continue) and = (2) some indication that the entity that sent the first packet on an = n-tuple can actually receive traffic on the source address it gave, = roughly equivalent to the third ACK leg of the TCP 3WHS. >=20 > We should have a longer discussion about how much more state might be = useful in the WG; that's what I hope to accomplish with my charter text = proposal. But without at least this much being visible to on-path = devices, QUIC will be largely incompatible with TCP-centric network = management practice, which I'm afraid will come with negative = consequences for deployment. >=20 >> I don't know of a clear definition of "attack traffic", >=20 > Heh. If I knew of one of *those*, that was always network visible and = didn't rely on the evil bit, I'd be in a different business. :) But I = think there are some basic signals a transport protocol can radiate = toward devices on the path that makes it possible for such devices to = reduce such traffic, as above. >=20 > Cheers, >=20 > Brian >=20 >> though I very much agree that network operators have to deal with = this problem for UDP. Without concrete requirements, it's hard to define = a solution in the transport. >>=20 >> - jana >>=20 >> The discussion below, I think, needs to happen in the WG. General = guidance here can come from PLUS (and indeed, I see a lot of points = raised in the SPUD-derived requirements document draft-trammell-spud-req = in Joe's list below), but the detailed evaluation of these aspects of = how the protocol will interact with devices on path in the specific case = of QUIC are a matter for QUIC. I believe the suggestion above allows = that work to happen. >>=20 >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>>> I heard two common requirements, "marking the beginning and end of = a flow," because that helps firewalls and load balancers manage = resource, and "assessing consent," because that helps differentiating = between regular traffic and attack traffic. Is there more? >>>=20 >>> If you want the processing to be efficient (and not ossify something = unintended), being able to separate QUIC traffic from non-QUIC UDP = traffic easily would be useful. Otherwise, path devices are likely to = grab whatever version number they see as the discriminant. >>>=20 >>> If =E2=80=9Cmarking the beginning of a flow=E2=80=9D also includes = being able to tell easily which side intended to initiate the = conversation, then that=E2=80=99s fine. >>>=20 >>> The protocol needs to ensure that a path element can associate = further traffic on a QUIC connection with the beginning of the flow. >>>=20 >>> There probably needs to be recommendations for time-outs, = particularly around the end of the flow. >>>=20 >>> The protocol doc needs to describe what happens with associated = ICMP. >>>=20 >>> The protocol needs to say what happens when a network or host = receives a QUIC packet it wasn=E2=80=99t expecting. >>>=20 >>> We need to think about return routability. >>>=20 >>> The protocol needs to keep in mind that state will be generated in = the network, so that as we add multi-path extensions (for example), we = don=E2=80=99t just start sending traffic on a new path without first = starting a new flow. >>>=20 >>> It is possible that we might want to describe what a load balancer = should do when it drops QUIC state due to a timeout (or when it is = *about* to drop state). We might want it to send a hint to one or both = of the endpoints, to avoid having to diagnose mid-stream black holes. = Some load TCP load balancers send RSTs in both directions in this case, = for example. >>>=20 >>> We should analyze the known attacks on TCP (at least) to ensure that = QUIC is not immediately vulnerable to the sorts of things we=E2=80=99ve = already fixed over the last 40 years. >>>=20 >>> There are probably a couple of others, and I=E2=80=99m open to = modifying the list as people see fit. Alternately, if we can find a way = to describe these kind of discussions in a way that does not bring in = the explicit path communication bits that we explored in SPUD, I think = the charter would be easier to understand. >>>=20 >>>>> QUIC will not be able to be deployed on some networks, such as the >>>>> one I'm on right now, unless we describe the changes that are = necessary >>>>> for the network devices that are currently blocking it. >>>>=20 >>>> There are such networks. But there also are networks today that = block outgoing TCP connections, because of some policy considerations. = We don't change TCP for that. We simply accept that these networks are = making a tradeoff. They care so much about some of their policies that = they are willing to forego some of the value of the Internet. That's = probably fine. Over time, the cost/advantage balance of the tradeoff = will change, and the policies will probably evolve. >>>=20 >>> Are you saying that people will want QUIC so much that they will = open their firewalls up to all UDP traffic in both directions? Or that = the terrible timing-based heuristics we have for generic UDP will be = enough for a large enterprise? Or that the current protocol = description, without discussion and analysis, should be presumed to be = perfect in this regard? >>>=20 >>> For once, we have a chance to do some thoughtful engineering before = a protocol is fully specified to consider how it will be deployed, = baking decades of learning into the design. I think the approach that = the TLS working group has been doing on TLS 1.3 to consider attack = vectors, backward-compatibility, etc. is a model for what is needed from = a protocol of QUIC=E2=80=99s potential impact. >>>=20 >>> -- >>> Joe Hildebrand >>>=20 >>> _______________________________________________ >>> QUIC mailing list >>> QUIC@ietf.org >>> https://www.ietf.org/mailman/listinfo/quic >>=20 >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >>=20 >>=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_AB6B548F-214E-4E41-BCE9-32E73C7DF4E0 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 iQEcBAEBCgAGBQJXaBQJAAoJEDWi+S0W7cO1+4EH/2n/T9vkGkT0n7rq/dPNfCjm RfQoLqXMWYnEqpmj1e4NVmXbqsatDjNYWfIG5j2MoKdGK9YJZkC2bYN31aAl4HmB D97LyCSPg+3Rm3DcYOoEzJfL1hlWifimxfGy1UC3OrMIrbTVN1moLPhVnQh29TZd YL0rar8RMrUOVq2q07FRZmE1hfv7B1e4hKDfEmRqsVh20cHDiRdVD2hgQf4oS3o8 Zi+WgyQW1C3E6QGjHWLhdBQ0+ug9X2Qf7KGACYRafFnGZ9nkb+4ipony66d9pHCC 4FaRiLpbzZxSHaOVg/8NiGLR20AuTjbJ4ovaxQRYiazZjrgxEHiSyXAKRjefIvc= =bHFR -----END PGP SIGNATURE----- --Apple-Mail=_AB6B548F-214E-4E41-BCE9-32E73C7DF4E0-- From nobody Mon Jun 20 13:36:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B61312D7AB for ; Mon, 20 Jun 2016 13:36:01 -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 m3-4p_WueYgs for ; Mon, 20 Jun 2016 13:35:59 -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 7063B12D7AF for ; Mon, 20 Jun 2016 13:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1466454959; x=1467664559; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3S78IF7VRwdQ1PRjt29JPLl/j/EToMgzNtE2nAbEneo=; b=H6aTGIZ9KF6mp/HKu+2EXaewQEAVmlptP2iAW2kArDmltbzxyH2PI6Ee MtYby76pekpBuOPn7g88U9PWoEk28G6oWv/TKLcpc1qrICNSK/pE5wjm4 3buMtXoFWziDJhjDBr+ay8Zrposh/kz083E5sHxIvUd4ML1d39ceqblDM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQBQAPU2hX/5BdJa1dgz6BUwa4XoQJh?= =?us-ascii?q?hcCHIEVOxEBAQEBAQEBZSeETAEBBCMRRRACAQgODAImAgICMBUQAgQOBYgwsQa?= =?us-ascii?q?QTAEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUmgXeCVoQqgxcrgi8BBJh2AY4pj?= =?us-ascii?q?yKPdgE0IINwbolJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,500,1459814400"; d="scan'208";a="117074668" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2016 20:35:58 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5KKZwA4021040 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 20:35:58 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 16:35:57 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 16:35:57 -0400 From: "Joe Hildebrand (jhildebr)" To: Mark Nottingham Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRyNHungnMNByYeE6HaTevmuxVO5/yB1AAgADNvIA= Date: Mon, 20 Jun 2016 20:35:57 +0000 Message-ID: References: <39812194-C385-42D3-A877-C0BC4320231D@cisco.com> <70336B4F-4137-4D08-8DA6-4CC458DB5EBC@mnot.net> In-Reply-To: <70336B4F-4137-4D08-8DA6-4CC458DB5EBC@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.134] Content-Type: text/plain; charset="utf-8" Content-ID: <94FDD0AAF52EB94097785221148C8A73@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 20:36:01 -0000 DQpPbiA2LzIwLzE2LCAxMjoxOSBBTSwgIk1hcmsgTm90dGluZ2hhbSIgPG1ub3RAbW5vdC5uZXQ+ IHdyb3RlOg0KDQo+VGhlIFNlcnZlciBQdXNoIG1lbnRpb24gaGVyZSBzZWVtcyBzcHVyaW91czsg SSB0aGluayB5b3UncmUgdHJ5aW5nIHRvIHRhbGsgYWJvdXQgdGhlIGlzc3VlcyB3aXRoIGxvbmct bGl2ZWQsIGlkbGUgLyAibG9uZyBwb2xsaW5nIiBzdHlsZXMgb2YgY29tbXVuaWNhdGlvbiwgbm90 IHNwZWNpZmljIHRvIFNlcnZlciBQdXNoLiANCj4NCj5UaGUgYmlnZ2VzdCBjdXJyZW50IHVzZSBj YXNlcyBmb3IgU2VydmVyIFB1c2ggYXJlIGFyb3VuZCBhdm9pZGluZyBhIFJUIHRvIGZldGNoIGEg cGFnZXMnIGFzc2V0czsgV2ViUHVzaCBpcyB1c2luZyBpdCBmb3IgbG9uZyBwb2xsaW5nLCBidXQg dGhhdCdzIHJlbGF0aXZlbHkgb2JzY3VyZSwgc28gcmVmZXJyaW5nIHRvIFNlcnZlciBQdXNoIGhl cmUgaXMgZ29pbmcgdG8gY29uZnVzZSBwZW9wbGUuDQoNCkFncmVlLiAgSSBoYWQgYWN0dWFsbHkg dHJhbnNsYXRlZCB0aGF0IGluIG15IGhlYWQgaW50byB3ZWJzb2NrZXRzLCB3ZWJwdXNoLCBhbmQg WE1QUCBvdmVyIFFVSUMuICBFYWNoIG9mIHRob3NlIGFyZSBtb3JlIGNvbmNyZXRlIHRoYW4gd2hh dCBpcyBjdXJyZW50bHkgaW4gdGhlIGRyYWZ0OyB3ZeKAmWxsIGRvIHdoYXQgd2UgY2FuIHRvIG1h a2UgaXQgbW9yZSBlYXNpbHkgY29tcHJlaGVuc2libGUgaW4gYSBmdXR1cmUgdmVyc2lvbi4NCg0K VGhlIGltcG9ydGFudCBwYXJ0IGlzIHRoYXQgUVVJQyBjb25uZWN0aW9ucyBtaWdodCBsYXN0IGEg bG9uZyB0aW1lLiAgUmlnaHQgbm93LCBzZWN0aW9uIDguMTAgb2YgdGhlIGRyYWZ0IHNheXMgdGhh dCBieSBkZWZhdWx0LCB5b3Ugc2VuZCBhIHBpbmcg4oCcYWZ0ZXIgMTUgc2Vjb25kcyBvZiBxdWll c2NlbmNlLCB3aGljaCBpcyBtdWNoIHNob3J0ZXIgdGhhbiBtb3N0IE5BVHMgdGltZSBvdXTigJ0u ICBEb2VzIHRoaXMgbWVhbiAxNSBzZWNvbmRzIHNpbmNlIEkgbGFzdCByZWNlaXZlZCBkYXRhPyAg MTVzIHNpbmNlIEkgbGFzdCBzZW50IGRhdGEgSWYgSeKAmW0gYSBuZXR3b3JrIGRldmljZSB0cmFj a2luZyBRVUlDIHN0YXRlLCBzaG91bGQgSSB0YWtlIDE2IHNlY29uZHMgb2YgcXVpZXNjZW5jZSBh cyBhbiBpbXBsaWNpdCBzaHV0ZG93bj8gIFRoaXMgaXMgYW4gZXhhbXBsZSBvZiB0aGUgc29ydCBv ZiB0aGluZyB3ZSBjb3VsZCBkaXNjdXNzLiAgDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0K From nobody Mon Jun 20 15:01:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E3E12DA85 for ; Mon, 20 Jun 2016 15:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 zQKMskVPAWAz for ; Mon, 20 Jun 2016 15:01:37 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 60FD512DA7B for ; Mon, 20 Jun 2016 15:01:37 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id i123so54218907pfg.0 for ; Mon, 20 Jun 2016 15:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RlpEE0TyLDwcwINgNOjdTiaGC2Lmm8G5i5HAzQEde4U=; b=G9DLA7H2cccx3AZIcL53FZKptSxnRUMxrSGTOH7eES2+VOVUzUgpOwNjtbpYRppLVk zfjrWePJgJgzi/wgathZeHqg60DMkoaTeBiBGuP1WhT95Vy2wJQcRtjs4swe/CzGhmRI P1u79hYKoXN1CfYtq1Y7gp2EqszAZO6wB71CY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RlpEE0TyLDwcwINgNOjdTiaGC2Lmm8G5i5HAzQEde4U=; b=UJq1OtRypKWWDKaVBqNqPZF6bSsPo+ISjhN4xx3DEGfTojn/0ike/MvFadvyHrzXpF g2yHJNnwaZLoWeMnRi7Baav9tglwCeOeBJr1vMVgSQyT0AZln6syVUQ27tOySzqd+o4D XA2MFJ4+fGTZ0Xh7NbTSlnYwaZF+nKOVQDtU6NxjUSZ6goM8stqVG8EkwpxgxKTPg8kj Ou0Y9bhyeaD758U3nsHD2bCrDqyzxjOsj/+pjF6ucFSvtgDCyNW4Vpnh2ySe5kSSYtq3 wVtfLQfj0TSvBQftgP3lZ1FcOeaIgtUxwXWI5di4JYp05CFpem7Fv4oNKQI0PW23Kbm+ EGHA== X-Gm-Message-State: ALyK8tJXk+NCANynYmPkVYLRTlejPMEflckJx2i6RXdo8T9sa52qGuh8DP49Fz7vpedHkuK0 X-Received: by 10.98.52.65 with SMTP id b62mr24293595pfa.40.1466460096226; Mon, 20 Jun 2016 15:01:36 -0700 (PDT) Received: from [100.127.71.37] ([69.53.245.200]) by smtp.gmail.com with ESMTPSA id a87sm32109385pfc.63.2016.06.20.15.01.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jun 2016 15:01:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randall Stewart In-Reply-To: <347EAB6E-9A7B-4548-95EA-4755F394DB5B@lurchi.franken.de> Date: Mon, 20 Jun 2016 15:01:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> <451E945B-3DCC-4A30-8AE6-F128D48FD87C@trammell.ch> <23946A08-826F-4A44-99C5-5F490A3FCC29@netflix.com> <347EAB6E-9A7B-4548-95EA-4755F394DB5B@lurchi.franken.de> To: =?utf-8?Q?Michael_T=C3=BCxen?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Jana Iyengar Subject: Re: [QUIC] Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 22:01:39 -0000 sure that would be fine :-) One other thing that should be added.. and I say this with my little bit = of Quic impl=C3=A9mentation experience=E2=80=A6. (not much)..=20 * ) Older Quic implementations MUST be able to interoperate with newer = ones.. That may be a bit unclear so let me explain. A while ago (last Sept?) we had someone hack up nginx and force fit = Googles Chrome/Quic into place. This got shelved before the person finished and left for a sabbatical. Now I was asked in Dec to work on this to see if I could get it to = =E2=80=9Cwork=E2=80=9D. I found a few bugs in the way it was done fixed those and was still having problems. Jana was nice enough to offer to help me out (thanks!) but when we = connected my older implementation with his, they would *not* talk.. they would just give an error msg = =E2=80=9Cthat guys too old for me to talk to=E2=80=9D. Now when building a transport prototyping system (which is what googles = Quic is) thats probably ok, since you can fall back to TCP. But for the *new* IETF-Quic that to me is = unacceptable. Just like an older version of TCP can talk to a newer version that supports SACK and new features, = or SCTP implementations can talk to each other with diverse feature sets, any IETF-Quic will need to = talk to older version number (if we even keep the version number.. after all everything will be on the table = for change here.. and we may want to go with just a capabilities negotiation instead).. but I = digress.. my point is we should have a requirement that makes in mandatory that older and newer implementations of the = protocol should be inter-operable.. That may be =E2=80=9Cobvious=E2=80=9D to some, but after my experience I = would like to have that noted down :-) R > On Jun 17, 2016, at 7:49 AM, Michael Tuexen = wrote: >=20 >>=20 >> On 17 Jun 2016, at 16:03, Randall Stewart wrote: >>=20 >>=20 >>> On Jun 17, 2016, at 7:00 AM, Brian Trammell = wrote: >>>=20 >>>>=20 >>>> On 17 Jun 2016, at 15:38, Randall Stewart wrote: >>>>=20 >>>> All: >>>>=20 >>>> So I think the final list of features that have so far been = mentioned as requirements are: >>>>=20 >>>> 1. Legacy NAT traversal (doable via UDP encapsulation) >>>> 2. Pacing >>>> 3. FEC >>>> 4. Path MTU limit >>>> 5. Fast connection setup >>>> 6. Improved loss recovery >>>> 7. CC agility >>>> 8. Encryption of transport layer information >>>> 9. Multi-Streaming >>>> 10. Implementable in User Space >>>> 11. 0-RTT connection setup^^ >>>>=20 >>>> Now from the perspective of my employer and our current network, I = would like to see >>>> a couple of other things added: >>>>=20 >>>> 12. It *must* be implementable in the kernel (i.e. no floating = point, or at least integer equivalents to >>>> any floating point operations defined). >>>> 13. The ability to do LRO/TSO in some fashion, this does *not* = exclude the possibility of >>>> enhanced hardware (i.e. we are not limited to the current set of = hardware).. but we should >>>> have some provision to gain TSO especially. I realize this is in = opposition (somewhat) to >>>> the encrypt every part but a bare minimum seen by middle boxes.. = but I think its needed :-) >>>=20 >>> One clarifying question: >>>=20 >>> Is the requirement here really "segmentation offload," or is the = requirement "minimize context switching=E2=80=9D? >>=20 >> Its not minimizing context switching :-) >>=20 >> We really need Segmentation offload.. when that is turned off the CPU = performance goes into the >> dumper=E2=80=A6=20 >>=20 >> Without TSO/LRO (and especially TSO) our performance is cut by at = least 50% > Would it be a way to say >=20 > 13. Ability for offload protocol processing to hardware, for example = by future > NICs. >=20 > This would allow things like LRO/TSO (which means some sort of packet = batching), > checksumming, hashing, encryption, decryption offload, or whatever = makes sense > for the particular protocol. >=20 > Best regards > Michael >>=20 >> R >>=20 >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>>>=20 >>>>=20 >>>> ^^ In cases where two endpoints have never talked to each other 0 = RTT would not be required. >>>> -------- >>>> Randall Stewart >>>> rrs@netflix.com >>>> 803-317-4952 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> QUIC mailing list >>>> QUIC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/quic >>=20 >> -------- >> Randall Stewart >> rrs@netflix.com >> 803-317-4952 -------- Randall Stewart rrs@netflix.com 803-317-4952 From nobody Mon Jun 20 18:35:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF56A12DAFB for ; Mon, 20 Jun 2016 18:35:43 -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 ozeFFSVN2cc9 for ; Mon, 20 Jun 2016 18:35:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7744112DAFF for ; Mon, 20 Jun 2016 18:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11696; q=dns/txt; s=iport; t=1466472941; x=1467682541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=09UZtfhRheEvcZGME2kuH6vVQrdIT44x4QnqCnS+P6c=; b=PncnIo2ZUj5IiAwRvUQb52TVpt79c70DhHzB64AZ0f6Jio1k8XrKrehv R5n6Y7Bioqc0Kt6AdxWcMzjl29Xbz+Mvz5wKib7eiranSROJD/cZoBPDk p7PtFSGz5MQ/cgLEaKTBMP9D8E5ufrbBZDE0Ziwg5zwbC/oQ0rR00A+sg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJBQBhmWhX/4QNJK1SCQGDPlZ9Brhih?= =?us-ascii?q?AkmhXECHIEZOxEBAQEBAQEBZSeETAEBAwEjEUUFCwIBCA4MAhUCDwICAjAVEAI?= =?us-ascii?q?EDgUfiAkIDrBgkFYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSaBdwiBS4EDh?= =?us-ascii?q?BgEJF0BgiMrgi8FiBeQXwGGBYgkgWmEUohnhlCJJgE0IIIIHIFMbgGJAwIkBxh?= =?us-ascii?q?/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,501,1459814400"; d="scan'208";a="288001667" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2016 01:35:40 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5L1ZeZq011406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2016 01:35:40 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 21:35:39 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 21:35:39 -0400 From: "Joe Hildebrand (jhildebr)" To: Jana Iyengar Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmdrA4n/SZAVekigMWYxC+73GZ/pJkIAgABsYID//6NcgIAAa8MA//+g6wCAAROkgIAA+uwAgABFU4CAAGq4gIACxmgAgARl7wA= Date: Tue, 21 Jun 2016 01:35:39 +0000 Message-ID: <1F70255A-6622-415E-9B73-9E02CEBF8E06@cisco.com> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.248.57] Content-Type: text/plain; charset="utf-8" Content-ID: <86C41A27F143AF47B982E43684782500@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 01:35:44 -0000 T24gNi8xNy8xNiwgMTA6MjUgUE0sICJKYW5hIEl5ZW5nYXIiIDxqcmlAZ29vZ2xlLmNvbT4gd3Jv dGU6DQoNCj5Kb2UsDQo+DQo+SSdkIGxpa2UgdG8gZmlyc3Qgc2F5IHRoYXQgSSdtIGdsYWQgd2Un cmUgaGF2aW5nIHRoaXMgY29udmVyc2F0aW9uIG5vdywgc2luY2UgSSBleHBlY3RlZCB0aGlzIGNv bnZlcnNhdGlvbiB0byBoYXBwZW4gc29vbmVyIG9yIGxhdGVyLiBXZSBjbGVhcmx5IGhhdmUgZGlm ZmVyZW5jZXMsIGJ1dCBJIHVuZGVyc3RhbmQgd2hlcmUgeW91J3JlIGNvbWluZyBmcm9tIGFuZCBJ IHdhbnQgdG8gdGhhbmsgeW91IGZvcg0KPiBlbmdhZ2luZyByZWFzb25hYmx5IChub3QgdGhhdCBJ IHdvdWxkIGhhdmUgZXhwZWN0ZWQgYW55dGhpbmcgbGVzc2VyIGZyb20geW91LikgDQoNCk9mIGNv dXJzZSBsZXQgbWUga25vdyBpZiB5b3UgdGhpbmsgSeKAmW0gYmVpbmcgdW5yZWFzb25hYmxlIGF0 IGFueSBwb2ludDsgdGhhdOKAmXMgdXN1YWxseSB3aGVyZSBJIGxlYXJuIHRoaW5ncy4NCg0KPkkg dGhpbmsgdGhlIHdvcmRpbmcgd2FzIHVuY2xlYXIsIGFuZCBJIHRoaW5rIEknbSBwcm9iYWJseSBm aW5lIHdpdGggQnJpYW4ncyBwcm9wb3NlZCB0ZXh0IChJJ2xsIHJlc3BvbmQgdG8gdGhlIHByb3Bv c2VkIHRleHQgc2VwYXJhdGVseS4pIFRoYXQgc2FpZCwgdGhlIGNoYXJ0ZXIgdGV4dCBpcyBvbmx5 IGEgcGxhY2Vob2xkZXIgZm9yIGEgY29udmVyc2F0aW9uIHdlIHdhbnQgdG8gaGF2ZSBpbiB0aGUg d2cuIE15IGRpc2FncmVlbWVudCBpcyB3aXRoIHRoZSBjb252ZXJzYXRpb24gdGhhdCB5b3UncmUg cHJvcG9zaW5nLg0KDQpJ4oCZbSBhbHNvIG9rIHdpdGggQnJpYW7igJlzIHRleHQsIGFuZCB3b3Vs ZCBsaWtlbHkgYmUgb2sgd2l0aCBvdGhlciBjaGFuZ2VzIHRvIGhpcyBzdWdnZXN0ZWQgYXBwcm9h Y2guDQoNCj4+IFdlJ3JlIG5vdCB0YWxraW5nIGFib3V0IGJvb2dleW1hbiBtaWRkbGVib3hlcyBo ZXJlLiAgVGhlcmUgaXMgbm8gbWVhc3VyZW1lbnQgbmVlZGVkLCBhbmQgbm8gdGVzdGluZy4NCj4N Cj5UaGF0J3Mgbm90IGEgY29udmluY2luZyBhcmd1bWVudCAtLSB3aXRoIG5vIG1lYXN1cmVtZW50 IG9yIGRhdGEsIHRoZXJlJ3Mgb25seSBib29nZXltZW4gbWlkZGxlYm94ZXMuLi4NCg0KSeKAmW0g bG9va2luZyBpbnRvIGdldHRpbmcgYSBwcmUtYWxwaGEgYnVpbGQgb2YgYSBmaXJld2FsbCBpbXBs ZW1lbnRpbmcgUVVJQyBjb2RlIGF2YWlsYWJsZSBmb3IgYXQgbGVhc3Qgc29tZSBpZGVudGlmaWVk IHBlb3BsZSB0byB0ZXN0IGFnYWluc3QuICBJZGVhbGx5LCB3ZSB3b3VsZCBjb250aW51ZSB0byB1 cGRhdGUgdGhhdCBjb2RlIGFzIGEgcG90ZW50aWFsIHdvcmtpbmcgZ3JvdXAgcHJvZ3Jlc3NlZC4N Cg0KPj5XZSdyZSB0YWxraW5nIGFib3V0IGZpcmV3YWxscyB0aGF0IGN1cnJlbnRseSBibG9jayBV RFAsIHN1Y2ggYXMgdGhlIG9uZSBJJ20gZ29pbmcgdGhyb3VnaCByaWdodCBub3cuICBJIHdvdWxk IGxpa2UgdG8gYWRkIGV4cGxpY2l0IFFVSUMgc3VwcG9ydCB0byB0aGF0IGJveCBzbyB0aGF0DQo+ DQo+Li4uIGFuZCB0aGF0J3MgeW91ciBib29nZXltYW4uIA0KDQpUaGF04oCZcyBqdXN0IGEgbGl0 dGxlIGhhcnNoLiAgSWYgeW91IHdhbnQgdG8gZ2l2ZSBtZSBzb21lIGluc3RydW1lbnRhdGlvbiB0 byBydW4gYWdhaW5zdCB0aGlzIGZpcmV3YWxsIGFuZCB0aG9zZSBvZiBvdGhlciBwZW9wbGUgcnVu bmluZyBzaW1pbGFyIGNvbmZpZ3VyYXRpb25zLCBJ4oCZZCBiZSBoYXBweSB0byBoZWxwIHlvdSBn YXRoZXIgZGF0YSBhYm91dCB3aGF0IHRoYXQgbG9va3MgbGlrZSB0byB0aGUgYXBwbGljYXRpb24u ICBJZiB0aGVyZSBpcyBhIHBhcnRpY3VsYXIgc2V0IG9mIGRhdGEgdGhhdCB5b3Ugd291bGQgYmVs aWV2ZSB0aGF0IHdvdWxkIGFsbG93IHlvdSB0byBjYXJlIGFib3V0IHRoaXMgdXNlciBiYXNlLCBs ZXTigJlzIGRpc2N1c3Mgd2hhdCB0aGF0IHdvdWxkIGxvb2sgbGlrZS4NCg0KPiBGb3J0dW5hdGVs eSwgdGhlcmUncyBkYXRhIG9uIHRoaXMgLS0gd2Ugc2hhcmVkIHRoaXMgaW4gdGhlIEJhckJvRiBs YXN0IHllYXIuIFRoYXQncyBhYm91dCA3JSBvZiB1c2Vycy4gUVVJQyB3b3JrcyB3ZWxsIGZvciA5 MiUgb2YgdGhlIHVzZXJzIHRyeWluZyB0byB1c2UgaXQgKHRoaXMgaXMgYXQgbWFzc2l2ZSBzY2Fs ZXMgb2YgdXNhZ2UpLCBhcyBzaG93biBvbiB0aGlzDQo+IHNsaWRlIDxodHRwczovL2RvY3MuZ29v Z2xlLmNvbS9wcmVzZW50YXRpb24vZC8xNWUxYkxLWWVONTZHTDFvVEpTRjlPWmlVc0ktcmN4aXNM bzlkRXlEa1dRcy9lZGl0I3NsaWRlPWlkLmdjMzQwMjViOWFfMF8wPi4gVGhpcyBkYXRhIGhhcyBi ZWVuIGluZGVwZW5kZW50bHkgdmFsaWRhdGVkIGJ5IG5vbi1Hb29nbGUgV2ViUlRDIGRlcGxveW1l bnRzLiBTbywgdGhpcyBxdWVzdGlvbiBjYW4gYXQgbGVhc3QgYmUgc2NvcGVkIHRvIDclIG9mIHVz ZXJzLiBJJ2xsIGFsc28gcG9pbnQgb3V0IHRoYXQganVzdCBiZWluZyBhYm91dCB0byBpZGVudGlm eSBRVUlDIGlzIG5vdCBnb2luZyB0byBiZSBlbm91Z2ggZm9yIHRoZSBlbnRpcmUgNyUsIHNvIGl0 J3MNCj4gcmVhbGx5IDwgNyUuDQoNCkkgYmVsaWV2ZSB0aGF0IG15IG5ldHdvcmssIGFuZCB0aG9z ZSBvZiBwZW9wbGUgd2hvIGJlbGlldmUgaW4gdXNpbmcgcGF0aCBlbGVtZW50cyBzdWNoIGFzIGZp cmV3YWxscyB0byBwcm90ZWN0IHRoZWlyIG5ldHdvcmssIG1heSBiZSB1bmRlci1yZXByZXNlbnRl ZCBieSB5b3VyIG1ldHJpYyDigJMgb3IgbWF5IGJlIGEgbGFyZ2UgcG9ydGlvbiBvZiB0aGUgNyUu ICBXZSB3b3VsZCBoYXZlIHRvIGRpZyBpbnRvIHlvdXIgZXhwZXJpbWVudCBkZXNpZ24gZm9yIG1l IHRvIGhhdmUgYSBtb3JlIGluZm9ybWVkIG9waW5pb24uDQoNCkkgYWxzbyB0aGluayB0aGUgYmVu ZWZpdHMgb2YgUVVJQyBzaG91bGQgYmUgYXZhaWxhYmxlIGZvciB1c2UgY2FzZXMgdGhhdCBhcmVu 4oCZdCBhIGNsb3NlIG1hdGNoIGZvciB3aGF0IEkgdGhpbmsgeW914oCZdmUgbWVhc3VyZWQgc28g ZmFyLg0KDQo+SSBkb24ndCBhZ3JlZSB3aXRoIHRoaXMgbGluZSBvZiByZWFzb25pbmcuIFRoZSBR VUlDIHdnIHNob3VsZCBzcGVjaWZ5IHdoYXQgdGhlIGVuZHBvaW50cyBkbyBvbiByZWNlaXZpbmcg SUNNUCBtZXNzYWdlcyBmcm9tIHRoZSBuZXR3b3JrLiBCdXQgeW91IGFyZSBhbHNvIGFza2luZyBm b3IgdGhlIFFVSUMgd2cgdG8gc3BlY2lmeSBub3JtYXRpdmUgYmVoYXZpb3Igb2YgZmlyZXdhbGxz LCB3aGVuIHRoZXJlIGlzIG5vIGVxdWl2YWxlbnQgY29uc2Vuc3VzDQo+IG9uIHdoYXQgdGhleSBv dWdodCB0byBkbyBmb3IgVENQLiAgDQoNCkFzIEJyaWFuIHNhaWQgaW4gaGlzIG1lc3NhZ2UsIHdl IG1pZ2h0IGJlIGFibGUgdG8gYWdyZWUgb24gYSBjb3VwbGUgb2YgdGhpbmdzLCBwYXJ0aWN1bGFy bHkgaGF2aW5nIHRvIGRvIHdpdGggZGlyZWN0aW9uIG9mIGNvbm5lY3Rpb24sIGNvcnJlbGF0aW9u IG9mIHN1YnNlcXVlbnQgcGFja2V0cyBpbiB0aGUgZmxvdywgYW5kIHRlcm1pbmF0aW9uLiAgQnV0 IEkgZG9u4oCZdCB0aGluayB3ZSBuZWVkIHRvIGRlY2lkZSB0aGF0IGxpc3QgcmlnaHQgbm93Lg0K DQpCdXQsIGZvciBleGFtcGxlLCBpdCBtaWdodCBiZSBuaWNlIGZvciBRVUlDIGNvbm5lY3Rpb25z IHRvIGJlIGFibGUgdG8gYXV0by1yZXBhaXIgc3RhdGUgb24gYSBmaXJld2FsbCB3aGVuZXZlciB0 aGUgY2xpZW50IHNlbmRzIHRyYWZmaWMgKHdoaWNoIGlzbuKAmXQgcG9zc2libGUgZm9yIFRDUCBm aXJld2FsbHMgdGhhdCBsb29rIGZvciBhIFNZTiBhdCB0aGUgc3RhcnQgb2YgY29ubmVjdGlvbiku ICBJdCBtYXkgZXZlbiBiZSBwb3NzaWJsZSB3aXRoIHdoYXTigJlzIGluIHRoZSBjdXJyZW50IHBy b3RvY29sLiAgSXQgbWlnaHQgZXZlbiBiZSBvYnZpb3VzIGhvdyBzdWNoIGEgZmlyZXdhbGwgc2hv dWxkIGJlIGltcGxlbWVudGVkIHRvIHRoZSBzbWFsbCBncm91cCBvZiBwZW9wbGUgdGhhdCBjdXJy ZW50bHkgaGFzIFFVSUMgZGV2ZWxvcG1lbnQgZXhwZXJpZW5jZS4gIEkgdGhpbmsgeW91IHNob3Vs ZCBiZSBhbGxvd2VkIHRvIHNoYXJlIHRoYXQgZXhwZXJpZW5jZSB3aXRoIHVzIGlmIHlvdeKAmXJl IHdpbGxpbmcgdG8uDQoNCj5XZSdyZSB0YWxraW5nIGFib3V0IHNvbHZpbmcgZm9yIGEgbGlzdCBv ZiBwcm9ibGVtcyB0aGF0IGhhcyBubyBjb25zZW5zdXMuIA0KDQpXZSBkb27igJl0IGhhdmUgY29u c2Vuc3VzIHRvIGZvcm0gYSB3b3JraW5nIGdyb3VwIHlldCwgZWl0aGVyLiAgV2UgY291bGQgd2hp dHRsZSBkb3duIHRoZSBsaXN0IHRvIHNvbWV0aGluZyBtdWNoIG1vcmUgY29uY3JldGUgaWYgdGhh dCB3b3VsZCBoZWxwIGdldCBjb25zZW5zdXMgb24gZm9ybWluZyBhIHdvcmtpbmcgZ3JvdXAuDQoN Cj5Nb3JlIGltcG9ydGFudGx5LCBteSBvcGluaW9uIGlzIHRoYXQgdGhpcyB3ZyBtYXkgbm90IGhh dmUgdGhlIHJpZ2h0IHNldCBvZiBmb2xrcyB3aXRoIHdob20geW91IHdhbnQgdG8gZHJpdmUgY29u c2Vuc3VzIG9uIHRoaXMgbGlzdCBvZiBmaXJld2FsbCBiZWhhdmlvcnMuDQoNCknigJltIHdvcmtp bmcgdG8gZ2V0IHRob3NlIHBlb3BsZSBpbnZvbHZlZC4gIFdlIGhhdmVu4oCZdCBkZXNpZ25lZCBh IG5ldyB0cmFuc3BvcnQgdGhhdCBhbnkgb2YgdGhlbSBoYXZlIGNhcmVkIGFib3V0IHJlY2VudGx5 LCBzbyBpdCBtYXkgdGFrZSBhIHdoaWxlIHRvIGdldCB0aGVtIGludGVyZXN0ZWQuICBNYW55IG9m IHRoZW0gd29u4oCZdCB3YW50IHRvIGJlIHRvbGQgdGhhdCB0aGVpciBleHBlcmllbmNlIGlzbuKA mXQgcmVsZXZhbnQgdW5sZXNzIHRoZXkgY2FuIHJ1biBhbiBleHBlcmltZW50IGF0IHRoZSBzYW1l IHNpemUgYXMgYSBicm93c2VyIG1hbnVmYWN0dXJlci4NCg0KPiAiUGVvcGxlIHdpdGggbW9yZSBR VUlDIGludHVpdGlvbiIgY2VydGFpbmx5IHdpbGwgaGF2ZSBzb21lIGlkZWEgb2Ygd2hhdCBiZWhh dmlvcnMgdG8gYnVpbGQgZm9yIChhbmQgSSBleHBlY3QgdGhhdCB0byBoYXBwZW4pLCBidXQgdGhl c2UgcGVvcGxlIHdpbGwgaGF2ZSBxdWl0ZSBsaW1pdGVkIGlkZWEgd2hhdCBmaXJld2FsbHMgbmVl ZCB0byBkbyBvbiBwYXRoLCBhbmQgd2hhdCBpbmZvcm1hdGlvbiBmaXJld2FsbHMgbmVlZC4gSU1P LCB5b3UgbmVlZA0KPiBuZXR3b3JrIG9wZXJhdGlvbnMgZm9sa3MgdG8gYmUgaGF2aW5nIHRoYXQg Y29udmVyc2F0aW9uLCBhbmQgUVVJQyBpcyBpbmNvbnZlbmllbnRseSBub3QgYmVpbmcgcHJvcG9z ZWQgaW4gT1BTQVJFQSAoSSdtIG5vdCBzdXJlIHdoaWNoIHdnIHdvdWxkIGJlIGFwcHJvcHJpYXRl LCB3aGljaCBpcyB3aHkgSSBwcm9wb3NlZCBJTlRBUkVBLiBQZXJoYXBzIE9QU0FSRUEgaXMgYSBi ZXR0ZXIgZml0LikNCg0KV2hlbiB0aG9zZSBwZW9wbGUgc2hvdyB1cCBhdCBhIHBvdGVudGlhbCBR VUlDIHdvcmtpbmcgZ3JvdXAsIHdpbGwgdGhleSBiZSB0b2xkIHRoYXQgdGhlaXIgdXNlIGNhc2Vz IGFyZW7igJl0IGludGVyZXN0aW5nLCBhbmQgdGhhdCB0aGVpciBjb25jZXJucyBhcmUgb3V0IG9m IHNjb3BlIGFueXdheT8NCg0KSWYgd2hhdCB5b3XigJlyZSBzYXlpbmcgaXMgdGhhdCB3ZSBjYW4g Y2hhcnRlciB3b3JrIHNvbWV3aGVyZSBlbHNlIGluIHRoZSBJRVRGIHRvIGRlYWwgd2l0aCBzb21l IG9mIHRoZXNlIHF1ZXN0aW9ucywgSeKAmW0gb3BlbiB0byB0aGF0LiAgSeKAmWQgbGlrZSB1cyB0 byBrbm93IHdoYXQgd29yayBuZWVkcyB0byBiZSBjaGFydGVyZWQgaW4gd2hhdCBhcmVhLCBhbmQg aGF2ZSBjaGFydGVyIGxhbmd1YWdlIGZvciBRVUlDIHRoYXQgc2F5cyBob3cgYSBwb3RlbnRpYWwg UVVJQyB3b3JraW5nIGdyb3VwIHdvdWxkIGludGVyZmFjZSB3aXRoIHRoYXQgb3RoZXIgd29yay4N Cg0KPj5JIGFncmVlIHRoYXQgYW55IG1vcmUgaW50ZXJlc3RpbmcgcGF0aCBpbnRlcmFjdGlvbnMs IHRvIHRoZSBleHRlbnQgdGhhdCB0aGV5IG1pZ2h0IGJlIGludGVyZXN0aW5nLCBhcmUgbW9yZSBp biB0aGUgcmVhbG0gb2YgUExVUy4NCj4NCj5XaHkgYXJlIHRoZXNlIGxlc3MgaW50ZXJlc3Rpbmcg cGF0aCBpbnRlcmFjdGlvbnM/IEV4cG9zaW5nIGJpdHMgdG8gYWxsb3cgZmlyZXdhbGxzIHRvIGRv ICJ3aGF0IHRoZXkgZG8iIGlzIG5vdCBnb2luZyB0byBiZSB0cml2aWFsLCBzaW5jZSAid2hhdCB0 aGV5IGRvIiBpcyBub3QgYWdyZWVkIHVwb24gZWxzZXdoZXJlLiANCg0KU29ycnksIOKAnG1vcmUg aW50ZXJlc3RpbmfigJ0gd2FzIGFuIHVuZm9ydHVuYXRlIGNob2ljZSBvZiB3b3Jkcy4gIFdoYXQg SSBtZWFuIGJ5IHRoYXQgd2FzIHRoZSBleHBsaWNpdCBwYXRoLXRvLWFwcGxpY2F0aW9uIGFuZCBh cHBsaWNhdGlvbi10by1wYXRoIHNpZ25hbGluZyB0aGF0IHdlIGV4cGxvcmVkIGluIHRoZSBTUFVE IHByb3RvdHlwZS4gIFVubGVzcyBzb21lb25lIGVsc2UgYXJndWVzIHdlIG91Z2h0IHRvIGFkZCB0 aGF0IHRvIFFVSUMsIGl0IHNlZW1zIGNsZWFybHkgb3V0IG9mIHNjb3BlIHVudGlsIGl0IGhhcyBi ZWVuIGV4cGxvcmVkIG11Y2ggbW9yZSBmdWxseSBieSBhIHBvdGVudGlhbCBQTFVTIHdvcmtpbmcg Z3JvdXAgb3IgZWxzZXdoZXJlLg0KDQpUaGUg4oCcbGVzcyBpbnRlcmVzdGluZ+KAnSBiaXRzICh0 byBtZSwgY29tcGFyYXRpdmVseSkgYXJlIHRoZSBvbmVzIHdl4oCZdmUgYmVlbiB0YWxraW5nIGFi b3V0IGluIHRoaXMgdGhyZWFkLiAgV2hpbGUgSSBkb27igJl0IGV4cGVjdCB0aGlzIHdvcmsgdG8g YmUgdHJpdmlhbCwgSSBkb27igJl0IGV4cGVjdCBpdCB0byByZXF1aXJlIGFueSBmdW5kYW1lbnRh bCByZXNlYXJjaC4gDQoNCj4gSSB3b3VsZCBsb3ZlIHRvIGJlbGlldmUgeW91LCBidXQgeW91IG11 c3QgdW5kZXJzdGFuZCB0aGF0IHlvdXIgd29yZCAob3INCj4geW91cnMgYW5kIERhbidzKSBqdXN0 IGlzbid0IGVub3VnaCBoZXJlLg0KDQpJIGRvbuKAmXQga25vdyBob3cgdG8gcmVzcG9uZCB0byB0 aGlzLiBQbGVhc2UgdW5kZXJzdGFuZCB0aGF0IERhbiBhbmQgSSBoYXZlIHJldmlld2VkIHdvcmtp bmcgUVVJQyBmaXJld2FsbCBjb2RlIGFuZCB0YWxrZWQgdG8gYSBsb3Qgb2YgcGVvcGxlIHdobyBk byBib3RoIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCB3b3JrIGZvciBDaXNjb+KA mXMgZmlyZXdhbGwgcHJvZHVjdHMuICBWZXJ5IGZldyBvZiB0aG9zZSBwZW9wbGUgYXJlIHdpbGxp bmcgdG8gcGFydGljaXBhdGUgYXQgdGhlIElFVEY7IGV2ZW4gaWYgdGhleSB3ZXJlLCBJ4oCZbSBu b3Qgc3VyZSBob3cgd2UgY291bGQgcHJvdmUgdG8gZXZlcnlvbmUgdGhhdCB0aGV5IHNob3VsZCBi ZSBsaXN0ZW5lZCB0by4NCg0KPkZhaXIgZW5vdWdoOyB0aG91Z2ggSSdsbCBjb250aW51ZSB0byBh c2sgZm9yIGRhdGEgd2hlbiB0aGUgY29udmVyc2F0aW9uIGNvbWVzIHVwLg0KDQpJZiB0aGF04oCZ cyBnb2luZyB0byBiZSB0aGUgYmFyIHRoYXQgd2UgaGF2ZSB0byBjbGVhciBmb3IgZXZlcnkgc2lu Z2xlIGNvbnZlcnNhdGlvbiB3ZSBoYXZlLCBJIHdvdWxkIGxpa2UgdXMgdG8gcHJlLW5lZ290aWF0 ZSB3aGF0IHNvcnQgb2YgZGF0YSB5b3Ugd2lsbCBhY2NlcHQsIGFuZCBob3cgeW91IGNhbiBjb21l IHRvIHRydXN0IHRoYXQgaXQgd2FzIGdhdGhlcmVkIGluIGEgcmVhc29uYWJsZSB3YXkuDQoNCj5J IGRlZmluaXRlbHkgYWdyZWUgd2l0aCB0aGUgc3Bpcml0LCBidXQgSSB3b3JyeSBhYm91dCB0aGlz IG5vdCBiZWluZyBzY29wZWQgdGlnaHRseSBlbm91Z2ggdG8gcHJldmVudCByYXRob2xlcyBvZiB2 YXJpb3VzIHNoYXBlcyBhbmQgc2l6ZXMuDQoNCkdyZWF0LiAgTGV04oCZcyB0YWxrIGFib3V0IGhv dyB0byBzY29wZSBpdCB0aWdodGx5IGVub3VnaC4NCg0KPlVuZGVyc3Rvb2QsIGFuZCBhcyBtdWNo IGFzIEkgd291bGQgbG92ZSB0byBzZWUgdGhlIHVuaXZlcnNhbCBkZXBsb3ltZW50IG9mIFFVSUMs IGxldCdzIGJlIGNsZWFyIHRoYXQgaXQncyBub3QgYSBwcm9ibGVtIGZvciA5MiUgb2YgdXNlcnMg YXQgdGhlIG1vbWVudC4NCg0KSSBhZ3JlZSB3ZeKAmXJlIHVubGlrZWx5IHRvIGdldCB0byAxMDAl LiAgSG93ZXZlciwgSSB3b3VsZCBsaWtlIHRoZSB1c2VycyB3aG8gYXJlIGRpc2FkdmFudGFnZWQg dG8gaGF2ZSB0aGUgb3B0aW9uIG9mIG9uZSBkYXkgZ2V0dGluZyBRVUlDIHN1cHBvcnQuICBPbmUg b2YgdGhlIHF1ZXN0aW9ucyB0aGF0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGV4cGxvcmUsIGZv ciBleGFtcGxlLCB3b3VsZCBiZSB0byBmaW5kIG91dCBpZiB0aGlzIDclIGlzIGFsc28gdGhlIHNl dCBvZiBmb2xrcyB0aGF0IHVwZ3JhZGUgdGhlaXIgZmlyZXdhbGxzIGZyZXF1ZW50bHkuDQoNCkp1 c3Qgd3JpdGluZyBvZmYgbW9yZSB0aGFuIDIwMCBtaWxsaW9uIHVzZXJzIGJlY2F1c2Ugd2Ugd2Vy ZW7igJl0IHdpbGxpbmcgdG8gdGFrZSB0aGUgdGltZSBvciBlZmZvcnQgdG8gZGVzY3JpYmUgaG93 IHRoZXkgY291bGQgb25lIGRheSB1c2UgUVVJQyBkb2VzbuKAmXQgc2VlbSBsaWtlIHdlIGFyZSBk b2luZyBhZGVxdWF0ZSBlbmdpbmVlcmluZy4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQo= From nobody Mon Jun 20 19:15:12 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AA812D881 for ; Mon, 20 Jun 2016 19:15:10 -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 lE8d0tGmICST for ; Mon, 20 Jun 2016 19:15:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265A012D1AF for ; Mon, 20 Jun 2016 19:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13490; q=dns/txt; s=iport; t=1466475307; x=1467684907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wpZ93I3793xOdxX11Fu5l2l7bMASM3SlgJWfkdaQqq8=; b=hl9u8+AkkMNXMQLe3efJU9UF2r1mGJX6DG/HlFoDytz4edPqFBzpXLmi 8LW5ggkcsiBHfLgsjXeZ8Z6xe77Ecdr4gbYxyfXykO9jKfOb5eQRSYmWI OsL3Lef0p+DVdWaZ6oB7f7W6X+9RmruwjoFpzLTS7FlJTrjBE1t0V6frM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgA8omhX/5ldJa1SCQGDPlZ9Brpxg?= =?us-ascii?q?XoXDYVzAhyBGjgUAQEBAQEBAWUnhEsBAQEEAQEBIBE6CwwEAgEIEQQBAQECAhU?= =?us-ascii?q?CDAMCAgIlCxQBCAgCBAENBQgXiBEOA7BXkFkBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEXBYEBhSaDSoEDhBgEgQEBgiOCWgWIF5BhAYYFiB2BcIRSiGeGUIkmAR42ggg?= =?us-ascii?q?cgUxuAYkDAiQHGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,501,1459814400"; d="scan'208";a="120751305" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 02:15:05 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5L2F5gm007812 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2016 02:15:05 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 21:15:04 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 21:15:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Joe Hildebrand (jhildebr)" , Jana Iyengar Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmpTIanK95WvS0SZW6hNTgv+eJ/pJkIAgABsYID//6NcgIAAa8MA//+g6wCAAROkgIAA+uwAgABFU4CAAGq4gIAC1yYAgASo/oD//7MvQA== Date: Tue, 21 Jun 2016 02:15:04 +0000 Message-ID: <3724d95354514cc9abf9e97960866656@XCH-RCD-017.cisco.com> References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <1F70255A-6622-415E-9B73-9E02CEBF8E06@cisco.com> In-Reply-To: <1F70255A-6622-415E-9B73-9E02CEBF8E06@cisco.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: [10.65.62.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 02:15:10 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lIEhpbGRlYnJhbmQNCj4gKGpoaWxkZWJy KQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDIxLCAyMDE2IDc6MDYgQU0NCj4gVG86IEphbmEgSXll bmdhcg0KPiBDYzogcXVpY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1FVSUNdIE5ldHdvcmsg UGF0aCBSZXF1aXJlbWVudHMgZm9yIFFVSUMNCj4gDQo+IE9uIDYvMTcvMTYsIDEwOjI1IFBNLCAi SmFuYSBJeWVuZ2FyIiA8anJpQGdvb2dsZS5jb20+IHdyb3RlOg0KPiANCj4gPkpvZSwNCj4gPg0K PiA+SSdkIGxpa2UgdG8gZmlyc3Qgc2F5IHRoYXQgSSdtIGdsYWQgd2UncmUgaGF2aW5nIHRoaXMg Y29udmVyc2F0aW9uIG5vdywNCj4gPnNpbmNlIEkgZXhwZWN0ZWQgdGhpcyBjb252ZXJzYXRpb24g dG8gaGFwcGVuIHNvb25lciBvciBsYXRlci4gV2UNCj4gPmNsZWFybHkgaGF2ZSBkaWZmZXJlbmNl cywgYnV0IEkgdW5kZXJzdGFuZCB3aGVyZSB5b3UncmUgY29taW5nIGZyb20gYW5kDQo+ID5JIHdh bnQgdG8gdGhhbmsgeW91IGZvciAgZW5nYWdpbmcgcmVhc29uYWJseSAobm90IHRoYXQgSSB3b3Vs ZCBoYXZlDQo+ID5leHBlY3RlZCBhbnl0aGluZyBsZXNzZXIgZnJvbSB5b3UuKQ0KPiANCj4gT2Yg Y291cnNlIGxldCBtZSBrbm93IGlmIHlvdSB0aGluayBJ4oCZbSBiZWluZyB1bnJlYXNvbmFibGUg YXQgYW55IHBvaW50Ow0KPiB0aGF04oCZcyB1c3VhbGx5IHdoZXJlIEkgbGVhcm4gdGhpbmdzLg0K PiANCj4gPkkgdGhpbmsgdGhlIHdvcmRpbmcgd2FzIHVuY2xlYXIsIGFuZCBJIHRoaW5rIEknbSBw cm9iYWJseSBmaW5lIHdpdGggQnJpYW4ncw0KPiBwcm9wb3NlZCB0ZXh0IChJJ2xsIHJlc3BvbmQg dG8gdGhlIHByb3Bvc2VkIHRleHQgc2VwYXJhdGVseS4pIFRoYXQgc2FpZCwgdGhlDQo+IGNoYXJ0 ZXIgdGV4dCBpcyBvbmx5IGEgcGxhY2Vob2xkZXIgZm9yIGEgY29udmVyc2F0aW9uIHdlIHdhbnQg dG8gaGF2ZSBpbiB0aGUNCj4gd2cuIE15IGRpc2FncmVlbWVudCBpcyB3aXRoIHRoZSBjb252ZXJz YXRpb24gdGhhdCB5b3UncmUgcHJvcG9zaW5nLg0KPiANCj4gSeKAmW0gYWxzbyBvayB3aXRoIEJy aWFu4oCZcyB0ZXh0LCBhbmQgd291bGQgbGlrZWx5IGJlIG9rIHdpdGggb3RoZXIgY2hhbmdlcyB0 byBoaXMNCj4gc3VnZ2VzdGVkIGFwcHJvYWNoLg0KPiANCj4gPj4gV2UncmUgbm90IHRhbGtpbmcg YWJvdXQgYm9vZ2V5bWFuIG1pZGRsZWJveGVzIGhlcmUuICBUaGVyZSBpcyBubw0KPiBtZWFzdXJl bWVudCBuZWVkZWQsIGFuZCBubyB0ZXN0aW5nLg0KPiA+DQo+ID5UaGF0J3Mgbm90IGEgY29udmlu Y2luZyBhcmd1bWVudCAtLSB3aXRoIG5vIG1lYXN1cmVtZW50IG9yIGRhdGEsIHRoZXJlJ3MNCj4g b25seSBib29nZXltZW4gbWlkZGxlYm94ZXMuLi4NCj4gDQo+IEnigJltIGxvb2tpbmcgaW50byBn ZXR0aW5nIGEgcHJlLWFscGhhIGJ1aWxkIG9mIGEgZmlyZXdhbGwgaW1wbGVtZW50aW5nIFFVSUMN Cj4gY29kZSBhdmFpbGFibGUgZm9yIGF0IGxlYXN0IHNvbWUgaWRlbnRpZmllZCBwZW9wbGUgdG8g dGVzdCBhZ2FpbnN0LiAgSWRlYWxseSwgd2UNCj4gd291bGQgY29udGludWUgdG8gdXBkYXRlIHRo YXQgY29kZSBhcyBhIHBvdGVudGlhbCB3b3JraW5nIGdyb3VwIHByb2dyZXNzZWQuDQo+IA0KPiA+ PldlJ3JlIHRhbGtpbmcgYWJvdXQgZmlyZXdhbGxzIHRoYXQgY3VycmVudGx5IGJsb2NrIFVEUCwg c3VjaCBhcyB0aGUNCj4gPj5vbmUgSSdtIGdvaW5nIHRocm91Z2ggcmlnaHQgbm93LiAgSSB3b3Vs ZCBsaWtlIHRvIGFkZCBleHBsaWNpdCBRVUlDDQo+ID4+c3VwcG9ydCB0byB0aGF0IGJveCBzbyB0 aGF0DQo+ID4NCj4gPi4uLiBhbmQgdGhhdCdzIHlvdXIgYm9vZ2V5bWFuLg0KPiANCj4gVGhhdOKA mXMganVzdCBhIGxpdHRsZSBoYXJzaC4gIElmIHlvdSB3YW50IHRvIGdpdmUgbWUgc29tZSBpbnN0 cnVtZW50YXRpb24gdG8gcnVuDQo+IGFnYWluc3QgdGhpcyBmaXJld2FsbCBhbmQgdGhvc2Ugb2Yg b3RoZXIgcGVvcGxlIHJ1bm5pbmcgc2ltaWxhciBjb25maWd1cmF0aW9ucywNCj4gSeKAmWQgYmUg aGFwcHkgdG8gaGVscCB5b3UgZ2F0aGVyIGRhdGEgYWJvdXQgd2hhdCB0aGF0IGxvb2tzIGxpa2Ug dG8gdGhlDQo+IGFwcGxpY2F0aW9uLiAgSWYgdGhlcmUgaXMgYSBwYXJ0aWN1bGFyIHNldCBvZiBk YXRhIHRoYXQgeW91IHdvdWxkIGJlbGlldmUgdGhhdA0KPiB3b3VsZCBhbGxvdyB5b3UgdG8gY2Fy ZSBhYm91dCB0aGlzIHVzZXIgYmFzZSwgbGV04oCZcyBkaXNjdXNzIHdoYXQgdGhhdCB3b3VsZA0K PiBsb29rIGxpa2UuDQo+IA0KPiA+IEZvcnR1bmF0ZWx5LCB0aGVyZSdzIGRhdGEgb24gdGhpcyAt LSB3ZSBzaGFyZWQgdGhpcyBpbiB0aGUgQmFyQm9GIGxhc3QNCj4gPiB5ZWFyLiBUaGF0J3MgYWJv dXQgNyUgb2YgdXNlcnMuIFFVSUMgd29ya3Mgd2VsbCBmb3IgOTIlIG9mIHRoZSB1c2Vycw0KPiA+ IHRyeWluZyB0byB1c2UgaXQgKHRoaXMgaXMgYXQgbWFzc2l2ZSBzY2FsZXMgb2YgdXNhZ2UpLCBh cyBzaG93biBvbiB0aGlzIHNsaWRlDQo+IDxodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9wcmVzZW50 YXRpb24vZC8xNWUxYkxLWWVONTZHTDFvVEpTRjlPWmlVc0ktDQo+IHJjeGlzTG85ZEV5RGtXUXMv ZWRpdCNzbGlkZT1pZC5nYzM0MDI1YjlhXzBfMD4uIFRoaXMgZGF0YSBoYXMgYmVlbg0KPiBpbmRl cGVuZGVudGx5IHZhbGlkYXRlZCBieSBub24tR29vZ2xlIFdlYlJUQyBkZXBsb3ltZW50cy4gU28s IHRoaXMNCj4gcXVlc3Rpb24gY2FuIGF0IGxlYXN0IGJlIHNjb3BlZCB0byA3JSBvZiB1c2Vycy4g SSdsbCBhbHNvIHBvaW50IG91dCB0aGF0IGp1c3QNCj4gYmVpbmcgYWJvdXQgdG8gaWRlbnRpZnkg UVVJQyBpcyBub3QgZ29pbmcgdG8gYmUgZW5vdWdoIGZvciB0aGUgZW50aXJlIDclLCBzbw0KPiBp dCdzIHJlYWxseSA8IDclLg0KPiANCj4gSSBiZWxpZXZlIHRoYXQgbXkgbmV0d29yaywgYW5kIHRo b3NlIG9mIHBlb3BsZSB3aG8gYmVsaWV2ZSBpbiB1c2luZyBwYXRoDQo+IGVsZW1lbnRzIHN1Y2gg YXMgZmlyZXdhbGxzIHRvIHByb3RlY3QgdGhlaXIgbmV0d29yaywgbWF5IGJlIHVuZGVyLQ0KPiBy ZXByZXNlbnRlZCBieSB5b3VyIG1ldHJpYyDigJMgb3IgbWF5IGJlIGEgbGFyZ2UgcG9ydGlvbiBv ZiB0aGUgNyUuICBXZSB3b3VsZA0KPiBoYXZlIHRvIGRpZyBpbnRvIHlvdXIgZXhwZXJpbWVudCBk ZXNpZ24gZm9yIG1lIHRvIGhhdmUgYSBtb3JlIGluZm9ybWVkDQo+IG9waW5pb24uDQo+IA0KPiBJ IGFsc28gdGhpbmsgdGhlIGJlbmVmaXRzIG9mIFFVSUMgc2hvdWxkIGJlIGF2YWlsYWJsZSBmb3Ig dXNlIGNhc2VzIHRoYXQgYXJlbuKAmXQNCj4gYSBjbG9zZSBtYXRjaCBmb3Igd2hhdCBJIHRoaW5r IHlvdeKAmXZlIG1lYXN1cmVkIHNvIGZhci4NCj4gDQo+ID5JIGRvbid0IGFncmVlIHdpdGggdGhp cyBsaW5lIG9mIHJlYXNvbmluZy4gVGhlIFFVSUMgd2cgc2hvdWxkIHNwZWNpZnkNCj4gPndoYXQg dGhlIGVuZHBvaW50cyBkbyBvbiByZWNlaXZpbmcgSUNNUCBtZXNzYWdlcyBmcm9tIHRoZSBuZXR3 b3JrLiBCdXQNCj4geW91IGFyZSBhbHNvIGFza2luZyBmb3IgdGhlIFFVSUMgd2cgdG8gc3BlY2lm eSBub3JtYXRpdmUgYmVoYXZpb3Igb2YNCj4gZmlyZXdhbGxzLCB3aGVuIHRoZXJlIGlzIG5vIGVx dWl2YWxlbnQgY29uc2Vuc3VzICBvbiB3aGF0IHRoZXkgb3VnaHQgdG8gZG8NCj4gZm9yIFRDUC4N Cj4gDQo+IEFzIEJyaWFuIHNhaWQgaW4gaGlzIG1lc3NhZ2UsIHdlIG1pZ2h0IGJlIGFibGUgdG8g YWdyZWUgb24gYSBjb3VwbGUgb2YgdGhpbmdzLA0KPiBwYXJ0aWN1bGFybHkgaGF2aW5nIHRvIGRv IHdpdGggZGlyZWN0aW9uIG9mIGNvbm5lY3Rpb24sIGNvcnJlbGF0aW9uIG9mDQo+IHN1YnNlcXVl bnQgcGFja2V0cyBpbiB0aGUgZmxvdywgYW5kIHRlcm1pbmF0aW9uLiAgQnV0IEkgZG9u4oCZdCB0 aGluayB3ZSBuZWVkDQo+IHRvIGRlY2lkZSB0aGF0IGxpc3QgcmlnaHQgbm93Lg0KPiANCj4gQnV0 LCBmb3IgZXhhbXBsZSwgaXQgbWlnaHQgYmUgbmljZSBmb3IgUVVJQyBjb25uZWN0aW9ucyB0byBi ZSBhYmxlIHRvIGF1dG8tDQo+IHJlcGFpciBzdGF0ZSBvbiBhIGZpcmV3YWxsIHdoZW5ldmVyIHRo ZSBjbGllbnQgc2VuZHMgdHJhZmZpYyAod2hpY2ggaXNu4oCZdA0KPiBwb3NzaWJsZSBmb3IgVENQ IGZpcmV3YWxscyB0aGF0IGxvb2sgZm9yIGEgU1lOIGF0IHRoZSBzdGFydCBvZiBjb25uZWN0aW9u KS4gIEl0DQo+IG1heSBldmVuIGJlIHBvc3NpYmxlIHdpdGggd2hhdOKAmXMgaW4gdGhlIGN1cnJl bnQgcHJvdG9jb2wuICBJdCBtaWdodCBldmVuIGJlDQo+IG9idmlvdXMgaG93IHN1Y2ggYSBmaXJl d2FsbCBzaG91bGQgYmUgaW1wbGVtZW50ZWQgdG8gdGhlIHNtYWxsIGdyb3VwIG9mDQo+IHBlb3Bs ZSB0aGF0IGN1cnJlbnRseSBoYXMgUVVJQyBkZXZlbG9wbWVudCBleHBlcmllbmNlLiAgSSB0aGlu ayB5b3Ugc2hvdWxkDQo+IGJlIGFsbG93ZWQgdG8gc2hhcmUgdGhhdCBleHBlcmllbmNlIHdpdGgg dXMgaWYgeW914oCZcmUgd2lsbGluZyB0by4NCj4gDQo+ID5XZSdyZSB0YWxraW5nIGFib3V0IHNv bHZpbmcgZm9yIGEgbGlzdCBvZiBwcm9ibGVtcyB0aGF0IGhhcyBubyBjb25zZW5zdXMuDQo+IA0K PiBXZSBkb27igJl0IGhhdmUgY29uc2Vuc3VzIHRvIGZvcm0gYSB3b3JraW5nIGdyb3VwIHlldCwg ZWl0aGVyLiAgV2UgY291bGQNCj4gd2hpdHRsZSBkb3duIHRoZSBsaXN0IHRvIHNvbWV0aGluZyBt dWNoIG1vcmUgY29uY3JldGUgaWYgdGhhdCB3b3VsZCBoZWxwIGdldA0KPiBjb25zZW5zdXMgb24g Zm9ybWluZyBhIHdvcmtpbmcgZ3JvdXAuDQo+IA0KPiA+TW9yZSBpbXBvcnRhbnRseSwgbXkgb3Bp bmlvbiBpcyB0aGF0IHRoaXMgd2cgbWF5IG5vdCBoYXZlIHRoZSByaWdodCBzZXQgb2YNCj4gZm9s a3Mgd2l0aCB3aG9tIHlvdSB3YW50IHRvIGRyaXZlIGNvbnNlbnN1cyBvbiB0aGlzIGxpc3Qgb2Yg ZmlyZXdhbGwNCj4gYmVoYXZpb3JzLg0KPiANCj4gSeKAmW0gd29ya2luZyB0byBnZXQgdGhvc2Ug cGVvcGxlIGludm9sdmVkLiAgV2UgaGF2ZW7igJl0IGRlc2lnbmVkIGEgbmV3DQo+IHRyYW5zcG9y dCB0aGF0IGFueSBvZiB0aGVtIGhhdmUgY2FyZWQgYWJvdXQgcmVjZW50bHksIHNvIGl0IG1heSB0 YWtlIGEgd2hpbGUNCj4gdG8gZ2V0IHRoZW0gaW50ZXJlc3RlZC4gIE1hbnkgb2YgdGhlbSB3b27i gJl0IHdhbnQgdG8gYmUgdG9sZCB0aGF0IHRoZWlyDQo+IGV4cGVyaWVuY2UgaXNu4oCZdCByZWxl dmFudCB1bmxlc3MgdGhleSBjYW4gcnVuIGFuIGV4cGVyaW1lbnQgYXQgdGhlIHNhbWUgc2l6ZQ0K PiBhcyBhIGJyb3dzZXIgbWFudWZhY3R1cmVyLg0KPiANCj4gPiAiUGVvcGxlIHdpdGggbW9yZSBR VUlDIGludHVpdGlvbiIgY2VydGFpbmx5IHdpbGwgaGF2ZSBzb21lIGlkZWEgb2YNCj4gPiB3aGF0 IGJlaGF2aW9ycyB0byBidWlsZCBmb3IgKGFuZCBJIGV4cGVjdCB0aGF0IHRvIGhhcHBlbiksIGJ1 dCB0aGVzZQ0KPiA+IHBlb3BsZSB3aWxsIGhhdmUgcXVpdGUgbGltaXRlZCBpZGVhIHdoYXQgZmly ZXdhbGxzIG5lZWQgdG8gZG8gb24gcGF0aCwNCj4gPiBhbmQgd2hhdCBpbmZvcm1hdGlvbiBmaXJl d2FsbHMgbmVlZC4gSU1PLCB5b3UgbmVlZCBuZXR3b3JrIG9wZXJhdGlvbnMNCj4gPiBmb2xrcyB0 byBiZSBoYXZpbmcgdGhhdCBjb252ZXJzYXRpb24sIGFuZCBRVUlDIGlzIGluY29udmVuaWVudGx5 IG5vdA0KPiA+IGJlaW5nIHByb3Bvc2VkIGluIE9QU0FSRUEgKEknbSBub3Qgc3VyZSB3aGljaCB3 ZyB3b3VsZCBiZSBhcHByb3ByaWF0ZSwNCj4gPiB3aGljaCBpcyB3aHkgSSBwcm9wb3NlZCBJTlRB UkVBLiBQZXJoYXBzIE9QU0FSRUEgaXMgYSBiZXR0ZXIgZml0LikNCj4gDQo+IFdoZW4gdGhvc2Ug cGVvcGxlIHNob3cgdXAgYXQgYSBwb3RlbnRpYWwgUVVJQyB3b3JraW5nIGdyb3VwLCB3aWxsIHRo ZXkgYmUNCj4gdG9sZCB0aGF0IHRoZWlyIHVzZSBjYXNlcyBhcmVu4oCZdCBpbnRlcmVzdGluZywg YW5kIHRoYXQgdGhlaXIgY29uY2VybnMgYXJlIG91dCBvZg0KPiBzY29wZSBhbnl3YXk/DQo+IA0K PiBJZiB3aGF0IHlvdeKAmXJlIHNheWluZyBpcyB0aGF0IHdlIGNhbiBjaGFydGVyIHdvcmsgc29t ZXdoZXJlIGVsc2UgaW4gdGhlIElFVEYNCj4gdG8gZGVhbCB3aXRoIHNvbWUgb2YgdGhlc2UgcXVl c3Rpb25zLCBJ4oCZbSBvcGVuIHRvIHRoYXQuICBJ4oCZZCBsaWtlIHVzIHRvIGtub3cNCj4gd2hh dCB3b3JrIG5lZWRzIHRvIGJlIGNoYXJ0ZXJlZCBpbiB3aGF0IGFyZWEsIGFuZCBoYXZlIGNoYXJ0 ZXIgbGFuZ3VhZ2UNCj4gZm9yIFFVSUMgdGhhdCBzYXlzIGhvdyBhIHBvdGVudGlhbCBRVUlDIHdv cmtpbmcgZ3JvdXAgd291bGQgaW50ZXJmYWNlIHdpdGgNCj4gdGhhdCBvdGhlciB3b3JrLg0KPiAN Cj4gPj5JIGFncmVlIHRoYXQgYW55IG1vcmUgaW50ZXJlc3RpbmcgcGF0aCBpbnRlcmFjdGlvbnMs IHRvIHRoZSBleHRlbnQgdGhhdCB0aGV5DQo+IG1pZ2h0IGJlIGludGVyZXN0aW5nLCBhcmUgbW9y ZSBpbiB0aGUgcmVhbG0gb2YgUExVUy4NCj4gPg0KPiA+V2h5IGFyZSB0aGVzZSBsZXNzIGludGVy ZXN0aW5nIHBhdGggaW50ZXJhY3Rpb25zPyBFeHBvc2luZyBiaXRzIHRvIGFsbG93DQo+IGZpcmV3 YWxscyB0byBkbyAid2hhdCB0aGV5IGRvIiBpcyBub3QgZ29pbmcgdG8gYmUgdHJpdmlhbCwgc2lu Y2UgIndoYXQgdGhleSBkbyINCj4gaXMgbm90IGFncmVlZCB1cG9uIGVsc2V3aGVyZS4NCj4gDQo+ IFNvcnJ5LCDigJxtb3JlIGludGVyZXN0aW5n4oCdIHdhcyBhbiB1bmZvcnR1bmF0ZSBjaG9pY2Ug b2Ygd29yZHMuICBXaGF0IEkgbWVhbg0KPiBieSB0aGF0IHdhcyB0aGUgZXhwbGljaXQgcGF0aC10 by1hcHBsaWNhdGlvbiBhbmQgYXBwbGljYXRpb24tdG8tcGF0aCBzaWduYWxpbmcNCj4gdGhhdCB3 ZSBleHBsb3JlZCBpbiB0aGUgU1BVRCBwcm90b3R5cGUuICBVbmxlc3Mgc29tZW9uZSBlbHNlIGFy Z3VlcyB3ZQ0KPiBvdWdodCB0byBhZGQgdGhhdCB0byBRVUlDLCBpdCBzZWVtcyBjbGVhcmx5IG91 dCBvZiBzY29wZSB1bnRpbCBpdCBoYXMgYmVlbg0KPiBleHBsb3JlZCBtdWNoIG1vcmUgZnVsbHkg YnkgYSBwb3RlbnRpYWwgUExVUyB3b3JraW5nIGdyb3VwIG9yIGVsc2V3aGVyZS4NCj4gDQo+IFRo ZSDigJxsZXNzIGludGVyZXN0aW5n4oCdIGJpdHMgKHRvIG1lLCBjb21wYXJhdGl2ZWx5KSBhcmUg dGhlIG9uZXMgd2XigJl2ZSBiZWVuDQo+IHRhbGtpbmcgYWJvdXQgaW4gdGhpcyB0aHJlYWQuICBX aGlsZSBJIGRvbuKAmXQgZXhwZWN0IHRoaXMgd29yayB0byBiZSB0cml2aWFsLCBJDQo+IGRvbuKA mXQgZXhwZWN0IGl0IHRvIHJlcXVpcmUgYW55IGZ1bmRhbWVudGFsIHJlc2VhcmNoLg0KPiANCj4g PiBJIHdvdWxkIGxvdmUgdG8gYmVsaWV2ZSB5b3UsIGJ1dCB5b3UgbXVzdCB1bmRlcnN0YW5kIHRo YXQgeW91ciB3b3JkDQo+ID4gKG9yIHlvdXJzIGFuZCBEYW4ncykganVzdCBpc24ndCBlbm91Z2gg aGVyZS4NCj4gDQo+IEkgZG9u4oCZdCBrbm93IGhvdyB0byByZXNwb25kIHRvIHRoaXMuIFBsZWFz ZSB1bmRlcnN0YW5kIHRoYXQgRGFuIGFuZCBJIGhhdmUNCj4gcmV2aWV3ZWQgd29ya2luZyBRVUlD IGZpcmV3YWxsIGNvZGUgYW5kIHRhbGtlZCB0byBhIGxvdCBvZiBwZW9wbGUgd2hvIGRvDQo+IGJv dGggdGhlIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IHdvcmsgZm9yIENpc2Nv4oCZcyBm aXJld2FsbCBwcm9kdWN0cy4NCj4gVmVyeSBmZXcgb2YgdGhvc2UgcGVvcGxlIGFyZSB3aWxsaW5n IHRvIHBhcnRpY2lwYXRlIGF0IHRoZSBJRVRGOyBldmVuIGlmIHRoZXkNCj4gd2VyZSwgSeKAmW0g bm90IHN1cmUgaG93IHdlIGNvdWxkIHByb3ZlIHRvIGV2ZXJ5b25lIHRoYXQgdGhleSBzaG91bGQg YmUNCj4gbGlzdGVuZWQgdG8uDQo+IA0KPiA+RmFpciBlbm91Z2g7IHRob3VnaCBJJ2xsIGNvbnRp bnVlIHRvIGFzayBmb3IgZGF0YSB3aGVuIHRoZSBjb252ZXJzYXRpb24NCj4gY29tZXMgdXAuDQo+ IA0KPiBJZiB0aGF04oCZcyBnb2luZyB0byBiZSB0aGUgYmFyIHRoYXQgd2UgaGF2ZSB0byBjbGVh ciBmb3IgZXZlcnkgc2luZ2xlDQo+IGNvbnZlcnNhdGlvbiB3ZSBoYXZlLCBJIHdvdWxkIGxpa2Ug dXMgdG8gcHJlLW5lZ290aWF0ZSB3aGF0IHNvcnQgb2YgZGF0YSB5b3UNCj4gd2lsbCBhY2NlcHQs IGFuZCBob3cgeW91IGNhbiBjb21lIHRvIHRydXN0IHRoYXQgaXQgd2FzIGdhdGhlcmVkIGluIGEN Cj4gcmVhc29uYWJsZSB3YXkuDQo+IA0KPiA+SSBkZWZpbml0ZWx5IGFncmVlIHdpdGggdGhlIHNw aXJpdCwgYnV0IEkgd29ycnkgYWJvdXQgdGhpcyBub3QgYmVpbmcgc2NvcGVkDQo+IHRpZ2h0bHkg ZW5vdWdoIHRvIHByZXZlbnQgcmF0aG9sZXMgb2YgdmFyaW91cyBzaGFwZXMgYW5kIHNpemVzLg0K PiANCj4gR3JlYXQuICBMZXTigJlzIHRhbGsgYWJvdXQgaG93IHRvIHNjb3BlIGl0IHRpZ2h0bHkg ZW5vdWdoLg0KPiANCj4gPlVuZGVyc3Rvb2QsIGFuZCBhcyBtdWNoIGFzIEkgd291bGQgbG92ZSB0 byBzZWUgdGhlIHVuaXZlcnNhbCBkZXBsb3ltZW50DQo+IG9mIFFVSUMsIGxldCdzIGJlIGNsZWFy IHRoYXQgaXQncyBub3QgYSBwcm9ibGVtIGZvciA5MiUgb2YgdXNlcnMgYXQgdGhlIG1vbWVudC4N Cj4gDQo+IEkgYWdyZWUgd2XigJlyZSB1bmxpa2VseSB0byBnZXQgdG8gMTAwJS4gIEhvd2V2ZXIs IEkgd291bGQgbGlrZSB0aGUgdXNlcnMgd2hvDQo+IGFyZSBkaXNhZHZhbnRhZ2VkIHRvIGhhdmUg dGhlIG9wdGlvbiBvZiBvbmUgZGF5IGdldHRpbmcgUVVJQyBzdXBwb3J0LiAgT25lDQo+IG9mIHRo ZSBxdWVzdGlvbnMgdGhhdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBleHBsb3JlLCBmb3IgZXhh bXBsZSwgd291bGQgYmUNCj4gdG8gZmluZCBvdXQgaWYgdGhpcyA3JSBpcyBhbHNvIHRoZSBzZXQg b2YgZm9sa3MgdGhhdCB1cGdyYWRlIHRoZWlyIGZpcmV3YWxscw0KPiBmcmVxdWVudGx5Lg0KPiAN Cj4gSnVzdCB3cml0aW5nIG9mZiBtb3JlIHRoYW4gMjAwIG1pbGxpb24gdXNlcnMgYmVjYXVzZSB3 ZSB3ZXJlbuKAmXQgd2lsbGluZyB0bw0KPiB0YWtlIHRoZSB0aW1lIG9yIGVmZm9ydCB0byBkZXNj cmliZSBob3cgdGhleSBjb3VsZCBvbmUgZGF5IHVzZSBRVUlDIGRvZXNu4oCZdA0KPiBzZWVtIGxp a2Ugd2UgYXJlIGRvaW5nIGFkZXF1YXRlIGVuZ2luZWVyaW5nLg0KDQpXZWJSVEMgbWVkaWEgc3Ry ZWFtcyBhbHNvIGhhZCBzaW1pbGFyIHByb2JsZW1zLCB3ZXJlIGJsb2NrZWQgYnkgZmlyZXdhbGxz LiBXZWJSVEMgYWRkZWQgc3VwcG9ydCBmb3IgY29uc2VudCBjaGVja3MgKFJGQyA3Njc1KSwgRmly ZXdhbGxzIHVwZGF0ZWQgdG8gcmVjb2duaXplIFNUVU4sIGFuZCBvcGVuL2Nsb3NlIHBpbi1ob2xl cyhodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamVubmluZ3MtYmVoYXZlLXJ0Y3dl Yi1maXJld2FsbC0wNCNzZWN0aW9uLTQuNSksIFRSQU0gV0cgaW50cm9kdWNlZCBUVVJOIGV4dGVu c2lvbnMgKFRVUk4gdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbiBSRkMgNzYzNSkgdG8gcGVybWl0 IG1lZGlhIGFuZCBkYXRhIGNoYW5uZWxzIG92ZXIgVURQLiANCg0KRmlyZXdhbGwgdHJhdmVyc2Fs IHNob3VsZCBiZSBjb25zaWRlcmVkIGluIHRoZSBkZXNpZ24gb2YgUVVJQy4NCg0KLVRpcnUNCg0K PiANCj4gLS0NCj4gSm9lIEhpbGRlYnJhbmQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFFVSUMgbWFpbGluZyBsaXN0DQo+IFFVSUNAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljDQo= From nobody Tue Jun 21 11:04:00 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E354012D5A9 for ; Tue, 21 Jun 2016 11:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 O_Ykn2YdXnS0 for ; Tue, 21 Jun 2016 11:03:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80D412D51C for ; Tue, 21 Jun 2016 11:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4GXAUHOLKXGDvaI/ttex/mrhsX+U5bkJu/FDmoHs/MU=; b=b0n3ps+116VR7ebWrxMD6mU6QTZrqRG4KIKS8RNrLaVz5fYUAk521Ao0DATX6I+IxMk6d8O2A3Ll/NwTLM5/XcXjLhqQhOBXStLb+hFTav5AaaUlyyNGtPhLtKeSLbFWPgWVsgGCZtTDAK5UwQoxfi6XxgjP9EDaPw4B3Ii6Nc4= Received: from CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) by CY1PR0301MB0652.namprd03.prod.outlook.com (10.160.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Tue, 21 Jun 2016 18:03:41 +0000 Received: from CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) by CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) with mapi id 15.01.0517.014; Tue, 21 Jun 2016 18:03:41 +0000 From: Christian Huitema To: "Tirumaleswar Reddy (tireddy)" , "Joe Hildebrand (jhildebr)" , Jana Iyengar Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHRxmpUm60htf9Ad0SGrBzG1iqBxJ/pTiaggAAJWoCAAActAIAABX+AgACvEICAAPrsAIAARVOAgADPS4CAAmHWAIAEqP2AgAALBACAAPwqAA== Date: Tue, 21 Jun 2016 18:03:41 +0000 Message-ID: References: <9D5D60A1-869C-495A-8C2A-7BEAAE93D2B3@cisco.com> <1F70255A-6622-415E-9B73-9E02CEBF8E06@cisco.com> <3724d95354514cc9abf9e97960866656@XCH-RCD-017.cisco.com> In-Reply-To: <3724d95354514cc9abf9e97960866656@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:d::4f3] x-ms-office365-filtering-correlation-id: d1473512-ebe9-4fdf-bc18-08d399fe60ee x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0652; 6:r16527eXB8/iz4/H7DHwG0cY26oeOu11MthUFiJI+hR+Q9vu62EAUjxn30GzyNEGpRUFR1BjCOQy0tuRWyRqO7nqia0Qm+df8ksrI2Obg7ybdH+d2RfWpirtbHGVZDK4Htg/0VmTzBMXfAUCTh9GXvwN4pZBzXJl2P2dWjjfmGhpQ0oxUb2MuKj/0IjDbafAOaginPyp0aXMIByD0y8SH5GywzeDuurxhzLWsSq23i3o1gv+js6XadLRVvcaBha+8ttjzcB7Conu11XMUYotmBAb87c18vmL+kJMgZAHefMAyRnJu78w7hzO/Ihtt468bq2Uta3cPu/UFHGzxq729A==; 5:ydr0WjYn5kFAXEhX30auZXqNWBlic1Zxj0qYG3RkJgBPwqYI2aC7WhZv+gTisqP9k+0gltBUghWjUxtdgbg90Wr5WQ0ZIWET3Vcq278dPOSvNu5U3fqWIqV9X5WVZlChUYH4v0SWaH/1z8t1KRCX8w==; 24:ouHfRCBzfwo9DoTac7TiAFtFrltRXFP/DoLhBdm8b9d+B0hrJND7JYJj8lYMG7jHoeu0Wrx8aAvKMXCSpnn/3CT0QsdekpcyJjaLJuaOVx0=; 7:+pK+SUaWL1W5mSPK1Fr54mFananoXp3KjvrLEbKxyZ95CVbsIyi9Ndkd61Ga8vxPPuP191va0lD60YgIG3Ky0DZ91GWCMvrvEWBMmSOdNzqDeYgKKIv4AEq4ICBvmNinvxqd0IiCZwzbz3Dm0RoA93lvYVvwlx4lhHzD7hJounD5DIqVHSF48Dwe4vdVc2TPfSxmEzfQ6Oy3wzJj/HcIAPWhRUAKbINKi2Y4wImvseLB8daScfc90VADaf5HGZoo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0652; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0652; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0652; x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(9686002)(3280700002)(76176999)(122556002)(99286002)(50986999)(19580395003)(101416001)(5005710100001)(5002640100001)(68736007)(7736002)(76576001)(11100500001)(81156014)(93886004)(81166006)(10400500002)(86612001)(10090500001)(54356999)(3660700001)(10290500002)(8676002)(86362001)(189998001)(97736004)(8990500004)(87936001)(74316001)(15975445007)(106356001)(33656002)(102836003)(4326007)(106116001)(8936002)(6116002)(105586002)(77096005)(586003)(2900100001)(2950100001)(92566002)(5003600100003)(7846002)(7696003)(2906002)(5001770100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0652; H:CY1PR0301MB0649.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2016 18:03:41.5212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0652 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 18:04:00 -0000 T24gTW9uZGF5LCBKdW5lIDIwLCAyMDE2IDc6MTUgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90 ZToNCj4gLi4uDQo+IA0KPiBXZWJSVEMgbWVkaWEgc3RyZWFtcyBhbHNvIGhhZCBzaW1pbGFyIHBy b2JsZW1zLCB3ZXJlIGJsb2NrZWQgYnkgZmlyZXdhbGxzLg0KPiBXZWJSVEMgYWRkZWQgc3VwcG9y dCBmb3IgY29uc2VudCBjaGVja3MgKFJGQyA3Njc1KSwgRmlyZXdhbGxzIHVwZGF0ZWQgdG8NCj4g cmVjb2duaXplIFNUVU4sIGFuZCBvcGVuL2Nsb3NlIHBpbi1ob2xlcyhodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtDQo+IGplbm5pbmdzLWJlaGF2ZS1ydGN3ZWItZmlyZXdhbGwtMDQj c2VjdGlvbi00LjUpLCBUUkFNIFdHIGludHJvZHVjZWQgVFVSTg0KPiBleHRlbnNpb25zIChUVVJO IHRoaXJkIHBhcnR5IGF1dGhvcml6YXRpb24gUkZDIDc2MzUpIHRvIHBlcm1pdCBtZWRpYSBhbmQg ZGF0YQ0KPiBjaGFubmVscyBvdmVyIFVEUC4NCj4gDQo+IEZpcmV3YWxsIHRyYXZlcnNhbCBzaG91 bGQgYmUgY29uc2lkZXJlZCBpbiB0aGUgZGVzaWduIG9mIFFVSUMuDQoNCkNvbnNpZGVyZWQsIGNl cnRhaW5seS4gQnV0IGxvdCBvZiB0aGUgY29tcGxleGl0eSB3aXRoIFdlYlJUQywgSUNFIGFuZCBT VFVOIGRlcml2ZXMgZnJvbSAicGVlciB0byBwZWVyIiBzY2VuYXJpb3MsIGluIHdoaWNoIGJvdGgg ZW5kcyBhcmUgYmVoaW5kIGZpcmV3YWxscy4gVGhlc2UgcGVlci10by1wZWVyIHNjZW5hcmlvcyBh cmUgbm90IHBhcnQgb2YgdGhlIGZpcnN0IHdhdmUgb2YgYXBwbGljYXRpb25zIHRhcmdldGVkIGJ5 IFFVSUMsIHNvIHdlIGNhbiBkZWJhdGUgd2hldGhlciB0aGV5IGJlbG9uZyBpbiB0aGUgY2hhcnRl ci4NCg0KVGhlIGZpcnN0IHdhdmUgb2YgUVVJQyBhcHBsaWNhdGlvbiBpcyBzb2xpZGx5ICJicm93 c2VyIHRvIGRhdGEgY2VudGVyLCIgYW5kIHdlIG9ic2VydmUgdGhhdCBmb3IgdGhlc2Ugc2NlbmFy aW9zIFFVSUMgaXMgdHJhdmVyc2luZyAic3RhdGVmdWwgZmlyZXdhbGxzIiBqdXN0IGZpbmUuIFRo ZSBub3JtYWwgZmxvdyBvZiBkYXRhIGFuZCBhY2tub3dsZWRnbWVudHMgaXMgbGFyZ2VseSBzdWZm aWNpZW50IHRvIG1haW50YWluIHRoZSBmaXJld2FsbCBzdGF0ZS4gWW91IG1lbnRpb24gImNvbnNl bnQsIiBidXQgdGhhdCdzIHZlcnkgbXVjaCBpbXBsaWNpdGx5IGdyYW50ZWQgYnkgdGhlIGZsb3cg b2YgcmV2ZXJzZSB0cmFmZmljLg0KDQpUaGUgb25seSBwb3RlbnRpYWwgaXNzdWUgdGhlcmUgaXMg dGhlIGNhc2Ugd2hlcmUgdGhlIHJldmVyc2UgdHJhZmZpYyBpcyBhbiBhbmdyeSAiZ28gYXdheSIg bWVzc2FnZS4gSXQgaXMgb2J2aW91c2x5IG5vdCBhbiBpbmRpY2F0aW9uIHRoYXQgbW9yZSBjb250 ZW50IGlzIGRlc2lyZWQsIGJ1dCBzaW5jZSBpdCBpcyBlbmNyeXB0ZWQsIHRoZSBmaXJld2FsbCBj YW5ub3QgdGVsbC4gT24gdGhlIG90aGVyIGhhbmQsIHdlIGhhdmUgYSBzcGVjaWZpY2F0aW9uIGZv ciBhIGNsZWFyIHRleHQgInJlc2V0LCIgd2hpY2ggdGhlIGNsaWVudCBjb3VsZCBzZW5kIGlmIHRo ZSBvdGhlciBwYXJ0eSBmYWlscyB0byBnbyBhd2F5LiBBbmQgdGhlIGZpcmV3YWxsIGNhbiBjZXJ0 YWlubHkgbm90aWNlIHRoYXQuDQoNClNvLCBpbiBwcmFjdGljZSwgSSBkb24ndCBiZWxpZXZlIHRo YXQgd2UgaGF2ZSBtdWNoIG9mIGEgcHJvYmxlbS4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0K IA0K From nobody Tue Jun 21 12:17:20 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7512DD1F for ; Tue, 21 Jun 2016 12:17:16 -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 u1WMi26uFzwM for ; Tue, 21 Jun 2016 12:17:15 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 CF77612DD11 for ; Tue, 21 Jun 2016 12:17:13 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id g13so18661111ioj.1 for ; Tue, 21 Jun 2016 12:17:13 -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=UwPU1XgkzV77nhDIsw9RxukBkZj9vkCnRIxSnpEzk0Q=; b=BMIFyG5pFz1BhBAe0s+K03wT8O9i6kDqgGG4KzBwdSrNYe47eXYvZymeDNJ3gNTP3/ I5E7KaWKDFRXkCiWPgYYB8OGvnCKmqf/o/7Py2/FgcR9jKUqPI2UIfU/WAVFGxUbEp2k DTu2exJsSzP01ijPqs56wSRgL+KQdOpzjspPyFBbwF7InaSA50IKNkIzDemEQ3771zg1 Ld6GM1hsCKvXpd8Lfj4mGhnfvw7PCbc1B+aR3MxhIeo1gMK6WJYok1hhm8Y/NyxVo7q6 WNvUaDtCH82WmNsYyl6R6Ww6GFYoxsfM4agRHc7kQfPMM6jxSVhrIw2gRCUJLKOVuJ4c nj8A== 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=UwPU1XgkzV77nhDIsw9RxukBkZj9vkCnRIxSnpEzk0Q=; b=OxtjYPl6q0EIBYIy2v9vVHfw27rn4ofGwtLaYRQQcHoCRVU3l/1R4kKhbk7Aa/BUW5 4jz/mOgBL2ooUBa0YQjNbg/wTDg7lgY72xuQn0vxn77z2XOngtPDfyJV6TnsI7lSO1ag OkLX0Xl1zkIOMapNQeEUEjgPYSsRkzBwoLVEXp/d26FGusDHBTOhRUx791gIQYGd0T9A 3cAdqCGXP2k4uL4QH8vah6rvySTYKq6JTiarJpT3a405TZwQAgBBdFdueHbPGbM4rN33 CaF1kJNDXWHkn2gh1X9ndV2wG/YFJ6tJW1vOlZWHLb55+CEi6alODtz6/e2NppYSFxAx sZ9A== X-Gm-Message-State: ALyK8tI1p571HulXv4ZDVJWINIFSVKLwfmLshoOj5OofAIxErz/M3vJRkpzIkfC0w2tLBs91JFAWUWS6qypbvs54 X-Received: by 10.107.9.78 with SMTP id j75mr33135356ioi.33.1466536632797; Tue, 21 Jun 2016 12:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.73 with HTTP; Tue, 21 Jun 2016 12:16:53 -0700 (PDT) In-Reply-To: <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com> <655C07320163294895BBADA28372AF5D488BD814@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D488C9873@FR712WXCHMBA15.zeu.alcatel-lucent.com> <99939A2C-286D-44BE-B865-0DA83E440D30@lurchi.franken.de> <3A0781FE-D2F2-4AD8-8F4D-4AC3A8D4D177@trammell.ch> From: Ian Swett Date: Tue, 21 Jun 2016 15:16:53 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a113f90120cb12a0535ceab61 Archived-At: Cc: "Scharf, Michael \(Nokia - DE\)" , spud , Jana Iyengar , =?UTF-8?Q?Michael_T=C3=BCxen?= , "quic@ietf.org" , Randall Stewart Subject: Re: [QUIC] Segment offload for UDP-based protocols Re: Requirements X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 19:17:16 -0000 --001a113f90120cb12a0535ceab61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would agree with you Brian that QUIC/PLUS could be offloaded if #2 was present. #3 is not an issue if the header is encrypted, since it's just part of the encrypted segment. If it wasn't encrypted, I would suggest it either be omitted from the non-first packets or identical across all packets. But either way, it's a solvable problem. That being said, I think we should think hard about whether we want to solve that problem, because it involves a lot of complexity and I believe we'd be better served in ensuring there are simple send/receive paths that are very fast. In regards to acks and LRO, some middleboxes/endpoints will drop all but the most recent ack if multiple arrive in close proximity. It's not clear this is always a feature from a congestion control perspective, but it likely increases throughput in some environments. However, given QUIC/PLUS can easily change the receiver's behavior, we can send fewer acks. Ideally the sender would be aware of that, so it can adjust it's congestion control to expect long pauses. I think this achieves the same goal end-to-end and CPU benchmarks in QUIC indicate it performs very well. I'm hugely concerned about the CPU performance of QUIC, but nothing has convinced me LRO or TSO would help enough to be worth the work. Instead, sending fewer acks and faster send/receive APIs show a lot more promise, at least on the host side. On Thu, Jun 9, 2016 at 6:41 AM, Brian Trammell wrote: > hi Randall, > > > On 09 Jun 2016, at 12:30, Randall Stewart wrote: > > > > > >> On Jun 9, 2016, at 5:06 AM, Michael Tuexen < > Michael.Tuexen@lurchi.franken.de> wrote: > >> > >> > >>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > >>> > >>> My concern is that the current charter suggestion markets the protoco= l > by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency for applicat= ions=E2=80=9D. IMHO this > can have rebound effects. > >>> > >>> Here is what I mean by wrong expectations: Whether a protocol is > indeed fast or not depends on many parameters including aspects such as > hardware acceleration/offload (which matters at 10G/40G line speed, to th= e > best of my knowledge). Some of these effects of > >> I think this refers to high throughput. For TCP, offloading TCP > processing to a NIC improves performance > >> of the TCP processing. I'm not sure if this still helps if > encryption/decryption comes into the game. > > > > I too was thinking Michael meant offloading such as TSO and LRO. I know > on most of the caches > > I develop on if I turn off TSO and LRO performance of the box drops by > roughly 50%=E2=80=A6 and I think > > this will be a consequence of encrypting everything since I don=E2=80= =99t think > you can do TSO/LRO unless > > the hardware/lower-layers has access to things equivalent to TCP > sequence numbers and ACK values, > > which is what I believe the encryption is meant to hide (from middle > boxes). > > > > That will be an extreme price to pay the question is, is it worth it > /and or/ is there some other way > > to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-) > > (adding spud@ietf.org, as this is a relevant question for PLUS, too): > > The question is what is the minimum information xSO/LRO needs to work. If > I understand how generic segment offload works, if QUIC(/PLUS) exposes: > > (1) a header field that can be used to order packets and find gaps that > the kernel can find and interpret, > > (2) a defined and easily-found boundary between header and payload, such > that the payload retains any framing/message boundaries needed to meet AP= I > contracts, and > > (3) rules about which header to choose for the "big" segment on receive > > then adding QUIC(/PLUS) aware SO/LRO to the kernel should be reasonably > simple. I don't see why you need ACK-equivalents to be exposed to make > this work, but I might be missing something. > > Hardware offload takes longer to deploy, obviously, but runs on equivalen= t > information. > > Cheers, > > Brian > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a113f90120cb12a0535ceab61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would agree with you Brian that QUIC/PLUS could be offlo= aded if #2 was present. =C2=A0#3 is not an issue if the header is encrypted= , since it's just part of the encrypted segment.=C2=A0 If it wasn't= encrypted, I would suggest it either be omitted from the non-first packets= or identical across all packets.=C2=A0 But either way, it's a solvable= problem.

That being said, I think we should think hard = about whether we want to solve that problem, because it involves a lot of c= omplexity and I believe we'd be better served in ensuring there are sim= ple send/receive paths that are very fast.

In rega= rds to acks and LRO, some middleboxes/endpoints will drop all but the most = recent ack if multiple arrive in close proximity.=C2=A0 It's not clear = this is always a feature from a congestion control perspective, but it like= ly increases throughput in some environments.=C2=A0 However, given QUIC/PLU= S can easily change the receiver's behavior, we can send fewer acks.=C2= =A0 Ideally the sender would be aware of that, so it can adjust it's co= ngestion control to expect long pauses.=C2=A0 I think this achieves the sam= e goal end-to-end and CPU benchmarks in QUIC indicate it performs very well= .

I'm hugely concerned about the CPU performan= ce of QUIC, but nothing has convinced me LRO or TSO would help enough to be= worth the work.=C2=A0 Instead, sending fewer acks and faster send/receive = APIs show a lot more promise, at least on the host side.

On Thu, Jun 9, 2016 at 6= :41 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Randall,

> On 09 Jun 2016, at 12:30, Randall Stewart <rrs@netflix.com> wrote:
>
>
>> On Jun 9, 2016, at 5:06 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> w= rote:
>>
>>
>>> On 09 Jun 2016, at 10:03, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> w= rote:
>>>
>>> My concern is that the current charter suggestion markets the = protocol by =E2=80=9Cminimizing (=E2=80=A6) overall transport latency for a= pplications=E2=80=9D. IMHO this can have rebound effects.
>>>
>>> Here is what I mean by wrong expectations: Whether a protocol = is indeed fast or not depends on many parameters including aspects such as = hardware acceleration/offload (which matters at 10G/40G line speed, to the = best of my knowledge). Some of these effects of
>> I think this refers to high throughput. For TCP, offloading TCP pr= ocessing to a NIC improves performance
>> of the TCP processing. I'm not sure if this still helps if enc= ryption/decryption comes into the game.
>
> I too was thinking Michael meant offloading such as TSO and LRO. I kno= w on most of the caches
> I develop on if I turn off TSO and LRO performance of the box drops by= roughly 50%=E2=80=A6 and I think
> this will be a consequence of encrypting everything since I don=E2=80= =99t think you can do TSO/LRO unless
> the hardware/lower-layers has access to things equivalent to TCP seque= nce numbers and ACK values,
> which is what I believe the encryption is meant to hide (from middle b= oxes).
>
> That will be an extreme price to pay the question is, is it worth it /= and or/ is there some other way
> to get the benefits of the TSO/LRO even with encryption=E2=80=A6 :-)
(adding spud@ietf.org, as this is a re= levant question for PLUS, too):

The question is what is the minimum information xSO/LRO needs to work. If I= understand how generic segment offload works, if QUIC(/PLUS) exposes:

(1) a header field that can be used to order packets and find gaps that the= kernel can find and interpret,

(2) a defined and easily-found boundary between header and payload, such th= at the payload retains any framing/message boundaries needed to meet API co= ntracts, and

(3) rules about which header to choose for the "big" segment on r= eceive

then adding QUIC(/PLUS) aware SO/LRO to the kernel should be reasonably sim= ple.=C2=A0 I don't see why you need ACK-equivalents to be exposed to ma= ke this work, but I might be missing something.

Hardware offload takes longer to deploy, obviously, but runs on equivalent = information.

Cheers,

Brian


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


--001a113f90120cb12a0535ceab61-- From nobody Fri Jun 24 09:41:19 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADDF12DC86; Fri, 24 Jun 2016 09:00:43 -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: <20160624160043.10933.21761.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:43 -0700 Archived-At: X-Mailman-Approved-At: Fri, 24 Jun 2016 09:41:14 -0700 Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com Subject: [QUIC] quic - Requested session has been scheduled for IETF 96 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:43 -0000 Dear Cindy Morgan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:30:00) Wednesday, Morning Session I 1000-1230 Room Name: Potsdam I size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: rmcat l4s tsvarea saag tls httpbis webpush rtcweb acme dispatch maprg tsvwg iccrg tcpm tcpinc mptcp taps t2trg ianaplan lurk lpwan plus Special Requests: --------------------------------------------------------- From nobody Wed Jun 29 10:31:05 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13AC12D0C7 for ; Wed, 29 Jun 2016 10:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 PBQH3TEhLjnx for ; Wed, 29 Jun 2016 10:30:58 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D45B412D5A9 for ; Wed, 29 Jun 2016 10:30:58 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5TFn48N011131 for ; Wed, 29 Jun 2016 11:49:22 -0400 Received: from flpi408.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049287.ppops.net-00191d01. with ESMTP id 23vgg9n2su-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Jun 2016 11:49:21 -0400 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5TFnKeu032157 for ; Wed, 29 Jun 2016 08:49:20 -0700 Received: from flpi487.ffdc.sbc.com (flpi487.ffdc.sbc.com [130.4.162.181]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5TFnBmL032016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 29 Jun 2016 08:49:14 -0700 Received: from CAFRFD1MSGHUBAE.ITServices.sbc.com (CAFRFD1MSGHUBAE.itservices.sbc.com [130.4.169.132]) by flpi487.ffdc.sbc.com (RSA Interceptor) for ; Wed, 29 Jun 2016 15:48:59 GMT Received: from CAFRFD1MSGUSRJC.ITServices.sbc.com ([169.254.3.253]) by CAFRFD1MSGHUBAE.ITServices.sbc.com ([130.4.169.132]) with mapi id 14.03.0294.000; Wed, 29 Jun 2016 08:48:58 -0700 From: "DRUTA, DAN" To: "quic@ietf.org" Thread-Topic: Re: [QUIC] Network Path Requirements for QUIC Thread-Index: AdHSHb67vgzdmYr5SJqgr/bgB2rxKw== Date: Wed, 29 Jun 2016 15:48:58 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.161.219.255] Content-Type: multipart/alternative; boundary="_000_4AA3A95D6033ED488F8AE4E45F474487723C76D7CAFRFD1MSGUSRJC_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-29_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606290148 Archived-At: Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 17:31:03 -0000 --_000_4AA3A95D6033ED488F8AE4E45F474487723C76D7CAFRFD1MSGUSRJC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been following the discussion and while it is probably premature to = agree on specific requirements I do believe the scope of the work must incl= ude the deployment, management and troubleshooting aspects. The enterprise use cases are also extremely important and we need to make s= ure we're addressing them from the beginning. With this being said, I support Brian's proposed wording in the pull reques= t #14. I think it covers the high level objectives that should be in scope = for the work. This is at least a good start. Regards, Dan --_000_4AA3A95D6033ED488F8AE4E45F474487723C76D7CAFRFD1MSGUSRJC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been following the discussion and while it is= probably premature to agree on specific requirements I do believe the scop= e of the work must include the deployment, management and troubleshooting a= spects.

The enterprise use cases are also extremely importan= t and we need to make sure we’re addressing them from the beginning.<= o:p>

With this being said, I support Brian’s propos= ed wording in the pull request #14. I think it covers the high level object= ives that should be in scope for the work.

This is at least a good start.

 

Regards,

Dan

--_000_4AA3A95D6033ED488F8AE4E45F474487723C76D7CAFRFD1MSGUSRJC_-- From nobody Wed Jun 29 14:30:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6DE12D596 for ; Wed, 29 Jun 2016 14:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VvvJ_kFVjJLr for ; Wed, 29 Jun 2016 14:29:56 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DD212D1A9 for ; Wed, 29 Jun 2016 14:29:55 -0700 (PDT) Received: from smtptc.telefonica.com (tgtim3c01.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E1F304610F8 for ; Wed, 29 Jun 2016 23:29:51 +0200 (CEST) Received: from ESTGVMSP105.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP105", Issuer "ESTGVMSP105" (not verified)) by smtptc.telefonica.com (Postfix) with ESMTPS id BD32A4610F2 for ; Wed, 29 Jun 2016 23:29:51 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 29 Jun 2016 23:29:51 +0200 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2166.eurprd06.prod.outlook.com (10.168.57.25) with Microsoft SMTP Server (TLS) id 15.1.523.4; Wed, 29 Jun 2016 21:29:49 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) with mapi id 15.01.0523.019; Wed, 29 Jun 2016 21:29:49 +0000 From: "Diego R. Lopez" To: "quic@ietf.org" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0k1dZLev/pUEHE2hhTV3STlPSw== Date: Wed, 29 Jun 2016 21:29:49 +0000 Message-ID: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> In-Reply-To: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.97.38.51] x-ms-office365-filtering-correlation-id: aa8ad963-02a6-4d87-3e3a-08d3a0648005 x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2166; 6:QCq8b9tb3KWhq9JjgGLruoXskOkGWMT1N7lh6vjJBnHT8J0Jds5re+u9f085DDFQumLKHheu15rNKuleXdBpxUW5s9xCdGFrIp0YWNToEt/KLRs6TkToHcJjBXCFlRh1PsB0YRddmNDTjmXSP7MhmYG9kQUkL1Aux4H5/vr4c1MhoF2jBXsv/i5oNKEQ/vffMSpeilgbNyokTtwXw13b0x4vv9P80CntYpsAoMDVur/vejAOGOj+Nnh0m3Q1anNE3N0zUi/ZnJFA3LhnTKDIi4eV1Lc0D+wM4+iwmydaUG91dwP4I9qqJ7I0VbdrCgeO; 5:5D6x6ETKlX8IyEj6yBpNO0Y6iQGT2JlJnxryP3MpuzWFLWdIq6pyCVVKpcqXKn4nDKZCxGewdUD28BdzhaKLvj6bN+3qf7Ee4iFnT6K9NKj1+0BL3P2UFUEx0tlLCJkMaZ2W2mN1gBW6Qqfvxicsfw==; 24:xPYFbhpjfJjaXReVvLAXLye4ZBhBlg2Xeu8oabnPXtvK3QChZExnAXcr3xo08ku3hpRPeaVAOw3rInP6/h6mLFVcYYqxq0Yk/IrsFMK9920=; 7:ijmfJgoWTLM6CfPBsjWFs0nEMud4zyTjpu4J3RefsB5/+IW0MLoai4wvD0gnjBXUp2VJkmz+iQkBuZmTjQKtZ4KNsMmD1OC+EJK2ImfmnKteQTMPrrN+RF+Obx0y0eODQdR6yL6jj/ahIL+TCxO9IJcVT8Qc6UHcdL4eA3PqoXYyZ0SDQvBNcWQzugYLNiHHu2u6vMUEaA/hwRDSWwn2ZIj+9m6YFM0ImgbI7LlFIsxzYBSRdfAvC7gUNK5LmtR8gQa7uHcC3CCF4nuweCvh9Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2166; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB6PR0601MB2166; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2166; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(252514010)(189002)(24454002)(81156014)(105586002)(5640700001)(106116001)(110136002)(106356001)(1730700003)(3660700001)(82746002)(19580405001)(19580395003)(97736004)(5002640100001)(189998001)(81166006)(83716003)(8676002)(10400500002)(33656002)(450100001)(586003)(15975445007)(7736002)(2900100001)(16236675004)(3280700002)(2906002)(6116002)(101416001)(87936001)(8936002)(77096005)(2501003)(76176999)(50986999)(66066001)(7846002)(54356999)(68736007)(19617315012)(107886002)(7906003)(2351001)(92566002)(11100500001)(3846002)(86362001)(36756003)(102836003)(2950100001)(122556002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2166; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B7E3BD55FFE74324879178EE890FBA31telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 21:29:49.3532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2166 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1549-8.0.0.1202-22422.002 X-TM-AS-Result: No--20.524-7.0-31-10 X-imss-scan-details: No--20.524-7.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1549-8.0.1202-22422.002 X-TMASE-Result: 10--20.523600-10.000000 X-TMASE-MatchedRID: yebcs53SkkDD66A+AisN3dlHf9Z3qZKTFpw9gj8mywroN8DSoota+coN Vks0i3E5VvV8yYebEhlg0AcA2H+x4G+L3lQx0OQBSDkh6bW+bceWXqxvAbU4cmso23uKlCJjqbD mzbecxFsRz9WLMwdVXYkDPUfA/9d9VQ7O/4REy+suLk8NfSpYehuOm1myZLGV+Cckfm+bb6CrrZ ChRqncjPYLegcYUwTBB9/j38gUmtcFCdq0JvYbZbU+IyHhkXf1QZXZg2I8JaaAzVvlUnjZ4MJVY ZIfOjrdkaE77KD+w0XrZ6ORa+O0FDXsnl5F3ulZAM+6FTg/nco0KsqrzThBFSsPy9l39RHsmJEx p7i2Lr3hP0syZaT6pJC85/U4OL+yp67lrWc/9EtPM1eQmkHL6JNoZd6gOueer0qf1DddSeqRMaG eOvYqr2/u5I23RiEwplUIKX/81oINd6u5z6TaDHucAaWNuD925Qes11VWaql8qc3SdzGdSuhZfi gbAidd5l4J7vT5frVmxiA2j3JOwPKR3ZxUvy8DSPaw9Yq+2fRj0mUvAvV2Dcpj/9aYiP+hi7e10 Bdta+1ytfbJolwT2Tpbbl7UGzVELkCbdgaXmMnEO0jjSgczbuHQ21j8Rtpl7tX8kP02fcy3vnGg a/RuZx3Mdo3zW4mFstMGudgmuiP6/h7SMq9lwdWUzIorxWCf8YrbYFYsi4Xbs8aqjdm0ZFEvKx9 OHxOr8n8Oz5r0Vv1Pah7VZkGTW/D1+q38f5Zw5ce1Fj8paFErZLLsPor9ceQWLHRqeYpH3NnqIn 3iHD6CBAmIJGIbFuGEuhchvL8oo5RUoF1j1rieAiCmPx4NwGmRqNBHmBvepTwPRvSoXL2ZMPCnT MzfOnkguuQorcgMfN4DmFAgJLl2LsUVvzaUEPZQm3k9Iv3tBA9+jBKcsBR+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.811037.0001-0-1-22:0,12:0 Archived-At: Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 21:30:01 -0000 --_000_B7E3BD55FFE74324879178EE890FBA31telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCBEYW4gb24gdGhlIHN1cHBvcnQgb2YgQnJpYW7igJlzIHB1bGwgcmVxdWVzdCwg YW5kIG9uIEpvZeKAmXMgY29uY2VybnMgb24gdGhlIGF2YWlsYWJpbGl0eSBvZiBkYXRhIHN1cHBv cnRpbmcgc29tZSBvZiB0aGUgc3RhdGVtZW50cyBtYWRlIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiwg ZXNwZWNpYWxseSB3aGVuIHRoZXkgaW1weSB0aGUgcmlzayBvZiBpZ25vcmluZyBhIHNpZ25pZmlj YW50IG51bWJlciBvZiB1c2Vycy4NCg0KQmUgZ29vZGUsDQoNCk9uIDI5IEp1biAyMDE2LCBhdCAx ODo0OCAsIERSVVRBLCBEQU4gPGRkNTgyNkBhdHQuY29tPG1haWx0bzpkZDU4MjZAYXR0LmNvbT4+ IHdyb3RlOg0KDQpJIGhhdmUgYmVlbiBmb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gYW5kIHdoaWxl IGl0IGlzIHByb2JhYmx5IHByZW1hdHVyZSB0byBhZ3JlZSBvbiBzcGVjaWZpYyByZXF1aXJlbWVu dHMgSSBkbyBiZWxpZXZlIHRoZSBzY29wZSBvZiB0aGUgd29yayBtdXN0IGluY2x1ZGUgdGhlIGRl cGxveW1lbnQsIG1hbmFnZW1lbnQgYW5kIHRyb3VibGVzaG9vdGluZyBhc3BlY3RzLg0KVGhlIGVu dGVycHJpc2UgdXNlIGNhc2VzIGFyZSBhbHNvIGV4dHJlbWVseSBpbXBvcnRhbnQgYW5kIHdlIG5l ZWQgdG8gbWFrZSBzdXJlIHdl4oCZcmUgYWRkcmVzc2luZyB0aGVtIGZyb20gdGhlIGJlZ2lubmlu Zy4NCldpdGggdGhpcyBiZWluZyBzYWlkLCBJIHN1cHBvcnQgQnJpYW7igJlzIHByb3Bvc2VkIHdv cmRpbmcgaW4gdGhlIHB1bGwgcmVxdWVzdCAjMTQuIEkgdGhpbmsgaXQgY292ZXJzIHRoZSBoaWdo IGxldmVsIG9iamVjdGl2ZXMgdGhhdCBzaG91bGQgYmUgaW4gc2NvcGUgZm9yIHRoZSB3b3JrLg0K VGhpcyBpcyBhdCBsZWFzdCBhIGdvb2Qgc3RhcnQuDQoNClJlZ2FyZHMsDQpEYW4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpRVUlDIG1haWxpbmcgbGlz dA0KUVVJQ0BpZXRmLm9yZzxtYWlsdG86UVVJQ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcXVpYw0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3Ms IERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpo dHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6 QHRlbGVmb25pY2EuY29tDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgy IDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mg c2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVu ZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNv IGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1 c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBs YSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9y aXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nD s24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9n YW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2 w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwg aW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmlj YXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0 cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkg cmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNh dGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVz IGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBw b2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOp IHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2Ug bsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90 aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291 IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUg ZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJy bywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3Rh IG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= --_000_B7E3BD55FFE74324879178EE890FBA31telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <5BE5D62A0C1A9A459457D6A14631F13E@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQWdyZWUgd2l0aCBEYW4gb24gdGhl IHN1cHBvcnQgb2YgQnJpYW7igJlzIHB1bGwgcmVxdWVzdCwgYW5kIG9uIEpvZeKAmXMgY29uY2Vy bnMgb24gdGhlIGF2YWlsYWJpbGl0eSBvZiBkYXRhIHN1cHBvcnRpbmcgc29tZSBvZiB0aGUgc3Rh dGVtZW50cyBtYWRlIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiwgZXNwZWNpYWxseSB3aGVuIHRoZXkg aW1weSB0aGUgcmlzayBvZiBpZ25vcmluZyBhIHNpZ25pZmljYW50IG51bWJlciBvZiB1c2Vycy4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlIGdv b2RlLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI5IEp1biAyMDE2LCBh dCAxODo0OCAsIERSVVRBLCBEQU4gJmx0OzxhIGhyZWY9Im1haWx0bzpkZDU4MjZAYXR0LmNvbSIg Y2xhc3M9IiI+ZGQ1ODI2QGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogTHVj aWRhR3JhbmRlOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CkkgaGF2ZSBiZWVuIGZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBhbmQgd2hpbGUgaXQgaXMgcHJv YmFibHkgcHJlbWF0dXJlIHRvIGFncmVlIG9uIHNwZWNpZmljIHJlcXVpcmVtZW50cyBJIGRvIGJl bGlldmUgdGhlIHNjb3BlIG9mIHRoZSB3b3JrIG11c3QgaW5jbHVkZSB0aGUgZGVwbG95bWVudCwg bWFuYWdlbWVudCBhbmQgdHJvdWJsZXNob290aW5nIGFzcGVjdHMuPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KVGhl IGVudGVycHJpc2UgdXNlIGNhc2VzIGFyZSBhbHNvIGV4dHJlbWVseSBpbXBvcnRhbnQgYW5kIHdl IG5lZWQgdG8gbWFrZSBzdXJlIHdl4oCZcmUgYWRkcmVzc2luZyB0aGVtIGZyb20gdGhlIGJlZ2lu bmluZy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQpXaXRoIHRoaXMgYmVpbmcgc2FpZCwgSSBzdXBwb3J0IEJyaWFu 4oCZcyBwcm9wb3NlZCB3b3JkaW5nIGluIHRoZSBwdWxsIHJlcXVlc3QgIzE0LiBJIHRoaW5rIGl0 IGNvdmVycyB0aGUgaGlnaCBsZXZlbCBvYmplY3RpdmVzIHRoYXQgc2hvdWxkIGJlIGluIHNjb3Bl IGZvciB0aGUgd29yay48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpUaGlzIGlzIGF0IGxlYXN0IGEgZ29vZCBzdGFy dC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpSZWdhcmRzLDxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCkRhbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogTHVjaWRhR3JhbmRlOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBMdWNpZGFHcmFuZGU7IGZv bnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogTHVjaWRhR3JhbmRlOyBmb250LXNp emU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5RVUlDDQogbWFpbGlu ZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEx1Y2lkYUdyYW5kZTsgZm9udC1z aXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOlFVSUNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEx1Y2lkYUdyYW5kZTsg Zm9udC1zaXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPlFVSUNAaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogTHVjaWRh R3JhbmRlOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3F1aWMiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsgZm9udC1mYW1pbHk6IEx1Y2lkYUdyYW5kZTsgZm9udC1zaXplOiAxMXB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYzwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCi0tPGJyIGNsYXNzPSIi Pg0KJnF1b3Q7RXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vJnF1b3Q7PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRHIgRGllZ28gUi4gTG9wZXo8YnIgY2xhc3M9IiI+ DQpUZWxlZm9uaWNhIEkmIzQzO0Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8vcGVvcGxl LnRpZC5lcy9kaWVnby5sb3Blei8iIGNsYXNzPSIiPmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdv LmxvcGV6LzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQplLW1haWw6IGRpZWdvLnIu bG9wZXpAdGVsZWZvbmljYS5jb208YnIgY2xhc3M9IiI+DQpUZWw6ICZuYnNwOyAmbmJzcDsmIzQz OzM0IDkxMyAxMjkgMDQxPGJyIGNsYXNzPSIiPg0KTW9iaWxlOiAmIzQzOzM0IDY4MiAwNTEgMDkx PGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFy aWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+PGJyPg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVu dG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNv bnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJh IHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8g ZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBx dWUgbGENCiBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2lu IGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdp c2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwg bGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBt aXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi48YnI+DQo8YnI+DQpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlz IG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sDQogZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcg b2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxl YXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Ljxicj4NCjxi cj4NCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRl IGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdp YWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3Ug ZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0 w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYQ0KIGxlaXR1cmEsIHV0aWxp emHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUg ZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVj ZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5p cXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0 cnVpw6fDo288YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B7E3BD55FFE74324879178EE890FBA31telefonicacom_-- From nobody Thu Jun 30 00:32:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BC712D92C for ; Thu, 30 Jun 2016 00:32:00 -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 r3Dasw75ay0d for ; Thu, 30 Jun 2016 00:31:55 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F6712B018 for ; Thu, 30 Jun 2016 00:31:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,550,1459839600"; d="asc'?scan'208";a="128501280" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 30 Jun 2016 00:26:27 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 30 Jun 2016 00:26:27 -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:26:27 -0700 From: "Eggert, Lars" To: "DRUTA, DAN" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qC2wkvifCiJMkutwQH56TWIFg== Date: Thu, 30 Jun 2016 07:26:26 +0000 Message-ID: <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> In-Reply-To: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.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.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_26046197-A618-4119-9122-CFE0D27EAB53"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 07:32:00 -0000 --Apple-Mail=_26046197-A618-4119-9122-CFE0D27EAB53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2016-06-29, at 17:48, DRUTA, DAN wrote: > I have been following the discussion and while it is probably = premature to agree on specific requirements I do believe the scope of = the work must include the deployment, management and troubleshooting = aspects. > The enterprise use cases are also extremely important and we need to = make sure we=E2=80=99re addressing them from the beginning. why are they extremely important? First, HTTP over TCP will continue to function as well as it does today = in such use cases. So if QUIC doesn't work, whatever happy-eyeballs = mechanism the user agent is using should make it fall back to TCP = gracefully. Second, limiting or blocking UDP in enterprise environments is a = management decision by the IT department, and not something that is due = to the technology used. Normal NATs in enterprise environments will pass = QUIC just fine. If it doesn't pass, it's because it has been = administratively disabled. So we're really talking about what kind of protocol features would make = an admin want to unblock UDP for QUIC sessions. I'm pretty sure there's = not going to be an easy or even uniform answer to that question. For = that reason, I believe that saying "you should open up UDP port 443" is = likely going to be as difficult a discussion to have with IT staff than = any discussion about yet undefined protocol features that we add in the = hopes of making QUIC appeal to them. We're talking about less than 10% of Internet paths here, and since HTTP = over TCP continues to be available and work as well as it does today, I = don't think that complicating QUIC for these use cases - especially = since we really don't know what features may make an admin want to = administratively unblock UDP for QUIC - is worthwhile. Lars PS: All hats off. > With this being said, I support Brian=E2=80=99s proposed wording in = the pull request #14. I think it covers the high level objectives that = should be in scope for the work. > This is at least a good start. >=20 > Regards, > Dan > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_26046197-A618-4119-9122-CFE0D27EAB53 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----- iQIcBAEBCAAGBQJXdMmhAAoJEFS1wwm/cMFXGrwP/i+Yim9FMMy7XwWuOL4p7D+0 BdsJbJnuBuR6tBbhdgInxGLg8zO3GQF9mmFJpCb+80GzSMuchVH6C137qqe0hcte M08JEpGLWZBn8VqJBP4LORgnkJqVegzfUQSFfv/sVXaszNHpk2PnNomp6Sc6bIsL naeaNAL0rpZzdFK6MCb3gtN/eH9Y7PX3H0cG57pwnZkAR0KTalkVf4sppFmPYvuJ bHUNVPH5VXA5x9K1NHZ2hPunFx/48vky0/yiiwbGS5fKBa/DjFkNqPECe1sflDrx fJiW/fNvFUTpHHSzdOjw3WwCJvuJRqJVkHxgrhVBkWNc7J9Jtci0HDwHgEdoYjpZ WzoK0sWhjTTM260jBdk0a2RkjthcwbUNQRnmbMm84SZNBKOjWBWWvtQkAWx3PSV+ EBNBipiUCicX3dfscbHO4dBPu1KzdUdecuAy5HBekWdTJspsQ6jNYoh4oGCMksii xetLUZrwG0ANhX5QWLU+tZtT2v7FesryZKlfDLncC+CKDoMKAmjKNfmgnHlcGOCF i/Atol6Q2cls8vy+N4AKQq30HwxAkhSldlYcM3LJnRQcMJIOo+uYQstUTGZNSh48 Gr/7u+Db7Gi4dt9zNsysnb2+h4PI/NVoE8HZk0rCh/P6UhhOtwSYR6458l+WMCRu uab7JYRXZa1RvwVJjVTI =C2xp -----END PGP SIGNATURE----- --Apple-Mail=_26046197-A618-4119-9122-CFE0D27EAB53-- From nobody Thu Jun 30 03:07:48 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3216712D9EE for ; Thu, 30 Jun 2016 03:07:47 -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=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 MLz3tlWprnBA for ; Thu, 30 Jun 2016 03:07:45 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94E12D1B3 for ; Thu, 30 Jun 2016 02:58:07 -0700 (PDT) Received: from [10.161.252.169] (unknown [213.55.176.238]) by trammell.ch (Postfix) with ESMTPSA id 5893E1A0351; Thu, 30 Jun 2016 11:57:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Brian Trammell X-Mailer: iPhone Mail (13F69) In-Reply-To: <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> Date: Thu, 30 Jun 2016 11:57:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> To: "Eggert, Lars" Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 10:07:47 -0000 Hi Lars, all, One tiny quibble (that turned into a short essay), inline: Sent from my iPhone > On 30 Jun 2016, at 09:26, Eggert, Lars wrote: >=20 > Hi, >=20 >> On 2016-06-29, at 17:48, DRUTA, DAN wrote: >> I have been following the discussion and while it is probably premature t= o agree on specific requirements I do believe the scope of the work must inc= lude the deployment, management and troubleshooting aspects. >> The enterprise use cases are also extremely important and we need to make= sure we=E2=80=99re addressing them from the beginning. >=20 > why are they extremely important? >=20 > First, HTTP over TCP will continue to function as well as it does today in= such use cases. So if QUIC doesn't work, whatever happy-eyeballs mechanism t= he user agent is using should make it fall back to TCP gracefully. >=20 > Second, limiting or blocking UDP in enterprise environments is a managemen= t decision by the IT department, and not something that is due to the techno= logy used. Normal NATs in enterprise environments will pass QUIC just fine. I think subtly different definitions of "just fine" here is where this discu= ssion is getting stuck. I want to unpack this part a bit: "UDP blocking is a policy decision" is a statement I'll accept as true: it's= hard to measure, but it seems reasonable. "UDP limits are not due to the technology": all the measurement we've done, a= nd all I've seen results from others, indicates this is also true. The lack o= f middleboxes that Just Want To Help UDP traffic even seems to make UDP work= better on some paths. If by "just fine" you mean "in the default configuration UDP traffic passes w= ith the same probability as TCP traffic", yes, that certainly seems to be th= e case. The order of magnitude difference between default UDP and TCP idle timeouts o= n NATs, however, remains a cause for concern; for persistent connections wit= h unlucky delays, this will work less "just fine". This is a particular inst= ance of the general problems caused by making transport state opaque. For H2 over QUIC, sending PING frames every thirty seconds "fixes" this prob= lem, for nonzero cost; there are I'm sure smarter ways of doing this. Or may= be QUIC decides to mark any path on which it has seen state loss as bad for a= while and falls back to TCP. But the WG will have to make a decision how to= handle this specific state. > If it doesn't pass, it's because it has been administratively disabled. We can make that assumption and most of the time it holds.=20 But, larger than and separate from the blocking/timeout issue, the reason I s= uggested the word "diagnosability" in my PR is "what happens when it doesn't= ". Right now, the state of the art in figuring out what's happening with a g= iven TCP connection is, in most environments I know of, peering at it for a w= hile in Wireshark. A network admin should be able to do at least that well w= hen trying to figure out what's happening with a QUIC connection. Cheers, Brian (no hats either) > So we're really talking about what kind of protocol features would make an= admin want to unblock UDP for QUIC sessions. I'm pretty sure there's not go= ing to be an easy or even uniform answer to that question. For that reason, I= believe that saying "you should open up UDP port 443" is likely going to be= as difficult a discussion to have with IT staff than any discussion about y= et undefined protocol features that we add in the hopes of making QUIC appea= l to them. >=20 > We're talking about less than 10% of Internet paths here, and since HTTP o= ver TCP continues to be available and work as well as it does today, I don't= think that complicating QUIC for these use cases - especially since we real= ly don't know what features may make an admin want to administratively unblo= ck UDP for QUIC - is worthwhile. >=20 > Lars >=20 > PS: All hats off. >=20 >> With this being said, I support Brian=E2=80=99s proposed wording in the p= ull request #14. I think it covers the high level objectives that should be i= n scope for the work. >> This is at least a good start. >>=20 >> Regards, >> Dan >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Thu Jun 30 07:17:38 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADE012D0DA for ; Thu, 30 Jun 2016 07:17:36 -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 A0NEWqxvMxua for ; Thu, 30 Jun 2016 07:17:35 -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 4030112D0BA for ; Thu, 30 Jun 2016 07:17:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,552,1459839600"; d="asc'?scan'208";a="124160054" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 30 Jun 2016 07:12:30 -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 07:12:30 -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 07:12:30 -0700 From: "Eggert, Lars" To: Brian Trammell Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qC2EnDpyDuvnE+IfLnz6AoxiKACO70AgABHNQA= Date: Thu, 30 Jun 2016 14:12:29 +0000 Message-ID: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> In-Reply-To: <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@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.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_E3E9450E-ABB4-4284-BB4F-BA5970E75C88"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:17:37 -0000 --Apple-Mail=_E3E9450E-ABB4-4284-BB4F-BA5970E75C88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2016-06-30, at 11:57, Brian Trammell wrote: >> On 30 Jun 2016, at 09:26, Eggert, Lars wrote: >>=20 >> Second, limiting or blocking UDP in enterprise environments is a = management decision by the IT department, and not something that is due = to the technology used. Normal NATs in enterprise environments will pass = QUIC just fine. >=20 > I think subtly different definitions of "just fine" here is where this = discussion is getting stuck. I want to unpack this part a bit: >=20 > "UDP blocking is a policy decision" is a statement I'll accept as = true: it's hard to measure, but it seems reasonable. >=20 > "UDP limits are not due to the technology": all the measurement we've = done, and all I've seen results from others, indicates this is also = true. The lack of middleboxes that Just Want To Help UDP traffic even = seems to make UDP work better on some paths. >=20 > If by "just fine" you mean "in the default configuration UDP traffic = passes with the same probability as TCP traffic", yes, that certainly = seems to be the case. yep, that is what I meant. Thanks for putting it into clearer words. > The order of magnitude difference between default UDP and TCP idle = timeouts on NATs, however, remains a cause for concern; for persistent = connections with unlucky delays, this will work less "just fine". This = is a particular instance of the general problems caused by making = transport state opaque. >=20 > For H2 over QUIC, sending PING frames every thirty seconds "fixes" = this problem, for nonzero cost; there are I'm sure smarter ways of doing = this. Or maybe QUIC decides to mark any path on which it has seen state = loss as bad for a while and falls back to TCP. But the WG will have to = make a decision how to handle this specific state. Correct; we measured this for the IMC study and I'd be shocked if it has = gotten better. My belief (since I don't have data) is that such middleboxes incorrectly = assumed that UDP was just being used for DNS, and that shorter timeout = are therefore OK. This is just another example of middlebox vendors = making wrong assumptions. (And - pet peeve - there is really no need for binding timeouts for TCP = or UDP to begin with. No binding needs to be timed out until the = middlebox runs out of memory, because as long as there are sufficient = resources, why bother managing all these timeouts? If a middlebox runs = out of resources, it needs a mechanism - LRU, etc. - to free resources, = i.e., remove bindings, anyway. So enforcing timeouts just makes things = more complicated without actually making anything better. Compare this = with processes on operating systems, they aren't being killed either = just because they happen to sleep a lot; at least until the OS runs out = of resources, and then all bets are off anyway in terms of what gets = killed and what doesn't.) There isn't anything QUIC can do to better pass through these existing = middleboxes - they need to be upgraded. >=20 >> If it doesn't pass, it's because it has been administratively = disabled. >=20 > We can make that assumption and most of the time it holds. >=20 > But, larger than and separate from the blocking/timeout issue, the = reason I suggested the word "diagnosability" in my PR is "what happens = when it doesn't". Right now, the state of the art in figuring out what's = happening with a given TCP connection is, in most environments I know = of, peering at it for a while in Wireshark. A network admin should be = able to do at least that well when trying to figure out what's happening = with a QUIC connection. Sure. But that sounds more like that we need a wireshark dissector for = QUIC, which actually already exists: = https://www.wireshark.org/docs/dfref/q/quic.html Lars --Apple-Mail=_E3E9450E-ABB4-4284-BB4F-BA5970E75C88 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----- iQIcBAEBCAAGBQJXdSjLAAoJEFS1wwm/cMFXeZwP+wWhOqHEHvCwh1g4ble/Owp+ GxAHtA5EbRQEO7fvtBvt8t9ND5mjQ2lTqiMUe03cRVCrgapHOh1DFqdPatfeCXpf CrdBFgG1zwoa1bvKYUmsyRItub/w0JFWwryZwakALLAwfkIw3dcTFAseCTmUUB0W qwbLhiH6yevGhC2MJo3XoFPupg0DZLttcpTEhiMdgfJVJOImKG2AvxPc5kHu3uIT KPPK47A56DAdAk2aJBX2pMidyLHi6lcVHDGW/kTgbUUXf7Hu8nh9ON/VGDQ1E5jD hSBn2SX84HU7zWYuo3RTupKJo0xUYCzwzCx9yfrQXDBgUe2v8Mv2G17X17MJauai A0EQK3fmaYah4zMsZcDcSk10Wr/9SxpJq6t/ZQ9i5CVcgHRgjvK/mzRDAR1agmIn OnAFx16+bVlWDvmlg2x9OgoczeM8zpdF/rcETFX3ku2Ow0KheqoQgbfdUwZFPWZg 0tZlyW1UJy+Ebz6SzC12JGuRjSoNO1I0dwGmJ9kbX2u/wYG29JVDLsz4zPKgAzDX 77zaJA80yvdIMkBnRZjXVkTkGg0M9Yt7SznkBX8IkuTt/J9YLJY7NH2ciYd/noGV dB/5JTeh1w4KMZtelmpUBNCgmzLt1varYGKUMncZKwYQTcM/58cc4hJ+gd7/yrgZ pXISQGslgWy8TJr7EBFu =Amhf -----END PGP SIGNATURE----- --Apple-Mail=_E3E9450E-ABB4-4284-BB4F-BA5970E75C88-- From nobody Thu Jun 30 07:43:52 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C3D12D0FD for ; Thu, 30 Jun 2016 07:43:50 -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 s3GOOq_Q4bOJ for ; Thu, 30 Jun 2016 07:43:48 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4E12D0FA for ; Thu, 30 Jun 2016 07:43:47 -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 58F5F1A03B4; Thu, 30 Jun 2016 16:43:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_22F76AA2-3217-4B2B-A057-E46203FB197C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 30 Jun 2016 16:43:14 +0200 Message-Id: <59DEA54A-A78D-4C5C-9275-F76EB57AE4D5@trammell.ch> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:43:50 -0000 --Apple-Mail=_22F76AA2-3217-4B2B-A057-E46203FB197C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Lars, > On 30 Jun 2016, at 16:12, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2016-06-30, at 11:57, Brian Trammell wrote: >>> On 30 Jun 2016, at 09:26, Eggert, Lars wrote: >>>=20 >>> Second, limiting or blocking UDP in enterprise environments is a = management decision by the IT department, and not something that is due = to the technology used. Normal NATs in enterprise environments will pass = QUIC just fine. >>=20 >> I think subtly different definitions of "just fine" here is where = this discussion is getting stuck. I want to unpack this part a bit: >>=20 >> "UDP blocking is a policy decision" is a statement I'll accept as = true: it's hard to measure, but it seems reasonable. >>=20 >> "UDP limits are not due to the technology": all the measurement we've = done, and all I've seen results from others, indicates this is also = true. The lack of middleboxes that Just Want To Help UDP traffic even = seems to make UDP work better on some paths. >>=20 >> If by "just fine" you mean "in the default configuration UDP traffic = passes with the same probability as TCP traffic", yes, that certainly = seems to be the case. >=20 > yep, that is what I meant. Thanks for putting it into clearer words. >=20 >> The order of magnitude difference between default UDP and TCP idle = timeouts on NATs, however, remains a cause for concern; for persistent = connections with unlucky delays, this will work less "just fine". This = is a particular instance of the general problems caused by making = transport state opaque. >>=20 >> For H2 over QUIC, sending PING frames every thirty seconds "fixes" = this problem, for nonzero cost; there are I'm sure smarter ways of doing = this. Or maybe QUIC decides to mark any path on which it has seen state = loss as bad for a while and falls back to TCP. But the WG will have to = make a decision how to handle this specific state. >=20 > Correct; we measured this for the IMC study and I'd be shocked if it = has gotten better. Would have cited the paper by name, but was stuck on an iPhone. :) > My belief (since I don't have data) is that such middleboxes = incorrectly assumed that UDP was just being used for DNS, and that = shorter timeout are therefore OK. This is just another example of = middlebox vendors making wrong assumptions. >=20 > (And - pet peeve - there is really no need for binding timeouts for = TCP or UDP to begin with. No binding needs to be timed out until the = middlebox runs out of memory, because as long as there are sufficient = resources, why bother managing all these timeouts? If a middlebox runs = out of resources, it needs a mechanism - LRU, etc. - to free resources, = i.e., remove bindings, anyway. So enforcing timeouts just makes things = more complicated without actually making anything better. FWIW, I agree. Lots of little stupid reasons collude here, I suspect: the operating = systems these things run on making it easier to fire a timer than to = figure out when their process(es) might be out of memory, a (possibly = misguided) desire to make (opaque) behavior predictable instead of = unpredictable, a (equally misguided) desire to make this predictable = thing admin-configurable. There's also the fact that it's not just memory that NATs need to = conserve: they might also be implemented to manage public address and = port scarcity. But LRU mechanisms can handle this scarcity at least as = well as timers can. > Compare this with processes on operating systems, they aren't being = killed either just because they happen to sleep a lot; at least until = the OS runs out of resources, and then all bets are off anyway in terms = of what gets killed and what doesn't.) >=20 > There isn't anything QUIC can do to better pass through these existing = middleboxes - they need to be upgraded. This only helps if they get upgraded to a something that actually has = better timeout/mapping expiry properties. Maybe I'm a little less optimistic than you are about the potential = impact of encouraging better engineering practice among middlebox = vendors, and maybe I'm more optimistic about the potential impact of = making this expiry behavior explicit. I'm not saying QUIC needs a PLUS-style endpoint-exposed desired-timeout = indicator; I think that's a discussion for PLUS, actually. I'm saying = that discussion of possible protocol design mitigations to the = timeout-and-spurious-keepalive problem (as a subpart of the general NAT = traversal problem) should be in scope for the WG. The WG might well = decide that it explicitly doesn't care, that middleboxes that timeout = UDP mappings on a ludicrously short scale are a reason to have TCP = fallback. But that decision should appear in the WG's output. >>> If it doesn't pass, it's because it has been administratively = disabled. >>=20 >> We can make that assumption and most of the time it holds. >>=20 >> But, larger than and separate from the blocking/timeout issue, the = reason I suggested the word "diagnosability" in my PR is "what happens = when it doesn't". Right now, the state of the art in figuring out what's = happening with a given TCP connection is, in most environments I know = of, peering at it for a while in Wireshark. A network admin should be = able to do at least that well when trying to figure out what's happening = with a QUIC connection. >=20 > Sure. But that sounds more like that we need a wireshark dissector for = QUIC, which actually already exists: = https://www.wireshark.org/docs/dfref/q/quic.html Yep. There's a lot more to using Wireshark for TCP debugging that just = the dissector, though. Some of these things need the protocol to radiate = information that QUIC doesn't. Again, not saying that QUIC should expose = ACKs, just saying that the discussion of the tradeoff between = information radiated and how much pain it inflicts on existing practice = needs to happen in the WG. Cheers, Brian (still no hats) >=20 > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_22F76AA2-3217-4B2B-A057-E46203FB197C 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 iQIcBAEBCgAGBQJXdTADAAoJEIoSt78L6kajuTEP/RFHKrWjfQ4WMC2b/ppglSTI g3biLwCeBosRFuHpIvPYksT9+tceMqJVbj42iClsyiizWew0yOBsaV+Gz8ZPZL+7 ez1/AEBDgs+8jOtAB88IjaPu+IztWGd/LqR820BQJEv9KgoQQdchmkMuzTzO2aNs JvL2gvFSzMdJjXaDNDAr7lAVxhhP3q0a0snSTDseg6wQPIbDCXSkPniXuvnzr0nN CgH2NqdiHA5LAzbiHoFcAZKees3hpihAwq+iCka3uhmmCuvtXPOtGRwQ0pmmaXyJ gEY4C1Zpf1d1PXYM6+PuE1tkgrtyLNAAnH004rfwwcaAXYvdDzylTTlWTeD/s+eR QLSUJGEM7q4yQCuNs6osKVsBCuNI8er+dyAByl2kvY8voE2guc67kY1RrmGWaQr9 +ZOhFeOm31k7PD5kS6+WBMS+KR8aBiFco++3TMcnAgDn3WmKrM6fmFR066oJCwlR y+Ac9VEYPXs3u77mQHspQqnWk52G4ufUVhUBfGHbVh70LSjxbSs17vDedWb4ENnt KizYd/BcRHBPGa/RMlIROvF2wKTkd13dWHubZ2Bfg09Neuhifdw6TQXz6p1Tf1YF lkjf4jvFs2gVuyXFuyr5yJIzPQIMyheHP8bLRQlDzoMyeEWYHD5o7146OoyXhD8R UaYtEorjRIJILDE318NP =xyHm -----END PGP SIGNATURE----- --Apple-Mail=_22F76AA2-3217-4B2B-A057-E46203FB197C-- From nobody Thu Jun 30 07:46:34 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7682412D10E for ; Thu, 30 Jun 2016 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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 rDLg92g2lbTn for ; Thu, 30 Jun 2016 07:46:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 8C5DB12D100 for ; Thu, 30 Jun 2016 07:46:30 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5UEhOXx029530; Thu, 30 Jun 2016 10:46:30 -0400 Received: from flpi408.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049287.ppops.net-00191d01. with ESMTP id 23w5bxg6d3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jun 2016 10:46:30 -0400 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5UEkSVf016440; Thu, 30 Jun 2016 07:46:29 -0700 Received: from flpi489.ffdc.sbc.com (flpi489.ffdc.sbc.com [130.4.162.183]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5UEkN74016408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jun 2016 07:46:25 -0700 Received: from CAFRFD1MSGHUBAE.ITServices.sbc.com (CAFRFD1MSGHUBAE.itservices.sbc.com [130.4.169.132]) by flpi489.ffdc.sbc.com (RSA Interceptor); Thu, 30 Jun 2016 14:46:10 GMT Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.81]) by CAFRFD1MSGHUBAE.ITServices.sbc.com ([130.4.169.132]) with mapi id 14.03.0294.000; Thu, 30 Jun 2016 07:46:10 -0700 From: "DRUTA, DAN" To: "Eggert, Lars" , Brian Trammell Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qDJaoOPZVnZsEKYiUtwZTqjnKACO70AgABHOYD//49I8A== Date: Thu, 30 Jun 2016 14:46:10 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.161.219.255] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606300141 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:46:33 -0000 Lars, Brian covered some the reasoning to explore enterprise use cases in detail. What's important is to understand and capture the reasons why IT Administra= tors are blocking UDP. Some are as you pointed out not related to the techn= ology but we need to make sure they get the right level of manageability wi= th QUIC in order troubleshooting legitimate traffic and prevent attacks. Regards, Dan -----Original Message----- From: Eggert, Lars [mailto:lars@netapp.com]=20 Sent: Thursday, June 30, 2016 7:12 AM To: Brian Trammell Cc: DRUTA, DAN; quic@ietf.org Subject: Re: [QUIC] Network Path Requirements for QUIC Hi, On 2016-06-30, at 11:57, Brian Trammell wrote: >> On 30 Jun 2016, at 09:26, Eggert, Lars wrote: >>=20 >> Second, limiting or blocking UDP in enterprise environments is a managem= ent decision by the IT department, and not something that is due to the tec= hnology used. Normal NATs in enterprise environments will pass QUIC just fi= ne. >=20 > I think subtly different definitions of "just fine" here is where this di= scussion is getting stuck. I want to unpack this part a bit: >=20 > "UDP blocking is a policy decision" is a statement I'll accept as true: i= t's hard to measure, but it seems reasonable. >=20 > "UDP limits are not due to the technology": all the measurement we've don= e, and all I've seen results from others, indicates this is also true. The = lack of middleboxes that Just Want To Help UDP traffic even seems to make U= DP work better on some paths. >=20 > If by "just fine" you mean "in the default configuration UDP traffic pass= es with the same probability as TCP traffic", yes, that certainly seems to = be the case. yep, that is what I meant. Thanks for putting it into clearer words. > The order of magnitude difference between default UDP and TCP idle timeou= ts on NATs, however, remains a cause for concern; for persistent connection= s with unlucky delays, this will work less "just fine". This is a particula= r instance of the general problems caused by making transport state opaque. >=20 > For H2 over QUIC, sending PING frames every thirty seconds "fixes" this p= roblem, for nonzero cost; there are I'm sure smarter ways of doing this. Or= maybe QUIC decides to mark any path on which it has seen state loss as bad= for a while and falls back to TCP. But the WG will have to make a decision= how to handle this specific state. Correct; we measured this for the IMC study and I'd be shocked if it has go= tten better. My belief (since I don't have data) is that such middleboxes incorrectly as= sumed that UDP was just being used for DNS, and that shorter timeout are th= erefore OK. This is just another example of middlebox vendors making wrong = assumptions. (And - pet peeve - there is really no need for binding timeouts for TCP or = UDP to begin with. No binding needs to be timed out until the middlebox run= s out of memory, because as long as there are sufficient resources, why bot= her managing all these timeouts? If a middlebox runs out of resources, it n= eeds a mechanism - LRU, etc. - to free resources, i.e., remove bindings, an= yway. So enforcing timeouts just makes things more complicated without actu= ally making anything better. Compare this with processes on operating syste= ms, they aren't being killed either just because they happen to sleep a lot= ; at least until the OS runs out of resources, and then all bets are off an= yway in terms of what gets killed and what doesn't.) There isn't anything QUIC can do to better pass through these existing midd= leboxes - they need to be upgraded. >=20 >> If it doesn't pass, it's because it has been administratively disabled. >=20 > We can make that assumption and most of the time it holds. >=20 > But, larger than and separate from the blocking/timeout issue, the reason= I suggested the word "diagnosability" in my PR is "what happens when it do= esn't". Right now, the state of the art in figuring out what's happening wi= th a given TCP connection is, in most environments I know of, peering at it= for a while in Wireshark. A network admin should be able to do at least th= at well when trying to figure out what's happening with a QUIC connection. Sure. But that sounds more like that we need a wireshark dissector for QUIC= , which actually already exists: https://www.wireshark.org/docs/dfref/q/qui= c.html Lars From nobody Thu Jun 30 07:54:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63DB12D0F5 for ; Thu, 30 Jun 2016 07:54:28 -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 xi0pKu6XlKUK for ; Thu, 30 Jun 2016 07:54:26 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 B6DF712B054 for ; Thu, 30 Jun 2016 07:54:26 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id c2so113154038vkg.1 for ; Thu, 30 Jun 2016 07:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hEedZr13F/FFM7wctLOrFxJzv0RHJoPSpj2jqQBWbME=; b=vOsHs60ro5qkMSGwomVSvIXAuiEkewTc3UDGc7mdokZg7wV2cIDDHlmUvcgGyz6h69 N2BJA/Aji2/7vXDVlu3MAVSp5f80h/dw+Iob46EzwqP3vnquTsYy73/PkRmjQfwPctok R2PdykaVY9mP+Fj7m/aKALVqfP2XDfLp4zxMaXKyxZrTgF9c46dfbaA+3A/i6veck22X VDgTTwX1ZPgPoGQpEg653PdwfngLpBcGj9C+XvaazKQCuQC1lRVfhwNHupeSIKTvSZ/F k0AccRiXFAcLcIYgW8rP5/DIFfTqCy6Evago3nEFcdwx3050IFAWDtFKLLJVra3NfyP0 T4iw== 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:content-transfer-encoding; bh=hEedZr13F/FFM7wctLOrFxJzv0RHJoPSpj2jqQBWbME=; b=NJVOk3hJd8ydMMh5WDG/U75G8R1doEqL8B/rWJEO7J2L3rEIjPZJtXDEV6MjfLGR3c HNO6QVymSfngYYGWaoh+9ZMnEuGoWqvuxcnzC107Ri9R7wWPTcuoAB9JJeaCZGskMNVE lw2eFDvBUN3FUTwJdmOdOc6dkBuAzNHEAsTfxqN5/TCbwLmNOlA5q0pa3/Mq/Ra3ruDN r0B7dBzQJYp8Vxy0zeFcbXGrOUmK3eCbk3c4KU8yUCvFnszUUwbbepf/9wNWxLaLvHAK 6gnybRd45pHX98WgbHjW4BXN+TzzSP2OXcZ4DAfATzoOnEzt99duHSOVSUXx8nWQ48Iv z3xQ== X-Gm-Message-State: ALyK8tK+saVKniNk6zt2NyJdj6XkyKUAPXNa993Bu4hD2etNu/omzIC3yxgsGUJL4SUPbhUpdYGNLzfqgJ/2TA== X-Received: by 10.159.40.164 with SMTP id d33mr6705200uad.109.1467298465722; Thu, 30 Jun 2016 07:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Thu, 30 Jun 2016 07:54:25 -0700 (PDT) In-Reply-To: <59DEA54A-A78D-4C5C-9275-F76EB57AE4D5@trammell.ch> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <59DEA54A-A78D-4C5C-9275-F76EB57AE4D5@trammell.ch> From: Watson Ladd Date: Thu, 30 Jun 2016 07:54:25 -0700 Message-ID: To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:54:29 -0000 On Thu, Jun 30, 2016 at 7:43 AM, Brian Trammell wrote: >>> >>> But, larger than and separate from the blocking/timeout issue, the reas= on I suggested the word "diagnosability" in my PR is "what happens when it = doesn't". Right now, the state of the art in figuring out what's happening = with a given TCP connection is, in most environments I know of, peering at = it for a while in Wireshark. A network admin should be able to do at least = that well when trying to figure out what's happening with a QUIC connection= . >> >> Sure. But that sounds more like that we need a wireshark dissector for Q= UIC, which actually already exists: https://www.wireshark.org/docs/dfref/q/= quic.html > > Yep. There's a lot more to using Wireshark for TCP debugging that just th= e dissector, though. Some of these things need the protocol to radiate info= rmation that QUIC doesn't. Again, not saying that QUIC should expose ACKs, = just saying that the discussion of the tradeoff between information radiate= d and how much pain it inflicts on existing practice needs to happen in the= WG. What sorts of things are we talking about? I have zero network operations experience but have investigated stuff with Wireshark before. > > Cheers, > > Brian (still no hats) > >> >> Lars >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Jun 30 08:05:50 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF59E12DA5B for ; Thu, 30 Jun 2016 08:05:48 -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 yfSyTC8sOHap for ; Thu, 30 Jun 2016 08:05:45 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 96E2812DA73 for ; Thu, 30 Jun 2016 08:05:41 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id c2so113668540vkg.1 for ; Thu, 30 Jun 2016 08:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LAMBtxkTperrVcVaRSz6fSF9Vy48Zl9xLDejspAyEBc=; b=HxVdacm6KMbez2fHm/y/ikhiWp6u1IINbR2AU6AWgmx8ife15pHd9+vCd6Gx+PO7DJ ZLhYwh79Hsd/3ThRZXIExfUJfVS2IHuh+NmSzpa7ZM5f9iZbTtOUm6IN5boZuSsagiNn 2Maxg6qDZ4sxirk0Yfhx1nQvXDj1+ru8QJ+2GWzcNSa4whSMThFVNpvityQOG2JcYPpl b49zvJuyt8VReZ9x0AdiSgjveb30BhV2MKY0MMJrGjxlsopUl+Ufq5/ce4ezyeDh7aus sXRF8cAmpZsXsqeuhx3tnbSMO78/XXtJpBFU9lzp8oMtwp0XlK1o7Tx9Gxpq6sPmea5Z ogTA== 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:content-transfer-encoding; bh=LAMBtxkTperrVcVaRSz6fSF9Vy48Zl9xLDejspAyEBc=; b=Hsv3Y+FS5oKk6aU56xSD1hFJdfr5NXhPCJf3uTsBLZPOceSfIPypSHcQk7MDl0wB42 0QVZQ8KXylTXTKh0UWLunHdYwl6l3gsrUvXBjV/nEodAl0dq6zlJUnFbbEBlPgp7m3YL 3ZQb6Tiq4XH+T4at9gqZDsDVWTuyRIMq4up184B+9IPadWlnMQqTTPvTwCk1TZ8Ade8Y s0jBfWymxD0gFMlqaQ4zH+6h9WeiraaLiy0FlAs6yCwbbb0YH6/AHnZIQ/ARETLFo6N3 OJ0CCbo2yK/OPR3TeqSMevNodoBDG06Lkwm8ZQPOd0Nc0U50NPzhhBleFDex+hD93s0B 052g== X-Gm-Message-State: ALyK8tLvBYMi7WAN6KWNtxDSWONBeK5OQQ+XfHWqPW0/1dUuI+kRcmh9gJeGVwX5oVeX9oUqwAcUBAEIsggj+w== X-Received: by 10.31.63.129 with SMTP id m123mr6665117vka.149.1467299140188; Thu, 30 Jun 2016 08:05:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Thu, 30 Jun 2016 08:05:39 -0700 (PDT) In-Reply-To: <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> From: Watson Ladd Date: Thu, 30 Jun 2016 08:05:39 -0700 Message-ID: To: "DRUTA, DAN" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:05:49 -0000 On Thu, Jun 30, 2016 at 7:46 AM, DRUTA, DAN wrote: > Lars, > > Brian covered some the reasoning to explore enterprise use cases in detai= l. > What's important is to understand and capture the reasons why IT Administ= rators are blocking UDP. Some are as you pointed out not related to the tec= hnology but we need to make sure they get the right level of manageability = with QUIC in order troubleshooting legitimate traffic and prevent attacks. So initial emails argued that we need an exposed consent mechanism to enable connection tracking for DOS prevention. But QUIC already has DOS prevention techniques: the server can tell clients to "GO AWAY AND WHEN YOU COME BACK QUOTE ME". Of course middlebox vendors have an incentive to pretend this isn't the case, and load balancer vendors can insist that connection tracking is essential (instead of something much more clever you can do with QUIC and not TLS), etc. But the reality is QUIC is working today. > > Regards, > Dan > > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Thursday, June 30, 2016 7:12 AM > To: Brian Trammell > Cc: DRUTA, DAN; quic@ietf.org > Subject: Re: [QUIC] Network Path Requirements for QUIC > > Hi, > > On 2016-06-30, at 11:57, Brian Trammell wrote: >>> On 30 Jun 2016, at 09:26, Eggert, Lars wrote: >>> >>> Second, limiting or blocking UDP in enterprise environments is a manage= ment decision by the IT department, and not something that is due to the te= chnology used. Normal NATs in enterprise environments will pass QUIC just f= ine. >> >> I think subtly different definitions of "just fine" here is where this d= iscussion is getting stuck. I want to unpack this part a bit: >> >> "UDP blocking is a policy decision" is a statement I'll accept as true: = it's hard to measure, but it seems reasonable. >> >> "UDP limits are not due to the technology": all the measurement we've do= ne, and all I've seen results from others, indicates this is also true. The= lack of middleboxes that Just Want To Help UDP traffic even seems to make = UDP work better on some paths. >> >> If by "just fine" you mean "in the default configuration UDP traffic pas= ses with the same probability as TCP traffic", yes, that certainly seems to= be the case. > > yep, that is what I meant. Thanks for putting it into clearer words. > >> The order of magnitude difference between default UDP and TCP idle timeo= uts on NATs, however, remains a cause for concern; for persistent connectio= ns with unlucky delays, this will work less "just fine". This is a particul= ar instance of the general problems caused by making transport state opaque= . >> >> For H2 over QUIC, sending PING frames every thirty seconds "fixes" this = problem, for nonzero cost; there are I'm sure smarter ways of doing this. O= r maybe QUIC decides to mark any path on which it has seen state loss as ba= d for a while and falls back to TCP. But the WG will have to make a decisio= n how to handle this specific state. > > Correct; we measured this for the IMC study and I'd be shocked if it has = gotten better. > > My belief (since I don't have data) is that such middleboxes incorrectly = assumed that UDP was just being used for DNS, and that shorter timeout are = therefore OK. This is just another example of middlebox vendors making wron= g assumptions. > > (And - pet peeve - there is really no need for binding timeouts for TCP o= r UDP to begin with. No binding needs to be timed out until the middlebox r= uns out of memory, because as long as there are sufficient resources, why b= other managing all these timeouts? If a middlebox runs out of resources, it= needs a mechanism - LRU, etc. - to free resources, i.e., remove bindings, = anyway. So enforcing timeouts just makes things more complicated without ac= tually making anything better. Compare this with processes on operating sys= tems, they aren't being killed either just because they happen to sleep a l= ot; at least until the OS runs out of resources, and then all bets are off = anyway in terms of what gets killed and what doesn't.) > > There isn't anything QUIC can do to better pass through these existing mi= ddleboxes - they need to be upgraded. > >> >>> If it doesn't pass, it's because it has been administratively disabled. >> >> We can make that assumption and most of the time it holds. >> >> But, larger than and separate from the blocking/timeout issue, the reaso= n I suggested the word "diagnosability" in my PR is "what happens when it d= oesn't". Right now, the state of the art in figuring out what's happening w= ith a given TCP connection is, in most environments I know of, peering at i= t for a while in Wireshark. A network admin should be able to do at least t= hat well when trying to figure out what's happening with a QUIC connection. > > Sure. But that sounds more like that we need a wireshark dissector for QU= IC, which actually already exists: https://www.wireshark.org/docs/dfref/q/q= uic.html > > Lars > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Jun 30 08:13:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F5812DA8F for ; Thu, 30 Jun 2016 08:13:12 -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 OdcX1de44QI5 for ; Thu, 30 Jun 2016 08:13:11 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A4BE012B04A for ; Thu, 30 Jun 2016 08:13: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 CA2CD1A16ED; Thu, 30 Jun 2016 17:13:09 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_54BEC365-D7EA-4BB3-9A36-4A47310B6A71"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 30 Jun 2016 17:13:08 +0200 Message-Id: <920948CC-2B2F-48E8-BB9D-56187DAF8EE1@trammell.ch> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <59DEA54A-A78D-4C5C-9275-F76EB57AE4D5@trammell.ch> To: Watson Ladd X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:13:13 -0000 --Apple-Mail=_54BEC365-D7EA-4BB3-9A36-4A47310B6A71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30 Jun 2016, at 16:54, Watson Ladd wrote: >=20 > On Thu, Jun 30, 2016 at 7:43 AM, Brian Trammell = wrote: > >>>>=20 >>>> But, larger than and separate from the blocking/timeout issue, the = reason I suggested the word "diagnosability" in my PR is "what happens = when it doesn't". Right now, the state of the art in figuring out what's = happening with a given TCP connection is, in most environments I know = of, peering at it for a while in Wireshark. A network admin should be = able to do at least that well when trying to figure out what's happening = with a QUIC connection. >>>=20 >>> Sure. But that sounds more like that we need a wireshark dissector = for QUIC, which actually already exists: = https://www.wireshark.org/docs/dfref/q/quic.html >>=20 >> Yep. There's a lot more to using Wireshark for TCP debugging that = just the dissector, though. Some of these things need the protocol to = radiate information that QUIC doesn't. Again, not saying that QUIC = should expose ACKs, just saying that the discussion of the tradeoff = between information radiated and how much pain it inflicts on existing = practice needs to happen in the WG. >=20 > What sorts of things are we talking about? I have zero network > operations experience but have investigated stuff with Wireshark > before. The simplest ones are the stream graphs (Statistics -> TCP Stream = Graphs), which give you a nice tcptrace-like visualization of what's = going on with the flow, but need to match sequence and ack numbers. = Following a flow (Analyze -> Follow -> TCP Stream) is also useful, but = QUIC gives enough information to do this already. Cheers, Brian >>=20 >> Cheers, >>=20 >> Brian (still no hats) >>=20 >>>=20 >>> Lars >>> _______________________________________________ >>> QUIC mailing list >>> QUIC@ietf.org >>> https://www.ietf.org/mailman/listinfo/quic >>=20 >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >>=20 >=20 >=20 >=20 > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. --Apple-Mail=_54BEC365-D7EA-4BB3-9A36-4A47310B6A71 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 iQIcBAEBCgAGBQJXdTcFAAoJEIoSt78L6kaja/oP/iD/cbcGqSaDk5YgBJ3wczlx SS/B2C5NCDoHlmXyfx2Mf+8T1q5WtR05jqlVQRffplqEmrWdbdFWg6JvV4En8hCb qpXALgEuvXB1ZH0b8zQV9OR/+j9lxfaFEnAWtX8jxcZ4NNQvBldeGb1ELBqr+0vP cZhKmcx/qjFpGprGsMJwCj2LOl/PYjwonJzvDplXORaxjNZzlirE/RJlmE87tABP QKkl4NpMJwASeoJ/OS0ooP9p8vjpGfejQT+AaeykegMbgEu5YDa6vsI8uQkLQ+6x BrKdr/9QHXP1t7FXTe+l9Mh987pDeYwniOQzygbqr0JW6/CNc1XCE8kB4hJa4/UQ DO0g1lC0j+VFwSZ2+TGdwpFzzqI+YbMGrESmqHRSBjXWg1UJnDyrJlGJjJxH/paH rC+WxvLjqExjsh+PzLhW42ZMNslrNHm8aRAb571bngaZmEyu5Q3jRrWcdEo8RBfD dah2ZAP872fR6T4EdrU3Bf2/Uqwrf8fTqdtEzyBAn+CJHoPOfd8eREysSWkoqAbx 3ajMdiyplNBjF1D2BrDNRV1f+ssDJxMlEF6i2aEUFgIAcJwhSNl22+A0SRmkez6J vtcIkkpbWIZg+TfEMmSlIUKc3F1onrvAvcaIljDnfjGd/6kITCUrO/msO+AU2NMq TCz/qUm/BRN6ydMA2Z6X =6riE -----END PGP SIGNATURE----- --Apple-Mail=_54BEC365-D7EA-4BB3-9A36-4A47310B6A71-- From nobody Thu Jun 30 08:14:20 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586D512B04A for ; Thu, 30 Jun 2016 08:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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 UAkd-IM3DDHI for ; Thu, 30 Jun 2016 08:14:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 8599A12B004 for ; Thu, 30 Jun 2016 08:14:16 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5UFDw9f002365; Thu, 30 Jun 2016 11:14:16 -0400 Received: from flpi408.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0048589.ppops.net-00191d01. with ESMTP id 23w5cd0wfd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jun 2016 11:14:15 -0400 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5UFEFuO010569; Thu, 30 Jun 2016 08:14:15 -0700 Received: from flpi489.ffdc.sbc.com (flpi489.ffdc.sbc.com [130.4.162.183]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5UFE9SF010497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jun 2016 08:14:09 -0700 Received: from CAFRFD1MSGHUBAG.ITServices.sbc.com (CAFRFD1MSGHUBAG.itservices.sbc.com [130.4.169.164]) by flpi489.ffdc.sbc.com (RSA Interceptor); Thu, 30 Jun 2016 15:14:01 GMT Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.81]) by CAFRFD1MSGHUBAG.ITServices.sbc.com ([130.4.169.164]) with mapi id 14.03.0294.000; Thu, 30 Jun 2016 08:14:00 -0700 From: "DRUTA, DAN" To: Watson Ladd Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qDJaoOPZVnZsEKYiUtwZTqjnKACO70AgABHOYD//49I8IAAf5KA//+LN0A= Date: Thu, 30 Jun 2016 15:14:00 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F474487723D713C@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.161.219.255] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606300145 Archived-At: Cc: Brian Trammell , "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:14:18 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXYXRzb24gTGFkZCBbbWFpbHRv OndhdHNvbmJsYWRkQGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSnVuZSAzMCwgMjAxNiA4 OjA2IEFNDQpUbzogRFJVVEEsIERBTg0KQ2M6IEVnZ2VydCwgTGFyczsgQnJpYW4gVHJhbW1lbGw7 IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUVVJQ10gTmV0d29yayBQYXRoIFJlcXVpcmVt ZW50cyBmb3IgUVVJQw0KDQpPbiBUaHUsIEp1biAzMCwgMjAxNiBhdCA3OjQ2IEFNLCBEUlVUQSwg REFOIDxkZDU4MjZAYXR0LmNvbT4gd3JvdGU6DQo+IExhcnMsDQo+DQo+IEJyaWFuIGNvdmVyZWQg c29tZSB0aGUgcmVhc29uaW5nIHRvIGV4cGxvcmUgZW50ZXJwcmlzZSB1c2UgY2FzZXMgaW4gZGV0 YWlsLg0KPiBXaGF0J3MgaW1wb3J0YW50IGlzIHRvIHVuZGVyc3RhbmQgYW5kIGNhcHR1cmUgdGhl IHJlYXNvbnMgd2h5IElUIEFkbWluaXN0cmF0b3JzIGFyZSBibG9ja2luZyBVRFAuIFNvbWUgYXJl IGFzIHlvdSBwb2ludGVkIG91dCBub3QgcmVsYXRlZCB0byB0aGUgdGVjaG5vbG9neSBidXQgd2Ug bmVlZCB0byBtYWtlIHN1cmUgdGhleSBnZXQgdGhlIHJpZ2h0IGxldmVsIG9mIG1hbmFnZWFiaWxp dHkgd2l0aCBRVUlDIGluIG9yZGVyIHRyb3VibGVzaG9vdGluZyBsZWdpdGltYXRlIHRyYWZmaWMg YW5kIHByZXZlbnQgYXR0YWNrcy4NCg0KU28gaW5pdGlhbCBlbWFpbHMgYXJndWVkIHRoYXQgd2Ug bmVlZCBhbiBleHBvc2VkIGNvbnNlbnQgbWVjaGFuaXNtIHRvDQplbmFibGUgY29ubmVjdGlvbiB0 cmFja2luZyBmb3IgRE9TIHByZXZlbnRpb24uIEJ1dCBRVUlDIGFscmVhZHkgaGFzDQpET1MgcHJl dmVudGlvbiB0ZWNobmlxdWVzOiB0aGUgc2VydmVyIGNhbiB0ZWxsIGNsaWVudHMgdG8gIkdPIEFX QVkgQU5EDQpXSEVOIFlPVSBDT01FIEJBQ0sgUVVPVEUgTUUiLiAgT2YgY291cnNlIG1pZGRsZWJv eCB2ZW5kb3JzIGhhdmUgYW4NCmluY2VudGl2ZSB0byBwcmV0ZW5kIHRoaXMgaXNuJ3QgdGhlIGNh c2UsIGFuZCBsb2FkIGJhbGFuY2VyIHZlbmRvcnMNCmNhbiBpbnNpc3QgdGhhdCBjb25uZWN0aW9u IHRyYWNraW5nIGlzIGVzc2VudGlhbCAoaW5zdGVhZCBvZiBzb21ldGhpbmcNCm11Y2ggbW9yZSBj bGV2ZXIgeW91IGNhbiBkbyB3aXRoIFFVSUMgYW5kIG5vdCBUTFMpLCBldGMuIEJ1dCB0aGUNCnJl YWxpdHkgaXMgUVVJQyBpcyB3b3JraW5nIHRvZGF5Lg0KDQpJJ20gbm90IGFyZ3VpbmcgaWYgaXQg ZG9lcyBvciBpdCBkb2Vzbid0LiBJJ20ganVzdCBzYXlpbmcgdGhhdCB1c2UgY2FzZXMgZHJpdmUg cmVxdWlyZW1lbnRzIGFuZCByZXF1aXJlbWVudHMgbWFwIHRvIGNhcGFiaWxpdGllcyB0aGF0IGFy ZSBpbXBsZW1lbnRlZCBpbiB0aGUgcHJvdG9jb2wuDQpJJ20gc3VyZSBjbGV2ZXIgdGhpbmdzIGNh biBiZSBkb25lLiBIb3cgdG8gbWFrZSBjbGV2ZXIgdGhpbmdzIHRoYXQgd29yayBpbiBhbiBpbnRl cm9wZXJhYmxlIHdheSBmb3IgYSBtYWpvcml0eSBvZiB0aGUgc3Rha2Vob2xkZXJzIGlzIHRoZSBo YXJkIHBhcnQuDQoNClJlZ2FyZHMsDQpEYW4NCg0KPg0KPiBSZWdhcmRzLA0KPiBEYW4NCj4NCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRWdnZXJ0LCBMYXJzIFttYWlsdG86 bGFyc0BuZXRhcHAuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAzMCwgMjAxNiA3OjEyIEFN DQo+IFRvOiBCcmlhbiBUcmFtbWVsbA0KPiBDYzogRFJVVEEsIERBTjsgcXVpY0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW1FVSUNdIE5ldHdvcmsgUGF0aCBSZXF1aXJlbWVudHMgZm9yIFFVSUMN Cj4NCj4gSGksDQo+DQo+IE9uIDIwMTYtMDYtMzAsIGF0IDExOjU3LCBCcmlhbiBUcmFtbWVsbCA8 aWV0ZkB0cmFtbWVsbC5jaD4gd3JvdGU6DQo+Pj4gT24gMzAgSnVuIDIwMTYsIGF0IDA5OjI2LCBF Z2dlcnQsIExhcnMgPGxhcnNAbmV0YXBwLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBTZWNvbmQsIGxp bWl0aW5nIG9yIGJsb2NraW5nIFVEUCBpbiBlbnRlcnByaXNlIGVudmlyb25tZW50cyBpcyBhIG1h bmFnZW1lbnQgZGVjaXNpb24gYnkgdGhlIElUIGRlcGFydG1lbnQsIGFuZCBub3Qgc29tZXRoaW5n IHRoYXQgaXMgZHVlIHRvIHRoZSB0ZWNobm9sb2d5IHVzZWQuIE5vcm1hbCBOQVRzIGluIGVudGVy cHJpc2UgZW52aXJvbm1lbnRzIHdpbGwgcGFzcyBRVUlDIGp1c3QgZmluZS4NCj4+DQo+PiBJIHRo aW5rIHN1YnRseSBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2YgImp1c3QgZmluZSIgaGVyZSBpcyB3 aGVyZSB0aGlzIGRpc2N1c3Npb24gaXMgZ2V0dGluZyBzdHVjay4gSSB3YW50IHRvIHVucGFjayB0 aGlzIHBhcnQgYSBiaXQ6DQo+Pg0KPj4gIlVEUCBibG9ja2luZyBpcyBhIHBvbGljeSBkZWNpc2lv biIgaXMgYSBzdGF0ZW1lbnQgSSdsbCBhY2NlcHQgYXMgdHJ1ZTogaXQncyBoYXJkIHRvIG1lYXN1 cmUsIGJ1dCBpdCBzZWVtcyByZWFzb25hYmxlLg0KPj4NCj4+ICJVRFAgbGltaXRzIGFyZSBub3Qg ZHVlIHRvIHRoZSB0ZWNobm9sb2d5IjogYWxsIHRoZSBtZWFzdXJlbWVudCB3ZSd2ZSBkb25lLCBh bmQgYWxsIEkndmUgc2VlbiByZXN1bHRzIGZyb20gb3RoZXJzLCBpbmRpY2F0ZXMgdGhpcyBpcyBh bHNvIHRydWUuIFRoZSBsYWNrIG9mIG1pZGRsZWJveGVzIHRoYXQgSnVzdCBXYW50IFRvIEhlbHAg VURQIHRyYWZmaWMgZXZlbiBzZWVtcyB0byBtYWtlIFVEUCB3b3JrIGJldHRlciBvbiBzb21lIHBh dGhzLg0KPj4NCj4+IElmIGJ5ICJqdXN0IGZpbmUiIHlvdSBtZWFuICJpbiB0aGUgZGVmYXVsdCBj b25maWd1cmF0aW9uIFVEUCB0cmFmZmljIHBhc3NlcyB3aXRoIHRoZSBzYW1lIHByb2JhYmlsaXR5 IGFzIFRDUCB0cmFmZmljIiwgeWVzLCB0aGF0IGNlcnRhaW5seSBzZWVtcyB0byBiZSB0aGUgY2Fz ZS4NCj4NCj4geWVwLCB0aGF0IGlzIHdoYXQgSSBtZWFudC4gVGhhbmtzIGZvciBwdXR0aW5nIGl0 IGludG8gY2xlYXJlciB3b3Jkcy4NCj4NCj4+IFRoZSBvcmRlciBvZiBtYWduaXR1ZGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIGRlZmF1bHQgVURQIGFuZCBUQ1AgaWRsZSB0aW1lb3V0cyBvbiBOQVRzLCBo b3dldmVyLCByZW1haW5zIGEgY2F1c2UgZm9yIGNvbmNlcm47IGZvciBwZXJzaXN0ZW50IGNvbm5l Y3Rpb25zIHdpdGggdW5sdWNreSBkZWxheXMsIHRoaXMgd2lsbCB3b3JrIGxlc3MgImp1c3QgZmlu ZSIuIFRoaXMgaXMgYSBwYXJ0aWN1bGFyIGluc3RhbmNlIG9mIHRoZSBnZW5lcmFsIHByb2JsZW1z IGNhdXNlZCBieSBtYWtpbmcgdHJhbnNwb3J0IHN0YXRlIG9wYXF1ZS4NCj4+DQo+PiBGb3IgSDIg b3ZlciBRVUlDLCBzZW5kaW5nIFBJTkcgZnJhbWVzIGV2ZXJ5IHRoaXJ0eSBzZWNvbmRzICJmaXhl cyIgdGhpcyBwcm9ibGVtLCBmb3Igbm9uemVybyBjb3N0OyB0aGVyZSBhcmUgSSdtIHN1cmUgc21h cnRlciB3YXlzIG9mIGRvaW5nIHRoaXMuIE9yIG1heWJlIFFVSUMgZGVjaWRlcyB0byBtYXJrIGFu eSBwYXRoIG9uIHdoaWNoIGl0IGhhcyBzZWVuIHN0YXRlIGxvc3MgYXMgYmFkIGZvciBhIHdoaWxl IGFuZCBmYWxscyBiYWNrIHRvIFRDUC4gQnV0IHRoZSBXRyB3aWxsIGhhdmUgdG8gbWFrZSBhIGRl Y2lzaW9uIGhvdyB0byBoYW5kbGUgdGhpcyBzcGVjaWZpYyBzdGF0ZS4NCj4NCj4gQ29ycmVjdDsg d2UgbWVhc3VyZWQgdGhpcyBmb3IgdGhlIElNQyBzdHVkeSBhbmQgSSdkIGJlIHNob2NrZWQgaWYg aXQgaGFzIGdvdHRlbiBiZXR0ZXIuDQo+DQo+IE15IGJlbGllZiAoc2luY2UgSSBkb24ndCBoYXZl IGRhdGEpIGlzIHRoYXQgc3VjaCBtaWRkbGVib3hlcyBpbmNvcnJlY3RseSBhc3N1bWVkIHRoYXQg VURQIHdhcyBqdXN0IGJlaW5nIHVzZWQgZm9yIEROUywgYW5kIHRoYXQgc2hvcnRlciB0aW1lb3V0 IGFyZSB0aGVyZWZvcmUgT0suIFRoaXMgaXMganVzdCBhbm90aGVyIGV4YW1wbGUgb2YgbWlkZGxl Ym94IHZlbmRvcnMgbWFraW5nIHdyb25nIGFzc3VtcHRpb25zLg0KPg0KPiAoQW5kIC0gcGV0IHBl ZXZlIC0gdGhlcmUgaXMgcmVhbGx5IG5vIG5lZWQgZm9yIGJpbmRpbmcgdGltZW91dHMgZm9yIFRD UCBvciBVRFAgdG8gYmVnaW4gd2l0aC4gTm8gYmluZGluZyBuZWVkcyB0byBiZSB0aW1lZCBvdXQg dW50aWwgdGhlIG1pZGRsZWJveCBydW5zIG91dCBvZiBtZW1vcnksIGJlY2F1c2UgYXMgbG9uZyBh cyB0aGVyZSBhcmUgc3VmZmljaWVudCByZXNvdXJjZXMsIHdoeSBib3RoZXIgbWFuYWdpbmcgYWxs IHRoZXNlIHRpbWVvdXRzPyBJZiBhIG1pZGRsZWJveCBydW5zIG91dCBvZiByZXNvdXJjZXMsIGl0 IG5lZWRzIGEgbWVjaGFuaXNtIC0gTFJVLCBldGMuIC0gdG8gZnJlZSByZXNvdXJjZXMsIGkuZS4s IHJlbW92ZSBiaW5kaW5ncywgYW55d2F5LiBTbyBlbmZvcmNpbmcgdGltZW91dHMganVzdCBtYWtl cyB0aGluZ3MgbW9yZSBjb21wbGljYXRlZCB3aXRob3V0IGFjdHVhbGx5IG1ha2luZyBhbnl0aGlu ZyBiZXR0ZXIuIENvbXBhcmUgdGhpcyB3aXRoIHByb2Nlc3NlcyBvbiBvcGVyYXRpbmcgc3lzdGVt cywgdGhleSBhcmVuJ3QgYmVpbmcga2lsbGVkIGVpdGhlciBqdXN0IGJlY2F1c2UgdGhleSBoYXBw ZW4gdG8gc2xlZXAgYSBsb3Q7IGF0IGxlYXN0IHVudGlsIHRoZSBPUyBydW5zIG91dCBvZiByZXNv dXJjZXMsIGFuZCB0aGVuIGFsbCBiZXRzIGFyZSBvZmYgYW55d2F5IGluIHRlcm1zIG9mIHdoYXQg Z2V0cyBraWxsZWQgYW5kIHdoYXQgZG9lc24ndC4pDQo+DQo+IFRoZXJlIGlzbid0IGFueXRoaW5n IFFVSUMgY2FuIGRvIHRvIGJldHRlciBwYXNzIHRocm91Z2ggdGhlc2UgZXhpc3RpbmcgbWlkZGxl Ym94ZXMgLSB0aGV5IG5lZWQgdG8gYmUgdXBncmFkZWQuDQo+DQo+Pg0KPj4+IElmIGl0IGRvZXNu J3QgcGFzcywgaXQncyBiZWNhdXNlIGl0IGhhcyBiZWVuIGFkbWluaXN0cmF0aXZlbHkgZGlzYWJs ZWQuDQo+Pg0KPj4gV2UgY2FuIG1ha2UgdGhhdCBhc3N1bXB0aW9uIGFuZCBtb3N0IG9mIHRoZSB0 aW1lIGl0IGhvbGRzLg0KPj4NCj4+IEJ1dCwgbGFyZ2VyIHRoYW4gYW5kIHNlcGFyYXRlIGZyb20g dGhlIGJsb2NraW5nL3RpbWVvdXQgaXNzdWUsIHRoZSByZWFzb24gSSBzdWdnZXN0ZWQgdGhlIHdv cmQgImRpYWdub3NhYmlsaXR5IiBpbiBteSBQUiBpcyAid2hhdCBoYXBwZW5zIHdoZW4gaXQgZG9l c24ndCIuIFJpZ2h0IG5vdywgdGhlIHN0YXRlIG9mIHRoZSBhcnQgaW4gZmlndXJpbmcgb3V0IHdo YXQncyBoYXBwZW5pbmcgd2l0aCBhIGdpdmVuIFRDUCBjb25uZWN0aW9uIGlzLCBpbiBtb3N0IGVu dmlyb25tZW50cyBJIGtub3cgb2YsIHBlZXJpbmcgYXQgaXQgZm9yIGEgd2hpbGUgaW4gV2lyZXNo YXJrLiBBIG5ldHdvcmsgYWRtaW4gc2hvdWxkIGJlIGFibGUgdG8gZG8gYXQgbGVhc3QgdGhhdCB3 ZWxsIHdoZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCdzIGhhcHBlbmluZyB3aXRoIGEgUVVJ QyBjb25uZWN0aW9uLg0KPg0KPiBTdXJlLiBCdXQgdGhhdCBzb3VuZHMgbW9yZSBsaWtlIHRoYXQg d2UgbmVlZCBhIHdpcmVzaGFyayBkaXNzZWN0b3IgZm9yIFFVSUMsIHdoaWNoIGFjdHVhbGx5IGFs cmVhZHkgZXhpc3RzOiBodHRwczovL3d3dy53aXJlc2hhcmsub3JnL2RvY3MvZGZyZWYvcS9xdWlj Lmh0bWwNCj4NCj4gTGFycw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBRVUlDIG1haWxpbmcgbGlzdA0KPiBRVUlDQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYw0KDQoNCg0KLS0gDQoiTWFu IGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMgaW4gY2hhaW5zIi4NCi0tUm91c3Nl YXUuDQo= From nobody Thu Jun 30 08:21:50 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECE312DAA2 for ; Thu, 30 Jun 2016 08:21:48 -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 eR4mtQggnqdl for ; Thu, 30 Jun 2016 08:21:46 -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 83B2C12DAA1 for ; Thu, 30 Jun 2016 08:21:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,552,1459839600"; d="asc'?scan'208";a="120509398" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 30 Jun 2016 08:21: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; Thu, 30 Jun 2016 08:21:22 -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 08:21:22 -0700 From: "Eggert, Lars" To: "DRUTA, DAN" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qC2EnDpyDuvnE+IfLnz6AoxiKACO70AgABHNQCAAAltAIAACdSA Date: Thu, 30 Jun 2016 15:21:21 +0000 Message-ID: <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> In-Reply-To: <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.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.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_8392A380-F2B4-4703-ACEE-4E10CDA7DFA7"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Brian Trammell , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:21:48 -0000 --Apple-Mail=_8392A380-F2B4-4703-ACEE-4E10CDA7DFA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2016-06-30, at 16:46, DRUTA, DAN wrote: > What's important is to understand and capture the reasons why IT = Administrators are blocking UDP. Some are as you pointed out not related = to the technology but we need to make sure they get the right level of = manageability with QUIC in order troubleshooting legitimate traffic and = prevent attacks. again: why? We're talking about less than 10% of the paths, and HTTPS = over TCP readily available as an alternative on those paths, supposedly = with all the manageability that IT admins need. My personal viewpoint is that I wouldn't want to complicate the protocol = or even slightly weaken its security for such a small subset of paths = (some of which may end up unblocking UDP port 443 anyway.) I'd be open = to the WG reviewing concrete proposals someone may have in this space = once the WG is underway, but I wouldn't want to see charter text making = it a requirement for QUIC to do anything about such paths, since we = really don't know what fulfilling this requirement may actually entail. Lars --Apple-Mail=_8392A380-F2B4-4703-ACEE-4E10CDA7DFA7 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----- iQIcBAEBCAAGBQJXdTjxAAoJEFS1wwm/cMFXrwUP/RJav83qHLmx/V/Z9RHCXOKS KHClyNfK4DKAsB2Au5HXsCsrXFV/BaHB1cJTbNCuHQUXMHSz9/yt9CUQsWzAQK9e Q+1O7dT6IR2e86qvCgoQZa6cK08Ze7qP1K/HlwRTiariZGLe0YnG/L0djwJM1KB+ ESkbxULseBe1rgGd1vOjAmtWOWozJlEPw0AX5w2wSFf51hkLrpctQwjHlgsNwa+U jg5pBIs0O4y43BiiivCOKcniBHodBlpYyPXytSf4NGXSiG3L99lrlONs8d4vVa52 K5KaD66PWN6WBOqQpcq/kafoT7V68N/mC1CRYo8GgenN01Q9G4nkbNVW/McXdKif bArTpTiLLceFRYDCIhugzH5o8voALJEPk0ox5KX7swuUnQrenkoeeHFVWEpDPvGW n9wRZUnNMUo/PbeVUhaPl5hwY4Oy2q1wuQkUQFQD8jdZHu+bt7blUspsWtTTkiMN QF1IAD6m5TTwXb/HyTJBtwLxtRVMGz2D6tr2B5xJ+dqBoQOvEeg4//eQTMm5l3GE Y6q0J8nzA9DqPA7kPOWrVypyl081hzSkOfLNrv0vMp5ouvqJWNOB9kS7aZOZ+xY6 8S1NhvY78mvWIyYF6edkxeXFlova0Flrn+A93AmnSjSq5fpm8AfwpBatbpxU3647 yRQUEs4ZRz/E4pRjZFQS =30mE -----END PGP SIGNATURE----- --Apple-Mail=_8392A380-F2B4-4703-ACEE-4E10CDA7DFA7-- From nobody Thu Jun 30 09:35:06 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A89812D097 for ; Thu, 30 Jun 2016 09:35:04 -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 Lx6BNZlX_z0x for ; Thu, 30 Jun 2016 09:35:02 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 8626912B036 for ; Thu, 30 Jun 2016 09:35:02 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r2so72947937oih.2 for ; Thu, 30 Jun 2016 09:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wZYuHE+nNwO4H9Kn4tKXDHye7JJ9ALXguAYEoWMZvO0=; b=CDoN6Ed92XF/sCnXdlC/dKi+X1dEJVO0du/SPJE+9fvaxLfalOrpZ/2GO0r44A48ah S4IM/YlzmHhsafWCgSbXrygb8dRGP+xVFMQa39qokgcZvAsO1CbN7YtezI9VqDqq17OJ YGh7LSrsfDH9d+rjr0hii+xHibOXmdkmSQgiDeOVc0p9ZeDrnEdiw0iRVR41uNnDMsU7 QO+uPjbRzwXvkyf5XNdeTO/Fph6+HMkkDkgTh/5/oZsj/DsPatxFiMSr6derciRfI/y/ Q7PU7qONZv+lxl+vSot3leh/gQ7w1//gJViEym1LDven3eMDeT9UEVd/Q/HqsjV2449K erIw== 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=wZYuHE+nNwO4H9Kn4tKXDHye7JJ9ALXguAYEoWMZvO0=; b=QvqBYRALaJTg4zCdoS8DeJuSMdRpCrtIXiD/RkIfdXPMMorM80VWvLQu2L34U1RTX/ Kg9QXldvKCLaPGBffvflSMXKoh23efwXw2CT5WFQ90cB1fc+E1yr1RQCayylQbbdLyi/ +ob/g5xDdHHakWtFDRU2kU0I+hrWPXlz3eeWYJYipCuRGJoyVLhdPNzt/IzRQx9Cx3zI uIov7XBmDN6xJRI0U2YzeUR5SVjJM68+Yq8pEOWJ/9+Wvy4lZDeoG3eoCLROPH/W3WxV qtQsK93DUgjYg43UwFdbHLWBO3KvM3qhZnbLJQHPqSX6aQdaH8645AGxdDFoMQm0d2e2 /vMw== X-Gm-Message-State: ALyK8tKKymQcOD+Adi94EjryEJ+v61zucL8+yluvbx1pNLgGLaCjmbjWQmb9WgUDyK2vYaMg2pZw40EOQH79Pg== X-Received: by 10.202.96.137 with SMTP id u131mr6096844oib.71.1467304501820; Thu, 30 Jun 2016 09:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Thu, 30 Jun 2016 09:34:32 -0700 (PDT) In-Reply-To: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> From: Ted Hardie Date: Thu, 30 Jun 2016 09:34:32 -0700 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a113d5fbe9bc69c05368173bf Archived-At: Cc: Brian Trammell , "quic@ietf.org" , "DRUTA, DAN" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:35:04 -0000 --001a113d5fbe9bc69c05368173bf Content-Type: text/plain; charset=UTF-8 On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars wrote: > (And - pet peeve - there is really no need for binding timeouts for TCP or > UDP to begin with. No binding needs to be timed out until the middlebox > runs out of memory, because as long as there are sufficient resources, why > bother managing all these timeouts? ) > If I understand this correctly, this is largely because many of these are NAT+FW boxes which combine the binding and the firewall permission; leaving them up for long periods of time leaves the pinhole up. If you really relied on state exhaustion, it might never happen at all for small networks. Eliminating the firewall permission to receive traffic and leaving the binding to send would be odd, so they don't. Joe H. might well be able to get you better and fersher data, but that's why I think the timers were put in in the first place. Ted --001a113d5fbe9bc69c05368173bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars <lars@netapp.= com> wrote:
(And - pet peeve - there is really n= o need for binding timeouts for TCP or UDP to begin with. No binding needs = to be timed out until the middlebox runs out of memory, because as long as = there are sufficient resources, why bother managing all these timeouts? <= ;snip>)

If I = understand this correctly, this is largely because many of=C2=A0 these are = NAT+FW boxes which combine the binding and the firewall permission; leaving= them up for long periods of time leaves the pinhole up.=C2=A0 If you reall= y relied on state exhaustion, it might never happen at all for small networ= ks.=C2=A0 Eliminating the firewall permission to receive traffic and leavin= g the binding to send would be odd, so they don't.

Joe H. might well be able to get you better and fersher= data, but that's why I think the timers were put in in the first place= .

Ted




--001a113d5fbe9bc69c05368173bf-- From nobody Thu Jun 30 09:43:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C33612D124 for ; Thu, 30 Jun 2016 09:43:02 -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 cktqx0PJ706r for ; Thu, 30 Jun 2016 09:43:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FC212D0B7 for ; Thu, 30 Jun 2016 09:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5599; q=dns/txt; s=iport; t=1467304980; x=1468514580; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZZCt4UO3u2DF+hsa+FNZuxVtBLasUw5DTVd7JXT7D+c=; b=XFoK/GgCBwfJ5RFacUhaBA7BN2SI4dddd9NGBdIZx4fTLa8+ASTWIRtd U5rXSsry8joxDFVd1zmsmUcfXtTTwckVTx08jcMnL/giGppM4ZkkjLCeB +IcvjiqZiKLBdDKIXWQBERbS2SDIOhPBwpU2J/ddDhOyz7ajDcGye83XX g=; X-Files: signature.asc : 495 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAgDuSnVX/5NdJa1bgz5WfQa3OIIPg?= =?us-ascii?q?Xwigj6DNwKBOzgUAQEBAQEBAWUnhEwBAQEDAXkFCwIBCBguMiUCBA4FDhCICgg?= =?us-ascii?q?Ow0UBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWGKIF3glaHbIIvBYgZkHIBgy2Bb?= =?us-ascii?q?G6CeoU/gWqNQIZViS8BHjaCAwUcgUxuiEJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,553,1459814400"; d="asc'?scan'208";a="291389682" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2016 16:42:59 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5UGgw59008025 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Jun 2016 16:42:59 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Jun 2016 12:42:58 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 30 Jun 2016 12:42:58 -0400 From: "Joe Hildebrand (jhildebr)" To: "Eggert, Lars" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qGNJsGpNQB40EWqiuBvsm2ewqACCXAAgABHOYCAAAlqAIAACdSAgAAWywA= Date: Thu, 30 Jun 2016 16:42:58 +0000 Message-ID: <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> In-Reply-To: <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: multipart/signed; boundary="Apple-Mail=_8766AE56-3EBE-4F1B-9DF4-F97A8CCD8E3A"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , Brian Trammell Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:43:02 -0000 --Apple-Mail=_8766AE56-3EBE-4F1B-9DF4-F97A8CCD8E3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 30, 2016, at 9:21 AM, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2016-06-30, at 16:46, DRUTA, DAN wrote: >> What's important is to understand and capture the reasons why IT = Administrators are blocking UDP. Some are as you pointed out not related = to the technology but we need to make sure they get the right level of = manageability with QUIC in order troubleshooting legitimate traffic and = prevent attacks. >=20 > again: why? We're talking about less than 10% of the paths, and HTTPS = over TCP readily available as an alternative on those paths, supposedly = with all the manageability that IT admins need. We're talking about less than 10% of the paths that were measured by one = experiment. I don't yet know how reproducible that is. Again, it's = 100% of the flows on my network, and on that of many other enterprise = networks where I have deployed software in the past. I guarantee that we will deploy new software for our firewall if it's = possible to do so in a way that we don't have to update for every = newly-popular version number that someone in the QUIC world decides to = deploy. > My personal viewpoint is that I wouldn't want to complicate the = protocol or even slightly weaken its security for such a small subset of = paths (some of which may end up unblocking UDP port 443 anyway.) If QUIC was only ever going to be used on 443/udp, some of the detection = issues would be easier. Right now, the prototype code I've seen for the = QUIC state tracker hardcodes individual version numbers to look for the = traffic that needs to be tracked - but the developer is just trying to = intuit what he's supposed to do from what has been written so far. I don't think anyone has proposed weakening QUIC's security yet. If = they did, the working group should have a thoughtful discussion of the = tradeoffs involved, and I would expect security to win out almost every = time. It may be that certain security measures could be implemented in = different ways to solve multiple problems, for instance. Mostly, I would like to see the assumptions that folks are making about = how the path might interact with the bits that are already explicitly = exposed to the path by the current protocol be discussed, then written = down. > I'd be open to the WG reviewing concrete proposals someone may have in = this space once the WG is underway, but I wouldn't want to see charter = text making it a requirement for QUIC to do anything about such paths, = since we really don't know what fulfilling this requirement may actually = entail. Brian's proposed text here: https://github.com/IETF-QUIC/Charter/pull/14/files says "This work will consider deployability, manageability and = diagnosability of the wire format, including how the wire format will be = processed by devices on path". I don't think that makes doing anything = for the path required, but it does make it possible to have the = conversation. If we're worried about this language requiring changes to = the protocol, rather than allowing for the conversation, we can of = course continue to tweak the language. =46rom a previous message of yours: > And - pet peeve - there is really no need for binding timeouts for TCP = or UDP to begin with. No binding needs to be timed out until the = middlebox runs out of memory, because as long as there are sufficient = resources, why bother managing all these timeouts? One of the reasons people give for this is the concern that traffic will = be allowed in from the outside to boxes and applications that are no = longer expecting the traffic. Since they believe that many older UDP = protocols don't have adequate security measures in place to = authenticate, authorize, or sessionize traffic, they just block it all = except for the protocols where they do deeper inspection, such as DNS. = It is not because these administrators are idiots, or because they have = misconfigured their boxes unintentionally. Many of the folks that block UDP *do* update their firewall software = often, and do review their security stance on blocked protocols = periodically. They will want their users to be able to take advantage = of the benefits of QUIC, so they will have incentives to do the review. = We need to at least provide them with the tools to do this review, such = as security considerations that tell an administrator how to continue to = protect their network from unknown UDP protocols while allowing QUIC. -- Joe Hildebrand --Apple-Mail=_8766AE56-3EBE-4F1B-9DF4-F97A8CCD8E3A 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 iQEcBAEBCAAGBQJXdUwQAAoJEPYNTJA0T1M0R9gH/1f6j80PItII/fs2343I/vk9 LWboxybw3mSx+Lgplme2sgh4d8HmcrUPkehfNS9RYCK3/cYxmg+hYgI7PY0DIdDi ZhV57eTTzbF+LwfxlZ0ZSdYSLy1LzjEwsy62Ii32zhlbwZIr+FIFF0r5tXP4Qrih 6XWc1Y1kiSrRn5PlgMpHkWkoY2CqmC+xhES8XJZ2kCM02Ol2yW7mfrdDW35XQqOp oqx3nFcsRU/3RTaWlwv1dWu01WI1SkrK+fLvtHT/l2QdpBvEEol6Tpsi3Uqn4+/M 16ln8qG/zjUmAAOFToXDuNWtS0I+0PiK+ceFj1iiByGD6OuZDE+dibt5dgc+KNk= =eBAa -----END PGP SIGNATURE----- --Apple-Mail=_8766AE56-3EBE-4F1B-9DF4-F97A8CCD8E3A-- From nobody Thu Jun 30 10:51:10 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE4D12D526 for ; Thu, 30 Jun 2016 10:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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 gt8SqLbQ6Hfm for ; Thu, 30 Jun 2016 10:51:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D663812D0B7 for ; Thu, 30 Jun 2016 10:51:06 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5UFTRLg014689; Thu, 30 Jun 2016 11:30:04 -0400 Received: from flpi408.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0049287.ppops.net-00191d01. with ESMTP id 23w5yfr7g0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jun 2016 11:30:04 -0400 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5UFU3Zw023422; Thu, 30 Jun 2016 08:30:03 -0700 Received: from flpi487.ffdc.sbc.com (flpi487.ffdc.sbc.com [130.4.162.181]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id u5UFTwZ5023294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jun 2016 08:29:59 -0700 Received: from CAFRFD1MSGHUBAA.ITServices.sbc.com (CAFRFD1MSGHUBAA.itservices.sbc.com [130.4.169.178]) by flpi487.ffdc.sbc.com (RSA Interceptor); Thu, 30 Jun 2016 15:29:54 GMT Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.81]) by CAFRFD1MSGHUBAA.ITServices.sbc.com ([130.4.169.178]) with mapi id 14.03.0294.000; Thu, 30 Jun 2016 08:29:54 -0700 From: "DRUTA, DAN" To: "Eggert, Lars" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qDJaoOPZVnZsEKYiUtwZTqjnKACO70AgABHOYD//49I8IAAg/WA//+LWtA= Date: Thu, 30 Jun 2016 15:29:53 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F474487723D720A@CAFRFD1MSGUSRJI.ITServices.sbc.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> In-Reply-To: <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.161.219.255] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606300147 Archived-At: Cc: Brian Trammell , "quic@ietf.org" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 17:51:09 -0000 > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Thursday, June 30, 2016 8:21 AM > To: DRUTA, DAN > Cc: Brian Trammell; quic@ietf.org > Subject: Re: [QUIC] Network Path Requirements for QUIC >=20 > Hi, >=20 > On 2016-06-30, at 16:46, DRUTA, DAN wrote: > > What's important is to understand and capture the reasons why IT > Administrators are blocking UDP. Some are as you pointed out not related = to > the technology but we need to make sure they get the right level of > manageability with QUIC in order troubleshooting legitimate traffic and > prevent attacks. >=20 > again: why? We're talking about less than 10% of the paths, and HTTPS ove= r > TCP readily available as an alternative on those paths, supposedly with a= ll the > manageability that IT admins need. >=20 > My personal viewpoint is that I wouldn't want to complicate the protocol = or > even slightly weaken its security for such a small subset of paths (some = of > which may end up unblocking UDP port 443 anyway.) I'd be open to the WG > reviewing concrete proposals someone may have in this space once the WG > is underway, but I wouldn't want to see charter text making it a requirem= ent > for QUIC to do anything about such paths, since we really don't know what > fulfilling this requirement may actually entail. >=20 I already said that for the charter I'm fine with the proposed text from Br= ian. > Lars =20 Regards, Dan From nobody Thu Jun 30 13:31:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F0712D59F for ; Thu, 30 Jun 2016 13:31:38 -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 oQ5Qdld61Ig4 for ; Thu, 30 Jun 2016 13:31:36 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6718712B017 for ; Thu, 30 Jun 2016 13:31:36 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id E46EA1A19D6; Thu, 30 Jun 2016 22:31:34 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_71A93BF2-2026-44A0-8D57-379CEA2C2F7A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Brian Trammell In-Reply-To: Date: Thu, 30 Jun 2016 22:31:34 +0200 Message-Id: <0DF92975-1C86-4B84-B71F-0FA1FED5A829@trammell.ch> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] Network Path Requirements for QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 20:31:39 -0000 --Apple-Mail=_71A93BF2-2026-44A0-8D57-379CEA2C2F7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30 Jun 2016, at 18:34, Ted Hardie wrote: >=20 > On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars wrote: > (And - pet peeve - there is really no need for binding timeouts for = TCP or UDP to begin with. No binding needs to be timed out until the = middlebox runs out of memory, because as long as there are sufficient = resources, why bother managing all these timeouts? ) >=20 > If I understand this correctly, this is largely because many of these = are NAT+FW boxes which combine the binding and the firewall permission; = leaving them up for long periods of time leaves the pinhole up. If you = really relied on state exhaustion, it might never happen at all for = small networks. Eliminating the firewall permission to receive traffic = and leaving the binding to send would be odd, so they don't. That makes sense, too. We're talking about "NATs" and "firewalls" as if = you could actually still buy or build a device that is capable of one = set of functionality but not the other. > Joe H. might well be able to get you better and fersher data, but = that's why I think the timers were put in in the first place. --Apple-Mail=_71A93BF2-2026-44A0-8D57-379CEA2C2F7A 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 iQIcBAEBCgAGBQJXdYGmAAoJEIoSt78L6kajZS4P/R2nVTIkx6mfZp7mSbgczH05 VXMNrPcoy+xaYvkG32KSOZgWfsIexUU7unb+dC3mMM8/URtVvrbCLPqbR25uWm2h 7BP0djnFjV2dYrBppf6RCHF5JwpaXvMgl3jVhDtcW3VBj/UXltdR00CnSORTD91L 5/TL1MJV/KsRq2AOg4kGP0oxhD2NXdnsX2rMQPigxjVIIhIQVeT+AjelSuhpDoUl W0jfzn8KOposFSyqVglek8rs3KC6jah6UeXIsVhSyZh2LnlIbUKEtPv0MnHQXY23 5JfD3FeTGrbfY8ttabvrmG17jzI9AEV4l89DhLwkBhof4LzBeX0n/naF5HlJIaJj 0B/ws3RmewBgIvjGiVW4J9petiUNs9wgfkLlHLvpbrdqd3gRiyttH0/7B/UyRX/i 460YjB6NEgDweZMfVDF2/qrBgpNTCVUZkI+YZF9jWqrBxEel4ug8lJb4IVzKqwpv bBupNglGet4VWQ/BBcj1bF7UtammjsBi4IbEK4rbsvIusattSA6qoYLo6yTdWyV9 Istcc4zI4lmYWrk86ouHO8M4jDorkYbYWyn+ie0hqY7NT3a0HYAJLvKnDKNrOMIq K6l0Upt9nBySVUnEw+AmbMsYSr7+oFBNP4E4MvWHyS3HDgF/WCpKC/FurHTsvxpQ xOg8IulECDrQWZoIe3Tm =KR4M -----END PGP SIGNATURE----- --Apple-Mail=_71A93BF2-2026-44A0-8D57-379CEA2C2F7A--